RFE: investigate Rust bindings

[pcmoore]

Given the growing popularity of Rust for system development, it seems like it might be a good idea to support a set of libseccomp Rust bindings. We could develop our own, but it seems that a developer has already created a set of bindings for Rust:

• https://github.com/polachok/seccomp-sys

I'm not a fan of reimplementing perfectly good code, so if the bindings above seem reasonable we may want to offer the developer a chance to migrate those bindings under https://github.com/seccomp (assuming they would want to do this). Of course, if the developer doesn't want to move their repo, and we agree that their bindings seem reasonable, we can just close this out and point people at the appropriate developers repo.

I mention this as I feel that there is value in having the bindings in one central location; not only does it help discoverability, I feel it helps keep the bindings current.

[pcmoore]

@drakenclimber thoughts on this? If this sounds good I can reach out to polachok to see if they are interested.

At the very least I would want to make sure that they are okay with the stuff in CONTRIBUTING.md and MAINTAINER_PROCESS.md; it seems like any project under github.com/seccomp should adopt similar policies. Thoughts?

[drakenclimber]

thoughts on this?

Yes, I think rust support would be a very good thing. (Aside - the rust kernel RFC that was recently sent out seems very interesting.)

At the very least I would want to make sure that they are okay with the stuff in CONTRIBUTING.md and MAINTAINER_PROCESS.md; it seems like any project under github.com/seccomp should adopt similar policies. Thoughts?

Sounds great to me. If possible, I would love to credit and use an existing project rather than reinventing a wheel.

[KentaTada]

Hello, @pcmoore @drakenclimber

I'm sorry to interrupt you, but I'd like to introduce you to our related project.
We have been developing a set of bindings for Rust https://github.com/ManaSugi/libseccomp-rs to use it for Kata container and our rust-based container runtime.
We will continue to maintain our libseccomp-rs because it will be adopted for Kata.
Could you check our project if you are interested in that?

@ManaSugi Could you explain feature and status of https://github.com/ManaSugi/libseccomp-rs?

[ManaSugi]

@KentaTada Thank you for the introduction!

Hello, @pcmoore, @drakenclimber
As described above, we are developing the libseccomp-rs that is a set of projects (high-level bindings, low-level bindings, and tool for generating low-level bindings automatically).

The libseccomp crate wraps libseccomp-sys of low-level bindings in a nice to use, mostly safe API.
The libseccomp-sys in libseccomp-rs seems like seccomp-sys developed by polachok.
The main difference between seccomp-sys and our libseccomp-sys is that libseccomp-sys is generated using bindgen automatically.

Currently, we are working on adding seccomp feature to kata-containers using our libseccomp-rs.
kata-containers/kata-containers#1788
We are preparing for the merge, discussing it with the community.

In addition, the libseccomp-rs has already been used in our rust-based container runtime that I presented at Cloud Native Rust Day a few weeks ago.
https://static.sched.com/hosted_files/cloudnativerustdayeu21/e8/Rust_based_Secure_and_Lightweight_Container_Runtime_for_Embedded_Systems.pdf

Please let me know if you are interested in our libseccomp crate.

[pcmoore]

Thanks @KentaTada and @ManaSugi, this is something worth looking into! Unfortunately I am still new to Rust so it is hard for me to judge things at the moment but I definitely prefer bindings which are generated by hand over automated bindings; they tend to hold up better over the long run. This is one of the reasons why the Python bindings were done by hand using Cython and not automated via SWIG.

I also very much like the idea of adopting bindings from people who have been active and contributed patches to the general libseccomp project already. These people are less of an unknown and I feel like I can trust them more than people who have never contributed :)

@drakenclimber any thoughts on the projects mentioned above?

[ManaSugi]

@pcmoore Thank you for your valuable opinion.

I definitely prefer bindings which are generated by hand over automated bindings; they tend to hold up better over the long >run. This is one of the reasons why the Python bindings were done by hand using Cython and not automated via SWIG.

I understand the reason.
We can stop using bindgen and maintain the crate by hand.
In that case, all we have to do is change libseccomp-sys which is low-level bindings inside libseccomp-rs.

[drakenclimber]

I looked through libseccomp-rs. Nice work, @ManaSugi and @KentaTada. It looks really solid to me.

I have a handful of thoughts:

• I see that calls to the libseccomp C library are surrounded by unsafe, e.g. let ret = unsafe { seccomp_export_pfc(self.ctx.as_ptr(), fd.as_raw_fd()) };. Did you experience memory issues without the unsafe flag?
• I noticed you have continuous integration setup (Awesome!) and several unit tests. I would love to see us connect it to up to the existing functional tests
• I saw in your README that you show how to statically link with libseccomp. I don't have a strong feeling about this one way or the other, but it's been a pain point for some C users over the years. I don't yet know if rust will hit the same issues
• What are others' thoughts on licensing? (I try to stay out of the licensing quagmire entirely.) I see the Rust bindings are Apache or MIT where libseccomp C code is LGPL.
• We had talked about splitting out the python bindings from the libcgroup github repo and putting them in their own repo. Do we consider doing that and figuring out a way to share as much automated testing as possible between C, Go, Python, and Rust?

[drakenclimber]

I see that calls to the libseccomp C library are surrounded by unsafe, e.g. let ret = > unsafe { seccomp_export_pfc(self.ctx.as_ptr(), fd.as_raw_fd()) };. Did you experience memory issues without the unsafe flag?

After looking at the Rust documentation, are you using the unsafe block for the pointer dereference? Would it be possible to only unsafe the dereference so that we can take advantage of Rust's memory checking in more places?

[ManaSugi]

Thank you very much for the review of our crate, @drakenclimber.

After looking at the Rust documentation, are you using the unsafe block for the pointer dereference? Would it be possible to only unsafe the dereference so that we can take advantage of Rust's memory checking in more places?

The reason why all calls to the libseccomp C library are surrounded by unsafe block is that we must use unsafe when we use Rust's FFI(Foreign Function Interface).
Foreign Functions are assumed to be unsafe so calls to them need to be wrapped with unsafe as a promise to Rust's compiler that everything contained within truly is safe. This is described in Rust documentation about FFI.
Therefore, we can not call libseccmp C library without unsafe.

Would it be possible to only unsafe the dereference so that we can take advantage of Rust's memory checking in more places?

Unfortunately, we can not call the libseccomp C library from Rust code without unsafe as I mentioned above.
Therefore, we have to create safe wrapper functions to hide unsafe internal details as much as possible.
For example, we use NonNull in ScmpFilterContext to ensure the return value of seccomp_init of libseccomp C is non-null.
Ref: https://github.com/ManaSugi/libseccomp-rs/blob/v0.1.3/libseccomp/src/lib.rs#L416

I saw in your README that you show how to statically link with libseccomp.
I don't have a strong feeling about this one way or the other, but it's been a pain point for some C users over the years.
I don't yet know if rust will hit the same issues.

Yes, we recommend that developers should use libseccomp crate with dynamically linked the libseccomp C library. Therefore, the crate is linked dynamically by default.
Howevever, some users want to link the crate statically, so the README shows how to statically link with libseccomp.
In fact, kata-containers will use the libseccomp crate with statically linked the llibrary.

What are others' thoughts on licensing? (I try to stay out of the licensing quagmire entirely.)
I see the Rust bindings are Apache or MIT where libseccomp C code is LGPL.

Our libseccomp crate includes only the function interface of the libseccomp C library, not the C code itself.
Therefore, we can publish the crate under the MIT or Apaches 2.0.
The reason I selected the license is that Rust community recommends that crates should be dual-licensed, under either the MIT or Apaches 2.0 licenses.
Ref: https://rust-lang.github.io/api-guidelines/necessities.html#crate-and-its-dependencies-have-a-permissive-license-c-permissive

However, if the crate is used with statically linked the libseccomp library that is under LGPL-2.1, we should comply with the LGPL-2.1 (6(a)) when we distribute the binary including the crate.
I should add an explanation about that in README.
Could you tell me your thoughts about the license?

We had talked about splitting out the python bindings from the libcgroup github repo and putting them in their own repo.
Do we consider doing that and figuring out a way to share as much automated testing as possible between C, Go, Python, and Rust?

I'm interested in sharing automated testing between various languages, but I think it is difficult because of the different function interfaces. Could you tell me your idea about a way to share libseccomp test?

[drakenclimber]

Thank you very much for the review of our crate, @drakenclimber.

After looking at the Rust documentation, are you using the unsafe block for the pointer dereference? Would it be possible to only unsafe the dereference so that we can take advantage of Rust's memory checking in more places?

The reason why all calls to the libseccomp C library are surrounded by unsafe block is that we must use unsafe when we use Rust's FFI(Foreign Function Interface).
Foreign Functions are assumed to be unsafe so calls to them need to be wrapped with unsafe as a promise to Rust's compiler that everything contained within truly is safe. This is described in Rust documentation about FFI.
Therefore, we can not call libseccmp C library without unsafe.

Makes sense. Thank you. I'm newer to rust as well and hadn't used the FFI portion yet, but did hit the memory checking once.

I saw in your README that you show how to statically link with libseccomp.
I don't have a strong feeling about this one way or the other, but it's been a pain point for some C users over the years.
I don't yet know if rust will hit the same issues.

Yes, we recommend that developers should use libseccomp crate with dynamically linked the libseccomp C library. Therefore, the crate is linked dynamically by default.
Howevever, some users want to link the crate statically, so the README shows how to statically link with libseccomp.
In fact, kata-containers will use the libseccomp crate with statically linked the llibrary.

Sounds good.

What are others' thoughts on licensing? (I try to stay out of the licensing quagmire entirely.)
I see the Rust bindings are Apache or MIT where libseccomp C code is LGPL.

Our libseccomp crate includes only the function interface of the libseccomp C library, not the C code itself.
Therefore, we can publish the crate under the MIT or Apaches 2.0.
The reason I selected the license is that Rust community recommends that crates should be dual-licensed, under either the MIT or Apaches 2.0 licenses.
Ref: https://rust-lang.github.io/api-guidelines/necessities.html#crate-and-its-dependencies-have-a-permissive-license-c-permissive

However, if the crate is used with statically linked the libseccomp library that is under LGPL-2.1, we should comply with the LGPL-2.1 (6(a)) when we distribute the binary including the crate.
I should add an explanation about that in README.
Could you tell me your thoughts about the license?

As I said originally, I try to stay out of license discussions and leave them to the lawyers :). But what you outlined above is exactly the scenario I was afraid of. It might be good to run these scenarios by your company's legal team.

We had talked about splitting out the python bindings from the libcgroup github repo and putting them in their own repo.
Do we consider doing that and figuring out a way to share as much automated testing as possible between C, Go, Python, and Rust?

I'm interested in sharing automated testing between various languages, but I think it is difficult because of the different function interfaces. Could you tell me your idea about a way to share libseccomp test?

(Warning - not a fully thought out idea here.)

The automated tests within libseccomp do a really good job of covering every major feature from a functional point of view. And the framework supports both C and Python already. I don't think it would be too tough to add support for more languages to the framework. Over time we could add Golang and Rust tests alongside the existing tests.

But where should these tests reside in github? In libcgroup, we split the tests into their own repo - which has had some definite pros/cons. We could leave the tests in the seccomp/libseccomp repo, then have the other languages add the tests (and libcgroup library code) as a git submodule. Again, thinking out loud here, that could work pretty well...

Ultimately my real goal is to get better functional code coverage for Golang and Rust. I'm open in how we get there.

Thanks!

[ManaSugi]

@drakenclimber, Thank you for the kind reply.

I'm sorry, I misunderstood about the automated tests, but now I understand that.
Do you mean that we should aggregate tests all in one tests directory of libseccomp?
I think it sounds great because we can get better function code coverage for various languages as you mentioned.
I'm interested in the work!

First of all, I'll start to create more tests of our libseccomp crate while referencing the existing functional tests.

Thanks again.

[drakenclimber]

Do you mean that we should aggregate tests all in one tests directory of libseccomp?

Possibly, but honestly I don't really know. I am also the maintainer of libcgroup, and a while back we split our tests into a separate git repo. Overall I have mixed feelings on the split. The tests can grow and change without excess code churn in the main repo, but keeping the two repos in sync is more work than I like. Also, using git submodules is less than ideal.

tl;dr - I'm not sure what the right answer is regarding tests for multiple languages and multiple platforms. I don't think there's an easy answer :(