Re: [PATCH] remove sys_security

From: Crispin Cowan (crispinat_private)
Date: Fri Oct 18 2002 - 02:36:31 PDT

  • Next message: Andi Kleen: "Re: [PATCH] remove sys_security"

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

    _______________________________________________ linux-security-module mailing list linux-security-moduleat_private

    This archive was generated by hypermail 2b30 : Fri Oct 18 2002 - 02:37:36 PDT