Uno Reverse Card: Using Omniglot for generating bindings to a Rust library in a C++ codebase

[johnDeSilencio]

Hello, @lschuermann! I hope you are doing well.

My name is Nick, and I work at a company in the energy sector. At my company, we use a lot of C++ in our products, and I've been looking for ways to make it easier for us to adopt Rust where it makes sense. To improve adoption, I'm looking for ways to make it as easy as possible for Rust to inter-operate with the mountains of C++ that have been written over the last two decades.

I'm attending RustConf in two weeks and stumbled on your paper through Princeton about Omniglot. First of all, amazing work that you and your co-authors have done! I am hoping that a tool like the one you have developed could help lower the barriers to adopting Rust at my company.

I had some questions, though. The paper primarily focuses on a scenario where a Rust codebase has to interact with a foreign library. In other words, Rust is "running the show". Can Omniglot be used in the other direction? What I'm specifically looking for is the ability to define some kind of interface in C++ (or C) that is then implemented in Rust. In that scenario, C++ is "running the show" and it is using libraries written in Rust.

Second question: the memory isolation primitives. I actually cloned the omniglot-mpk and tried to get it to run on my workstation. That's how I found out that my (old) x86 Intel CPU doesn't actually support MPK! And there's also no guarantees that the CPUs that we use in our products at my company provide memory isolation capabilities in hardware. Would it be possible to extend Omniglot to provide some kind of runtime check for those platforms without hardware support? That would be bad for performance, of course, but it would make Omniglot portable.

[lschuermann]

Hi Nick, good to meet you, and my apologies for this severely delayed response... My time around RustConf was pretty packed, and I'm just now catching up on things.

At my company, we use a lot of C++ in our products, and I've been looking for ways to make it easier for us to adopt Rust where it makes sense. To improve adoption, I'm looking for ways to make it as easy as possible for Rust to inter-operate with the mountains of C++ that have been written over the last two decades.

This is a really interesting use-case that has been brought up a couple times before. Indeed, in a lot of cases, Rust is being integrated into large, existing and monolithic code-bases, like the Linux kernel. It would be great to get better safety and soundness assurances in those systems, esp. given the large complexity and control that "foreign" code exercises in these settings. So this is definitely a research question worth exploring.

I will note at this point that Omniglot, at least right now, does not make it "easy" to interop with languages like C or C++. Its interface is relatively low-level and admittedly somewhat clunky (effectively an augmented version of the Rust bindgen output). Solving this problem is important, but tangential, and I hope that we can build higher-level bindings on top of the low-level interface that Omniglot provides.

Can Omniglot be used in the other direction? What I'm specifically looking for is the ability to define some kind of interface in C++ (or C) that is then implemented in Rust. In that scenario, C++ is "running the show" and it is using libraries written in Rust.

As hinted at in my answer at the talk, I think this should be possible, with slight modifications.

The most important consideration is that Rust would need to run at a higher privilege level than the C/C++ codebase. As long as an appropriate isolation mechanism exists in hardware (like x86 MPK/VT-x, RISC-V PMP, CHERI, ...) this should be feasible: execution would start in C/C++, but when initializing the Rust libraries, those would take control over those protection mechanisms.

Then, all calls from C/C++ to Rust would incur a protection domain switch from the lower, into the higher privilege level. This is virtually identical to how Omniglot implements callbacks from a foreign library back into Rust today.

That's how I found out that my (old) x86 Intel CPU doesn't actually support MPK! And there's also no guarantees that the CPUs that we use in our products at my company provide memory isolation capabilities in hardware. Would it be possible to extend Omniglot to provide some kind of runtime check for those platforms without hardware support? That would be bad for performance, of course, but it would make Omniglot portable.

Yes, and that's already in progress. We are porting the Omniglot prototype to a Software Fault Isolation mechanism called LFI (https://github.com/lfi-project). This works on x86-64 and AArch64 and does not require any specialized hardware features. It will also be significantly more secure than our current MPK implementation.

Again, apologies for the late response and thank you for raising these questions. I'm interested to work on these issues, and also happy to talk synchronously if you're interested in potentially adopting an approach like Omniglot.