On Wed, Feb 7, 2018 at 6:12 PM, Tom Hromatka <tom.hroma...@oracle.com> wrote:
> On 02/07/2018 03:17 PM, Paul Moore wrote:
>> * Improved performance is always good, but functional equivalency and
>> compatibility with the existing API/callers is another hard
>> requirement. I mention this because of your comments regarding
>> argument filtering and hybrid BPF filters, can you elaborate a bit
>> more on the possible solutions to ensure this works under EBPF
>> (including hybrid options)?
>
> Agreed. We cannot afford to break existing seccomp users.
>
> So this is purely theoretical, but I think it should work. We could
> utilize seccomp's ability in the kernel to run multiple seccomp filters.
> The first filter to run would be the EBPF filter. If it returns an
> action to run, we could bail out of the for() loop in seccomp_run_filters()
> early. If not, continue running the cBPF filter(s) as usual. Existing
> seccomp users wouldn't even load an EBPF filter so their behavior would
> remain unchanged.
>
> On the libseccomp side, I would expect something like this:
>
> int sys_filter_load(struct db_filter_col *col)
> {
> int rc;
>
> /* load the classic BPF filter first */
> rc = sys_bpf_filter_load(col);
> if (rc < 0)
> return rc;
>
> /* process the EBPF filter. note - it will only load a
> * filter if it has been instructed to do so by the user.
> * for classic seccomp filters this is effectively a nop
> */
> rc = sys_ebpf_filter_load(col);
>
> return rc;
> }
One of the gotchas with loading multiple filters is that the first,
and all non-final, filters need to allow the syscalls necessary to
load the additional filter (I'm not 100% on EBPF, but I believe it is
still just seccomp(2)). Generally this is user/caller problem, but if
we are hiding the fact that we are loading two filters instead of one
we are going to need to do some additional work to ensure we can load
the second filter and not allow any syscalls the caller didn't intend.
It might be a better use of time and energy to look into improving
libseccomp's filter generation, e.g. Kees' comments around
sorted-trees/qsort.
--
paul moore
www.paul-moore.com
--
You received this message because you are subscribed to the Google Groups
"libseccomp" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to libseccomp+unsubscr...@googlegroups.com.
To post to this group, send email to libseccomp@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
