On Thu, Feb 8, 2018 at 9:26 AM, Tom Hromatka <tom.hroma...@oracle.com> wrote:
> On 02/07/2018 08:30 PM, Paul Moore wrote:
>> 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.
> You are definitely correct.  The cBPF filter would have to
> (at a minimum) allow __NR_seccomp and __NR_bpf.  __NR_bpf is
> used to create and populate the EBPF map.
> If a user was especially security conscious, they would then
> need to block those syscalls in the EBPF map.  This is
> potentially error prone and slightly cumbersome.

Yes, exactly.

It's also not backwards compatible, you need a new(er) kernel for this
to work.  Like I said earlier, it might be easier to look into
improving the existing syscall sorting code in libseccomp; I believe
all the relevant code lives in src/gen_bpf.c:_gen_bpf_arch() and
should be relatively easy to play with ... much easier than the stuff
in src/db.c ;)

>> 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

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.

Reply via email to