[HN Gopher] Asterinas: OS kernel written in Rust and providing L...
       ___________________________________________________________________
        
       Asterinas: OS kernel written in Rust and providing Linux-compatible
       ABI
        
       Author : Klasiaster
       Score  : 113 points
       Date   : 2024-10-15 12:01 UTC (10 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | tiffanyh wrote:
       | OT: if you're interested in Asterinas, you might also be
       | interested in Redox (entire OS written in Rust).
       | 
       | https://www.redox-os.org/
        
         | metaketa wrote:
         | 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 wrote:
           | https://gitlab.redox-os.org/redox-
           | os/kernel/-/tree/master/sr...
        
       | spease wrote:
       | What's the intended use case for this? Backend containers?
        
         | Animats wrote:
         | Makes a lot of sense for virtual machine containers. Inside a
         | container inside a VM, you need far less operating system.
        
       | akira2501 wrote:
       | 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 wrote:
         | Rust code is usually well commented in my experience.
        
           | cies wrote:
           | 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?
        
       | depressedpanda wrote:
       | 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.
        
         | MattPalmer1086 wrote:
         | 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 wrote:
         | Sounds like their goal is to improve their x86-64 support
         | before implementing other ISAs.
        
         | nurb wrote:
         | 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
        
         | convolvatron wrote:
         | it would be nice to know how much userspace it supports.
         | supporting the dynamic loader, reasonable futexes, epoll,
         | signals, uring are all big milestones
        
         | wrs wrote:
         | 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."
        
         | None4U wrote:
         | Distinction here is between "supports" and "production-ready
         | on", not "x86-64" and "x86-64"
        
       | valunord wrote:
       | 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 wrote:
       | I'll mention another OS written in Rust, Twizzler:
       | https://twizzler.io/
       | 
       | Its more of a research OS but still cool.
        
         | Teever wrote:
         | And I'll mention another one that a friend of mine is working
         | on: uxrt
         | 
         | https://gitlab.com/uxrt
        
       | treeshateorcs wrote:
       | 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
        
       | justmarc wrote:
       | 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.
        
         | treeshateorcs wrote:
         | 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....
        
           | justmarc wrote:
           | 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 wrote:
           | They mention this in https://github.com/asterinas/asterinas/b
           | lob/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.
        
             | justmarc wrote:
             | 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.
        
               | Jyaif wrote:
               | > emulate all the Linux syscalls
               | 
               | and emulate the virtual filesystems (/proc/...)
        
           | yjftsjthsd-h wrote:
           | 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 A
           | _P_ I 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.
        
             | bcrl wrote:
             | 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.
        
               | yjftsjthsd-h wrote:
               | Oh sure, the user-space ABI is stable; I meant kernel-
               | space. Although I realize now that I failed to write that
               | explicitly.
        
         | cgh wrote:
         | 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/
        
           | jauntywundrkind wrote:
           | This was true a decade ago, with modern io_uring dpdk is
           | probably an anti-pattern.
        
             | cgh wrote:
             | 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.
        
         | nijave wrote:
         | 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
        
           | mjevans wrote:
           | 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.
        
       | jackhalford wrote:
       | 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
        
       | havaker wrote:
       | 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 wrote:
         | 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?
        
       | cryptonector wrote:
       | > Linux-compatible ABI
       | 
       | There's no specification of that ABI, much less a compliance test
       | suite. How complete is this compatibility?
        
         | Klasiaster wrote:
         | 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....
        
           | cryptonector wrote:
           | There's also tons of ioctls and /proc and what not.
        
       | Klasiaster wrote:
       | There was also the similar project Kerla1 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.
       | 
       | 1 https://github.com/nuta/kerla/
        
       | weinzierl wrote:
       | 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.)
        
       ___________________________________________________________________
       (page generated 2024-10-15 23:00 UTC)