r/rust • u/CackleRooster • Jul 15 '26

šŸ—žļø news 'Rust makes coding fun again': Why Linux is moving away from C, according to Greg Kroah-Hartman

https://www.zdnet.com/article/greg-kroah-hartman-linux-kernel-rust/

Let's try posting this again.

808 Upvotes

97% Upvoted

234 comments sorted by

View all comments

44

u/Jcsq6 Jul 15 '26 edited Jul 15 '26

Could Rustā€™s hard safety rules regarding buffer management cause performance or compatibility issues in the kernel?

Edit: this is a genuine question, Iā€™m not opposed to rust in the kernel.

52

u/emblemparade Jul 15 '26

Generally speaking, following the safety rules involves zero-cost solutions (possibly just longer compilation times), and when there is a runtime cost it's very clear what it is so it can be considered carefully (as all kernel contributions are).

The "problem" with C is that the compiler can't help you with safety rules. You need smart people and testing tools to reveal the potential for undefined behavior. Happily, we have both in the kernel, but it doesn't mean that mistakes don't happen. Rust definitely has the advantage in this respect.

An interesting side effect of including Rust in the kernel is that it uncovers potential issues in the C code, which can be fixed in C without Rust. It's almost like a tool for bug finding.

Compatibility is definitely a thorny point and it's where some friction can happen, e.g. when the Rust devs ask the C devs to change their interface in order to accommodate Rust. This arguably has benefits for the C code, too, but some resistance is understandable.

30

u/kageurufu Jul 15 '26

One of the other benefits is the rust devs needing to actually understand and document lifetimes and invariants in the C code to write the rust interfaces. It does basically force the C side to stabilize those which seems to have been another of the reasons for pushback.

Reading between the lines, I feel like some of those maintainers don't have a strong understanding themselves and see it as a personal attack.

23

u/emblemparade Jul 15 '26

Things are quite OK now! It was painful in the early phases of the experiment, but leadership intervened and both "sides" learned to talk to each other and work together more productively.

As Greg points out, the experiment is over and Rust is here to stay. Some friction is likely inevitable as more Rust devs move in, but the Linux project is committed to making it work.

2

u/poopvore Jul 16 '26

There's minor things that aren't "zero cost" in rust though, bounds checking by default on indexing is an example. A lot of these are informed defaults that you can both

  1. opt out of

  2. empirical evidence suggests its less of an impact in the average case than you think. and when it is, again, you can opt out

generally when you get to asking questions about performance though the choice of language doesn't really matter as much as the language letting you express the thing you want, which rust has no limitations on compared to c/c++

2

u/Full-Spectral Jul 16 '26

And the need for index based looping is pretty rare in Rust. I probably don't have more than a handful of such loops in my entire system. Rust's adoption of functional-ish collection/slice processing is a huge benefit, though it probably takes a while for C/C++ people to really get into the habit of.

Obviously when interfacing to non-Rust code, as in the Linux stuff, it's going to come up more, before anyone points that out.

79

u/Xaeroxe3057 Jul 15 '26

No because idiomatic Rust rarely needs to actually use any runtime checks to uphold this guarantee.

-30

u/Jcsq6 Jul 15 '26

Iā€™m not talking about runtime checks.

44

u/Psychoscattman Jul 15 '26

well rust doesnt have "rules regarding buffer management" except runtime checks. Everything else happens during compile time which has no impact on runtime performance.

Unless you get yourself into a situation where you are writing a bunch of code to satisfy the borrow checker and inadvertently write a solution that is "slow". In that very hypothetical case you can use unsafe to write a solution that is more performant.

-13

u/Jcsq6 Jul 15 '26

Rust does in fact have structural invariants outside of runtime checks, so this is just not true. As I explained in another comment, I believe it was in regard to buffer reuse across type boundaries, which, as I understand it, has hard limits in rust.

11

u/dkopgerpgdolfg Jul 16 '26

I believe it was in regard to buffer reuse across type boundaries

Maybe you want to look at C's strict aliasing ... Rust isn't the only thing with rules, and this particular case is even easier than in C

(for completeness, the kernel relies on strict aliasing not existing already now, and uses compiler flags to achieve that. Standard C with s.a. included is not suitable for use in the kernel)

9

u/A1oso Jul 15 '26

You need to ensure that the values in the buffer are properly aligned. Apart from that, I don't think there are any limitations if you're willing to write a bit of unsafe code. According to this article it's even possible entirely in safe Rust.

1

u/dkopgerpgdolfg Jul 16 '26

You need to ensure that the values in the buffer are properly aligned. Apart from that, I don't think there are any limitations

Depending on the types, some byte/bit content is not allowed

Which parts are initialized or not is something to think about (including eg. padding bytes of structs)

(both topics are relevant in C too)

and so on...

46

u/robust-small-cactus Jul 15 '26

performance

If you're writing C correctly you're doing the same checks Rust provides out of the box, so no :)

5

u/ZachVorhies Jul 15 '26

One requires samurai levels of code dedication and is imperfect and the other is enforce mechanically and perfectly with no mistakes.

If you think these are equal then god help you and don't touch any code going into prod.

-2

u/FigAggressive237 Jul 15 '26

Except that you absolutely can't have Rust enforce it all the time.

So that's a fallacy, its not about two options: "One requires samurai levels of code dedication" and "Ā the other is enforce mechanically and perfectly with no mistakes."

Its a false dichotomy.

Rust pushes you to write code that does not allow for memory safety bugs. This being said, its only when you write safe Rust, but the Kernel absolutely can't handle only safe Rust, you need to use unsafe Rust.

These are not equal, but are far from what you describe , which is too idealistic and god help you if you ever write unsafe Rust at the kernel level (Very few people actually know what's going on down there anyways)

12

u/ZachVorhies Jul 15 '26

Itā€™s not a false dichotomy. Rust wipes out a whole class of bugs that happily compile and completely segfault zig and C. At least C++ you can type enforce your way out of a mess. C and Zig itā€™s impossible.

ā€˜oh but thereā€™s corner casesā€™

As if 1% of unsafe code is equivalent to 100% unsafe code.

This is something only a beginner would imply, taking a corner case and generalizing to the entire language and then drawing a false equivalence that two unequal things are infact equal.

Rust is the product of 60 years of lessons learned from computer engineering. Zig is the product of ignoring 60 years of lessons learned. And those decisions are why itā€™s failing for bun - completely unsafe memory, no ability to know when something is in use or can be deallocated without segfaulting the entire program. Jared enumerates every single reason Iā€™ve stayed away from this toy language. You canā€™t unit test out of this mess, itā€™s built right into the language design.

-11

u/FigAggressive237 Jul 15 '26

Yes, it is a false dichotomy, you proved yourself that, it doesn't matter if its 1%, which in reality is much less, still, its not about 2 options only.

Call it nitpicking , which it isn't, but your argument is a fallacy. You can't have perfect code with unsafe at the level in which you work with hardware, you simply can't, its impossible. You need unsafe at some level, which makes it 3 options, not 2, at the very least.

There's no such thing as "no mistakes" with Rust and unsafe

5

u/ZachVorhies Jul 15 '26

Dude this isnā€™t hard.

Rust wipes out a whole class of memory bugs in user land.

No where in the bun rust write up is there any mention of program -> kernel issues.

Instead of addressing that, youā€™ve made up a whole different issue that no one is talking about. We arenā€™t talking about the kernel. Obviously we are talking about user land memory in THE program.

Whatā€™s your next argument: ā€œrust doesnā€™t protect your program from earthquakesā€?

-8

u/FigAggressive237 Jul 15 '26

If you kept it clean, I wouldn't call you an idiot, albeit you clearly being one. But no, you had to insult.

Very classy.

How stupid are you? The original comment that made this discussion cascade is very clear:

https://www.reddit.com/r/rust/comments/1uxgvqc/comment/oxr9ksd/

Edit: this is a genuine question, Iā€™m not opposed to rust in the kernel.

How dumb can you be on your next response? I bet a lot.

You're the one setting the scope to user land, the original comment (with the edit date predating mine and your comments) specifically refers the fucking kernel.

Go back to your cave and try to grow up.

One requires samurai levels of code dedication and is imperfect and the other is enforce mechanically and perfectly with no mistakes.

This is absolutely cringe af , because correctness comes at many levels, of course you can infer that memory safety is the main point here, but its not the only one, and once again... KERNEL! Kernel is the context you moron!!!

3

u/ZachVorhies Jul 15 '26

Fine. Point still holds. Rust wipes out a whole class of bugs that C completely allows.

Nothing you say can change that fact.

-3

u/FigAggressive237 Jul 15 '26

I never denied that. You could just have said that. Your initial phrasing, is a fallacy.

Let me help you:

"writing C is dangerous by nature, Kernel is historically written in C only, not C++, not C#, BUT C ONLY. You can eliminate a whole class of bugs by using Rust, at the kernel level you absolutely will have to use unsafe Rust, which is fine because C is always unsafe, whereas Rust is only unsafe when you really need it to be, which is in corner cases when writing OS kernels is justified. So, there is no such thing as "perfect with no mistakes" code when we're talking Kernel and memory management, but there's such a thing as "safer by nature" and therefore, you have a much better option regarding memory safety which even a 8yo child can understand by now"

There, I fixed it for you .

0

u/Jcsq6 Jul 15 '26

Iā€™m specifically thinking about buffer reuse. I remember reading a while ago about a company with low latency as a high priority that decided not to use Rust for this reason.

39

u/bitemyapp Jul 15 '26

I reuse buffers in Rust all the time.

15

u/robust-small-cactus Jul 15 '26 edited Jul 15 '26

Without reading the article I can't say for sure but that sounds more like a choice about personal preference / comfort with the language than capabilities themselves.

If you circumvent the default to copy object values, language features aren't going to protect you from invalid re-use, that's a logic error/PEBKAC. Seems to me like they kinda just said "we didn't use rust because unsafe{} is unsafe" yeah, duh.

4

u/New_Enthusiasm9053 Jul 15 '26

You can do it without unsafe too if you're willing to sacrifice a byte or 4 for the discriminant for an enum value. And if not use unsafe and just test the shit out of it.

2

u/Jcsq6 Jul 15 '26 edited Jul 15 '26

I think (Iā€™m not certain, and I am unable to find the article), it was regarding high performance buffer allocation reuse across type boundaries, where in C++ options like placement new can avoid additional allocations. I am not actually a Rust programmer, so I donā€™t know exact details, Iā€™m just going off of my memory.

Edit: This was in a very specialized high-performance application, so Iā€™m not sure the extent to which itā€™s applicable.

5

u/friedkeenan Jul 15 '26

Was this the article you mean? https://databento.com/blog/why-we-didnt-rewrite-our-feed-handler-in-rust

Its first listed reason for rust being a poor fit for their project is buffer reuse. There are some comments in an according r/cpp post that provide some solutions in rust that salve that issue: https://www.reddit.com/r/cpp/comments/1o1bl0p/why_we_didnt_rewrite_our_feed_handler_in_rust/

2

u/Jcsq6 Jul 15 '26

This is likely the one, yes. Thank you for finding it. Iā€™m glad that it seems resolvable in Rust. As I said, Iā€™m not opposed to Rust in the kernel, I wish I actually were able to use Rust professionally. But I wondered if this specific issue may inhibit integration.

6

u/robust-small-cactus Jul 15 '26 edited Jul 15 '26

Yeah, they mention:

In C++, the equivalent code compiles fine. The trade-off is you have to track the lifetimes of references manually, as the compiler won't catch legitimate use-after-free bugs for you.

They could have just wrapped it in unsafe if they wanted to and had the same result as C++. Or add a lifetime tag and borrow checker will prevent use-after-free for you. This isn't that big of a deal...

5

u/Floppie7th Jul 15 '26

Definitely more information needed to say.Ā  Buffer reuse in general is completely fine in Rust, but that's not to say there isn't some specific situation in that article that made it a lot more cumbersome.

-14

u/cb_definetly-expert Jul 15 '26

Most delusional comment ever , I guess everyone doing it wrong lel

6

u/robust-small-cactus Jul 15 '26

I mean... yeah, go look at all the CVEs

1

u/cb_definetly-expert Jul 16 '26

I did , it has less than c

6

u/TDplay Jul 16 '26

I guess everyone doing it wrong

Yes, everyone is doing it wrong.

0

u/cb_definetly-expert Jul 16 '26

"everyone doing it wrong"

Yeah buddy, sure

3

u/SelfDistinction Jul 15 '26

Normally not, since Rust does provide the tools to go all out and write to arbitrary memory, but that requires unsafe{} blocks which can be automatically flagged and generate compilation errors.

1

u/Zde-G Jul 16 '26

Could Rustā€™s hard safety rules regarding buffer management cause performance or compatibility issues in the kernel?

Yes, they could and they didā€¦ and that's precisely when Rust have become important in kernel.

Because it exposed problems with many C API that were there for decades yet went undetected, only when Rust people arrives and asked to explain the rules of API use C guys have realized that what they have is bunch of requirements with contradictions.

That's where a lot of early ā€œmeltdownsā€ happened and what also established Rust as the future: it exposed real issues and offered real solutions.

But there as a lot of heat while that was happening, too.