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. Tom Hromatka (1): all: RFC - add support for ebpf include/seccomp.h.in | 31 ++++++++ src/Makefile.am | 2 +- src/api.c | 36 ++++++++- src/arch.c | 24 +++++- src/arch.h | 3 + src/db.c | 208 +++++++++++++++++++++++++++++++++++++----------- src/db.h | 25 +++++- src/gen_ebpf.c | 206 ++++++++++++++++++++++++++++++++++++++++++++++++ src/gen_ebpf.h | 38 +++++++++ src/gen_pfc.c | 62 +++++++++++++++ src/libbpf.h | 197 +++++++++++++++++++++++++++++++++++++++++++++ src/system.c | 219 ++++++++++++++++++++++++++++++++++++++++++++++++--- src/system.h | 2 +- 13 files changed, 988 insertions(+), 65 deletions(-) create mode 100644 src/gen_ebpf.c create mode 100644 src/gen_ebpf.h create mode 100644 src/libbpf.h -- 2.7.4 -- 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.
