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.
--- Z'ok. We add an XOR DX,DX @ the top of the syscall64 kernel call. Would that work for you?> > 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). > > My suggestion is to do this on 32-bit architectures: --- You are suggesting the below for the *common* code. This means it is also forced on the 64 bit architectures. I'm up for providing an alternate. sys_getaudit_id_indirect, that does what you want for those architectures that are too limited to allow an easy implementation of a 64 bit return value.
> asmlinkage int sys_getaudit_id(int id, long long *p) > { > long long res; > res = do_getaudit_id(id); > return put_user(res, p); > } > > and then let libc (which is also arch-dependent) handle the different > calling methods. --- And sys_getaudit_id could be a lib call on the 32-bit limited arch's to sys_getaudit_id_indirect.
Would those changes work for you?
-- 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