On Wed, Feb 16, 2005 at 06:25:03AM +0100, Herbert Poetzl wrote: > hmm, just an idea, but have you thought about using > an indirect syscall table for your purposes? > > current->syscall_table > > and have a table for every 'mode' you want to use ...
That would add an additional level of indirection for every syscall (you'll have to potentially waste a cacheline to read the address of the syscall table). While my current approach is absolutely zero cost for the fast path on x86-64 and it's a mere s/movb/movw/ for x86 (i.e. zero for x86 too). Perahps I could even get away with a movb on x86 but frankly I didn't even try ;) My priority has been not to change the fast path at all, and clearly I have to add a bitflag to achieve that. And once I've the bitflag it's not worth it anymore to change the syscall table, and I can validate the syscall number right away (this avoid building arrays and other more complex stuff). > or maybe have a 'mask' for every syscall (in a > separate table) which describes the allowed 'modes' > > just because checking the syscall number in a loop > doesn't look very scaleable to me ... You're right about it being O(N) if you use it for all modes, but it's really O(1) since it's being used for mode 0 only, and the number of syscalls in mode 0 is fixed so it's O(1) and more important the number is so small that it's really like O(1) in practice too (and not only in math terms just because the number of syscalls in mode 0 is fixed ;). Each mode can implement the mask as it wishes, so if you were to allow hundred of syscalls in mode 1 then you'd better implement the check as a bitmask as you suggested and you can do that while implementing mode 1. But seccomp isn't designed to allow a ton of syscalls, so there can be tiny differences between mode 0/1/2 and they should all have very few syscalls, so I doubt it'd worth implementing the bitmask thingy right now. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
