To be expected, given how many organisations now require employees to use AI if they want to meet their OKRs, especially all that sell AI tools.

More links with discussion:

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

Microsoft doesn't have a very good track record with security or privacy. Maybe it works, but yeah you'll probably get screwed over at some point.

Still, the fact that it's open source is a good thing. People can now take that code and make something better (ripping out the AI for example) or just use bits and pieces for their own totally unrelated projects. I can't see that as anything but a win. I have no problem giving shitty companies credit where its due and they've done a good thing here.

This isn't supposed to replace Windows, and it isn't a GUI desktop operating system at all. I doubt anyone working on this has anything to do with the modern Windows desktop UX.

UI of Windows is buggy and inconsistent. Kernel and low level stuff are actually very stable and good.

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.

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.

https://en.wikipedia.org/wiki/Operating_system#Library

yeah, same here, I was like "wow what an interesting side to their business, a whole operating system intended to serve public and academic libraries!"

People seem to believe writing things in rust means it's correct.

The sandboxing on mobile platforms puts the OS vendor in a special position to enforce a monopoly on apps and features. Apple enforces it aggressively, while Google only reluctantly so far. It also prevents the user from exerting full control of the system. Apple does it by locking things down directly, while Google punishes you for owning your devices with attestation.

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.

That's 238 dependencies (counting multiple versions of the same crate).

* 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.

What would be a reasonable amount of time to audit the dependencies?

They ran it through Copilot which gave it the all-clear.

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

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

Given, you know, Microsoft, I'd demand proof even if they said they did.

My understanding of this is that it is a sandbox. Providing a common interface like if it was an OS for the program to run inside, but avoiding the program to use the OS directly.

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.

A library OS is an OS that is linked directly to your program instead of being a separate program accessed through a syscall to kernel mode. About the same as a “unikernel”, but a more recent term.

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

IIUC, if you have the source you can recompile said Windows app with LiteBox to statically link in the Windows OS kernel dependencies, so it'll run on any compatible processor regardless of OS (since it won't be making syscalls anymore). It's a unikernel basically.

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

They say

> 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

It's both; it's aimed at hosting a single user program on another userspace, but also seems to have its own kernel as well?

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.

The reddit conversation seems to allude to you being correct.

Just assume the only thing a human did was name write the initial prompt.