Library Sandboxing for Verona
9 comments
·February 6, 2025mike_hearn
Says a lot that they don't support Windows.
This sounds similar to Chrome's Mojo system which lets you do RPCs on objects between processes, transmitting shared memory segments and fds/handles between them transparently. Mojo is really nice, I wish it were fully factored out into a separate codebase you could git clone without the rest of Chrome. It also supports Windows sandboxing.
pjmlp
Many Microsoft Research projects are done on Linux, and many also sadly die, like Singularity, Midori, Sing#, System C#, ....
However others do end in production like Windows Phone 7 kernel, Drawbridge, P*, .NET generics, F#, FStar, Lean,..
Actually I thought Verona was no longer active.
spooneybarger
It is definitely still active
guipsp
It really doesn't say much
bluelightning2k
Given this says it's potentially useful beyond Verona does this make it equivalent to gvisor/firecracker? Although why not use firecracker itself as it's so extensively battle tested
ameliaquining
They're solving different problems.
The problem this is solving is: It's the future, and Verona is no longer a research project but instead a real language that people write production systems in. You are working in a Verona codebase and need to add a dependency on an existing library written in a memory-unsafe language like C or C++. (Perhaps, e.g., this library is the only available parser for some obscure file format, and the format is too complicated for you to feasibly write a new parser from scratch.) You do not trust this library to be free of exploitable memory-safety vulnerabilities, so you need a way to call it that doesn't allow an attacker to take over your computer if they can find such a vulnerability. And you would like this to happen in a reasonably low-engineering-overhead way, rather than having to spin up a new microservice or similar. This is what this feature is trying to offer.
This is indeed something that any memory-safe language, not just Verona, could benefit from. However, a lot of the actual work being done here is on the language-integration side, and so would have to be repeated for every new host language. It's possible that the sandbox-side work could be reused.
The actual sandboxing is done with Linux's security features like seccomp-bpf. (The readme also mentions Capsicum so I guess FreeBSD is also supported?) This is lower-overhead than Firecracker or gVisor. Firecracker and gVisor can defend against some kinds of attacks that seccomp-bpf can't, particularly bugs in the Linux kernel, and if you are deliberately running potentially-hostile code on your server then these may be worth defending against. But it's likely overkill if your goal is just to sandbox a slightly dodgy parsing library.
guipsp
Firecracker requires KVM or equivalent, while this does not.
nesarkvechnep
It would've been nice to have an example or two in the README.
Verona is a research language: https://github.com/microsoft/verona/blob/master/docs/faq.md