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

31–40 of 196 posts

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

#31

Post by fork-bomber »

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 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 those subsystems where Rust's intrinsic safety and security properties helps the most.

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

#32

Post by geewee »

wongarsu wrote: post #30
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.

That's what may happen with the Linux kernel over time, now that it allows parts written in Rust. The limitation of that approach is that all internal interfaces (which includes most data structures) have to be C-compatible. You can get much of the safety benefits of Rust, but lose a lot of Rust's ergonomics.

I don't think that the Linux kernel has decided (yet) to allow rust code into the kernel proper, has it?

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

#33

Post by ordu »

Just to clarify goals of the project:

"I completely agree that rewriting existing large, feature-rich, and robust operating system kernels is not a good idea. However, a question came to my mind: what are the pros and cons of writing a practical UNIX-like OS kernel in Rust from scratch? How does it look like? This is why I started this project."[1]

[1] https://seiya.me/writing-linux-clone-in-rust

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

#34

Post by skocznymroczny »

simion314 wrote: post #19
thawkins wrote: post #12

Earlier quoted context omitted.

But its a fun thing to do, and that's a good enough reason to do it. After all is that not exactly how Linux came into being anyway.

Maybe I will write a TODO app in Rust, should it be on top of HN because is some unoriginal,incomplete,bug filled,toy stuff just because the reason is written in Rust? 1 My assumption is that all titles with Rust get blind upvotes, sure a new kernel is cool but would be more cool if is more then someone toy project, this should probably be posted and upvoted in Rust forums so it gets support from the fans and hopeful…

I mean, if you had a headline like "Show HN: org-mode in Rust" you'd get a ton of clicks

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

#35

Post by fork-bomber »

roblabla wrote: post #23
fork-bomber wrote: post #15

Very cool! I think a killer feature would be to emulate the Linux kernel device driver model such that existing C driver modules could be used with Kerla. Further, borrow (no pun intended!) the Linux device driver Rust wrappers from the Rust for Linux kernel project to then enable writing Linux device drivers in Rust. The question is whether emulating the Linux device driver model (by which I kind of mean mimicking t…

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.

I asked this question during the recent Linux kernel plumbers conference: "How often in practice do the kernel A{B,P}Is fro device drivers change ?". I got a very mixed response.

My take away was that while 'new' driver classes/subsystems do involve more churn in the core kernel support subsystems, there is a clear trend towards convergence in terms of significant change.

If the change truly was significant and continuous then that would impede productisation with the Rust kernel. I'm not saying that the A{B,P}Is are in any way stable but I personally don't think that keeping up will be an intractable problem.

In the spirit of Kerla's authors prime motive - which appears to be hacking for knowledge - this might be something to try, perhaps with a driver class that is known to be more stable.

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

#36

Post by roblabla »

fivelessminutes wrote: post #17
Klasiaster wrote: post #11

Earlier quoted context omitted.

The type of software makes the difference - does it process untrusted input, maybe even over the network? This here is a kernel including a memory-safe TCP/IP stack ( https://github.com/smoltcp-rs/smoltcp/ ), and not having it crash or be full of security vulnerabilities due to preventable memory corruption is a quality beyond personal language preferences.

It is possible to overstate a valid case until it becomes meaningless... are modern OS IP stacks written in C really 'crash'ing or 'full of security vulnerabilities'? No.

There has actually been a few crashes in the core TCP/IP stack of both Linux and Windows in the last 5 years, though I'm not sure any of them were due to memory safety (most were logic bugs as far as I can tell). That said, rust's approach to error handling could help avoid crashes here as well.

However, we have seen *many* memory-safety crashes in the drivers to talk to network interfaces. Those really are full of security vulnerabilities. The most prominent recent one was broadcom's wifi driver having heap buffer overflows allowing remote code execution by anyone within wifi range in 2019[0].

[0]: https://www.bleepingcomputer.com/news/security/broadcom-wifi...

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

#37

Post by fork-bomber »

geewee wrote: post #32
wongarsu wrote: post #30

Earlier quoted context omitted.

That's what may happen with the Linux kernel over time, now that it allows parts written in Rust. The limitation of that approach is that all internal interfaces (which includes most data structures) have to be C-compatible. You can get much of the safety benefits of Rust, but lose a lot of Rust's ergonomics.

I don't think that the Linux kernel has decided (yet) to allow rust code into the kernel proper, has it?

It hasn't. But the attitude towards using Rust for device driver development has now gotten very positive, especially post the recent kernel summit.

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

#38

Post by jatone »

gabrielhidasy wrote: post #7

For each piece of software, there just be a version in Rust, and that version must advertise it's rustiness

I mean honestly who cares? its their time. I use rust over c/c++ these days for practical reasons.

1. the toolchain is better. (cargo ala)

2. maintenance of the software is better. (static linked binaries, easier deploys)

3. memory safety.

4. resource consumption (cpu/ram)

when I don't need 4 I use golang (most cases) because of 1, 2, and 3.

and I choose tools (all other things being equal) written in rust for the same reasons.

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

#39

Post by kryptiskt »

nivenkos wrote: post #16

Post it when it's production ready. A big problem in the Rust ecosystem is the lack of continued work and support on libraries (understandably, since many are new and aren't commercially supported). For example, pyroute2 is still better for Linux admin that the equivalent Rust crates. Whilst the latter often fully support async, none of them cover all of the features of pyroute2 nor the easy-to-use API. Hopefully thi…

> Post it when it's production ready.

This is Hacker News, not Enterprise IT News.

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

#40

Post by fork-bomber »

pjc50 wrote: post #26
fork-bomber wrote: post #15

Very cool! I think a killer feature would be to emulate the Linux kernel device driver model such that existing C driver modules could be used with Kerla. Further, borrow (no pun intended!) the Linux device driver Rust wrappers from the Rust for Linux kernel project to then enable writing Linux device drivers in Rust. The question is whether emulating the Linux device driver model (by which I kind of mean mimicking t…

> The question is whether emulating the Linux device driver model (by which I kind of mean mimicking the set of core kernel services needed to support drivers - kernel threads, sync primitives, allocators etc) ends up being a massive task akin to writing the core kernel itself. The kernel has (deliberately) never had a simple or stable driver ABI, so I think this is potentially a huge task. And then you've also left…

Towards the C-based attack surface:

I think using the Rust-for-linux wrappers to implement the drivers in Rust would eventually help.

Also, even if initially Linux C drivers were transplanted into Kerla that could be a net benefit if the tradeoff of wide device driver availability vs increase in the trusted compute base was acceptable.

I personally think that tradeoff would be acceptable - if the transplanting ability was tractable. It's a hard one to absolutely agree on, admittedly.

Towards the minimal set of hardware, fair point! I think that one should be able to get quite far with judicious selection of device driver classes and leave the truly in-flux classes alone ?

Post reply on HN