RFE: ensure parity with the current libseccomp release

[pcmoore]

The libseccomp golang bindings have lagged the main libseccomp release for some time now. Before the next release of the bindings we need to go through and ensure that all of the main libseccomp functionality (e.g. ABI support, new APIs, etc.) that makes sense in golang is supported in the golang bindings.

[kolyshkin]

What are some features that are not implemented in here, compared to the C library?

I was only able to find SCMP_FLTATR_CTL_OPTIMIZE support which seems to be trivial to add. Is there anything else?

[rata]

@kolyshkin I don't have a comprehensive list. One item comes to mind, though: the seccomp notify addfd functionality is not implemented in golang, but IIRC it is in the C library.

[kolyshkin]

@pcmoore PTAL #37 (comment). Can we have a list of features that need to be added?

[pcmoore]

Well, the reason I wrote "... we need to go through and ensure that all of the main libseccomp functionality ..." is that at the time no one had done a gap analysis between the main library and the golang bindings. It looks like @kolyshkin may have now done that, at least to some degree; if not, a good place to start is the main seccomp.h header file.

• https://github.com/seccomp/libseccomp/blob/main/include/seccomp.h.in

[drakenclimber]

Well, the reason I wrote "... we need to go through and ensure that all of the main libseccomp functionality ..." is that at the time no one had done a gap analysis between the main library and the golang bindings. It looks like @kolyshkin may have now done that, at least to some degree; if not, a good place to start is the main seccomp.h header file.

* https://github.com/seccomp/libseccomp/blob/main/include/seccomp.h.in

Agreed. Unfortunately we dug ourselves a small hole when we added new features to libseccomp proper but didn't add corresponding RFE issues to libseccomp-golang.

But once we're caught up, this should be manageable now that we're all aware of the problem.

[kolyshkin]

I have a WIP implementation of SCMP_FLTATR_API_SYSRAWRC and SCMP_FLTATR_CTL_OPTIMIZE support, which I'll finalize and open a PR for as soon as the existing PRs (#70, #72, #74) are approved and merged, as otherwise there will be conflicting hunks.

[kolyshkin]

I have a WIP implementation of SCMP_FLTATR_API_SYSRAWRC and SCMP_FLTATR_CTL_OPTIMIZE support, which I'll finalize and open a PR for

For the sake of completeness, here it is: #75

Is there anything else that's missing from this package, compared to the C library?

[kolyshkin]

Is there anything else that's missing from this package, compared to the C library?

@pcmoore @drakenclimber as per previous comment, I need some help identifying the gaps that have yet to be filled. Does not need to be elaborate and/or precise -- a quick bullet point list will do.

[pcmoore]

As this is a larger undertaking, I'm wondering if we should move this to the v1.0.0 milestone so we don't hold up any of the v0.Y.Z releases?