9 ms·

Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

364 points by Klasiaster 2y ago

tiffanyh 2y ago
OT: if you're interested in Asterinas, you might also be interested in Redox (entire OS written in Rust). https://www.redox-os.org/ https://www.redox-os.org/
- metaketa 2y ago
  This is fascinating! Couldn't really find the kernel code but would love to know more about the applicability. I'm curious since seeing the Unikraft release that promised millisecond container boot times
  - cmiller1 2y ago
    https://gitlab.redox-os.org/redox-os/kernel/-/tree/master/src?ref_type=heads https://gitlab.redox-os.org/redox-os/kernel/-/tree/master/sr...
- snvzz 2y ago
  Redox has a proper architecture, aka microkernel multiserver. Thus it is a much more interesting project.
  - apatheticonion 2y ago
    To be fair Aester is just a monolithic kernel that philosophically quarantines unsafe code to the lowest level of the kernel. You still have kernel modules for microkernel-like functionality
- DoctorOW 2y ago
  I love Redox as a project because while it still has a massive ways to go, it's the closest to being a new OS/Kernel that has the potential to make it to a viable daily driver. Windows/MacOS/Unix/Linux are all incredibly old by software standards and Redox is bringing some cool design decisions.
spease 2y ago
What’s the intended use case for this? Backend containers?
- Animats 2y ago
  Makes a lot of sense for virtual machine containers. Inside a container inside a VM, you need far less operating system.
akira2501 2y ago
I personally dislike rust, but I love kernels, and so I'll always check these projects out. This is one of the nicer ones. It looks pretty conservative in it's use of Rust's advanced features. The code looks pretty easy to read and follow. There's actually a decent amount of comments (for rust code). Not bad!
- IshKebab 2y ago
  Rust code is usually well commented in my experience.
  - cies 2y ago
    Instead of asking "what other languages and project (open/closed, big/small, web/mobile/desktop, game/consumerapp/bizapp) have you experience with as to come to this conclusion?" people down vote you. So lemme ask: what other languages and project (open/closed, big/small, web/mobile/desktop, game/consumerapp/bizapp) have you experience with as to come to this conclusion?
    - dangsux 2y ago
      [dead]
    - ramon156 2y ago
      I expect the downvotes to be there because it's talking positively about rust, which is blasphemy! /j
      - tracker1 2y ago
        I'm guessing a lot of any perception of a lack of comments or documentation in a rust codebase comes down to how new or green a developer is to rust. If you're just starting out or doing something relatively simple, your goal is to get something working. This is so true regardless of the language.
        2y ago
depressedpanda 2y ago
From the README: > Currently, Asterinas only supports x86-64 VMs. However, our aim for 2024 is to make Asterinas production-ready on x86-64 VMs. I'm confused.
- None4U 2y ago
  Distinction here is between "supports" and "production-ready on", not "x86-64" and "x86-64"
- MattPalmer1086 2y ago
  Yeah, I had to read that a few times... I think they just mean it isn't production ready yet, but that's what they are aiming for.
- favorited 2y ago
  Sounds like their goal is to improve their x86-64 support before implementing other ISAs.
- nurb 2y ago
  It's clearer from the book roadmap: > By 2024, we aim to achieve production-ready status for VM environments on x86-64. > In 2025 and beyond, we will expand our support for CPU architectures and hardware devices. https://asterinas.github.io/book/kernel/roadmap.html https://asterinas.github.io/book/kernel/roadmap.html
- convolvatron 2y ago
  it would be nice to know how much userspace it supports. supporting the dynamic loader, reasonable futexes, epoll, signals, uring are all big milestones
  - throw4950sh06 2y ago
    Check it out https://asterinas.github.io/book/kernel/linux-compatibility.html https://asterinas.github.io/book/kernel/linux-compatibility....
- wrs 2y ago
deleted 2y ago
[deleted]
valunord 2y ago
I like what they're working towards with V in Vinix as well. Exciting times to see such things with ABI compat with Linux opening new paradigms.
Alexsky2 2y ago
I’ll mention another OS written in Rust, Twizzler: https://twizzler.io/ https://twizzler.io/ Its more of a research OS but still cool.
- Teever 2y ago
  And I'll mention another one that a friend of mine is working on: uxrt https://gitlab.com/uxrt https://gitlab.com/uxrt
treeshateorcs 2y ago
https://www.youtube.com/watch?v=3AQ5lpXujGo https://www.youtube.com/watch?v=3AQ5lpXujGo Asterinas: A safe Rust-based OS kernel for TEE by H. Tian & C. Song (Ant Group & Intel) | OC3 2024
- gghh 2y ago
  Exactly. I see elsewhere in this page people comparing this project to Linus Torvalds starting an OS in his dorm room while studying CS. Like these were "young and clueless" devs writing an OS for fun. From the looks of it, this seems like a serious corporate backed project made by employees of the Ant Group, the chinese fintech giant. A more fair comparison would be with Google's Fuchsia OS (defunct) or Huawei's HarmonyOS. It may succeed, it may fail, but it's nothing like a couple of kids doing a passion project to learn Rust.
justmarc 2y ago
I'm interested in these kind of kernels to run very high performance network/IO specific services on bare metal, with minimal system complexity/overheads and hopefully better (potential) stability and security. The big concern I have however is hardware support, specifically networking hardware. I think a very interesting approach would be to boot the machine with a FreeBSD or Linux kernel, just for the purposes of hardware as well as network support, and use a sort of Rust OS/abstraction layer for the rest, bypassing or simply not using the originally booted kernel for all user land specific stuff.
- protoman3000 2y ago
  Why don’t you just use a SmartNIC and P4? It won’t get faster than running on the NIC itself
- treeshateorcs 2y ago
  i might be wrong but if it's ABI compatible the same drivers will work? p.s.: i was wrong >While we prioritize compatibility, it is important to note that Asterinas does not, nor will it in the future, support the loading of Linux kernel modules. https://asterinas.github.io/book/kernel/linux-compatibility.html https://asterinas.github.io/book/kernel/linux-compatibility....
  - justmarc 2y ago
    No, it means you can run Linux userland/apps on this kernel, to the level/depth which they currently support of course. They might not yet implement everything that's needed to boot a standard Linux userland but you could say boot straight into a web server built for Linux, instead of booting into init for example.
  - bicolao 2y ago
    They mention this in https://github.com/asterinas/asterinas/blob/2af9916de92f8ca1e694bb6ac5e33111bbcf51fd/docs/src/kernel/linux-compatibility.md?plain=1#L7 https://github.com/asterinas/asterinas/blob/2af9916de92f8ca1... > While we prioritize compatibility, it is important to note that Asterinas does not, nor will it in the future, support the loading of Linux kernel modules.
jackhalford 2y ago
The building process happens in a container? > If everything goes well, Asterinas is now up and running inside a VM. Seems like the developers are very confident about it too
- deleted 2y ago
  [deleted]
havaker 2y ago
The license choice is explained with the following: > [...] we accommodate the business need for proprietary kernel modules. Unlike GPL, the MPL permits the linking of MPL-covered files with proprietary code. Glancing at the readme, it also looks like they are treating it as a big feature: > Asterinas surpasses Linux in terms of developer friendliness. It empowers kernel developers to [...] choose between releasing their kernel modules as open source or keeping them proprietary, thanks to the flexibility offered by MPL. Can't wait to glue some proprietary blobs to this new, secure rust kernel /s
- yjftsjthsd-h 2y ago
  I'm curious about the practical aspect: Are they going to freeze a stable driver ABI, or are they going to break proprietary drivers from time to time?
  - gpm 2y ago
    Considering their OS as a framework approach I would guess they are more likely to expose a stable API than a stable ABI. Which also plays well with the MPL license (source file based) rather than something like the LGPL (~linking based).
    - throw4950sh06 2y ago
      This is the most interesting new OS I have seen in many years.
cryptonector 2y ago
> Linux-compatible ABI There's no specification of that ABI, much less a compliance test suite. How complete is this compatibility?
- Klasiaster 2y ago
  Here is a list of implemented syscalls, but of course each checked one could still be slightly incompatible: https://asterinas.github.io/book/kernel/linux-compatibility.html https://asterinas.github.io/book/kernel/linux-compatibility....
  - cryptonector 2y ago
    There's also tons of ioctls and /proc and what not.
- mgerdts 2y ago
  While developing the lx brand on illumos/SmartOS, ltp was helpful. It may not be complete, but it is a pretty good start. https://linux-test-project.readthedocs.io/en/latest/ https://linux-test-project.readthedocs.io/en/latest/
  - cryptonector 2y ago
    LTP really needs to be a part of Linux itself.
Klasiaster 2y ago
There was also the similar project Kerla¹ but development stalled. Recently people argued that instead of focusing on Rust-for-Linux it would be easier to create a drop-in replacement like these two. I wonder if there are enough people interested to make this happen as a sustained project. ¹ https://github.com/nuta/kerla/ https://github.com/nuta/kerla/
- kelnos 2y ago
  > Recently people argued that instead of focusing on Rust-for-Linux it would be easier to create a drop-in replacement like these two I guess it depends on what they mean by "easy". Certainly it's easier in the sense that you can just write code all day long, and not have to deal with the politics about Rust inside Linux, or deal with all the existing C interfaces, finding ways to wrap them in Rust in good, useful ways that leverage Rust's strengths but don't make it harder to evolve those C interfaces without trouble on the Rust side. But the bulk of Linux is device drivers. You can build a kernel in Rust (like Asterinas) that can run all of a regular Linux userland without recompilation, and I imagine it's maybe not even that difficult to do so. But Asterinas only runs on x86_64 VMs right now, and won't run on real hardware. Getting to the point where it could -- especially on modern hardware -- might take years. Supporting all the architectures and various bits of hardware that Linux supports could take decades. I suppose limiting themselves to three or four architectures, and only supporting hardware made more recently could cut that down. But still, it's a daunting project.
weinzierl 2y ago
Decades ago Linus Torvalds was asked in an interview if he feared Linux to be replaced by something new. His answer was that some day someone young and hungry would come along, but unless they liked writing device drivers Linux would be safe. This is all paraphrased from my memory, so take it with a grain of salt. I think the gist of it is still valid: Projects like Asterinas are interesting and have a place, but they will not replace Linux as we have it today. (Asterinas, from what I understood, doesn't claim to replace Linux, but it a common expectation.)
- loeg 2y ago
  More recently, in a similar vein: > Torvalds seemed optimistic that "some clueless young person will decide 'how hard can it be?'" and start their own operating system in Rust or some other language. If they keep at it "for many, many decades", they may get somewhere; "I am looking forward to seeing that". Hohndel clarified that by "clueless", Torvalds was referring to his younger self; "Oh, absolutely, yeah, you have to be all kinds of stupid to say 'I can do this'", he said to more laughter. He could not have done it without the "literally tens of thousands of other people"; the "only reason I ever started was that I didn't know how hard it would be, but that's what makes it fun". https://lwn.net/Articles/990534/ https://lwn.net/Articles/990534/
  - ackfoobar 2y ago
    > Hohndel clarified that by "clueless", Torvalds was referring to his younger self As the saying goes "We do this not because it is easy, but because we thought it would be easy." Occasionally these are starts of great things.
    - nickpsecurity 2y ago
      Sometimes, we do such things because it’s hard. We enjoy the challenge. Those that succeed are glad to make it, too.
      - dathinab 2y ago
phlip9 2y ago
Super cool project. Looks like the short-term target use-case is running a Linux-compatible OS in an Intel TDX guest VM with a significantly safer and smaller TCB. Makes sense. This way you also postpone a lot of the HW driver development drudgery and instead only target VM devices.
hkalbasi 2y ago
> In the framekernel OS architecture, the entire OS resides in the same address space (like a monolithic kernel) and is required to be written in Rust. However, there's a twist---the kernel is partitioned in two halves ... the unprivileged Services must be written exclusively in safe Rust. Unprivileged services can exploit known compiler bugs and do anything they want in safe Rust. How this affects their security model?
- rcxdude 2y ago
  I think it's not so much intended as a "you can allow arbitrary untrusted code to run as an unprivileged service" and more "a buggy unprivileged service won't compromise the whole system".
snvzz 2y ago
I looked into the architecture. It turns out to be monolithic with marketing[0]. Sure is a lot of text to say: We try to use unsafe as little as possible. Which is the minimum you'd expect anyways ¯\_(ツ)_/¯ 0. https://asterinas.github.io/book/kernel/the-framekernel-architecture.html https://asterinas.github.io/book/kernel/the-framekernel-arch...
- netbsdusers 2y ago
  It's just what we used to call a "layered architecture".
exabrial 2y ago
I think this looks incredible. Like how does one create a compatible abi _for all of linux_??? Wow! > utilize the more productive Rust programming language Nitpick: it’s 2024 and these ‘more productive’ comparisons are silly, completely unscientific, And a bit of a red flag for your project: The most productive language for a developer is the one they understand what is happening one layer below the level of abstraction they are working with. Unless you’re comparing something rating Ruby vs RiscV assembly, it’s just hocus-pocus.
- ozgrakkurt 2y ago
  Everyone says what they are used to is better or more productive. Even in assembly vs ruby, some stuff are much easier in assembly and maybe impossible in ruby afaik
  - exabrial 2y ago
    I’m aging myself, but ~17 years ago I was in San Diego for a conference. There was a table level competition to see who could write the fastest program in 20 minutes (we were doing a full text search of a ‘giant’ 5g file). One of the guys at the table wrote some SPARC assembly to optimize character matching that was a hotspot like he was speaking French. Ah good times.
- kelnos 2y ago
  > Like how does one create a compatible abi _for all of linux_??? You look at Linux's syscall table[0], read through the documentation to figure out the arguments, data types, flags, return values, etc., and then implement that in your kernel. The Linux ABI is just its "library" interface to userspace. It's probably not that difficult; writing the rest of the kernel itself is more challenging, and, frankly, more interesting. Certainly matching behavior and semantics can be tricky sometimes, I'm sure. And I wouldn't be surprised if the initial implementation of some things (like io_uring, for example, if it's even supported yet) might be primitive and poorly optimized, or might even use other syscalls to do their work. But it's doable. While Linux's internal ABI is unstable, the syscall interface is sacred. One of Torvalds' golden rules is you don't break userspace. [0] https://filippo.io/linux-syscall-table/ https://filippo.io/linux-syscall-table/
xiaodai 2y ago
Lol. I am Malaysian Chinese but I honestly don't think anyone will put into production a Chinese made kernel. The risk is too high, same as no one will use a Linux distro coming out of Russian, Iran or NK. It's just cultural bias in the west.
- throw4950sh06 2y ago
  You're wrong. A lot of Chinese code and hardware is in production in the west. Huawei networking hardware is widespread, for example.
  - tredre3 2y ago
    > Huawei networking hardware is widespread That's an interesting example because Huawei equipment is currently being removed by several Western countries (UK, Canada, US, Germany) specifically because it's Chinese. https://www.nytimes.com/2024/07/11/business/huawei-germany-ban.html https://www.nytimes.com/2024/07/11/business/huawei-germany-b... https://www.cbc.ca/news/politics/huawei-5g-decision-1.6310839 https://www.cbc.ca/news/politics/huawei-5g-decision-1.631083... https://www.gov.uk/government/news/huawei-to-be-removed-from-uk-5g-networks-by-2027 https://www.gov.uk/government/news/huawei-to-be-removed-from... https://www.reuters.com/business/media-telecom/us-open-program-replace-huawei-equipment-us-networks-2021-09-27/ https://www.reuters.com/business/media-telecom/us-open-progr...
    - cozzyd 2y ago
      When we got a license for a private LTE network in the middle of the Greenland ice sheet, the one stipulation was we couldn't use Huawei equipment...
- gpm 2y ago
  Supposing it caught on... which do you think is riskier? Running an OS written in mostly memory safe code that somewhat might have tried to slip a backdoor in, or running an OS written in mostly memory unsafe code that has a long history of vulnerabilities and the Chinese almost certainly know about a vulnerability in. If this catches on and has generally been subject to significant third party code review with positive results, I'm not sure any backdoor is lower cost to use than an equivalent linux vulnerability. To be fair, I'm not sure it isn't either.
deleted 2y ago
[deleted]
wg0 2y ago
Side question - I have always wondered how a Linux system is configured at the lowest level? Let's take example of network. There's IP address, gateway, DNS, routes etc. Depending on distribution we might see something like netplan reading config files and then calling ABI functions? Or Linux kernel directly also reads some config files? Probably not...
- NewJazz 2y ago
  Linux kernel as much as possible tries not to parse or read external data (besides stuff like acpi tables, device trees, hardware registers). For networking, you might look at the iproute codebase to see how they do things like bring a network device up, or create a bridge device, add a route, et cetera. Edit: looks like iproute2 uses NETLINK, but non-networking tools might use syscalls or device ioctls. https://en.m.wikipedia.org/wiki/Netlink https://en.m.wikipedia.org/wiki/Netlink
wiz21c 2y ago
> Linux-compatible ABI Does it mean it can re-use the drivers written for hardware to run with linux ?
- dezgeg 2y ago
  No. There is no stable ABI nor API for in-kernel device drivers.
  - apatheticonion 2y ago
    Do other mainstream kernels have a stable driver API? I guess the NT kernel needs to. Does Darwin?
- eptcyka 2y ago
  No. The drivers in Linux are kernel modules, most often in-tree - meaning that the source for the drivers is built along the rest of the kernel source code. Most hardware drivers depend on various common kernel structures that change often - when they do, the source for drivers is fixed practically in the same git branch. There is no driver ABI to speak of.
pjmlp 2y ago
Besides all examples, Microsoft is now using TockOS for Pluton firmware, another Rust based OS. https://tockos.org/ https://tockos.org/
prmoustache 2y ago
> docker run -it --privileged --network=host --device=/dev/kvm -v $(pwd)/asterinas:/root/asterinas asterinas/asterinas:0.9.3 Is that the new generation of curl | bashism in action?
- wslh 2y ago
  Is the "--privileged" option ironic here? The project is very interesting, but it feels a bit pedantic, especially when emphasizing Rust's safety features while downplaying Linux. At the same time, it seems they're not fully applying those principles themselves, which makes it feel like they're not quite 'eating their own lunch'.
  - prmoustache 2y ago
    A bit below in the github readme there is a link to the handbook where they explain how to build and run the project using cargo: https://asterinas.github.io/book/osdk/guide/run-project.html https://asterinas.github.io/book/osdk/guide/run-project.html
- oefrha 2y ago
  Hardly different from downloading random binary installers and executing them. Or random source distributions and (sudo) make install. Or npm/pip/cargo/etc. install random packages. Before anyone mentions distros and package managers, as a former team member of a major package manager I can assure you we don’t vet shit beyond project notability, and new versions are accepted semi-automatically. We’ll yank something after the fact if you report a malicious update, sure. curl | bash has an actual problem: potential execution of an incomplete script (which can be mitigated with function calling). And there’s the mostly theoretical problem of the server being pwned / sending malicious code just to you (which of course also applies to any other unsigned channel). Arbitrary code execution is never a problem unique to it, but people dunk on it all the time because they saw another person dunking on it in the past.
  - hnfong 2y ago
    > as a former team member of a major package manager I can assure you we don’t vet shit beyond project notability, and new versions are accepted semi-automatically An example that illustrates this: https://lwn.net/Articles/22991/ https://lwn.net/Articles/22991/ (And wow, it's been 22 years already...?)
sylware 2y ago
Linux is mostly a decades long maintained repository of real hardware programing code, and written in mostly simple "kernel" 'C', not some ultra complex syntax language (unfortunately, it has been tied to compiler specific extensions or "modern C" tantrums, _generic for instance). Have a look at AMD GPU driver. Massive, and full of 'stabilization/work around' code... happening all the time, for years. I guess, the real "first thing first" is to design hardware, performant hardware on latest silicon process , with a, as simple as possible, modern, standard and stable hardware programing interface. Because, for many types of hardware, 'now we know how to do it properly' (command hardware ring buffers usually, or a good compromise for modern CPU architecture, like RISC-V). Another angle of "cleanup", I guess it would be the removal of many of the C compiler extension (or "modern C") tantrums from linux, or at least proper alternatives with not-inline assembly to allow small and alternative compilers to step in. Personally, I tend to write rv64 assembly (which I interpret on x86_64), but for the userland. If I code C, I push towards mostly "simple and plain C99". The more I think about it, the more I get the following coming to my mind: 'hardware with simple standard interfaces' and standard assembly for the kernel.
- artemonster 2y ago
  Huh? What is this nonsense?? Are you suggesting that you like to write practical-oriented, simple and working solutions instead of yak shaving half a day at perfecting ridiculous type signatures, removing „unsafe“ code and satisfying borrow checker? Proposterous! /s
a99c43f2d565504 2y ago
Zig kernel when
- bigfishrunning 2y ago
  When someone writes one
rpgraham84 2y ago
oh cool, now I can have an unverifiable kernel from a team in China
mococa 2y ago
This is exactly what I was discussing with a friend who works on the kernel. I don’t think Rust should be supported; the kernel should remain in C. Instead, a completely new kernel in Rust should be created with API/ABI compatibility with the original kernel.
- apatheticonion 2y ago
  Shame about the lack of a stable kernel driver ABI/API in Linux otherwise this kernel could inherent a lot of drivers.
fithisux 2y ago
Now we need Rust Windows compatible kernel to save us from Recall.
apatheticonion 2y ago
I wish I could work on this as my paid day job. As soon as I can financially retire, I'll make contributing to this my full time job!
hulitu 2y ago
> Asterinas: OS kernel written in Rust and providing Linux-compatible ABI > Currently, Asterinas only supports x86-64 VMs. So no real hardware.

364 points by Klasiaster 2y ago

OT: if you're interested in Asterinas, you might also be interested in Redox (entire OS written in Rust). https://www.redox-os.org/ https://www.redox-os.org/

metaketa 2y ago
This is fascinating! Couldn't really find the kernel code but would love to know more about the applicability. I'm curious since seeing the Unikraft release that promised millisecond container boot times
- cmiller1 2y ago
  https://gitlab.redox-os.org/redox-os/kernel/-/tree/master/src?ref_type=heads https://gitlab.redox-os.org/redox-os/kernel/-/tree/master/sr...
snvzz 2y ago
Redox has a proper architecture, aka microkernel multiserver. Thus it is a much more interesting project.
- apatheticonion 2y ago
  To be fair Aester is just a monolithic kernel that philosophically quarantines unsafe code to the lowest level of the kernel. You still have kernel modules for microkernel-like functionality
DoctorOW 2y ago
I love Redox as a project because while it still has a massive ways to go, it's the closest to being a new OS/Kernel that has the potential to make it to a viable daily driver. Windows/MacOS/Unix/Linux are all incredibly old by software standards and Redox is bringing some cool design decisions.

spease 2y ago

What’s the intended use case for this? Backend containers?

Animats 2y ago
Makes a lot of sense for virtual machine containers. Inside a container inside a VM, you need far less operating system.

akira2501 2y ago

I personally dislike rust, but I love kernels, and so I'll always check these projects out. This is one of the nicer ones. It looks pretty conservative in it's use of Rust's advanced features. The code looks pretty easy to read and follow. There's actually a decent amount of comments (for rust code). Not bad!

IshKebab 2y ago
Rust code is usually well commented in my experience.
- cies 2y ago
  Instead of asking "what other languages and project (open/closed, big/small, web/mobile/desktop, game/consumerapp/bizapp) have you experience with as to come to this conclusion?" people down vote you. So lemme ask: what other languages and project (open/closed, big/small, web/mobile/desktop, game/consumerapp/bizapp) have you experience with as to come to this conclusion?
  - dangsux 2y ago
    [dead]
  - ramon156 2y ago
    I expect the downvotes to be there because it's talking positively about rust, which is blasphemy! /j
    - tracker1 2y ago
      I'm guessing a lot of any perception of a lack of comments or documentation in a rust codebase comes down to how new or green a developer is to rust. If you're just starting out or doing something relatively simple, your goal is to get something working. This is so true regardless of the language.
      - 2y ago

depressedpanda 2y ago

From the README: > Currently, Asterinas only supports x86-64 VMs. However, our aim for 2024 is to make Asterinas production-ready on x86-64 VMs. I'm confused.

None4U 2y ago
Distinction here is between "supports" and "production-ready on", not "x86-64" and "x86-64"
MattPalmer1086 2y ago
Yeah, I had to read that a few times... I think they just mean it isn't production ready yet, but that's what they are aiming for.
favorited 2y ago
Sounds like their goal is to improve their x86-64 support before implementing other ISAs.
nurb 2y ago
It's clearer from the book roadmap: > By 2024, we aim to achieve production-ready status for VM environments on x86-64. > In 2025 and beyond, we will expand our support for CPU architectures and hardware devices. https://asterinas.github.io/book/kernel/roadmap.html https://asterinas.github.io/book/kernel/roadmap.html
convolvatron 2y ago
it would be nice to know how much userspace it supports. supporting the dynamic loader, reasonable futexes, epoll, signals, uring are all big milestones
- throw4950sh06 2y ago
  Check it out https://asterinas.github.io/book/kernel/linux-compatibility.html https://asterinas.github.io/book/kernel/linux-compatibility....
wrs 2y ago

deleted 2y ago

[deleted]

valunord 2y ago

I like what they're working towards with V in Vinix as well. Exciting times to see such things with ABI compat with Linux opening new paradigms.

Alexsky2 2y ago

I’ll mention another OS written in Rust, Twizzler: https://twizzler.io/ https://twizzler.io/ Its more of a research OS but still cool.

Teever 2y ago
And I'll mention another one that a friend of mine is working on: uxrt https://gitlab.com/uxrt https://gitlab.com/uxrt

treeshateorcs 2y ago

https://www.youtube.com/watch?v=3AQ5lpXujGo https://www.youtube.com/watch?v=3AQ5lpXujGo Asterinas: A safe Rust-based OS kernel for TEE by H. Tian & C. Song (Ant Group & Intel) | OC3 2024

gghh 2y ago
Exactly. I see elsewhere in this page people comparing this project to Linus Torvalds starting an OS in his dorm room while studying CS. Like these were "young and clueless" devs writing an OS for fun. From the looks of it, this seems like a serious corporate backed project made by employees of the Ant Group, the chinese fintech giant. A more fair comparison would be with Google's Fuchsia OS (defunct) or Huawei's HarmonyOS. It may succeed, it may fail, but it's nothing like a couple of kids doing a passion project to learn Rust.

justmarc 2y ago

I'm interested in these kind of kernels to run very high performance network/IO specific services on bare metal, with minimal system complexity/overheads and hopefully better (potential) stability and security. The big concern I have however is hardware support, specifically networking hardware. I think a very interesting approach would be to boot the machine with a FreeBSD or Linux kernel, just for the purposes of hardware as well as network support, and use a sort of Rust OS/abstraction layer for the rest, bypassing or simply not using the originally booted kernel for all user land specific stuff.

protoman3000 2y ago
Why don’t you just use a SmartNIC and P4? It won’t get faster than running on the NIC itself
treeshateorcs 2y ago
i might be wrong but if it's ABI compatible the same drivers will work? p.s.: i was wrong >While we prioritize compatibility, it is important to note that Asterinas does not, nor will it in the future, support the loading of Linux kernel modules. https://asterinas.github.io/book/kernel/linux-compatibility.html https://asterinas.github.io/book/kernel/linux-compatibility....
- justmarc 2y ago
  No, it means you can run Linux userland/apps on this kernel, to the level/depth which they currently support of course. They might not yet implement everything that's needed to boot a standard Linux userland but you could say boot straight into a web server built for Linux, instead of booting into init for example.
- bicolao 2y ago
  They mention this in https://github.com/asterinas/asterinas/blob/2af9916de92f8ca1e694bb6ac5e33111bbcf51fd/docs/src/kernel/linux-compatibility.md?plain=1#L7 https://github.com/asterinas/asterinas/blob/2af9916de92f8ca1... > While we prioritize compatibility, it is important to note that Asterinas does not, nor will it in the future, support the loading of Linux kernel modules.

jackhalford 2y ago

The building process happens in a container? > If everything goes well, Asterinas is now up and running inside a VM. Seems like the developers are very confident about it too

deleted 2y ago
[deleted]

havaker 2y ago

The license choice is explained with the following: > [...] we accommodate the business need for proprietary kernel modules. Unlike GPL, the MPL permits the linking of MPL-covered files with proprietary code. Glancing at the readme, it also looks like they are treating it as a big feature: > Asterinas surpasses Linux in terms of developer friendliness. It empowers kernel developers to [...] choose between releasing their kernel modules as open source or keeping them proprietary, thanks to the flexibility offered by MPL. Can't wait to glue some proprietary blobs to this new, secure rust kernel /s

yjftsjthsd-h 2y ago
I'm curious about the practical aspect: Are they going to freeze a stable driver ABI, or are they going to break proprietary drivers from time to time?
- gpm 2y ago
  Considering their OS as a framework approach I would guess they are more likely to expose a stable API than a stable ABI. Which also plays well with the MPL license (source file based) rather than something like the LGPL (~linking based).
  - throw4950sh06 2y ago
    This is the most interesting new OS I have seen in many years.

cryptonector 2y ago

> Linux-compatible ABI There's no specification of that ABI, much less a compliance test suite. How complete is this compatibility?

Klasiaster 2y ago
Here is a list of implemented syscalls, but of course each checked one could still be slightly incompatible: https://asterinas.github.io/book/kernel/linux-compatibility.html https://asterinas.github.io/book/kernel/linux-compatibility....
- cryptonector 2y ago
  There's also tons of ioctls and /proc and what not.
mgerdts 2y ago
While developing the lx brand on illumos/SmartOS, ltp was helpful. It may not be complete, but it is a pretty good start. https://linux-test-project.readthedocs.io/en/latest/ https://linux-test-project.readthedocs.io/en/latest/
- cryptonector 2y ago
  LTP really needs to be a part of Linux itself.

Klasiaster 2y ago

There was also the similar project Kerla¹ but development stalled. Recently people argued that instead of focusing on Rust-for-Linux it would be easier to create a drop-in replacement like these two. I wonder if there are enough people interested to make this happen as a sustained project. ¹ https://github.com/nuta/kerla/ https://github.com/nuta/kerla/

kelnos 2y ago
> Recently people argued that instead of focusing on Rust-for-Linux it would be easier to create a drop-in replacement like these two I guess it depends on what they mean by "easy". Certainly it's easier in the sense that you can just write code all day long, and not have to deal with the politics about Rust inside Linux, or deal with all the existing C interfaces, finding ways to wrap them in Rust in good, useful ways that leverage Rust's strengths but don't make it harder to evolve those C interfaces without trouble on the Rust side. But the bulk of Linux is device drivers. You can build a kernel in Rust (like Asterinas) that can run all of a regular Linux userland without recompilation, and I imagine it's maybe not even that difficult to do so. But Asterinas only runs on x86_64 VMs right now, and won't run on real hardware. Getting to the point where it could -- especially on modern hardware -- might take years. Supporting all the architectures and various bits of hardware that Linux supports could take decades. I suppose limiting themselves to three or four architectures, and only supporting hardware made more recently could cut that down. But still, it's a daunting project.

weinzierl 2y ago

Decades ago Linus Torvalds was asked in an interview if he feared Linux to be replaced by something new. His answer was that some day someone young and hungry would come along, but unless they liked writing device drivers Linux would be safe. This is all paraphrased from my memory, so take it with a grain of salt. I think the gist of it is still valid: Projects like Asterinas are interesting and have a place, but they will not replace Linux as we have it today. (Asterinas, from what I understood, doesn't claim to replace Linux, but it a common expectation.)

loeg 2y ago
More recently, in a similar vein: > Torvalds seemed optimistic that "some clueless young person will decide 'how hard can it be?'" and start their own operating system in Rust or some other language. If they keep at it "for many, many decades", they may get somewhere; "I am looking forward to seeing that". Hohndel clarified that by "clueless", Torvalds was referring to his younger self; "Oh, absolutely, yeah, you have to be all kinds of stupid to say 'I can do this'", he said to more laughter. He could not have done it without the "literally tens of thousands of other people"; the "only reason I ever started was that I didn't know how hard it would be, but that's what makes it fun". https://lwn.net/Articles/990534/ https://lwn.net/Articles/990534/
- ackfoobar 2y ago
  > Hohndel clarified that by "clueless", Torvalds was referring to his younger self As the saying goes "We do this not because it is easy, but because we thought it would be easy." Occasionally these are starts of great things.
  - nickpsecurity 2y ago
    Sometimes, we do such things because it’s hard. We enjoy the challenge. Those that succeed are glad to make it, too.
    - dathinab 2y ago

phlip9 2y ago

Super cool project. Looks like the short-term target use-case is running a Linux-compatible OS in an Intel TDX guest VM with a significantly safer and smaller TCB. Makes sense. This way you also postpone a lot of the HW driver development drudgery and instead only target VM devices.

hkalbasi 2y ago

> In the framekernel OS architecture, the entire OS resides in the same address space (like a monolithic kernel) and is required to be written in Rust. However, there's a twist---the kernel is partitioned in two halves ... the unprivileged Services must be written exclusively in safe Rust. Unprivileged services can exploit known compiler bugs and do anything they want in safe Rust. How this affects their security model?

rcxdude 2y ago
I think it's not so much intended as a "you can allow arbitrary untrusted code to run as an unprivileged service" and more "a buggy unprivileged service won't compromise the whole system".

snvzz 2y ago

I looked into the architecture. It turns out to be monolithic with marketing[0]. Sure is a lot of text to say: We try to use unsafe as little as possible. Which is the minimum you'd expect anyways ¯\_(ツ)_/¯ 0. https://asterinas.github.io/book/kernel/the-framekernel-architecture.html https://asterinas.github.io/book/kernel/the-framekernel-arch...

netbsdusers 2y ago
It's just what we used to call a "layered architecture".

exabrial 2y ago

I think this looks incredible. Like how does one create a compatible abi _for all of linux_??? Wow! > utilize the more productive Rust programming language Nitpick: it’s 2024 and these ‘more productive’ comparisons are silly, completely unscientific, And a bit of a red flag for your project: The most productive language for a developer is the one they understand what is happening one layer below the level of abstraction they are working with. Unless you’re comparing something rating Ruby vs RiscV assembly, it’s just hocus-pocus.

ozgrakkurt 2y ago
Everyone says what they are used to is better or more productive. Even in assembly vs ruby, some stuff are much easier in assembly and maybe impossible in ruby afaik
- exabrial 2y ago
  I’m aging myself, but ~17 years ago I was in San Diego for a conference. There was a table level competition to see who could write the fastest program in 20 minutes (we were doing a full text search of a ‘giant’ 5g file). One of the guys at the table wrote some SPARC assembly to optimize character matching that was a hotspot like he was speaking French. Ah good times.
kelnos 2y ago
> Like how does one create a compatible abi _for all of linux_??? You look at Linux's syscall table[0], read through the documentation to figure out the arguments, data types, flags, return values, etc., and then implement that in your kernel. The Linux ABI is just its "library" interface to userspace. It's probably not that difficult; writing the rest of the kernel itself is more challenging, and, frankly, more interesting. Certainly matching behavior and semantics can be tricky sometimes, I'm sure. And I wouldn't be surprised if the initial implementation of some things (like io_uring, for example, if it's even supported yet) might be primitive and poorly optimized, or might even use other syscalls to do their work. But it's doable. While Linux's internal ABI is unstable, the syscall interface is sacred. One of Torvalds' golden rules is you don't break userspace. [0] https://filippo.io/linux-syscall-table/ https://filippo.io/linux-syscall-table/

xiaodai 2y ago

Lol. I am Malaysian Chinese but I honestly don't think anyone will put into production a Chinese made kernel. The risk is too high, same as no one will use a Linux distro coming out of Russian, Iran or NK. It's just cultural bias in the west.

throw4950sh06 2y ago
You're wrong. A lot of Chinese code and hardware is in production in the west. Huawei networking hardware is widespread, for example.
- tredre3 2y ago
  > Huawei networking hardware is widespread That's an interesting example because Huawei equipment is currently being removed by several Western countries (UK, Canada, US, Germany) specifically because it's Chinese. https://www.nytimes.com/2024/07/11/business/huawei-germany-ban.html https://www.nytimes.com/2024/07/11/business/huawei-germany-b... https://www.cbc.ca/news/politics/huawei-5g-decision-1.6310839 https://www.cbc.ca/news/politics/huawei-5g-decision-1.631083... https://www.gov.uk/government/news/huawei-to-be-removed-from-uk-5g-networks-by-2027 https://www.gov.uk/government/news/huawei-to-be-removed-from... https://www.reuters.com/business/media-telecom/us-open-program-replace-huawei-equipment-us-networks-2021-09-27/ https://www.reuters.com/business/media-telecom/us-open-progr...
  - cozzyd 2y ago
    When we got a license for a private LTE network in the middle of the Greenland ice sheet, the one stipulation was we couldn't use Huawei equipment...
gpm 2y ago
Supposing it caught on... which do you think is riskier? Running an OS written in mostly memory safe code that somewhat might have tried to slip a backdoor in, or running an OS written in mostly memory unsafe code that has a long history of vulnerabilities and the Chinese almost certainly know about a vulnerability in. If this catches on and has generally been subject to significant third party code review with positive results, I'm not sure any backdoor is lower cost to use than an equivalent linux vulnerability. To be fair, I'm not sure it isn't either.

deleted 2y ago

[deleted]

wg0 2y ago

Side question - I have always wondered how a Linux system is configured at the lowest level? Let's take example of network. There's IP address, gateway, DNS, routes etc. Depending on distribution we might see something like netplan reading config files and then calling ABI functions? Or Linux kernel directly also reads some config files? Probably not...

NewJazz 2y ago
Linux kernel as much as possible tries not to parse or read external data (besides stuff like acpi tables, device trees, hardware registers). For networking, you might look at the iproute codebase to see how they do things like bring a network device up, or create a bridge device, add a route, et cetera. Edit: looks like iproute2 uses NETLINK, but non-networking tools might use syscalls or device ioctls. https://en.m.wikipedia.org/wiki/Netlink https://en.m.wikipedia.org/wiki/Netlink

wiz21c 2y ago

> Linux-compatible ABI Does it mean it can re-use the drivers written for hardware to run with linux ?

dezgeg 2y ago
No. There is no stable ABI nor API for in-kernel device drivers.
- apatheticonion 2y ago
  Do other mainstream kernels have a stable driver API? I guess the NT kernel needs to. Does Darwin?
eptcyka 2y ago
No. The drivers in Linux are kernel modules, most often in-tree - meaning that the source for the drivers is built along the rest of the kernel source code. Most hardware drivers depend on various common kernel structures that change often - when they do, the source for drivers is fixed practically in the same git branch. There is no driver ABI to speak of.

pjmlp 2y ago

Besides all examples, Microsoft is now using TockOS for Pluton firmware, another Rust based OS. https://tockos.org/ https://tockos.org/

prmoustache 2y ago

> docker run -it --privileged --network=host --device=/dev/kvm -v $(pwd)/asterinas:/root/asterinas asterinas/asterinas:0.9.3 Is that the new generation of curl | bashism in action?

wslh 2y ago
Is the "--privileged" option ironic here? The project is very interesting, but it feels a bit pedantic, especially when emphasizing Rust's safety features while downplaying Linux. At the same time, it seems they're not fully applying those principles themselves, which makes it feel like they're not quite 'eating their own lunch'.
- prmoustache 2y ago
  A bit below in the github readme there is a link to the handbook where they explain how to build and run the project using cargo: https://asterinas.github.io/book/osdk/guide/run-project.html https://asterinas.github.io/book/osdk/guide/run-project.html
oefrha 2y ago
Hardly different from downloading random binary installers and executing them. Or random source distributions and (sudo) make install. Or npm/pip/cargo/etc. install random packages. Before anyone mentions distros and package managers, as a former team member of a major package manager I can assure you we don’t vet shit beyond project notability, and new versions are accepted semi-automatically. We’ll yank something after the fact if you report a malicious update, sure. curl | bash has an actual problem: potential execution of an incomplete script (which can be mitigated with function calling). And there’s the mostly theoretical problem of the server being pwned / sending malicious code just to you (which of course also applies to any other unsigned channel). Arbitrary code execution is never a problem unique to it, but people dunk on it all the time because they saw another person dunking on it in the past.
- hnfong 2y ago
  > as a former team member of a major package manager I can assure you we don’t vet shit beyond project notability, and new versions are accepted semi-automatically An example that illustrates this: https://lwn.net/Articles/22991/ https://lwn.net/Articles/22991/ (And wow, it's been 22 years already...?)

sylware 2y ago

Linux is mostly a decades long maintained repository of real hardware programing code, and written in mostly simple "kernel" 'C', not some ultra complex syntax language (unfortunately, it has been tied to compiler specific extensions or "modern C" tantrums, _generic for instance). Have a look at AMD GPU driver. Massive, and full of 'stabilization/work around' code... happening all the time, for years. I guess, the real "first thing first" is to design hardware, performant hardware on latest silicon process , with a, as simple as possible, modern, standard and stable hardware programing interface. Because, for many types of hardware, 'now we know how to do it properly' (command hardware ring buffers usually, or a good compromise for modern CPU architecture, like RISC-V). Another angle of "cleanup", I guess it would be the removal of many of the C compiler extension (or "modern C") tantrums from linux, or at least proper alternatives with not-inline assembly to allow small and alternative compilers to step in. Personally, I tend to write rv64 assembly (which I interpret on x86_64), but for the userland. If I code C, I push towards mostly "simple and plain C99". The more I think about it, the more I get the following coming to my mind: 'hardware with simple standard interfaces' and standard assembly for the kernel.

artemonster 2y ago
Huh? What is this nonsense?? Are you suggesting that you like to write practical-oriented, simple and working solutions instead of yak shaving half a day at perfecting ridiculous type signatures, removing „unsafe“ code and satisfying borrow checker? Proposterous! /s

a99c43f2d565504 2y ago

Zig kernel when

bigfishrunning 2y ago
When someone writes one

rpgraham84 2y ago

oh cool, now I can have an unverifiable kernel from a team in China

mococa 2y ago

This is exactly what I was discussing with a friend who works on the kernel. I don’t think Rust should be supported; the kernel should remain in C. Instead, a completely new kernel in Rust should be created with API/ABI compatibility with the original kernel.

apatheticonion 2y ago
Shame about the lack of a stable kernel driver ABI/API in Linux otherwise this kernel could inherent a lot of drivers.

fithisux 2y ago

Now we need Rust Windows compatible kernel to save us from Recall.

apatheticonion 2y ago

I wish I could work on this as my paid day job. As soon as I can financially retire, I'll make contributing to this my full time job!

hulitu 2y ago

> Asterinas: OS kernel written in Rust and providing Linux-compatible ABI > Currently, Asterinas only supports x86-64 VMs. So no real hardware.