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

31–40 of 148 posts

Re: The state of the kernel Rust experiment

#31

Post by uecker »

yourdetect wrote: post #29
uecker wrote: post #23

Earlier quoted context omitted.

That is is undefined behavior does not mean it is exploitable. But I also have not seen an argument why a data race should not be exploitable in this context.

I am very wary of going that route. If there is undefined behavior, the compiler is in principle allowed to do anything and everything, unless it promises something beyond what the language promises. One could then argue that a specific version of a specific compiler with specific settings in a specific case, after investigation of the generated assembly or inspection of what guarantees the compiler provides beyond t…

It is very common for C implementation to define undefined behavior and also common for C programs to rely on this. For this reason, I think it is very misleading to say that undefined behavior is automatically exploitable or even a bug.

Re: The state of the kernel Rust experiment

#35

Post by aw1621107 »

uecker wrote: post #27
dannersy wrote: post #19

Earlier quoted context omitted.

There are lots of vulnerabilities in the C code, too. Should we remove C or do we accept that fact that no language is perfect since they are used by humans and continue to make improvements and use tools that help us along as time goes forward? The cherry picking for this one Rust vulnerability to the ~150 C vulnerabilities is such a weird take that I can't help but think people have some weird hatred of Rust.

I do not think it is weird. Every C bug was taken as clear evidence that we need to abandon C and switch to Rust. So the fact that there are also such bugs in Rust is - while obvious - also important to highlight. So it is not weird hatred against Rust, but hatred against bullshit. And considering that most of the code is C, your 150 C vulnerabilities is a meaningless number, so you still continue with this nonsense.

> Every C bug was taken as clear evidence that we need to abandon C and switch to Rust.

I think more charitably it's every "simple" C bug that tends to provoke that reaction. Buffer overflows, use-after-frees, things for which mechanically-enforceable solutions have existed and been widespread for a while. I think more exotic bugs tend to produce more interesting discussions since the techniques for avoiding those bugs tend to be similarly exotic.

> So the fact that there are also such bugs in Rust

Similarly, I think you need to be careful about what exactly "such bugs" encompasses. This bug wasn't one of the above "simple" bugs IMHO, so I would guess an equivalent bug in C code would at least avoid the worst of the more strident calls you so dislike. Hard to say for sure, though, given our unfortunate lack of a time machine.

Re: The state of the kernel Rust experiment

#36

Post by nevi-me »

Jean-Papoulos wrote: post #26

>Bergmann agreed with declaring the experiment over, worrying only that Rust still "doesn't work on architectures that nobody uses". I love you Arnd. More seriously, this will become an issue when someone starts the process of integrating Rust code into a core subsystem. I wonder whether this will lead to the kernel dropping support for some architectures, or to Rust doing the necessary work. Probably a bit of both.

I suspect more the latter than anything. It could be that by the time Rust gets used in the kernel core, one or both of the GCC implementations would be functional enough to compile the kernel.

I'm curious though, if someone has an ancient/niche architecture, what's the benefit of wanting newer kernels to the point where it'd be a concern for development?

I presume that outside of devices and drivers, there's little to no new developments in those architectures. In which case, why don't the users/maintainers of those archs use a pre-6.1 kernel (IIRC when Rust was introduced) and backport what they need?

Re: The state of the kernel Rust experiment

#38

Post by kubb »

yourdetect wrote: post #2

From the comment section: > To me the more salient questions are how long before (a) we get Rust in a core subsystem (thus making Rust truly _required_ instead of "optional unless you have hardware foo"), and (b) requiring Rust for _all_ new code. Previously, the position was that C developers would not be forced to learn Rust. And a few days ago a security vulnerability was found in the Rust Linux kernel code. https…

I think you’ve said the quiet part out loud by mentioning learning Rust.

The learning seems to be the only legitimate issue that people have. But they avoid mentioning it because it sounds intellectually lazy.

Re: The state of the kernel Rust experiment

#39

Post by Someone »

ibotty wrote: post #28
yourdetect wrote: post #25

Earlier quoted context omitted.

[flagged]

There is relatively little Rust in the kernel, but there are even less Rust CVEs. In this cycle alone there were 160 CVEs, one in Rust. The first one! The amount of rust is way less than 1/160 and even that statistic is off, because one should count all CVEs.

> because one should count all CVEs.

That is debatable, and I think untrue. It sometimes takes years to find CVEs in C code, and I don’t know of an argument why that would be different for Rust.

The fairest comparison, I think, would be with other new code of similar complexity in the kernel, and track #of CVEs per equivalent functionality (per line of code might be sufficient, but if one language is verbose than the other, you should correct for that)

Re: The state of the kernel Rust experiment

#40

Post by bitwize »

uecker wrote: post #27
dannersy wrote: post #19

Earlier quoted context omitted.

There are lots of vulnerabilities in the C code, too. Should we remove C or do we accept that fact that no language is perfect since they are used by humans and continue to make improvements and use tools that help us along as time goes forward? The cherry picking for this one Rust vulnerability to the ~150 C vulnerabilities is such a weird take that I can't help but think people have some weird hatred of Rust.

I do not think it is weird. Every C bug was taken as clear evidence that we need to abandon C and switch to Rust. So the fact that there are also such bugs in Rust is - while obvious - also important to highlight. So it is not weird hatred against Rust, but hatred against bullshit. And considering that most of the code is C, your 150 C vulnerabilities is a meaningless number, so you still continue with this nonsense.

Safe Rust eliminates some of the more common memory bugs in C. The bug under discussion was written in unsafe Rust—but even that doesn't obviate the huge advantages Rust has over C. Even unsafe Rust, for instance, has far fewer UB gotchas than C. And with Rust, you can isolate the tricky bits in 'unsafe' blocks and write higher-level logic in safe Rust, giving your code an extra layer of protection. C is 100% unsafe—"unsafe at any speed" as I like to say.
Post reply on HN