crosvm VS slog

The Linux kernel has a huge attack surface, and privilege escalation vulnerabilities abound. This is why https://gvisor.dev/ exists - it's a memory-safe proxy for Linux syscalls. This is also why Chrome OS runs its Linux environment in a custom hypervisor written in Rust instead of containers.

Same protocol, but the implementation is at the discretion of whoever writes the server code.

For example I went to check and in crosvm we use a BTreeMap already for Fids for our p9 implementation (thankfully): https://github.com/google/crosvm/blob/main/common/p9/src/ser...

I'm not sure, but maybe because it started as a fork of crosvm[0]?

[0]: https://github.com/google/crosvm

However i think what you're looking for is rather backend stuff, maybe take a look at here.

I've also been looking into shipping apps as VM images with a minimal kernel. Do you know if WHPX requires the user to have admin rights? On the host side, Windows and Mac ports of crosvm [1] could be useful. crosvm seems to have all the necessary virtio device types, but a greater focus on security than QEMU.

[1]: https://google.github.io/crosvm/

I only recently learned about rustwide myself when implementing sandboxed rustdoc builds for Shipyard.rs. After spending a good amount of time with the codebase, I have found it to be generally high quality, but the way the code is organized makes it fairly difficult to adapt for different purposes than it was intended for (not modular). I have a fork that I have changed to do what I need but not sure whether the two codebases can be reconciled because I ended up needing to put stuff very specific to my purposes in there. I also ran into a weird issue where the logging from rustwide was conflicting with the slog-based logging from my code, which feels to me like there is some UB lurking somewhere.

Slog Core Crate : core package to the gateway of logging modules.