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

The state of the kernel Rust experiment

lwn.net

Post reply on HN
Print view View original

101–110 of 148 posts

Re: The state of the kernel Rust experiment

#101

Post by inejge »

bgwalter wrote: post #57
Certhas wrote: post #55

Earlier quoted context omitted.

Maybe you haven't been paying much attention in this space. Google found empirically that error density in _unsafe_ Rust is still much lower than in C/C++. And only a small portion of code is unsafe. So per LOC Rust has orders of magnitudes fewer errors than C/C++ in real world Android development. And these are not small sample sizes. By now more code is being written in Rust than C++ at Google: https://security.goo…

[flagged]

> Why don't they use qmail as an example?

Perhaps because qmail is an anomaly, not Android? To remain relatively bug-free, a sizeable C project seems to require a small team and iron discipline. Unix MTAs are actually pretty good examples. With qmail, for a long time, it was just DJB. Postfix has also fared well, and (AFAIK) has a very small team. Both have been architected to religiously check error conditions and avoid the standard library for structure manipulation.

Android is probably more representative of large C (or C++) projects one may encounter in the wild.

Re: The state of the kernel Rust experiment

#102

Post by uecker »

UltraSane wrote: post #96
uecker wrote: post #84

Earlier quoted context omitted.

Giving the size and age of the C ecosystem, the number of bugs is not really a valid argument. We will see an increasing numbers with Rust as Rust is increasingly used. I also do not question that Rust solves some problems. It just solves them rather badly and at high cost while bringing new problems. I looked at firefox code a decade ago, it was a complete complex nightmare mix of different languages. I can see that…

The number of memory related bugs is absolutely a valid issue with C when the same bugs are impossible in Rust. The C memory model is a disaster when every computer is connected to the Internet.

You are saying the Rust bug in the kernel was impossible? How did it happen then? Come on guys.

Re: The state of the kernel Rust experiment

#103

Post by uecker »

Certhas wrote: post #55
uecker wrote: post #15

Earlier quoted context omitted.

This is certainly not true. But also arguments about "common" are completely misleading as long as there is many orders of magnitude more C code than Rust code.

Maybe you haven't been paying much attention in this space. Google found empirically that error density in _unsafe_ Rust is still much lower than in C/C++. And only a small portion of code is unsafe. So per LOC Rust has orders of magnitudes fewer errors than C/C++ in real world Android development. And these are not small sample sizes. By now more code is being written in Rust than C++ at Google: https://security.goo…

Hey, it was my point that the number of CVEs is red herring.

And no, I do not care or even believe what Google says. There are so many influencing factors.

Re: The state of the kernel Rust experiment

#104

Post by uecker »

ivanbakel wrote: post #61
uecker wrote: post #52

Earlier quoted context omitted.

There were certainly a lot of people running around claiming that "Rust eliminates the whole class of memory safety bugs." Of course, not everybody made such claims, but some did. Whether it is "significantly easier" to manage these types of problems and at what cost remains to be seen. I do not understand you comment about "confirmation bias" as did not make a quantitative prediction that could have bias.

> There were certainly a lot of people running around claiming that "Rust eliminates the whole class of memory safety bugs." Safe Rust does do this. Dropping into unsafe Rust is the prerogative of the programmer who wants to take on the burden of preventing bugs themselves. Part of the technique of Rust programming is minimising the unsafe part so memory errors are eliminated as much as possible. If the kernel could…

Yes, but this is the marketing bullshit I am calling out. "Safe Rust" != "Rust" and it is not "Safe Rust" which is competing with C it is "Rust".

Re: The state of the kernel Rust experiment

#105

Post by sarchertech »

atoav wrote: post #41

If you build a house out of inflammable bricks instead of magnesium ones you can at least rule out magnesium fires. Now the question is: If we live in a world where magnesium fires are common, can we afford to not at least try building with the inflammable bricks? I know this topic stokes emotions, but if you haven't tried Rust as someone with C/C++ experience, give it a go. You will come out wiser on the other side,…

Inflammable doesn’t mean not flammable. It means able to be inflamed. Language changes over time but this word is particularly problematic, so I’d avoid it to avoid confusion.

Re: The state of the kernel Rust experiment

#107

Post by simonask »

uecker wrote: post #104
ivanbakel wrote: post #61

Earlier quoted context omitted.

> There were certainly a lot of people running around claiming that "Rust eliminates the whole class of memory safety bugs." Safe Rust does do this. Dropping into unsafe Rust is the prerogative of the programmer who wants to take on the burden of preventing bugs themselves. Part of the technique of Rust programming is minimising the unsafe part so memory errors are eliminated as much as possible. If the kernel could…

Yes, but this is the marketing bullshit I am calling out. "Safe Rust" != "Rust" and it is not "Safe Rust" which is competing with C it is "Rust".

This is just so obtuse. Be serious.

Even if you somehow manage to ignore the very obvious theoretical argument why it works, the amount of quantitative evidence at this point is staggering: Rust, including unsafe warts and all, substantially improve the ability of any competent team to deliver working software. By a huge margin.

This is the programming equivalent of vaccine denialism.

Re: The state of the kernel Rust experiment

#108

Post by simonask »

yourdetect wrote: post #76
simonask wrote: post #47

Earlier quoted context omitted.

You have a wild amount of confirmation bias going on here, though. Of course, this bug was in an `unsafe` block, which is exactly what you would expect given Rust's promises. The promise of Rust was never that it is magical. The promise is that it is significantly easier to manage these types of problems.

> Of course, this bug was in an `unsafe` block, which is exactly what you would expect given Rust's promises. The fix was outside of any Rust unsafe blocks. Which confused a lot of Rust developers on Reddit and elsewhere. Since fans of Rust have often repeated that only unsafe blocks have to be checked. Despite the Rustonomicon clearly spelling out that much more than the unsafe blocks might need to be checked in ord…

Rust fanboys on Reddit are not contributing to the Linux kernel. What matters here is that Rust helps serious people deliver great code.

Re: The state of the kernel Rust experiment

#109

Post by uecker »

johncolanduoni wrote: post #99
uecker wrote: post #84

Earlier quoted context omitted.

Giving the size and age of the C ecosystem, the number of bugs is not really a valid argument. We will see an increasing numbers with Rust as Rust is increasingly used. I also do not question that Rust solves some problems. It just solves them rather badly and at high cost while bringing new problems. I looked at firefox code a decade ago, it was a complete complex nightmare mix of different languages. I can see that…

What number of CVEs is Rust kernel code allowed to have before we have good evidence it’s a categorical failure? Do you turn off KASLR for your Linux machines because there exist CVEs it doesn’t protect against?

As long as the kernel will be developed, there will be CVEs - even with Rust. So at what point the number is so high that we should drop Rust and move to formal verification? And even then, there will be CVEs... This whole argument is nonsense.

But I also do not agree that memory safety is of much higher importance than other issues. Memory safety is highly critical if you have a monopolistic walled garden spyware ecosystem - such as Android. Not that I do not want memory safety, but the people I know who got hacked, did not get hacked because of memory safety issue, but because of weak passwords or unpatched software. And at least the later problems gets harder with Rust...

Re: The state of the kernel Rust experiment

#110

Post by queejjd »

unrealhoang wrote: post #86
uecker wrote: post #70

Earlier quoted context omitted.

First, if "unsafe" worked so well 100% time, why did we have this bug? (and many other) So this already obviously wrong statement. Then yes, you can use dangerous features in C at any time, but obviously you can also use "unsafe" at any time. The only difference is that "unsafe" is clearer to recognize. But how much this is worth is unclear. First, if you do not invalidly reduce the discussion to only memory safety,…

> logic bugs outside "unsafe" can cause bugs unsafe. This is the wrong understanding of Rust's unsafety encapsulation. For example, no logic bug outside of `unsafe` can cause undefined behavior of Rust std's `Vec` abstraction, which is using underlying unsafe to build. The point that "because unsafe is used so the entire Rust program is also unsafe" is a real major myth. It's as absurd as saying "because Java runtime…

Two questions:

Why was the fix to this unsafe memory safety bug [0] only changes to code outside of unsafe Rust blocks?[1][2]

Why does the Rustonomicon[3] say the following?

> This code is 100% Safe Rust but it is also completely unsound. Changing the capacity violates the invariants of Vec (that cap reflects the allocated space in the Vec). This is not something the rest of Vec can guard against. It has to trust the capacity field because there's no way to verify it.

> Because it relies on invariants of a struct field, this unsafe code does more than pollute a whole function: it pollutes a whole module. Generally, the only bullet-proof way to limit the scope of unsafe code is at the module boundary with privacy.

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

[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...

[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...

[3] https://doc.rust-lang.org/nomicon/working-with-unsafe.html

Post reply on HN