APPLIED: [Precise][Pull Request] SECCOMP mode 2, BPF

Will Drewry wad at
Tue Mar 27 22:02:53 UTC 2012

On Mon, Mar 26, 2012 at 9:21 PM, Tim Gardner <rtg.canonical at> wrote:
> On 03/23/2012 12:14 AM, Kees Cook wrote:
>> Hi,
>> On Thu, Mar 22, 2012 at 01:43:57PM -0500, Will Drewry wrote:
>>> On Thu, Mar 22, 2012 at 8:07 AM, Tim Gardner<tim.gardner at>
>>>  wrote:
>>>> On 03/21/2012 02:35 PM, Kees Cook wrote:
>>>>> On Wed, Mar 21, 2012 at 02:28:33PM -0600, Tim Gardner wrote:
>>>>>> Applied for now pending Leann's opinion. I've made a first pass
>>>>>> review.
>>>>>> Some of it is a bit dense. I'll have another look tomorrow.
>>>>> Thanks! I'm happy to field any questions about it, if that helps, and
>>>>> if I can't answer them, I'm sure Will can. :)
>>>> So I guess it got uploaded. How about a quick description of how to
>>>> utilize the seccomp filter?
>>>> [...]
>>>> In the meantime I guess I'll go read the seccomp patch to the
>>>> Documentation directory.
>>> If the docs can be made more coherent, I'm more than happy to change them
>>> up.
>> I've put together a little tutorial (with working code samples) on using
>> basic syscall filtering via seccomp filter here:
>> -Kees
> Kees - I've read through your tutorial. Thanks by the way for that. With
> regard to determining seccomp BPF functionality, do you think its sufficient
> to just test for one or two syscalls ? That will at least indicate that the
> seccomp subsystem is alive and functional. We could almost just use your
> example program for that.

In general, I think that's enough.  If you want, I finally finished
porting my organically developed tests into something a "little" bit
prettier and arch agnostic which might be useful:

I believe all the tests will pass for the patch series merged, except
for one, where I tightened the mask on the return values (in a
to-be-posted v17).  No userspace code ABI changes specifically, just
ensuring a hard cap on the highest BPF return value, so nothing scary

> Is there benefit to performing an exhaustive syscall filter test, or are all
> syscalls treated the same ?

Yup - the BPF is basically just a userspace API for syscall-time use
of syscall_get_number and syscall_get_arguments, and syscall_get_arch.
 So once you've grabbed one syscall number, you could've grabbed any
of them :)

The tests above don't explore all the argument edge cases,
architecture values, etc, but it covers a large amount of the ground
and fills in gaps where the kernel/samples/seccomp and Kees's tutorial
don't touch explicitly.


More information about the kernel-team mailing list