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).
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?
> 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?
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.
Couldn't you just boot the Linux kernel directly and launch a generic app as pid 1 instead of a full blown init system with a bunch of daemons?
That's basically what you're getting with Docker containers and a shared kernel. AWS Lambda is doing something similar with dedicated kernels with Firecracker VMs
If you want truly high-performance networking, you can bypass the kernel altogether with DPDK. So you don't have to worry about alternative kernels for other tasks at all. On the downside, DPDK takes over the NIC entirely, removing the kernel from the equation, so if you need the kernel to see network traffic for some reason, it won't work for you.
Their conclusion is io_uring is still slower but not by much, and future improvements may make the difference negligible. So you're right, at least in part. Given the tradeoffs, DPDK may not be worth it anymore.
There are also just a bunch of operational hassles with using DPDK or SPDK. Your usual administrative commands don't work. Other operations aren't intermediated by the kernel -- instead you need 100% dedicated application devices. Device counters usually tracked by the kernel aren't. Etc. It can be fine, but if io_uring doesn't add too much overhead, it's a lot more convenient.
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.
Linux doesn't even maintain ABI compatibility with itself, nobody else is going to manage it. The possibility that might work is there's a couple projects that maintain just enough API compatibility to reuse driver code from Linux (IIRC FreeBSD does this for some graphics drivers). But even then you're gambling with whether Linux decides to change implementation details one day, since internal APIs explicitly aren't stable.
The Linux kernel community takes ABI compatibility for userland very seriously. That developers in userland are frequently unwilling to understand issues surrounding ABI stability is not the fault of the Linux kernel.
> 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.
It's a lot "simpler" to support a Linux userland as that means one needs to "just" emulate all the Linux syscalls, than to implement the literally countless internal APIs needed for drivers etc, as that would otherwise mean literally reimplementing the whole Linux kernel and that's neither realistic, nor too useful.
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.
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.)
> 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".
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.
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
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.
I think it’s “Currently, Asterinas only supports x86-64 VMs. However, [rather than working on additional architectures this year,] our aim for 2024 is to make Asterinas production-ready on x86-64 VMs.”
> 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.
it would be nice to know how much userspace it supports. supporting the dynamic loader, reasonable futexes, epoll, signals, uring are all big milestones
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
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?
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).
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!
Rust code is usually well commented in my experience.
for the downvoters: it’s true, and it’s because of rustdoc and doccomment tests.
think the downvotes are because of relevance. point was not using advanced rust features, not being documented
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?
I expect the downvotes to be there because it's talking positively about rust, which is blasphemy! /j
[dead]
> 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?
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.
Couldn't you just boot the Linux kernel directly and launch a generic app as pid 1 instead of a full blown init system with a bunch of daemons?
That's basically what you're getting with Docker containers and a shared kernel. AWS Lambda is doing something similar with dedicated kernels with Firecracker VMs
Yes, you can. You can even have a different Pid 1 configure whatever and then replace it's core image with the new Pid 1.
If you want truly high-performance networking, you can bypass the kernel altogether with DPDK. So you don't have to worry about alternative kernels for other tasks at all. On the downside, DPDK takes over the NIC entirely, removing the kernel from the equation, so if you need the kernel to see network traffic for some reason, it won't work for you.
You can check out hardware support here: https://core.dpdk.org/supported/nics/
This was true a decade ago, with modern io_uring dpdk is probably an anti-pattern.
Interesting, it's been awhile since I looked at this stuff so I did a little searching and found this: https://www.diva-portal.org/smash/get/diva2:1789103/FULLTEXT...
Their conclusion is io_uring is still slower but not by much, and future improvements may make the difference negligible. So you're right, at least in part. Given the tradeoffs, DPDK may not be worth it anymore.
There are also just a bunch of operational hassles with using DPDK or SPDK. Your usual administrative commands don't work. Other operations aren't intermediated by the kernel -- instead you need 100% dedicated application devices. Device counters usually tracked by the kernel aren't. Etc. It can be fine, but if io_uring doesn't add too much overhead, it's a lot more convenient.
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....
Linux doesn't even maintain ABI compatibility with itself, nobody else is going to manage it. The possibility that might work is there's a couple projects that maintain just enough API compatibility to reuse driver code from Linux (IIRC FreeBSD does this for some graphics drivers). But even then you're gambling with whether Linux decides to change implementation details one day, since internal APIs explicitly aren't stable.
The Linux kernel community takes ABI compatibility for userland very seriously. That developers in userland are frequently unwilling to understand issues surrounding ABI stability is not the fault of the Linux kernel.
Oh sure, the user-space ABI is stable; I meant kernel-space. Although I realize now that I failed to write that explicitly.
They mention this in 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.
It's a lot "simpler" to support a Linux userland as that means one needs to "just" emulate all the Linux syscalls, than to implement the literally countless internal APIs needed for drivers etc, as that would otherwise mean literally reimplementing the whole Linux kernel and that's neither realistic, nor too useful.
> emulate all the Linux syscalls
and emulate the virtual filesystems (/proc/...)
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.
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/
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
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.
OT: if you're interested in Asterinas, you might also be interested in Redox (entire OS written in Rust).
https://www.redox-os.org/
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
https://gitlab.redox-os.org/redox-os/kernel/-/tree/master/sr...
I’ll mention another OS written in Rust, Twizzler: https://twizzler.io/
Its more of a research OS but still cool.
And I'll mention another one that a friend of mine is working on: uxrt
https://gitlab.com/uxrt
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/
> Linux-compatible ABI
There's no specification of that ABI, much less a compliance test suite. How complete is this compatibility?
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....
There's also tons of ioctls and /proc and what not.
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 think it’s “Currently, Asterinas only supports x86-64 VMs. However, [rather than working on additional architectures this year,] our aim for 2024 is to make Asterinas production-ready on x86-64 VMs.”
Sounds like their goal is to improve their x86-64 support before implementing other ISAs.
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
Distinction here is between "supports" and "production-ready on", not "x86-64" and "x86-64"
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.
it would be nice to know how much userspace it supports. supporting the dynamic loader, reasonable futexes, epoll, signals, uring are all big milestones
Check it out https://asterinas.github.io/book/kernel/linux-compatibility....
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.
What’s the intended use case for this? Backend containers?
Makes a lot of sense for virtual machine containers. Inside a container inside a VM, you need far less operating system.
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
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
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?
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).
This is the most interesting new OS I have seen in many years.