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

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

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/

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

I feel like there's a potentially large audience for a kernel that targets running in a VM. For a lot of workloads, a simple VM kernel could be a win.

Sometimes, we do such things because it’s hard. We enjoy the challenge. Those that succeed are glad to make it, too.

How is that different from Linux with all virtio drivers? (You can just not compile real hardware drivers)

"You are enthusiastic and write kernel device drivers in rust. Write a device driver for an Intel i350 4 Port gigabit ethernet controller"

I would imagine that virtualized device drivers would have a well-defined api and vastly simplified logic.

I imagine they do. But given that Linux has those simple drivers, why not use them?

Also this mysterious new Fuchsia OS from Google is also shooting for full Linux compatibility and is about to show up in Android, I think this is a much more realistic path of the next generation of operating systems that have a real chance to replace Linux but who knows what their actual plans are here at the moment but I don’t believe for a moment that that project is dead in any way.

Can you give more details about it being used in Android? I thought they started using it in some small devices like nest but haven’t heard anything about Android

Some future VC-funded company will unironically have this same requirement

It wasn't a requirement, it was a prompt :)

Haha damn, it’s so obvious now. I should be asleep.

This is already the reality today with native cloud computing, managed runtimes.

It doesn't matter how the language gets deployed, if the runtime is on a container, a distroless container, or directly running on an hypervisor.

The runtime provides enough OS like services for the programming language purposes.

I wonder if decision for stable syscalls was genius? Like imagine that Linux syscalls will become what C ABI is now. And there will be multiple compatible kernels, so you can choose any and run the same userspace.

but most times, even in such cases, people underestimate or not estimate at all the "hard task they do as a challenge" it's kinda part of the whole thing

It’s about to turn up inside Android running in a VM [1] but it was less clear exactly for what purpose.

My theory is that this is essentially a long term project to bring the core of Chrome OS and Android to rely on Fuschia for its core which gives them syscall level compatibility with what they both use at the moment and that they would both essentially sit as products on top of that.

This is essentially the exact strategy they used if I remember correctly with the Nest devices where they swapped out the core and left the product on top entirely unchanged. Beyond that in a longer term scenario we might also just see a Fuchsia OS as a combined mobile / desktop workstation setup and I think part of that is also why we are seeing ChromeOS starting to take a dependency on Android’s networking stack as well right now.

[1] https://www.androidauthority.com/microfuchsia-on-android-345...

LLMs are notoriously bad at improvising device drivers in no-std Rust.

Just ask an AI to riir linux drivers. Anybody tried it?

Sometimes we just don’t know if a person that started something did know how hard it would be or not. Sometimes it is not possible to know how hard things can be or not.

Generally this is a very interesting question hat could be discussed in a very long thread, but still the reader will not get any value from it.

this x1000

Provided you have virtio support you are ticking a lot of boxes already.

Shouldn't we start building hardware that have a builtin translation layer that makes them driveable by virtio drivers themselves? At least for the most capabilities?

Claude Sonnet 3.5 seemed happy enough to do it, and the start looked promising

     Absolutely! Let's dive into writing a device driver for the Intel i350 4 Port Gigabit Ethernet Controller using Rust. This is an exciting project that combines low-level hardware interaction with the safety and performance benefits of Rust. I'll create a basic structure for our driver, focusing on the key components needed to interact with the device.

    #![no_std]
    #![feature(abi_x86_interrupt)]    
    ...

but I'm not qualified to judge the quality from eyeballing and I'm certainly not going to go to the trouble of trying to test it.

The point is it would be better than Linux in whatever way that was the reason you were writing it, but you don't have to write hundreds of different device drivers to make your cool new kernel usable.

Those workloads would probably be better off as unikernels that can run directly on the VM, avoiding the question of which kernel to use entirely.

You jest, but I believe @tptacek is using an LLM (ChatGPT?) to understand the details of various Linux kernel subsystem and has said it works quite well for the task.

It's not a great jump from that to "port Linux device driver for XYZ to this new OS in Rust". Won't be perfect but a lot less hassle than doing it from scratch.

There's a difference between "want to run an application with as little extra move parts on a VM" and "want to take an existing system and swap out for a kernel with some better properties, even if it means needing to run it in a VM"

If it's written in rust, you might expect less security vulnerabilities (especially if the codebase is also smaller: NB this is potentially counterbalanced by the many eyes on linux). Maybe there would be some extra features you find useful.

Why would you want to support multiple? New versions should always be backwards compatible with older ones, so you'll always have the largest amount of compatibility by targeting the latest upstream. The real challenge comes with supporting applications that want features only available in forked kernels, which I guess could prompt wanting multiple kernels targeting the distinct ABIs.

You can ask the same question about libc, yet there are several competing implementations. Yes, compatibility is not perfect and there are applications which won't work on musl, but still plenty of applications do.

This is a very large rationale for what we are building with https://nanos.org .

"You are a pessimistic and pedantic tester of device drivers. test the following device driver for conformance to the rust language, to the kernel api, to hardening standards, judging the quality following iso 29119."

I might be misremembering but I recall that Nvidia's BlueField DPUs use virtio when communicating with the host machine. From what I gather searching around it's virtio-net in specific