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

Rust in the kernel is no longer experimental

lwn.net

Post reply on HN
Print view View original

731–740 of 853 posts

Re: Rust in the kernel is no longer experimental

#731

Post by steveklabnik »

torginus wrote: post #726
dwattttt wrote: post #720

Earlier quoted context omitted.

The panic_immediate_abort feature should prevent this. build-std is the name of the feature that recompiles the Rust standard libraries with your chosen profile, so the combination of these two features should result in no unwinding code bloat.

Are all crates compatible with this feature?

A crate can add a setting in the package that says "hey if you try to build me without unwinding, cause an error, because I need unwinding to work."

I have never run into such a crate in the wild, I don't think.

Re: Rust in the kernel is no longer experimental

#732

Post by dwattttt »

accelbred wrote: post #728
dwattttt wrote: post #724

Earlier quoted context omitted.

This is ultimately a good example of how to use Rust. You express as much of the API as you can safely, and the rest is unsafe. APIs that can't be safely modelled can still be exposed to Rust & marked unsafe, if they're needed

That works for functions. For datatypes that are used throughout the API, it does not work so well.

Wouldn't a data type with no safe method of construction satisfy that? You can only get one by calling an unsafe function & satisfying its constraints.

Re: Rust in the kernel is no longer experimental

#733

Post by jpc0 »

torginus wrote: post #631
jcranmer wrote: post #70

Earlier quoted context omitted.

There is a cost to having multiple language-level types that represent the exact same set of values, as C has (and is really noticeable in C++). Rust made an early, fairly explicit decision that a) usize is a distinct fundamental type from the other types, and not merely a target-specific typedef, and b) not to introduce more types for things like uindex or uaddr or uptr, which are the same as usize on nearly every p…

I'd say, that even more than pointer sizes, the idea that a pointer is just a number really needs to die, and is in no way a forward looking decision expected of a modern language. Pointers should at no point be converted into numbers and back as that trips up many assumptions (special runtimes, static/dynamic analysis tools, compiler optimizations). Additionally, I would make it a priority that writing FFIs should b…

> Which is a huge risk factor for Rust, especially in today's context of the Linux kernel. If I have an object created/handled by external native code, how do I make sure that it respects Rust's lifetime/aliasing rules?

Can you expand on this point? Like are you worried about whether the external code is going to free the memory out from under you? That is part of a guarantee, the compiler cannot guarantee what happens at runtime no matter what the author of a language wants, the CPU will do what it's told, it couldn't care about Rusts guarantees even if you built your code entirely with rust.

When you are interacting with the real world and real things you need to work with different assumptions, if you don't trust that the data will remain unmodified then copy it.

No matter how many abstractions you put on top of it there is still lighting in a rock messing with 1s and 0s.

Re: Rust in the kernel is no longer experimental

#735

Post by amiga386 »

CursedSilicon wrote: post #614
iurbwdj wrote: post #394

Earlier quoted context omitted.

It involved large parts of the Rust community, and the famous Rust developer Hector Martin (with an alter ego of Asahi Lina, a female vtuber, which he appears irrationally embarrassed about), harassing others. Even Linus Torvalds called out Hector Martin. https://lkml.org/lkml/2025/2/6/1292 > On Thu, 6 Feb 2025 at 01:19, Hector Martin wrote: > > If shaming on social media does not work, then tell me what does, becaus…

Is there any evidence "Asahi Lina" is Hector?

There is. You can easily find by googling "hector martin" "asahi lina" and you will soon find a pile of obsessively archived evidence.

My view, now that Hector has resigned from the LKML both as himself and as Lina, is there is no problem any more. If Hector wants to project a persona, or decide his identity is the persona, or maybe multiple personas, that is fine on social media. People do that. So long as he's not sockpuppeting Linux kernel maintenance, it's fine.

Re: Rust in the kernel is no longer experimental

#736

Post by QuiEgo »

torginus wrote: post #729
QuiEgo wrote: post #649

Earlier quoted context omitted.

I’d like to take a swipe at this Rust has no_std to handle not having an allocator. Tons of things end up being marked “unsafe” in systems/embedded Rust. The idea is you sandbox the unsafeness. Libraries like zero copy are a good example of “containing” unsafe memory accesses in a way that still gets you as much memory safety as possible given the realities of embedded. Tl;dr you don’t get as much safety as higher le…

Dunno. I used to do embedded. A ton of (highly capable) systems have tiny amounts of RAM (like 32kb-128kb). Usually these controllers run a program in an infinite event loop (with perhaps a sleep in the end of the iteration), communication with peripherals is triggered via interrupts. There's no malloc, memory is pre-mapped. This means: - All lifetimes are either 'stack' or 'forever' - Thread safety in the main loop…

FWIW teaching it critical sections is dead simple, and likely already done for you. Ex cortex M:

https://github.com/rust-embedded/cortex-m/blob/master/cortex...

You can look at asynch and things like https://github.com/rtic-rs/rtic and https://github.com/embassy-rs/embassy for common embedded patterns.

You handle DMA the same way as on any other system - e.x. you mark the memory as system/uncached (and pin it if you have virtual memory on), you use memory barriers when you are told data has arrived to get the memory controller up to speed with what happened behind its back, and so on. You’re still writing the same code that controls the hardware in the same way, nothing about that is especially different in C vs Rust.

I think there is very much a learning curve, and that friction is real - hiring people and teaching them Rust is harder than just hiring C devs. People on HN tend to take this almost like a religious question - “how could you dare to write memory unsafe code in 2025? You’re evil!” But pragmatically this is a real concern.

Re: Rust in the kernel is no longer experimental

#738

Post by ChadNauseam »

jacquesm wrote: post #509
dwattttt wrote: post #212

Earlier quoted context omitted.

There is, I understand, an expectation that if you do make breaking changes to kernel APIs, you fix the callers of such APIs. Which has been a point of contention, that if a maintainer doesn't know Rust, how would they fix Rust users of an API? The Rust for Linux folks have offered that they would fix up such changes, at least during the experimental period. I guess what this arrangement looks like long term will be…

Without a very hard commitment that is going to be a huge hurdle to continued adoption, and kernel work is really the one place where rust has an actual place. Everywhere else you are most likely better off using either Go or Java.

I'm using it for frontend web development and it's perfect. Much better than Go or Java would be. It's pretty wild that the language I use in the browser is also in the kernel.

Re: Rust in the kernel is no longer experimental

#739

Post by brokencode »

NetMageSCW wrote: post #667
Ygg2 wrote: post #327

Earlier quoted context omitted.

It removes a class of security vulnerabilities, modulo any unsound unsafe (in compiler, std/core and added dependency). In practice you see several orders of magnitude fewer segfaults (like in Google Android CVE). You can compare Deno and Bun issue trackers for segfaults to see it in action. As mentioned a billion times, seatbelts don't prevent death, but they do reduce the likelihood of dying in a traffic accident.…

“by removing the nastiest class of security vulnerabilities” and “reduce the likelihood” don’t seem to be in the same neighborhood.

If you are reducing the likelihood of something by 99%, you are basically eliminating it. Not fully, but it’s still a huge improvement.

It reminds me of this fun question:

What’s the difference between a million dollars and a billion dollars? A billion dollars.

A million dollars is a lot of money to most people, but it’s effectively nothing compared to a billion dollars.

Post reply on HN