Brian Gerst wrote:
>
> Linda Walsh wrote:
> >
> > Brian Gerst wrote:
> > > Do we really need another syscall interface for this? If we really do,
> > > then the syscall tables should be seperate. Otherwise, calling a 32-bit
> > > syscall with syscall64 leaves %edx with random data.
> > --
> > Why would someone randomly call a "C" function implemented
> > to return an 'int' as a 'long long'? 1) They must be running w/o type
> > checking turned on, and 2) it's just erroneous/bad code.
>
> 3) Code trying to get data from the kernel for possible exploitation.
> I'm not saying that it's very probable, but something could be leaked.
--- I still think this is a good idea...but> Have you looked at adding a 64-bit syscall to other 32-bit architectures > besides the x86? PPC and MIPS for example appear to have single > instructions to get into kernel mode ("sc" and "syscall" respectively). --- In thinking about this one, I don't want to clutter up the kernel unless there is a *need*. Basically, I need someone who's an expert for PPC/MIPS to tell me it is needed. Otherwise, I feel I should leave the call 'as is' and if the PPC/MIPS folks need the indirect code later on, it can be added to the common code. At this point, though, I don't see a need to clutter up the common code.
-l
-- Linda A Walsh | Trust Technology, Core Linux, SGI law@sgi.com | Voice: (650) 933-5338
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:09 EST