I was curious about why the sys_security() system call got removed
and found the following rather long thread from LKML that shows what
led to this decision:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.2/0644.html
It looks to me like the main reason the syscall was removed has to do
with architectures in which the kernel executes in 64-bit mode and
user-space code may execute in 32-bit mode. I think x86_64, ia64,
and sparc64 is a comprehensive list of such architectures that are
supported by Linux; is this correct?
The basic problem, as I understand it, is that on such architectures
there is a layer of kernel code at the system call entry points that
converts syscall parameters to 64-bit values as appropriate (i.e. an
int may be a 32-bit value for user-space code and a 64-bit value for
the kernel). This code layer must deal with pointers to structs that
user-space code may pass as parameters, converting the layout of the
32-bit notion of a struct as seen by user-space code to the
corresponding layout for the same struct as seen by 64-bit kernel
code (and vice-versa for syscalls that fill user-space structs with
info from the kernel). For this to work, the code must know the
exact definitions of structs used for information exchange between
kernel and user-space code. Because sys_security() allowed modules
to define their own arbitratry system call APIs, there was no way for
the code to obtain this information. Is this a correct summary of
the problem?
I was thinking that this is the exact same problem that the original
developers of RPC had to overcome. Therefore it seems reasonable to
me that Linux could solve the problem using a marshalling technique
similar to that used by RPC. A user-space library and a
corresponding kernel module could be developed for
marshalling/unmarshalling system call parameters. Then developers of
LSM modules that wish to define their own system call API would do
the following:
- On the user-space side, a library containing system call stubs
for a given LSM module would be developed that links to the
marshalling/unmarshalling library.
- On the kernel side, the LSM module would use the functionality
provided by the marshalling/unmarshalling kernel module.
The marshalling/unmarshalling code would only need to be implemented
for the few architectures supported by linux in which the
32-bit/64-bit issue exists; and once it is implemented, all LSM
modules could make use of it. On the kernel side, my guess is that
the existing layer of code that deals with 32-bit/64-bit conversions
on architectures that need this may already provide essentially all
of the needed functionality (which could be exported so that LSM
modules may use it). Does this seem like a reasonable idea, or is
there something I'm missing?
Even if the above suggestion seems like a reasonable thing to do,
there is still the issue of getting the Linux kernel developers to
accept something like this. My guess is that this may be difficult
considering the amount of resistance there apparently was to even
getting the existing LSM interface into the kernel. Reading the
above-mentioned LKML thread, I suspect that those who argued in favor
of keeping sys_security() didn't want to argue their case too
strongly due to concern over possibly jeopardizing the chances of
getting -any- LSM changes into the mainstream kernel. Anyway, I
think it's great that at least something got in, even though it may
not be all that was originally hoped for.
--
Dave Peterson
dave_peterson@private
This archive was generated by hypermail 2.1.3 : Sun Apr 17 2005 - 20:23:08 PDT