I'm not involved with the kernel coding, but I've been doing quite a bit of
user-land SE Linux development (and the first cut at strace support).
SE Linux has currently 52 system calls. One system call was added recently,
and other system calls may need to be added. SE Linux is still in a state of
development.
Now if every SE system call was to be a full Linux system call then LANANA
would be involved in the discussions every time that a new SE call was added,
which would not be desired by the SE Linux people or the LANANA people. So
this means having a switch statement for the different SE calls.
So if we accept that it's a maximum of one system call per security module,
then it's only a small step to do the same for LSM.
Do we expect that SE Linux or other security system calls will be such a
performance bottleneck that an extra switch or two will hurt?
> But this will require every security module project to petition for a
> syscall, which would be a pain, and is the whole point of having this
> sys_security call.
Also it would mean that developmental projects would be more difficult. If
you are doing some experimental coding that's not ready for release then
there might be a number of kernels released during the development cycle
before you petition for a number. In this case you may be forced to change
the syscall number if someone else gets the number you were working with.
Then when we share patches of experimental software there will be issues of
syscall conflicts. With the current LSM setup of a 2^32 LSM calls, you can
choose a number somewhat arbitarily and be fairly sure that it won't conflict
and that you can later register the same number with the LSM people.
-- 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- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/