Re: seccomp for 2.6.11-rc4

[Andrea Arcangeli <andrea@cpushare.com>]

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.