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

141–148 of 148 posts

Re: The state of the kernel Rust experiment

#141

Post by aw1621107 »

uecker wrote: post #139
aw1621107 wrote: post #132

Earlier quoted context omitted.

> Also "If .. are implemented soundly" sounds harmless but simply means there is no safety guarantee (in contrast to Fil-C or formally verified C, for example). Don't those also depend on implementations being sound? Fil-C has its own unsafe implementation, formal verification tools have their trusted kernels, it's turtles all the way down.

The implementation itself being sound, yes. And yes, in Rust if you only use sound libraries (in combination), never use unsafe yourself and ignore the known defects in Rust, then it is also guaranteed to be safe. But in system programming, you usually have to use "unsafe" in your own code, and then there is no guarantee and you make sure the could has no UB yourself, just like in C.

Sure. My point is mostly that the problem is less that your safety guarantees rely on correct implementations (since that applies to all "safe" systems as long as we're running on unsafe hardware) and more that the trusted codebase tends to be quite a bit larger for (current?) Rust compared to Fil-C/formal verification tools. There are efforts to improve the situation there, but it'll take time.

Does make me wonder how easy porting Fil-C to Rust/Zig/etc. would be. IIRC most of the work is done via LLVM pass(es?) and changes to frontends were relatively minor, so it might be an interesting alternative to MIRI/ASan.

Re: The state of the kernel Rust experiment

#142

Post by yencabulator »

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…

The unsafe code relied on an assumption that was not true; the chosen fix was to make that assumption be true. Makes perfect sense to me.

Re: The state of the kernel Rust experiment

#143

Post by uecker »

simonask wrote: post #107
uecker wrote: post #104

Earlier quoted context omitted.

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.

There is a lot of science showing vaccines work. For Rust showing that it is better this is still lacking. And no Google's blog posts are not science.

Re: The state of the kernel Rust experiment

#144

Post by uecker »

ivanbakel wrote: post #131
uecker wrote: post #104

Earlier quoted context omitted.

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".

> it is not "Safe Rust" which is competing with C it is "Rust". It is intended that Safe Rust be the main competitor to C. You are not meant to write your whole program in unsafe Rust using raw pointers - that would indicate a significant failure of Rust’s expressive power. Its true that many Rust programs involve some element of unsafe Rust, but that unsafety is meant to be contained and abstracted, not pervasive th…

But there are more than 2000 uses of "unsafe" even in the tiny amount of Rust use in the Linux kernel. And you would need to compare to C code where an equally amount of effort was done to develop safe abstractions. So essentially this is part of the fallacy Rust marketing exploits: comparing an idealized "Safe Rust" scenario compared to real-word resource-constrained usage of C by overworked maintainers.

Re: The state of the kernel Rust experiment

#145

Post by uecker »

tialaramex wrote: post #114
uecker wrote: post #103

Earlier quoted context omitted.

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.

I would expect that the largest factor is cultural, and of course it's possible to inculcate safety culture in a team working on a C or C++ codebase, but it seems to me that we've shown it's actually easier to import the culture with a language which supports it. Essentially Weak Sapir–Whorf but for programming languages rather than natural languages. Which is such a common idea that it's the subject of a Turing Awar…

I also think that the largest factor is cultural. But my conclusion from this is not that one should import it with a new language while pretending achieving similar results is not possible otherwise. This just gives an excuse for not caring for the existing code anymore, which I suspect is one reason some parts of the industry like Rust ("nobody can expect us to care about the legacy code, nothing can be done until it is rewritten in Rust")

Re: The state of the kernel Rust experiment

#146

Post by Certhas »

uecker wrote: post #145
tialaramex wrote: post #114

Earlier quoted context omitted.

I would expect that the largest factor is cultural, and of course it's possible to inculcate safety culture in a team working on a C or C++ codebase, but it seems to me that we've shown it's actually easier to import the culture with a language which supports it. Essentially Weak Sapir–Whorf but for programming languages rather than natural languages. Which is such a common idea that it's the subject of a Turing Awar…

I also think that the largest factor is cultural. But my conclusion from this is not that one should import it with a new language while pretending achieving similar results is not possible otherwise. This just gives an excuse for not caring for the existing code anymore, which I suspect is one reason some parts of the industry like Rust ("nobody can expect us to care about the legacy code, nothing can be done until…

Of course highly correct C code is possible [1]. But ADA makes it easier. Rust makes it easier. You can write anything in any language, that is _not_ the argument. How could you plausibly advocate for a culture that invests a lot of effort [1] into making codes correct, and not also advocate for tools and languages that make it easier to check important aspects of correctness? A craftsman is responsible for his tools. Using subpar tools with the argument that with sufficient knowledge, skill and an appropriate culture you can overcome their shortcomings is absurd.

Rust is also often not the right tool. I looked at it fairly deeply some years ago for my team to transition away from Python/C hybrids, but settled on a fully garbage-collected language in the end. That was definitely the right choice for us.

[1] e.g. MISRA C, or https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Dev...

Re: The state of the kernel Rust experiment

#147

Post by Daishiman »

uecker wrote: post #143
simonask wrote: post #107

Earlier quoted context omitted.

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.

There is a lot of science showing vaccines work. For Rust showing that it is better this is still lacking. And no Google's blog posts are not science.

So kernel devs claiming Rust works isn't good enough? CloudFlare? Mozilla? Your're raising the bar to a place where no software will be good enough for you.

Re: The state of the kernel Rust experiment

#148

Post by Daishiman »

uecker wrote: post #144
ivanbakel wrote: post #131

Earlier quoted context omitted.

> it is not "Safe Rust" which is competing with C it is "Rust". It is intended that Safe Rust be the main competitor to C. You are not meant to write your whole program in unsafe Rust using raw pointers - that would indicate a significant failure of Rust’s expressive power. Its true that many Rust programs involve some element of unsafe Rust, but that unsafety is meant to be contained and abstracted, not pervasive th…

But there are more than 2000 uses of "unsafe" even in the tiny amount of Rust use in the Linux kernel. And you would need to compare to C code where an equally amount of effort was done to develop safe abstractions. So essentially this is part of the fallacy Rust marketing exploits: comparing an idealized "Safe Rust" scenario compared to real-word resource-constrained usage of C by overworked maintainers.

The C code comparison exists because people have written DRM drivers in Rust that were of exceedengly high quality and safety compared to the C equivalents.
Post reply on HN