On Thu, Feb 8, 2018 at 8:27 AM, Tom Hromatka <tom.hroma...@oracle.com> wrote:
> This patch adds support for EBPF hash maps to seccomp.
>
> Several in-house customers have identified that their large
> seccomp filters are slowing down their applications.  Their
> filters largely consist of simple allow/deny logic for many
> syscalls (306 in one case) and for the most part don't utilize
> argument filtering.
>
> I put together a rough but fully working prototype that called
> getppid() in a loop using one of my customer's seccomp filters.
> I ran this loop one million times and recorded the min, max,
> and mean times (in TSC ticks) to call getppid().  (I didn't
> disable interrupts, so the max time was often large.)  I chose
> to report the minimum time because I feel it best represents the
> actual time to traverse the syscall.
>
> Test Case                      minimum TSC ticks to make syscall
> ----------------------------------------------------------------
> seccomp disabled                                             620
> getppid() at the front of 306-syscall seccomp filter         722
> getppid() in middle of 306-syscall seccomp filter           1392
> getppid() at the end of the 306-syscall filter              2452
> seccomp using a 306-syscall-sized EBPF hash map              800

Are the filters generated by libseccomp sorted as a binary tree? Based
on these numbers, it would seem not. I think you could get a huge
performance gain out of large filters by having them set up that way.

(Also, 306-syscall-sized filter? There are only 332 syscalls in
x86_64, even in a worst-case, this should be 1 greater-than compare
and 26 equality checks, not 306 equality checks...)

> As shown in the table above, adding EBPF hash map support to
> seccomp can significantly improve syscall performance in the
> average and worst case for these customers.

I'm not against eventually adding eBPF hash map support, but every
time someone has talked about slow filters, it's because they're doing
something hugely inefficient in their filter. :)

-Kees

-- 
Kees Cook
Pixel Security

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