Candidate replacement approach for seccomp_filter (no ftrace)

[Will Drewry]

On Fri, Jan 27, 2012 at 10:17 AM, Will Drewry <wad at chromium.org> wrote:
> On Fri, Jan 27, 2012 at 8:09 AM, Stefan Bader
> <stefan.bader at canonical.com> 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.
>>
>> 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.
>
> Most likely it is the gap between the last public post and what was
> pulled from the chromium-os tree.  In order to support the LXC case, I
> added inheritance for CAP_SYS_ADMIN processes, so I wouldn't be
> surprised if those fail.
>
> It also looks like CONFIG_FTRACE_SYSCALLS is not enabled on the above
> kernel either since all of the ftrace tests that should pass fail.
> I'd guess both of these issues are causing the failures.
>
>> 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?
>
> Yes! I just got "cross"-arch userspace tooling working last night. I
> am cleaning up the patch series and reposting today.  I hope that's
> not too late!  The biggest challenge is the no_new_privs patch.  I can
> either push up a version with seccomp_check_exec() again or I can
> leave it dependent on luto's no_new_privs if you think that will be
> picked up too.  Either way is fine for me.  (The seccomp_check_exec()
> is a quite small change.)
>
> Thanks!
> will
>
>>
>> -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

Looking at the oops, it appears to be in ftrace filter creation.  It's
possible that ftrace changes its internals in the middle of that
kernel roll and create_preds is walking off into space.  I can take a
look, if needed - let me know.

cheers!
will