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.
> They are separate calls, separate functions, separate type
> definitions. None of this would affect previous code -- no one should
> "change" to the new 64 bit interface for any existing function.
>
> >
> > However, I think that this syscall should be implemented by passing a
> > pointer and using put_user() to return it to user space, at least on
> > 32-bit architectures.
> > Other 32-bit arches may not have multiple ways to
> > enter the kernel like the x86 does.
> ---
> Can you supply any facts to back up your FUD? Which
> 32-bit kernels couldn't implement a 64-bit interface
> The X86 code was approximately 12 lines of source code. Only
> 1 line of that was 'new' code (different from the 32 bit interface).
>
> Implementing a 64 bit return interface simply simplifies
> the kernel code -- no need for special casing for 32-bit archs in the
> mainline code. 32 or 64 bits is an *architecture* difference that
> shouldn't be kludged for in the mainline code. Architectural differences
> are supposed to be hidden in the architecture specific code. It
> sure makes the code *more efficient* on 64 bit architectures and on
> the ia32 as well. All of the 32 bit archs support a 64 bit return value
> in their C compilers. I'd lay odds that it's more efficient on every
> one of them than allocating a buffer, passing in a pointer and doing an
> indirect store.
>
> Why are you supporting special cases and complexity in the base
> line kernel code when its not necessary?
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:
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.
Of course, Linus has the final say in the matter. This is just my 2
cents.
--Brian Gerst
- 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