RFE: tool to precompile filters

[vapier]

one downside to libseccomp is that you have to link it into every project that wants to use it, and then generate the bpf program on the fly before it can be loaded. this is useful in some scenarios (where the filter needs are dynamic), but a common situation (in my experience in Chrome OS) is that the filter is always the same on every run. it would be nice if we could compile the filter at build time and have the runtime just load the program into the kernel and not have any libseccomp dependency at runtime at all.

i've actually built a limited proof of concept in Gentoo's pax-utils. i'll link to them here, but it's more as an FYI rather than an immediate discussion point, so please don't look too hard at them.

• seccomp-bpf.c links against libseccomp at build time to generate the filter programs for all possible architectures.
• seccomp-bpf.h is the generated header that is included in the program itself -- this is checked in so even people building the project don't need libseccomp, only when updating the filter.
• security.c includes seccomp-bpf.h and calls PR_SET_SECCOMP at runtime to install the filter.

now i'm wondering if we can generalize this in libseccomp itself. while eBPF has the luxury of an LLVM backend, plain BPF does not. so i think we'd have to:

• design a DSL for what BPF can actually support
• add a tool to ship with libseccomp that'd parse the DSL and produce the BPF
• the BPF can either be raw binary file, or it can generate source code ready to be included directly in projects
• for example, as seen above, you can see seccomp-bpf.h produces a simple C header that is ready to be included, and the project only needs to make a single prctl() to load it

WDYT ? is this something we can do as part of libseccomp ?

[pcmoore]

I've been thinking about this for a while now, it just hasn't percolated up the priority ladder:

• https://github.com/seccomp/libseccomp/issues/15

I'm not sure we want to go quite as far as what you've described, e.g. design a new DSL, as I believe that is a bit beyond the scope of the core libseccomp library. However, I do think it would be reasonable to add support for exporting a libseccomp filter into a C header file that would contain the BPF as well as the necessary NNP and other calls to load/instantiate the filter at runtime.

Applications which wanted to make use of this could simply transfer their existing libseccomp calls into a separate tool which is built/executed at build time and the resulting header file included in the main application.

If we eventually decide that we do want to go the full blown language route we can do that later, the header file generation would be a first step regardless.

[pcmoore]

Also, do we want to consolidate this issue with #15?

[vapier]

I certainly understand the concern about scope creep. I'm happy to take it one step at a time.

I'll start with the C header generation in #15. I did a quick search before but didn't find that one, so thanks for the link.

up to you whether you want to close this issue now, or leave it open for a bit in case anyone shows up with their thoughts. not that reopening is hard to do.

[drakenclimber]

This issue has arisen a few times within Oracle as well. Most recently a team that frequently creates/deletes containers expressed interest in the ability to build a filter once up front rather than each time a container is created. They experimented with exporting BPF and trying to pass that around, but it felt fragile.

I'm open to a variety of solutions, but perhaps starting small(er) would be best.