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

91–100 of 196 posts

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

#91

Post by cormacrelf »

cormacrelf wrote: post #77
abendstolz wrote: post #72

Earlier quoted context omitted.

Oh, wow, I was under the impression that the error message would be stack only, no heap involved, but as Result is part of the std library and not of core, this totally makes sense. So for `Rust for Linux` they also need to implement a `Result-like` type that is stack only based to solve this issue, right? If so, cool, thanks, you just made my day by tickling my learning nerves! :)

It has nothing to do with Result, whatsoever. Result does not allocate. If you used a Result that way, you could certainly try to "gracefully" handle the allocation failure, but if you think it would be easy, you would be wrong. As Tialaramex said, you are probably just going to make the problem worse because it is very difficult to ensure you do not attempt to allocate during allocation-failure-recovery. Rustc doesn…

An addendum to tie this back to the original discussion: the reason kernel devs want these APIs more than userland is that (a) in a kernel, panicking = crashing the computer, which would be bad, and (b) they have a much bigger toolbox for handling OOM.

They can kill entire misbehaving processes. What are you going to do in your little program, clear a cache whose objects are sprinkled evenly across 150 different pages? You would need more control than you get from blindly using malloc/free/rust_alloc globally. Something like memcached would be able to use these APIs, because it uses its own allocator, and knows enough about its layout to predictably free entire pages at once.

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

#92

Post by geofft »

maleldil wrote: post #43
fork-bomber wrote: post #31

Earlier quoted context omitted.

The Rust for Linux kernel project aims to enable writing Linux kernel device drivers in Rust. See: https://lwn.net/Articles/862018/ The issue of Rust's LLVM based compiler toolchain not targeting all CPU archs is intended to be solved by the gcc-rs project. See: https://lwn.net/Articles/871283/ I think the approach the Rust for Linux project is taking is wise: Not about outright re-writes but more about focusing on t…

Last I checked, one of the big problems was the Rust panics when you run out of memory, which is unacceptable in the kernel. Is there any progress on that?

Yes, this is called "fallible allocations." You add methods with the "try_" prefix that work like the existing methods, except they return a Result which fails if it's out of memory instead of panicking.

We have a light / temporary fork of the Rust stdlib allocator with fallible allocation support: https://github.com/Rust-for-Linux/linux/tree/rust/rust/alloc

See e.g. https://github.com/Rust-for-Linux/linux/commit/487d7578bd036...

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

#93

Post by phkahler »

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.

IMHO getting a minimal set that works is good enough to get people on board. This is still nontrivial. But for example, getting FUSE working would be useful. Even if the driver itself was not ABI compatible, it would bring functionality and someone might then aim for ABI compatibility afterward which would open even more doors.

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

#94

Post by phkahler »

maleldil wrote: post #43
fork-bomber wrote: post #31

Earlier quoted context omitted.

The Rust for Linux kernel project aims to enable writing Linux kernel device drivers in Rust. See: https://lwn.net/Articles/862018/ The issue of Rust's LLVM based compiler toolchain not targeting all CPU archs is intended to be solved by the gcc-rs project. See: https://lwn.net/Articles/871283/ I think the approach the Rust for Linux project is taking is wise: Not about outright re-writes but more about focusing on t…

Last I checked, one of the big problems was the Rust panics when you run out of memory, which is unacceptable in the kernel. Is there any progress on that?

>> one of the big problems was the Rust panics when you run out of memory, which is unacceptable in the kernel.

If the kernel is running out of memory, IMHO that's a bug. The kernel is ultimately responsible for memory management right? It needs to prioritize itself over everything else or the system is in trouble.

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

#95

Post by [deleted] »

nuta wrote: post #41

Author here. I'm surprised to see my hobby project on Hacker News. I know this kind of stuff spark the ``it's meaningless to rewrite everything (especially Linux) in Rust'' debate. I agree 100% that rewriting Linux in Rust (or your favorite language) is just a waste of time and such a project won't live long. That said, what I'd say here is that it's fun. Really fun. Implementing ABI compatibility requires you to und…

[deleted]

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

#96

Post by krylon »

phendrenad2 wrote: post #76
krylon wrote: post #21

This may be a naive question, but I cannot help but wonder: As C and Rust aim to be link-compatible, wouldn't it be easier to gradually replace parts of the Linux kernel with Rust code? The only technical problem I can think of is that Rust may not be available for all CPU architectures Linux supports, but this is just speculation on my part having done no research on the matter.

The Linux kernel is massive, so writing any part of it in Rust is an enormous undertaking. Even a few functions at a time, we're talking decades.

Well, writing a kernel from scratch that supports as many CPU architectures and devices as Linux would take about as long, assuming one could attract a critical mass of developers.

Using an incremental approach at least gives us some benefits in the near future.

I'm not even saying a fresh start would be a bad idea. But incrementally replacing parts of Linux seems like a more promising approach, IMHO.

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

#97

Post by surajrmal »

panick21_ wrote: post #80
nuta wrote: post #74

Earlier quoted context omitted.

In addition to its huge contribution to OS development in Rust, as a microkernel enthusiast, it sounds exciting to writing a microkernel in Rust, in the "Everything is a URL" principle. Moreover, it can run a good-looking GUI on a real machines [1]! I know it's very hard to be realized. Aside from Redox, I'd mention Tock [2], an embedded operating system. It introduces a novel components isolation using Rust's power.…

There are more good efforts, the BeTrusted guys are working on Xous, its a microkernel for a phone like device called the Precurser. https://github.com/betrusted-io/xous-core As a embedded service processor OS for a big server rack, Oxide Computer is working on 'HubrisOS'. They seem to have not released it yet, but that will be open sourced. https://github.com/oxidecomputer Those are two efforts where I know real res…

Is Hubris targeted at BMCs? Or is something different?

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

#98

Post by a-dub »

nuta wrote: post #41

Author here. I'm surprised to see my hobby project on Hacker News. I know this kind of stuff spark the ``it's meaningless to rewrite everything (especially Linux) in Rust'' debate. I agree 100% that rewriting Linux in Rust (or your favorite language) is just a waste of time and such a project won't live long. That said, what I'd say here is that it's fun. Really fun. Implementing ABI compatibility requires you to und…

nice project! curious how the rust ownership model works in a monolithic kernel context. are the lifetimes of kernel structures associated with a process "owned" by the process itself somehow?

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

#99

Post by panick21_ »

surajrmal wrote: post #97
panick21_ wrote: post #80

Earlier quoted context omitted.

There are more good efforts, the BeTrusted guys are working on Xous, its a microkernel for a phone like device called the Precurser. https://github.com/betrusted-io/xous-core As a embedded service processor OS for a big server rack, Oxide Computer is working on 'HubrisOS'. They seem to have not released it yet, but that will be open sourced. https://github.com/oxidecomputer Those are two efforts where I know real res…

Is Hubris targeted at BMCs? Or is something different?

I think its an FPGA with a costume Open-Source Titan chip on it (RISC-V). It is not really a traditional BMC, its more like a service processor that does secure boot and gets you in the OS. It does a few other things but I think they really want it to have minimum functionality.

This is a great talk about what they do and why: https://www.youtube.com/watch?v=vvZA9n3e5pc

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

#100

Post by bcantrill »

surajrmal wrote: post #97
panick21_ wrote: post #80

Earlier quoted context omitted.

There are more good efforts, the BeTrusted guys are working on Xous, its a microkernel for a phone like device called the Precurser. https://github.com/betrusted-io/xous-core As a embedded service processor OS for a big server rack, Oxide Computer is working on 'HubrisOS'. They seem to have not released it yet, but that will be open sourced. https://github.com/oxidecomputer Those are two efforts where I know real res…

Is Hubris targeted at BMCs? Or is something different?

Hubris is targeted at microcontrollers. Much more information (and, importantly, the source code!) will be available in our talk at the Open Source Firmware Conference[0], the abstract for which elaborates on our motivations and use case:

On Hubris and Humility: when "write your own OS" isn't the worst idea

Hubris is a small open-source operating system for deeply-embedded computer systems, such as our server's replacement for the Baseboard Management Controller. Because our BMC replacement uses a lower-complexity microcontroller with region-based memory protection instead of virtual memory, our options were limited. We were unable to find an off-the-shelf option that met our requirements around safety, security, and correctness, so we wrote one.

Hubris provides preemptive multitasking, memory isolation between separately-compiled components, the ability to isolate crashing drivers and restart them without affecting the rest of the system, and flexible inter-component messaging that eliminates the need for most syscalls -- in about 2000 lines of Rust. The Hubris debugger, Humility, allows us to walk up to a running system and inspect the interaction of all tasks, or capture a dump for offline debugging.

However, Hubris may be more interesting for what it doesn't have. There are no operations for creating or destroying tasks at runtime, no dynamic resource allocation, no driver code running in privileged mode, and no C code in the system. This removes, by construction, a lot of the attack surface normally present in similar systems.

This talk will provide an overview of Hubris's design, the structure of a Hubris application, and some highlights of things we learned along the way.

[0] https://talks.osfc.io/osfc2021/featured/

Post reply on HN