[mustache_kimono]

> So the prediction that incautious and unverified unsafe {} blocks would cause CVEs seems entirely accurate.

This is one/the first CVE caused by a mistake made using unsafe Rust. But it was revealed along with 159 new kernel CVEs found in C code.[0]

It may just be me, but it seems wildly myopic to draw conclusions about Rust, or even, unsafe Rust from one CVE. More CVEs will absolutely happen. But even true Rust haters have to recognize that tide of CVEs in kernel C code runs something like 19+ CVEs per day? What kind of case can you make that "incautious and unverified unsafe {} blocks" is worse than that?

[0]: https://social.kernel.org/notice/B1JLrtkxEBazCPQHDM

[uecker]

Github says 0.3% of the kernel code is Rust. But even normalized to lines of code, I think counting CVEs would not measure anything meaningful.

[mustache_kimono]

> Github says 0.3% of the kernel code is Rust. But even normalized to lines of code, I think counting CVEs would not measure anything meaningful.

Your sense seems more than a little unrigorous. 1/160 = 0.00625. So, several orders of magnitude fewer CVEs per line of code.

And remember this also the first Rust kernel CVE, and any fair metric would count both any new C kernel code CVEs, as well as those which have already accrued against the same C code, if comparing raw lines of code.

But taking a one week snapshot and saying Rust doesn't compare favorably to C, when Rust CVEs are 1/160, and C CVEs are 159/160 is mostly nuts.

[pjjpo]

I'm more interested in the % of rust code that is marked unsafe. If you can write a kernel with 1% safe, that sounds pretty great. If the nature of dealing with hardware (AFAIK most of a kernel is device drivers) means something higher, maybe 10%, then maybe safety becomes difficult, especially because unsafety propagates in an unclear way since safe code becomes unsafe to some degree when it calls into it.

I'm also curious about the percentage of implicit unsafe code in C, given there are still compilers and linters checking something, just not at the level of lifetimes etc in Rust. But I guess this isn't easy to calculate.

I like rust for low level projects and see no need to pick C over it personally - but I think it's fair to question the real impact of language safety in a realm that largely has to be unsafe. There's no world where Rust is more unsafe than C though so it's all academic. I just wonder if there's been any analysis on this, in close to metal applications like a kernel.

[mustache_kimono]

> I'm more interested in the % of rust code that is marked unsafe.

I think you should less interested in % unsafe as what the unsafe is used to do, that is, it's likelihood to cause UB, etc. If it's unsafe to interface with C code, or unsafe to do a completely safe transmute, I'm not sure one should care.

[uecker]

> There's no world where Rust is more unsafe than C though so it's all academic

I think Rust is more unsafe than C due to supply chain issues in the Rust ecosystem, which have not fully materialized yet. Rust certainly has an advantage in terms of memory safety, but I do not believe it is nearly as big as people like to believe compared to a C project that actually cares about memory safety and applies modern tooling to address safety. There seems to be a lot of confirmation bias. I also believe Rust is much safer for average coders doing average projects by being much safer by default.

[mustache_kimono]

> I think Rust is more unsafe than C due to supply chain issues in the Rust ecosystem

This is such an incredibly cheap shot. First, the supply chain issues referenced have nothing to do with Rust, the language, itself. Second, Rust's build system, cargo, may have these issues, but cargo's web fetch features simply aren't used by the Linux kernel.

So -- we can have a debate about which is a better a world to live in, one with or without cargo, but it really has nothing to do with the Linux kernel security.

[mustache_kimono]

> Your sense seems more than a little unrigorous. 1/160 = 0.00625. So, several orders of magnitude fewer CVEs per line of code.

This is incorrect. Chalk it up to the flu and fever! Sorry.

0.00625 == .625%. or about twice the instance of Rust code however as stated above these are just the metric from one patch cycle.

[uecker]

It wasn't me trying to conclude anything from insufficient data.

[thrance]

To be actually fair, you should probably only look at CVEs concerning new-ish code.

[taproottap]

It would probably have to be normalized to something slightly different as lines of code necessary to a feature varies by language.. But even with the sad state of CVE quality, I would certainly prefer a language that deflects CVEs for a kernel that is both in places with no updates and in places with forced updates for relevant or irrelevant CVE.

[nottorp]

If you tell us $LANGUAGE is the second coming of $DEITY daily, in multiple ways, we will expect that it is the second coming.

What's even the point of introducing Rust into the Linux kernel when you have to use the hidden under the rug unsafe parts of it to function?

[stouset]

All of C is unsafe. Tiny, limited parts of kernel Rust code are unsafe. The percentage of unsafe Rust code will almost certainly decrease over time.

This isn’t really hard to wrap your head around.

[hulitu]

> The percentage of unsafe Rust code will almost certainly decrease over time.

Famous last words. /s

[accelbred]

The kernel policy for CVEs is any patch that is backported, no? So this is just the first Rust patch, post being non-experimental, that was backported?