Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Asterinas: A new Linux-compatible kernel project

lwn.net

Post reply on HN
Print view View original

51–60 of 81 posts

Re: Asterinas: A new Linux-compatible kernel project

#51

Post by ninkendo »

daeken wrote: post #47
digdugdirk wrote: post #41

Earlier quoted context omitted.

Hmmm... Would containers + AI enable a scattershot "just let the LLM keep trying stuff until it works" approach to driver development?

Given the number of times I've bricked hardware during reverse-engineering and driver development, I don't find it super likely, tbh. I'm by no means an expert here, but it's one of those things where if you already have good enough documentation (which in this case could be a known-good implementation) then it's more of a translation task and LLMs could absolutely be helpful there, but the edge cases are sharp and f…

It's interesting though, because you don't really need to reverse engineer anything if the device has an in-tree Linux driver. You "just" need to port the Linux driver to your OS. This is certainly something an LLM can help with, although the usual skepticism applies (it works until it doesn't, etc.)

In fact I sometimes wonder whether it's feasible to write a new kernel while somehow shimming into Linux's driver model, while still keeping your own kernel unique (ie. not just a straight clone of Linux itself.) Some way of "virtualizing" the driver layer so that a driver can "think" it's in a Linux kernel but with a layer of indirection to everything somehow.

Re: Asterinas: A new Linux-compatible kernel project

#52

Post by nickpsecurity »

weinzierl wrote: post #24

This is an interesting approach, and I wish it will succeed. I am still skeptical. In the late 90s or early 2000s Linus was interviewed on TV and what he said stuck with me to this day. When asked about competitors he roughly said: No one likes writing device drivers and as long no one young and hungry comes along who is good at writing device drivers I am save. I think he was already well aware at that time that kee…

Prior art includes SPIN OS (Modula 3), JX OS (Java), House OS' H-Layer (Haskell), and Verve. Each one had a type-safe, memory-safe language for implementing the features. They usually wall off the unsafe stuff behind checked, function calls. Some use VM's, too.

Ignoring performance or adoption, the main weaknesses are: abstraction, gap attacks; unsafe code bypassing the whole thing; compiler or JIT-induced breakage of safety model; common, hardware failures like cosmic rays. This is still far safer than kernels and user apps in unsafe languages.

One can further improve on it by using static analysis of unsafe code, ensuring all unsafe functions respect type-safe/memory-safe interfaces, compilers that preserve abstraction safety during integration, and certified compilers for individual components. We have production tools for all except secure, abstract compilation which (a) is being researched and (b) can be checked manually for now.

Re: Asterinas: A new Linux-compatible kernel project

#53

Post by plingbang »

vbezhenar wrote: post #22

Is it novel development: splitting kernel into small unsafe core and large safe modules? It sounds very interesting and promising. No hardware overhead of microkernel and no safety issues of monolith. Such a project, obviously, depends on a systems language with explicit unsafe/safe separation.

A very close idea was jokingly suggested in The Birth & Death of JavaScript[1] at 18:07 (rewind to 14:14 for more context)

[1]: https://www.destroyallsoftware.com/talks/the-birth-and-death...

Re: Asterinas: A new Linux-compatible kernel project

#54

Post by anthk »

reactordev wrote: post #36
tatetian16 wrote: post #29

Earlier quoted context omitted.

> keeping the driver interface unstable is his moat Maybe we will have young and hungry AI-for-system researchers who would like to take on the job of developing AI agents that translate Linux drivers in C to Asterinas ones in (safe) Rust. Another feasible approach is to reuse Linux drivers by running a Linux kernel inside some kind of isolated environments. For example, the HongMeng kernel leverages User-Mode Linux…

This is the future. Hardware has already standardized more towards USB HID than in previous decades, Linus interview included. When AI can develop these device drivers based on just probing the HID info, we’ll be on Cloud9. Because maybe then, we’ll get the year of the Linux desktop.

USB it's a nightmare.

Re: Asterinas: A new Linux-compatible kernel project

#55

Post by Vilian »

pjmlp wrote: post #48
yjftsjthsd-h wrote: post #34

Earlier quoted context omitted.

> while running tons of containers for basic tasks. Those containers run on a monolithic kernel; what's your point?

The supposed performance gains from monolithic kernel being wasted on features that mimic microkernel features.

And still manage to run better than a complete microkernel

Re: Asterinas: A new Linux-compatible kernel project

#56

Post by pjmlp »

Vilian wrote: post #55
pjmlp wrote: post #48

Earlier quoted context omitted.

The supposed performance gains from monolithic kernel being wasted on features that mimic microkernel features.

And still manage to run better than a complete microkernel

So goes the mythological tales from ancient times.

That is what happens when people don't update themselves.

Re: Asterinas: A new Linux-compatible kernel project

#57

Post by weinzierl »

jitl wrote: post #43
weinzierl wrote: post #24

This is an interesting approach, and I wish it will succeed. I am still skeptical. In the late 90s or early 2000s Linus was interviewed on TV and what he said stuck with me to this day. When asked about competitors he roughly said: No one likes writing device drivers and as long no one young and hungry comes along who is good at writing device drivers I am save. I think he was already well aware at that time that kee…

On the other hand, running on real hardware is less important if none of your hardware is real! 98% of Linux I interact with is running virtualized: on my desktop/laptop systems it’s either Virtualbox full-screened so I can use Windows for drivers, or a headless VM managed by Docker.app on my Mac. All my employer’s production workloads are AWS virtual machines. My only Linux bare metal hardware is a home server, whic…

In computer science we are taught it's turtles all the way down but in the real world you learn that you hit the world of bits and bytes really fast.[1]

My point is that every virtualized environment needs a layer that talks to real hardware down below. We have enough diversity in the upper layers but not enough in the lowest layer.

[1] I heard it expressed like this from an Azul Systems employee first, but unfortunately don't remember who it was.

Re: Asterinas: A new Linux-compatible kernel project

#58

Post by rwmj »

yjftsjthsd-h wrote: post #4

> This IPC often has a performance impact, which is a big part of why microkernels have remained relatively unpopular. I thought newer microkernels... Reduced that? Fixed it? I forget, I just had the impression it wasn't actually that bad except that the industry is still traumatized by Mach. From the project website: > Only the privileged Framework is allowed to use unsafe features of Rust, while the unprivileged Se…

> I thought newer microkernels... Reduced that? Fixed it?

They have.

Actually the elephant in the room is modern hardware which makes even syscalls into monolithic kernels expensive. That's why io_uring and virtio perform well - they queue requests and replies between the OS and applications (or the hypervisor and the guest for virtio) avoiding transitions between address spaces. Any operating system in the future is going to need some kind of queuing syscall mechanism to perform well, and once you've got it doesn't much matter if you structure the components of your OS as a monolith or microkernel or something else.

Re: Asterinas: A new Linux-compatible kernel project

#59

Post by reactordev »

anthk wrote: post #54
reactordev wrote: post #36

Earlier quoted context omitted.

This is the future. Hardware has already standardized more towards USB HID than in previous decades, Linus interview included. When AI can develop these device drivers based on just probing the HID info, we’ll be on Cloud9. Because maybe then, we’ll get the year of the Linux desktop.

USB it's a nightmare.

Sarcasm is too for some

Re: Asterinas: A new Linux-compatible kernel project

#60

Post by yjftsjthsd-h »

pjmlp wrote: post #48
yjftsjthsd-h wrote: post #34

Earlier quoted context omitted.

> while running tons of containers for basic tasks. Those containers run on a monolithic kernel; what's your point?

The supposed performance gains from monolithic kernel being wasted on features that mimic microkernel features.

> The supposed performance gains from monolithic kernel being wasted on features that mimic microkernel features.

So two things:

1. Containers don't have a meaningful performance hit. (They are semi-frequently used with things that can have a perf hit, like overlay filesystems, but this is generally easy to skip when it matters.)

2. I don't think containers meaningfully mimic microkernel features. If I run everything on my laptop in a container, and a device driver crashes, then the machine is still hosed.

Post reply on HN