Candidate replacement approach for seccomp_filter (no ftrace)

[Stefan Bader]

On 27.01.2012 15:09, Stefan Bader wrote:
> On 11.01.2012 18:31, Will Drewry wrote:
>> Hiya ubuntu kernel team,
>>
>> I've just posted a new round of seccomp_filter patches.  I'm taking a
>> wholly different tack which I think is both much saner than the
>> original patch series and is easier to maintain if upstream never
>> accepts it.  I'd certainly love your feedback and thoughts about
>> possible viability given that you were kind enough to pick up my
>> original patch series.  (I'm most certainly happy to help if I can to
>> avoid too much pain, but I realize there are no consumers of
>> seccomp_filter on ubuntu yet :)
>>
>> That aside, they have been sent to linux-kernel:
>>   marc.info/?l=linux-kernel&m=132630290817221&w=2
>>   marc.info/?l=linux-kernel&m=132630294217251&w=2
>>   marc.info/?l=linux-kernel&m=132630293217243&w=2
>>
>> Cheers!
>> will
>>
> Yesterday I got pinged about some potential regression on EC2[1]. Looking at the
> traces I saw seccomp code being the cause (this is the old patchset in 12.04
> Precise). Then I checked a bit more and found that this also seems to happen on
> older Precise kernels and actually on bare metal as well (64bit). Not sure
> whether this is triggered by changes to the qa regression test suite or just has
> been missed all the time.
> 

Darn, I wanted to add that the same old patchset in 11.10 Oneiric does not seem
to have any issues. The test succeeds there. So its probably some interaction
between changes from 3.0->3.2 that causes this. I did not go back too far but it
seemed in our 3.2.0-7.x to now.

-Stefan

> So I went ahead and reverted anything we had in precise that was labeled seccomp
> and picked the two patches Will had posted to LKLM. Having build a kernel with
> those and re-run the tests (Sidenote: any reason why befs is used for some
> subtest? Cause that is now in the extra modules package for virtual).
> Using that kernel I would not see any Oops but some of the subtests are failing.
> Now I am not sure this is because something is wrong in the patch or in the
> test. Could be just looking at a feature that is not (yet) implemented.
> 
> Given, the oops and that there is the new approach, I think we want to
> concentrate on the new set. The discussion about that was longer and I have not
> looked to closely. Will, is there already a newer version of this?
> 
> -Stefan
> 
> ======================================================================
> FAIL: test_110_seccomp_filter (__main__.KernelSecurityTest)
> seccomp_filter works
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "./test-kernel-security.py", line 1385, in test_110_seccomp_filter
>     shelltimeout(expected, ["./seccomp_tests"])
>   File "/home/ubuntu/qa-regression-test/testlib.py", line 1102, in __call__
>     result = self.function(*args, **kwargs)
>     self.assertEquals(expected, rc, msg + result + report)
> AssertionError: Got exit code 1, expected 0
> Command: './seccomp_tests'
> Output:
> PASS :: mode_one_ok
> PASS :: mode_one_kill
> PASS :: mode_one_ok
> PASS :: mode_one_kill
> PASS :: add_filter_too_long
> PASS :: mode_one_ok
> PASS :: mode_one_kill
> PASS :: add_filter_too_long
> PASS :: add_filter_too_short
> PASS :: mode_one_ok
> PASS :: mode_one_kill
> PASS :: add_filter_too_long
> PASS :: add_filter_too_short
> PASS :: add_filter_null
> PASS :: add_bool_apply
> PASS :: add_bool_apply_event
> Failed to enter mode 2: -1
> prctl: Bad address
> Read in:
> write: Bad address
> PASS :: mode_one_ok
> PASS :: mode_one_kill
> PASS :: add_filter_too_long
> PASS :: add_filter_too_short
> PASS :: add_filter_null
> PASS :: add_bool_apply
> PASS :: add_bool_apply_event
> FAIL :: add_bool_apply_fail
> FAIL :: add_bool_apply_get
> PASS :: add_bool_apply_add
> PASS :: add_bool_apply_drop
> FAIL :: add_bool_apply_drop_die
> PASS :: add_ftrace_apply
> FAIL :: add_ftrace_apply_fail
> FAIL :: add_ftrace_apply_get
> FAIL :: add_ftrace_apply_append_get
> PASS :: mode_one_ok
> PASS :: mode_one_kill
> PASS :: add_filter_too_long
> PASS :: add_filter_too_short
> write: Bad address
> PASS :: mode_one_ok
> PASS :: mode_one_kill
> PASS :: add_filter_too_long
> PASS :: add_filter_too_short
> PASS :: add_filter_null
> PASS :: add_bool_apply
> PASS :: add_bool_apply_event
> FAIL :: add_bool_apply_fail
> FAIL :: add_bool_apply_get
> PASS :: add_bool_apply_add
> PASS :: add_bool_apply_drop
> FAIL :: add_bool_apply_drop_die
> PASS :: add_ftrace_apply
> FAIL :: add_ftrace_apply_fail
> FAIL :: add_ftrace_apply_get
> FAIL :: add_ftrace_apply_append_get
> PASS :: mode_one_ok
> PASS :: mode_one_kill
> PASS :: add_filter_too_long
> PASS :: add_filter_too_short
> PASS :: add_filter_null
> PASS :: add_bool_apply
> PASS :: add_bool_apply_event
> FAIL :: add_bool_apply_fail
> FAIL :: add_bool_apply_get
> PASS :: add_bool_apply_add
> PASS :: add_bool_apply_drop
> FAIL :: add_bool_apply_drop_die
> PASS :: add_ftrace_apply
> FAIL :: add_ftrace_apply_fail
> FAIL :: add_ftrace_apply_get
> FAIL :: add_ftrace_apply_append_get
> FAIL :: add_drop_ftrace_proc
> FAIL :: keep_exec
> FAIL :: keep_exec_drop
> FAIL :: lose_exec
> 
> [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/921816
>