On Wed, Feb 7, 2018 at 4:27 PM, 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 > > 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. > > TODOs: > * These changes collide with commit ce3dda9a - "massive src/db.c > rework". I will rebase them on top of that commit, but it > doesn't look trivial at the moment > * Add BPF_PROG_TYPE_SECCOMP and its associated functions to the > kernel > * Add doxygen comments > * Add libseccomp tests > * Address the handful of TODOs in the RFC > > Next Steps: > Obviously the kernel changes need to be committed prior to adding > EBPF hash map support to the seccomp library, but I wanted to get > this community's buy-in before continuing much further. The > critical logic changes largely reside in this library, so I chose > to start here. > > A few questions for this community: > * General thoughts on this patch, of course > * Going forward from here - some of my customers also need to > add a few more advanced rules which filter on syscall arguments > (in addition to their many basic allow/deny rules). I have been > waffling between supporting a hybrid cBPF and EBPF solution > initially vs. adding full EBPF support. A hybrid cBPF/EBPF > solution (where two filters are loaded into the kernel) could be > completed in a much quicker timeframe than full EBPF support.
Hi Tom, Thanks for the patches, I obviously haven't had a chance to look at them in detail, but I wanted to provide some quick feedback/confirmation as well as ask a few questions; in no particular order: * You are correct, we need kernel support before we can consider merging the libseccomp code into the master branch. However, if you feel it would be helpful to have libseccomp support in order to test/verify the kernel support, I would consider merging the code into a development branch. * My apologies on the collision with the "massive src/db.c rework". That was a bit of a special case patch and I only did it that way because I didn't believe anyone else had any pending work that involved that code. If there is anything I can do to help here, let me know. * Testing is a pretty hard requirement for libseccomp, especially these patches. I'm going to ask for +90% test coverage of this new code (we're currently at ~92%); I know that's a lot, but this is critical code. * 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)? -- 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.
