RFE: export filter in a C header file format

[pcmoore]

Add functionality to export the seccomp BPF filter in a C header file format suitable for including in a project. Ideally the generated C header would include the filter loading function which would handle the prcrtl()/seccomp() call as well as any NNP settings as defined by the filter.

Proposed new libseccomp API:

API int seccomp_export_chdr(const scmp_filter_ctx ctx, int fd);

[pcmoore]

Related: #342

Building upon the strawman API for exporting the filter in original issue description, my thinking is that the generated header file would include a int seccomp_load_chdr(void) function which the application would call to do the necessary settings, e.g. NNP, and load the filter.

[vapier]

how would one handle multiple programs in a single project ? for example, i want to generate two filters and then select between them based on runtime settings -- if i know i need to fork a helper, i'll load one filter, but if i don't need that, i'll load a smaller filter. if we only ever defined seccomp_load_chdr, it wouldn't be easy to utilize. the caller would have to #define seccomp_load_chdr foo, include the 1st header, then #define seccomp_load_chdr bar, and include the 2nd header.

tbh, it's not clear to me how multiple arches should be handled. do we want to generate a single program with all the arches included, or manually separate them out, or some hybrid ? i could see having a single filter for x86/x32/x86_64 making sense, but not also including s390/arm64 in there. maybe i'm not being creative enough. if we separate them out, will we walk all of the architectures added and emit the program for each one with appropriate ifdef protection ? for example, see my mapping of SCMP_ARCH_XXX to ifdefs in pax-utils's seccomp-bpf.c.

are we planning on C being the only target we ever care about ? C++ can ingest these easily enough, but what about Rust or Python or the next hot language ?

i'm starting to wonder if libseccomp (the library) is the right home for this API. who do we see as the target audience of libseccomp (the library, not the project) ? clearly it's meant to be used by production code who want to setup & activate filters. but is it also for development purposes ? should we be throwing all of these more clearly development-oriented APIs into the same library ? or should there be a sep library to hold these, or perhaps a CLI tool ? a sep library would be easy to handle -- have the pkg-config file specify both -lseccomp and -lseccomp-dev, and most linkers will discard the -lseccomp-dev linkage if it's not actually used (or if we wanted, could get into linker scripts to hide the separation pretty easily).

[pcmoore]

In an effort to get v2.6.0 out sooner than later, I'm going to suggest we push this out to v2.7.0; if you have any concerns or objections please drop a comment.