On Thu, Feb 8, 2018 at 9:42 AM, Tom Hromatka <tom.hroma...@oracle.com> wrote:
> On 02/08/2018 07:34 AM, Paul Moore wrote:
>> 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 can be made backward compatible if libseccomp only calls __NR_bpf and
> __NR_seccomp iff the user has requested EBPF features. But I digress.
>
> Okay, I'll dig into src/gen_bpf.c and try to improve the syscall sorting
> code.
> I'm intrigued by the binary tree idea. Let me know if there's anything you
> would like to see added/changed.
If you're speaking in general terms, we do use the GH issue tracker:
* https://github.com/seccomp/libseccomp/issues
... which is a good place to start, feel free to find something you
find interesting and let me know.
If you're speaking specific to BPF filter generation, I think we
already talked about my thinking; my initial desire being to find a
balance between the existing returns-near-the-top behavior and a fully
sorted approach. Feel free to come back to the list with any ideas
you may have and we talk it over if you like.
--
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.
