The idea behind the safe/unsafe split is to provide safe abstractions over code that has to be unsafe.

The unsafe parts have to be written and verified manually very carefully, but once that's done, the compiler can ensure that all further uses of these abstractions are correct and won't cause UB.

Everything in Rust becomes "unsafe" at some lower level (every string has unsafe in its implementation, the compiler itself uses unsafe code), but as long as the lower-level unsafe is correct, the higher-level code gets safety guarantees.

This allows kernel maintainers to (carefully) create safe public APIs, which will be much safer to use by others.

C doesn't have such explicit split, and its abstraction powers are weaker, so it doesn't let maintainer create APIs that can't cause UB even if misused.

> I am not sure what point did you try to make by giving something that is not even a production quality code?

let's start by prefacing that 'production quality' C is 100% unsafe in Rust terms.

> Sorry, I am not buying that argument.

here's where we fundamentally disagree: you listed a couple dozen unsafe places in 1.5kLOC of code; let's be generous and say that's 10% - and you're trying to sell it as a bad thing, whereas I'm seeing the same numbers and think it's a great improvement over status quo ante.

> let's start by prefacing that 'production quality' C is 100% unsafe in Rust terms.

I don't know what one should even make from that statement.

> here's where we fundamentally disagree: you listed a couple dozen unsafe places in 1.5kLOC of code; let's be generous and say that's 10%

It's more than 10%, you didn't even bother to look at the code but still presented it, what in reality is a toy driver example, as something credible (?) to support your argument of me spreading FUD. Kinda silly.

Even if it was only that much (10%), the fact it is in the most crucial part of the code makes the argument around Rust safety moot. I am sure you heard of 90/10 rule.

The time will tell but I am not holding my breath. I think this is a bad thing for Linux kernel development.

> I don't know what one should even make from that statement.

it's just a fact. by definition of the Rust language unsafe Rust is approximately as safe as C (technically Rust is still safer than C in its unsafe blocks, but we can ignore that.)

> you didn't even bother to look at the code but still presented

of course I did, what I've seen were one-liner trait impls (the 'whole traits' from your own post) and sub-line expressions of unsafe access to bindings.

> technically Rust is still safer than C in its unsafe blocks

This is quite dubious in a practical sense, since Rust unsafe blocks must manually uphold the safety invariants that idiomatic Safe Rust relies on at all times, which includes, e.g. references pointing to valid and properly aligned data, as well as requirements on mutable references comparable to what the `restrict` qualifier (which is rarely used) involves in C. In practice, this is hard to do consistently, and may trigger unexpected UB.

Some of these safety invariants can be relaxed in simple ways (e.g. &Cell<T> being aliasable where &mut T isn't) but this isn't always idiomatic or free of boilerplate in Safe Rust.

It's great that the Google Android team has been tracking data to answer that question for years now and their conclusion is:

-------

The primary security concern regarding Rust generally centers on the approximately 4% of code written within unsafe{} blocks. This subset of Rust has fueled significant speculation, misconceptions, and even theories that unsafe Rust might be more buggy than C. Empirical evidence shows this to be quite wrong.

Our data indicates that even a more conservative assumption, that a line of unsafe Rust is as likely to have a bug as a line of C or C++, significantly overestimates the risk of unsafe Rust. We don’t know for sure why this is the case, but there are likely several contributing factors:

    unsafe{} doesn't actually disable all or even most of Rust’s safety checks (a common misconception).
    The practice of encapsulation enables local reasoning about safety invariants.
    The additional scrutiny that unsafe{} blocks receive.

-----

From https://security.googleblog.com/2025/11/rust-in-android-move...

> The practice of encapsulation enables local reasoning about safety invariants.

> The additional scrutiny that unsafe{} blocks receive.

None of this supports an argument that "unsafe Rust is safer than C". It's just saying that with enough scrutiny on those unsafe blocks, the potential bugs will be found and addressed as part of development. That's a rather different claim.

It does, if you read the report and run a little (implied) math.

The report says that their historical data gives them an estimate of 1000 Memory Safety issues per Million Lines of Code for C/C++.

The same team currently has 5 Million lines of Rust code, of which 4% are unsafe (200 000). Assuming that unsafe Rust is on par with C/C++, this gives us an expected value of about 200 memory safety issues in the unsafe code. They have one. Either they have 199 hidden and undetected memory safety issues, or the conclusion is that even unsafe Rust is orders of magnitude better than C/C++ when it comes to memory safety.

I trust them to track these numbers diligently. This is a seasoned team building foundational low level software. We can safely assume that the Android team is better than the average C/C++ programmer (and likely also than the average Rust programmer), so the numbers should generalize fairly well.

Part of the benefits of Rust is indeed that it allows local reasoning about crucial parts of the code. This does allow for higher scrutiny which will find more bugs, but that's a result of the language design. unsafe {} was designed with that im mind - this is not a random emergent property.

They say "With roughly 5 million lines of Rust in the Android platform and one potential memory safety vulnerability found (and fixed pre-release), our estimated vulnerability density for Rust is 0.2 vuln per 1 million lines (MLOC).".

Do you honestly believe that there is 1 vulnerability per 5 MLoC?

literally from the quote:

    unsafe{} doesn't actually disable all or even most of Rust’s safety checks (a common misconception).

It actually does support it. Human attention is a finite resource. You can spend a little bit if attention in every line to scrutinize safety or you can spend a lot of time scrutinizing the places where you can't mechanically guarantee safety.

It's safer because it spends the human attention resource more wisely.

So, unsafe block every 70 LoC in 1500 LoC toy example? Sure, it's a strong argument.

How is that worse than everything being unsafe?

I've seen this argument thrown around often here in HN ("$IMPROVEMENT is still not perfect! So let's keep the statu quo.") and it baffles me.

C is not perfect and it still replaced ASM in 99% of its use cases.

No, I am not saying keep the status quo. I am simply challenging the idea that kernel will enjoy benefits that is supposed to be provided by Rust.

Distribution of bugs across the whole codebase is not following the normal distribution but multimodal. Now, imagine where the highest concentration of bugs will be. And how many bugs there will be elsewhere. Easy to guess.

> Now, imagine where the highest concentration of bugs will be. And how many bugs there will be elsewhere.

You're doing it again!

Doesn't matter where the majority of bugs will be. If you avoid the minority it's still an improvement.

Also, Rust safety is not related at all to bugs. You seem to have a misunderstanding of what Rust is or what safe Rust provides.

(Also, I'd challenge the rest of your assumptions, but that's another story.)

What am I exactly doing again? I am providing my reasoning, sorry if that itches you the wrong way. I guess you don't have to agree but let me express my view, ok? My view is not extremist or polarized as you see. I see the benefit of Rust but I say the benefit is not what Internet cargo-cult programming suggests. There's always a price to be paid, and in case of kernel development I think it outweighs the positive sides.

If I spend 90% of time debugging freaking difficult to debug issues, and Rust solves the other 10% for me, then I don't see it as a good bargain. I need to learn a completely new language, surround myself with a team which is also not hesitant to learn it, and all that under assumption that it won't make some other aspects of development worse. And for surely it will.

Unsafe doesn't mean a wild-west free-for-all. Unsafe Rust still has more safety guarantees than C or C++.

Have you written any Rust?