remove sys_security

David refers to the 32bit emulation issues. Some ports have a 64bit kernel, but support 64bit and 32bit userland (e.g. ia64 or x86-64). Some ports even only have 32bit userland but 64bit kernel (like sparc64 or mips64)

The 32bit and the 64bit worlds have different data types. Structure layout are different. To handle this the kernel has an emulation layer that converts the arguments of ioctls and system calls between 32bit and 64bit.

This emulation layer sits at the 'edge' of the kernel. For example to convert an ioctl it first figures out the ioctl, converts it then reissues the same ioctl internally with 64bit arguments. When the ioctl returns outgoing arguments are converted too as needed.

For this to work all data structures need to be transparent. The emulation layer needs to have a way to figure out what and how to convert without looking at internal state in the kernel. Otherwise it cannot do its job.

Without working emulation sparc64 won't work and David will be unhappy.

-Andi

Thank you very much for clarifying.

I'm all for 64-bit support, and for easy transition from 32 to 64 bits. Really: I was around to watch the pain of transition from 16 bits to 32 bits, and I'm thrilled to see people taking the problem more seriously this time.

So: does it help to specify that the sys_security arguments be (say) "unsigned int"? Then you can just zero-pad them, or truncate them.

And even if the 32bit emulation layer doesn't perfectly translate the sys_security arguments: that just breaks LSM modules. It would not surprise me that something like an application trying to talk to a security module might not cleanly port from 32 to 64 bits. By carefully stating the assumptions (clean data types) most of these problems should be addressed.

I don't get why this is a hard problem.

Crispin

Yes that works fine.

But the problem is when people pass pointers to structures and copy_*_user them later. And they near always do. Structures need to be converted when they contain pointers or long long (on x86-64/ia64 long long has different alignment than ia32 long long)

The application does not need to be ported. That's the whole point of the emulation layer. Just the in kernel stuff needs to be.

You can specify clean data types. But it's very likely that eventually someone fucks up and adds something that needs to be translated (at least it's very likely with such an 'designed to be extensible' interface like you have)

And then having a basic design that makes translation impossible would be unfortunate.

-Andi

For such ports would we need to have security system calls operating in both 64bit and 32bit versions? For SE Linux half the programs that use the SE system calls are specific to SE Linux (loading policy, showing or toggling "enforcing mode", etc), the other half are modified versions of ls, ps, cron, login, and a few other important system programs.

I can't imagine why you would want to use a 32bit policy loading program on a 64bit SE kernel.

As for cron etc, is it going to be difficult to get those programs compiled for 64bit operation?

So for those ports we could have a straight 32bit interface and again have no problems.

Which is terribly ugly.

I agree with the point about not wanting to be converting between 32bit and 64bit for the LSM calls. However I am not certain that we need to support both 32bit and 64bit interfaces to LSM on the same platform.

http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

On most 64bit ports it is no big issue, just a nuisance. But sparc64 and mips64 don't have a 64bit userland, only 32bit. For these it is a showstopper.

So you want to maintain an own interface for sparc64? That's identical to an emulation layer effectively, but somewhat less maintainable.

-Andi

You'll only need to support it if you insist on keeping sys_security in the kernel ;)

Rik

Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://distro.conectiva.com/
Current spamtrap:  <a href=mailto:"[email protected]">[email protected]</a>

Why not let the security module supply the information about the struct layout?

I'm thinking of something roughly like stdarg.h, e.g.

    #include <linux/user_args.h>
    
    user_args args;

    user_args_start(&args, ptr);

where args is some variable where user_args can save internal state and ptr is the pointer to the struct from userland (which is translated appropriately to a kernel space pointer; maybe also a size argument might be handy, so that you can copy the struct from userspace memory to kernel memory at once instead of accessing user address space for every struct member individually), then

    struct.longlongmember = user_args_get(&args, long long);

which applies the right alignment, translates 32bit to 64bit etc. Due to complexity probably one wants to restrict that to a set of common types instead of making it full generic (and e.g. use something like user_args_get_longlong() instead of the type argument), but I don't think this would be a serious restriction (you can always extend it later if you really need another type to get through).

This wouldn't work on an architecture where members following later in a struct could affect the alignment of previous members, but are there any (sane) architectures around where this is the case? Personally I can't think of any reason why one possibly wanted to do that...

Andreas

       Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
     ---------------------------------------------------------
         +49 521 1365800 - [email protected] - www.devcon.net