It's a library that is linked to in place of an operating system - so whatever interface the OS provided (syscalls+ioctls, SMC methods, etc.) ends up linked / compiled into the application directly, and the "external interface" of the application becomes something different.
This is how most unikernels work; the "OS" is linked directly into the application's address space and the "external interface" becomes either hardware access or hypercalls.
Wine is also arguably a form of "library OS," for example (although it goes deeper than the most strict definition by also re-implementing a lot of the userland libraries).
So for example with this project, you could take a Linux application's codebase, recompile it linked to LiteBox, and run it on SEV-SNP. Or take an OP-TEE TA, link it to LiteBox, and run it on Linux.
The notable thing here is that it tries to cut the interface in the middle down to an intermediate representation that's supposed to be sandbox-able - ie, instead of auditing and limiting hundreds of POSIX syscalls like you might with a traditional kernel capabilities system, you're supposed to be able to control access to just a few primitives that they're condensed down to in the middle.
> So for example with this project, you could take a Linux application's codebase, recompile it linked to LiteBox
If you have to recompile, you might as well choose to recompile to WASM+WASI. The sandboxing story here is excellent due to its web origins. I thought the point of LiteBox is that recompilation isn’t needed.
Looking more closely, it looks like there are some "North" sides (platforms) with ABI shims (currently Linux and OP-TEE), but others (Windows, for example), would still require recompilation.
> If you have to recompile, you might as well choose to recompile to WASM+WASI.
I disagree here; this ignores the entire swath of functionality that an OS or runtime provides? Like, as just as an example, I can't "just recompile" my OP-TEE TA into WASM when it uses the KDF function from the OP-TEE runtime?
I had previous experience with WASM on TEE. Just use the foreign function interface. Remember WASM isn’t native code so you still need other native code to run WASM (such as wasmtime), and you can import other native functions into WASM through the runtime.
Any pure code (WASM or otherwise) that does not perform any input/output is by definition useless. It consumes electricity to do computation and there is no way to communicate its results.
The use case here was to use a KDF function from the TEE, and I assume it serves as an oracle where the actual key material cannot be revealed.
Turing machines have a well-defined input, and output if they halt.
So no, they are absolutely not useless, they are just "single-shot" models of computation. Certain software fit that model very nicely (e.g. compilers), others less so.
It's absolutely trivial to make a very strict sandbox - just a simple, mathematical Turing machine is 100% safe.
The hard part is having actual capabilities, and only WASI (which is much smaller than WASM) helps here, and it's not clear why would it be any better than other options, like LiteBox. Especially that wasm does have a small, but real overhead.
I think that's an OS in the form of a library, like Wine for example. From what I get from the description it allows you to run programs on your real OS and make it see a cut down API to your actual system to reduce the attack surface.
