Skip to content

[EXPERIMENTAL] Proof-of-Concept Custom LiteBox Kernel on Asterinas OSTD#517

Draft
jaybosamiya-ms wants to merge 30 commits intomainfrom
jayb/experimental/ostd
Draft

[EXPERIMENTAL] Proof-of-Concept Custom LiteBox Kernel on Asterinas OSTD#517
jaybosamiya-ms wants to merge 30 commits intomainfrom
jayb/experimental/ostd

Conversation

@jaybosamiya-ms
Copy link
Member

@jaybosamiya-ms jaybosamiya-ms commented Nov 21, 2025

Warning

This PR is NOT intended to be merged into main. This is purely an experimentation/demonstration PR for a proof-of-concept prototype.

Note

Any changes to existing crates in LiteBox are due to the fact that Asterinas OSTD does not work on latest stable or recent-enough nightly Rust. This is a fixable problem, but is punted in this PR by just forcing LiteBox to work with a version of nightly Rust that works with Asterinas OSTD. Thus, ignore the changes to existing crates when looking at this PR. These are incidental and are not the correct way we should handle them (for long-term maintainability), but this is a prototype PR after all :) Please focus on the new files in ostd-test/.

This PR prototypes what it would take to integrate LiteBox on top of Asterinas OSTD. This essentially means we have a custom kernel that can run unmodified Linux applications in userland on top of LiteBox.

Specifically, this PR sets up a runner and a platform specific to Asterinas OSTD to connect it to LiteBox. Currently the runner is hardcoded to run an unmodified Linux hello world binary (this is what prints the hello world. in the example output below), but essentially anything supported by our Linux shim would fairly easily work.

Testing

  1. Install cargo-osdk (via cargo install cargo-osdk).
  2. Run cargo osdk run at the root of the repo on this branch (you may need to put your user into the kvm group if you want it to be faster; or you can delete the -enable-kvm line in OSDK.toml if you're willing for it to run slower but don't want to bother setting up KVM things).
  3. Enjoy a Linux binary running on our own custom kernel inside of QEMU.

Output:

SeaBIOS (version 1.16.3-debian-1.16.3-2)


iPXE (https://ipxe.org) 00:02.0 CA00 PCI2.10 PnP PMM+7EFCACC0+7EF0ACC0 CA00



Booting from DVD/CD...
Activating VmSpace...
   _     _ _       ____
  | |   (_) |_ ___| __ )  _____  __
  | |   | | __/ _ \  _ \ / _ \ \/ /
  | |___| | ||  __/ |_) | (_) >  <
  |_____|_|\__\___|____/ \___/_/\_\

Runner initialized with binary at /bin/hello_world_static
Loading and executing program...
ElfLoaderMmap::mmap(addr: Some(400000), len: 839680, prot: 1, flags: 2, offset: 0, fd: Some(3))
ElfLoaderMmap::mmap(addr: Some(401000), len: 618496, prot: 5, flags: 12, offset: 4096, fd: Some(3))
ElfLoaderMmap::mmap(addr: Some(498000), len: 167936, prot: 1, flags: 12, offset: 622592, fd: Some(3))
ElfLoaderMmap::mmap(addr: Some(4c1000), len: 49152, prot: 3, flags: 12, offset: 786432, fd: Some(3))
hello world.
Program exited

@github-actions
Copy link

🤖 SemverChecks 🤖 No breaking API changes detected

Note: this does not mean API is unchanged, or even that there are no breaking changes; simply, none of the detections triggered.

@jaybosamiya-ms jaybosamiya-ms added the must-not-merge:prototype An experimental/proof-of-concept PR that must not be merged. label Nov 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

must-not-merge:prototype An experimental/proof-of-concept PR that must not be merged.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant