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

Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

github.com

Post reply on HN
Print view View original

121–130 of 196 posts

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#121

Post by PaulDavisThe1st »

jacquesm wrote: post #60

Rewriting the Linux kernel in rust would be a rehash of why we ended up with Linux in the first place: rewriting an older OS from scratch. I would love to see a solid implementation of a real micro kernel based OS based on a message passing core in Rust to become a viable alternative to the now 50 year old Unix architecture. This would give us a possibility of some real progress on the security and process scheduling…

Mach's internals didn't follow the Unix model, and was by almost any metric a failure.

There have been several other "real micro kernel based OS based on a message passing core", and they too, by almost any metric, have been a failure.

Process scheduling in Linux in 2021 is far, far ahead of anything in any other OS, ukernel or MP-based. The idea that there hasn't been progress in this area is really completely absurd. In fact, the general idea that Linux follows "the now 50 year old Unix architecture" is also pushing the boundaries quite a lot.

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#122

Post by bcantrill »

panick21_ wrote: post #107
bcantrill wrote: post #101

Earlier quoted context omitted.

This is a very reasonable inference, as it absolutely was when I gave that talk. ;) Very shortly after that talk, however, we came to the realization that the OpenTitan was not going to be what we needed when we needed it, and moved to a Cortex M7-based microcontroller for our service processor (and a separate M33-based microcontroller for our root of trust); Hubris is the operating system that runs on those two MCUs…

Not that it matters all that much, but why a Cortex when you can get RISC-V chips form SiFive (or whoever) that do about the same stuff? Does that mean the product will not have an FPGA? I kind of liked that idea of updating the hardware. P.S: Twitter spaces about the history of computing are really fun. Love to hear more about all the dead computer companies you researched. There is not enough content about computer…

Yeah... a bunch of reasons. We definitely have a couple of FPGAs in the product (Bluespec FTW!), and we anticipate that we will have more over time -- but not for the RoT or SP, or at least not now. The reasons are different for each, but include:

1. ASICs are out of the question for us for a bunch of economic reasons

2. FPGAs by and large do not have a good security story

3. The ones that do (or rather, the one that does) has an entirely proprietary ecosystem and a terrible toolchain -- and seems to rely on security-through-obscurity

4. Once you are away from a softcore, the instruction set is frankly less material than the SoC -- and the RISC-V SoC space is still immature in lots of little ways relative to the Cortex space

5. Frankly, there's a lot to like about ST: good parts, good docs, good eval boards, pretty good availability (!), minimum of proprietary garbage.

We tried really hard (and indeed, I think my colleagues would say that I probably tried a little too hard) to get FPGAs to be viable, and then to get FPGAs + hardcores to be viable, and then multicore hardcores to be viable (one for the SP, one for the RoT). Ultimately, all of these paths proved to be not yet ready. And while we're big believers in FPGAs and RISC-V, we're even bigger believers in our need to ship a product! ;)

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#123

Post by PaulDavisThe1st »

afr0ck wrote: post #117
jacquesm wrote: post #60

Rewriting the Linux kernel in rust would be a rehash of why we ended up with Linux in the first place: rewriting an older OS from scratch. I would love to see a solid implementation of a real micro kernel based OS based on a message passing core in Rust to become a viable alternative to the now 50 year old Unix architecture. This would give us a possibility of some real progress on the security and process scheduling…

Why do people implicitly assume that micro kernels are the best OS design? In fact, micro kernels have a lot of issues and limit the possibilities of what an OS can do! One of the most important issues is they prevents resource sharing in a rich and efficient way between the components of the kernel. They make building rich relationships between kernel data structures and kernel subsystems very messy, complicated, im…

This is a limitation of the memory model, not the microkernel. If you had a single hardware-protected address space, kernel modules could share resources freely.

But this does argue against message passing, since such systems preferentially try to use messages over sharing whenever it's possible.

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#124

Post by bcantrill »

bcantrill wrote: post #122
panick21_ wrote: post #107

Earlier quoted context omitted.

Not that it matters all that much, but why a Cortex when you can get RISC-V chips form SiFive (or whoever) that do about the same stuff? Does that mean the product will not have an FPGA? I kind of liked that idea of updating the hardware. P.S: Twitter spaces about the history of computing are really fun. Love to hear more about all the dead computer companies you researched. There is not enough content about computer…

Yeah... a bunch of reasons. We definitely have a couple of FPGAs in the product (Bluespec FTW!), and we anticipate that we will have more over time -- but not for the RoT or SP, or at least not now. The reasons are different for each, but include: 1. ASICs are out of the question for us for a bunch of economic reasons 2. FPGAs by and large do not have a good security story 3. The ones that do (or rather, the one that…

Also, where are my manners?! Really glad you're enjoying our Twitter Spaces[0] -- and thank you for the kind words!

[0] https://github.com/oxidecomputer/twitter-spaces

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#125

Post by pjmlp »

jedimastert wrote: post #116
pjmlp wrote: post #113

Earlier quoted context omitted.

I have a A* search algorithm and a toy compiler that I use exactly for the same purpose. I just rewrite them all the time as means to get a feeling about programming languages. I dumped a couple of other stuff on GitHub so that HR people are happy to get a link that they never read anyway. Then I get back to Java and .NET at the office. :)

I've actually been considering adding a toy compiler to my collection of getting-up-to-speed projects, do you mind sharing what you think are good features?

Try to follow along the Tiger Book, in the variant that appeals to you.

https://www.cs.princeton.edu/~appel/modern/

It covers most areas quite alright even if a bit aged.

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#126

Post by yjftsjthsd-h »

nuta wrote: post #64
qwerty456127 wrote: post #57

Earlier quoted context omitted.

Even "rewriting Linux in Rust" is far from a waste if you make it run and if your code quality is good enough for others to join. If only you could write an entirely new (meant to be better, for some cases at least) kernel compatible with Linux hardware drivers - this would be not waste at all but in fact fantastic.

The most challenging point is, as others said, the lack of the compatibility with Linux Driver API. I believe it would be really hard to implement and keep following changes in Linux. An idea in my mind is to use Kerla for virtualized environments like KVM where only limited device drivers are needed (virtio for example).

> The most challenging point is, as others said, the lack of the compatibility with Linux Driver API. I believe it would be really hard to implement and keep following changes in Linux.

Especially since, as I understand it, even Linux isn't compatible with the Linux driver API across versions; they can and will change internals at will and just update in-tree drivers to match. Hence some of the difficulty doing things like getting a newer kernel on assorted embedded devices (ex. 99% of phones) because you have to port the vendor's drivers to the new version and both sides changed stuff.

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#127

Post by dnautics »

jacquesm wrote: post #60

Rewriting the Linux kernel in rust would be a rehash of why we ended up with Linux in the first place: rewriting an older OS from scratch. I would love to see a solid implementation of a real micro kernel based OS based on a message passing core in Rust to become a viable alternative to the now 50 year old Unix architecture. This would give us a possibility of some real progress on the security and process scheduling…

I believe someone is building something like that on top of sel4, which gives even stronger correctness guarantees than Rust, even though it's C.

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#128

Post by phkahler »

EdSchouten wrote: post #66

This is awesome. Imagine the potential if it was just complete enough to run Kubernetes’ kubelet on a cloud instance. Lots of security minded folks would love it.

That's IMHO how you get something like this off the ground. Make it useful for a simple use-case while offering something of value - in this case the security of Rust. It can then become a preferred solution to some problem and that will bring users and developers looking to incrementally expand it.

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#129

Post by dnautics »

PaulDavisThe1st wrote: post #121
jacquesm wrote: post #60

Rewriting the Linux kernel in rust would be a rehash of why we ended up with Linux in the first place: rewriting an older OS from scratch. I would love to see a solid implementation of a real micro kernel based OS based on a message passing core in Rust to become a viable alternative to the now 50 year old Unix architecture. This would give us a possibility of some real progress on the security and process scheduling…

Mach's internals didn't follow the Unix model, and was by almost any metric a failure. There have been several other "real micro kernel based OS based on a message passing core", and they too, by almost any metric, have been a failure. Process scheduling in Linux in 2021 is far, far ahead of anything in any other OS, ukernel or MP-based. The idea that there hasn't been progress in this area is really completely absur…

> "real micro kernel based OS based on a message passing core", and they too, by almost any metric, have been a failure.

BeOS wasn't half bad. The failure was probably mostly commercial. It is true that they moved their networking stack into the kernel, but it's not entirely clear to me that they had to do that, it was just the most expedient way to get acceptable performance and stability given the (programmer-time) resourcing constraints of the project.

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#130

Post by robocat »

krater23 wrote: post #73
roblabla wrote: post #23

Earlier quoted context omitted.

Linux drivers don't have a fixed ABI (or even API), making such a feat somewhere between hard and impossible. You'd have to constantly play catch up with the latest kernel refactorings, which would require a tremendous amount of engineering effort. Heck, it'd probably be easier to emulate the Windows driver architecture - at least those have proper ABI compat.

>Heck, it'd probably be easier to emulate the Windows driver architecture - at least those have proper ABI compat. And better drivers.

Actually many Linux drivers are far better than their Windows counterparts - many Windows drivers are complete shit. It is entirely dependant on your particular hardware. I know the driver for my WiFi in my laptop is far crappier in Windows for example.
Post reply on HN