Reddit discussion: https://www.reddit.com/r/linux/comments/1qw4r71/microsofts_n...

Project lead James Morris announcing it on social.kernel.org: https://social.kernel.org/notice/B2xBkzWsBX0NerohSC

  grep 'name = ' ms-litebox-Cargo.lock | wc -l
     238

  grep 'name = ' ms-litebox-Cargo.lock | sort -u | wc -l
     221

* Many of them are part of families of crates maintained by the same people (e.g. rust-crypto, windows, rand or regex).

* Most of them are popular crates I'm familiar with.

* Several are only needed to support old compiler versions and can be removed once the MSRV is raised

So it's not as bad as it looks at first glance.

The "North" part seems to be what I think you'd traditionally think of as a library OS, and then the "South" part seems to be shims to use various userlands and TEEs as the host (rather than the bare hardware in your example).

I'm really confused by the complete lack of documentation and examples, though. https://github.com/microsoft/litebox/pull/491 seems like it would get closer; it looks like it's a test harness that would compile TAs to run on qemu.

That's the theory, but I don't know how far LiteBox is along to supporting that workflow.

> It focuses on easy interop of various "North" shims and "South" platforms.

For replacing wine on Linux the "North" would be kernel32 API or similar, the "South" would be Linux sys all API.

However this is meant as a library, thus require linking the Windows program to it and eine is more than the system interface, it has all the GUI parts etc of win32 API

There has to be a better way. I think Linux's flatpak is a reasonable approach here, although the execution might be rather poor. I want a basic set of trusted tool that I can do anything with, and run less trusted tools like GUI programs in sandboxes with limited filesystem access.

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.

What is unclear is if it uses its own common ABI or if you use the one of the host os. I don't know why but from the project description I have a little bit of feeling that this is another vibe coded project.

Basically it lets your program run directly on a hypervisor VM, though this one will also run as a Linux/Windows/BSD process.