Re: [PATCH] remove sys_security

crispinat_private

Andi Kleen wrote:

>Crispin Cowan <crispinat_private> writes:
>  
>
>>Could you elaborate on why this is a sign of trouble, design wise?
>>    
>>
>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)
>
Thank you very much for clarifying.

>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.
>
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