On Wed, Feb 7, 2018 at 7:12 PM, Kees Cook <[email protected]> wrote: > On Thu, Feb 8, 2018 at 8:27 AM, Tom Hromatka <[email protected]> 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.
The libseccomp generated filters are not sorted that way. The libseccomp generated filters are generated with the idea that it is best to put the shortest rules at the front of the filter; with the users having some ability to influence the exact ordering via priority hints (see seccomp_syscall_priority(3)). The idea of sorting syscalls via a balanced tree has come up in the past, I just haven't had the time to play with it. There are other optimizations, but they mostly come into play when filtering on syscall arguments. > (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...) ... or honestly, just a blacklist. Without knowing more about the application it's hard to recommend an approach, but most users have been finding blacklists to be much more manageable, even if it doesn't provide the same level of warm fuzzies. >> 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 [email protected]. > To post to this group, send email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- 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 [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
