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.
OT: if you're interested in Asterinas, you might also be interested in Redox (entire OS written in Rust).
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.
Besides all examples, Microsoft is now using TockOS for Pluton firmware, another Rust based OS.
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
I’ll mention another OS written in Rust, Twizzler: https://twizzler.io/
Its more of a research OS but still cool.
> 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?
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.
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.
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.
> Linux-compatible ABI
There's no specification of that ABI, much less a compliance test suite. How complete is this compatibility?
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.
What’s the intended use case for this? Backend containers?
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...
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-arch...
> Linux-compatible ABI
Does it mean it can re-use the drivers written for hardware to run with linux ?
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!
> Asterinas: OS kernel written in Rust and providing Linux-compatible ABI
> Currently, Asterinas only supports x86-64 VMs.
So no real hardware.
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.
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.
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
Zig kernel when
Now we need Rust Windows compatible kernel to save us from Recall.
oh cool, now I can have an unverifiable kernel from a team in China
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.)
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
> 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?
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.
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!