On Thu, Aug 10, 2017 at 2:24 PM, Tyler Hicks <tyhi...@canonical.com> wrote:
> Hello - I'm working on some libseccomp patches to support new kernel
> filter flags (SECCOMP_FILTER_FLAG_LOG and maybe
> SECCOMP_FILTER_FLAG_KILL_PROCESS) and return actions (SECCOMP_RET_LOG)
> being discussed upstream. I've bumped into an issue with the libseccomp
> test suite and would like to get some direction on how to proceed.
I must apologize, I've seen your patches upstream but I haven't had a
chance to give them any sort of review.
> The problems stem from the (new) need for libseccomp to call the
> seccomp() syscall in order to verify that the kernel supports the new
> filter flags and new return action. The seccomp() syscall can already be
> used to verify that specific filter flags are supported and will likely
> soon get a new operation that allows the caller to check if a specific
> action is supported.
> The first problem is that the build tests may be running under an older
> kernel that doesn't support the new features. If specifying the new
> SECCOMP_RET_LOG as an action, seccomp_rule_add() could fail due to the
> kernel not supporting the action and there's no way in the current test
> infrastructure to handle that. Additionally, seccomp_attr_set() may fail
> when trying to set one of the new filter flags.
The good news is that we already have some provisions for runtime
checking of kernel capabilities, specifically the seccomp() syscall;
see src/system.c, sys_chk_seccomp_syscall() and
sys_chk_seccomp_flag(). I would need to better understand exactly how
the detection would work with your new patches, but I expect you could
do something similar.
> The second problem is with the valgrind tests. Valgrind doesn't wrap
> This means that the valgrind tests will always fail because libseccomp
> will see ENOSYS when attempting to verify that the kernel supports those
> new filter flags and the new action.
At present libseccomp does not run valgrind on the "live" tests, only
the simulated BPF tests so this shouldn't be an issue. If it was, we
would be seeing failures with the current (and past) releases.
> The best solution that I can think of is for libseccomp to call
> secure_getenv(), prior to calling seccomp() to check feature support,
> and always blindly assume that a feature is supported if a "magic"
> environment variable is set. The test runner would set that env variable
> prior to running each test. Is this an acceptable solution? If not, do
> you have any ideas that you like better?
My initial reaction to using environment variables in this manner is
not positive. Let's try to do runtime checking in a similar manner as
we are doing now (see above comments) and if that doesn't work we can
reevaluate things, sound good?
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
For more options, visit https://groups.google.com/d/optout.