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

111–120 of 148 posts

Re: The state of the kernel Rust experiment

#111

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…

If a logic bug inside Vec and outside any unsafe blocks inside Vec happens, and that logic bug violates any invariants and requirements of the unsafe blocks, that can cause memory unsafety.

Re: The state of the kernel Rust experiment

#112

Post by queejjd »

dannersy wrote: post #95
uecker wrote: post #27

Earlier quoted context omitted.

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.

Okay, fair that since the majority of the codebase is C and that 150 vulnerabilities is probably negligible in comparison since we're talking about ratios, but if we're to be THAT nuanced then we also need to consider that code has been iterated upon for decades, so, I think the point is moot. The claim has never, ever, been that Rust is bug free. The objective was to help reduce bugs, which is an outcome I've seen f…

What features do you like the most in Rust? Are pattern matching and enums some of them?

Re: The state of the kernel Rust experiment

#113

Post by wmanley »

uecker wrote: post #98
wmanley wrote: post #73

Earlier quoted context omitted.

> in C only specific language features are unsafe and not all code Using rust's definition of unsafe which is roughly "can cause undefined behaviour" then it seems to me isolating use of these features isn't possible. What is C without: * Dereferencing pointers * Array access * Incrementing signed integers You can do all of the above without invoking UB, but you can't separate the features in C that can cause UB from…

The first misunderstanding is that safety is a property of the language or not. Rust marketing convinced many people that this is so, but C can be safe or unsafe. Fil-C shows that even all of C can be memory safe (but at a substantial cost in performance). But even just with GCC and Clang, array access and signed integer can be made safe with a compiler flag, and a violation then traps and this is similar to a Rust p…

I guess that means you're using the colloquial meaning of the word safety/unsafe rather than the rust definition. It's worth being explicit about that (or choosing a different word) in these discussions to prevent confusion.

For Rust safety (meaning no UB) most definitely is a property of the language. If a module does not contain unsafe and the modules it uses that do contain unsafe are implemented soundly then there is no UB.

In C UB is a part of the language.

Re: The state of the kernel Rust experiment

#114

Post by tialaramex »

uecker wrote: post #103
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…

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 Award speech. Because the code you read and write in Rust usually has these desirable safety properties, that's how you tend to end up thinking about the problems expressed in that code. You could think this way in C, or C++ but the provided tooling and standard libraries don't support that way of using them so well.

Re: The state of the kernel Rust experiment

#115

Post by immibis »

airstrike wrote: post #33
yourdetect wrote: post #25

Earlier quoted context omitted.

[flagged]

It's in a block explicitly marked unsafe lmao As opposed to an implicitly unsafe what 1 million lines of C

What good does that do though? They still have the bug, whether it's marked "unsafe" or not. You could mark every C source file as "unsafe" and that wouldn't magically make C a better language or have fewer bugs.

This talking point needs to stop. Rust could be a better language but that would be because it causes fewer bugs, not because the bugs are labeled "unsafe"

Re: The state of the kernel Rust experiment

#116

Post by unrealhoang »

queejjd wrote: post #111
unrealhoang wrote: post #86

Earlier quoted context omitted.

> 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…

If a logic bug inside Vec and outside any unsafe blocks inside Vec happens, and that logic bug violates any invariants and requirements of the unsafe blocks, that can cause memory unsafety.

That would be the unsoundness of `Vec` itself, but if the abstraction of `Vec` is sound, there would be no way to use `Vec` outside of `unsafe` that can cause memory unsafety.

The point coming back to abstraction and responsibility, in Rust, you can build abstraction that is sound and guarantee memory safety from there. There can be soundness bug inside your abstraction, but it will be a massively smaller surface for auditing and expert required to write such abstraction. Also, when soundness bug appears, the responsibility is solely on the abstraction writer, not the user.

Whereas in C, without those safe abstraction, the surface of doing thing right to avoid memory safety issue is your entire codebase, and responsibility of "holding the knife correctly" is on the user.

Re: The state of the kernel Rust experiment

#117

Post by yjftsjthsd-h »

nevi-me wrote: post #36
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…

> 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?

Wanting big fixes (including security fixes, because old machines can still be networked) and feature improvements, just like anyone else?

> I presume that outside of devices and drivers, there's little to no new developments in those architectures.

There's also core/shared features. I could very easily imagine somebody wanting eg. ebpf features to get more performance out of ancient hardware.

> 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?

Because backporting bits and pieces is both hard and especially hard to do reliably without creating more problems.

Re: The state of the kernel Rust experiment

#118

Post by queejjd »

unrealhoang wrote: post #116
queejjd wrote: post #111

Earlier quoted context omitted.

If a logic bug inside Vec and outside any unsafe blocks inside Vec happens, and that logic bug violates any invariants and requirements of the unsafe blocks, that can cause memory unsafety.

That would be the unsoundness of `Vec` itself, but if the abstraction of `Vec` is sound, there would be no way to use `Vec` outside of `unsafe` that can cause memory unsafety. The point coming back to abstraction and responsibility, in Rust, you can build abstraction that is sound and guarantee memory safety from there. There can be soundness bug inside your abstraction, but it will be a massively smaller surface for…

> There can be soundness bug inside your abstraction, but it will be a massively smaller surface for auditing and expert required to write such abstraction.

If all of the Vec has to be "audited", or checked and reviewed, including all the code that is not inside unsafe blocks, how would the surface be any smaller?

> The point coming back to abstraction and responsibility, in Rust, you can build abstraction that is sound and guarantee memory safety from there.

Isn't it normal for programming languages to support building abstractions that can help with not only memory safety, but general correctness? C is a bit barebones, but lots of other programming languages, like C#, C++, Haskell and Scala support building abstractions that are harder to misuse.

Re: The state of the kernel Rust experiment

#119

Post by unrealhoang »

queejjd wrote: post #118
unrealhoang wrote: post #116

Earlier quoted context omitted.

That would be the unsoundness of `Vec` itself, but if the abstraction of `Vec` is sound, there would be no way to use `Vec` outside of `unsafe` that can cause memory unsafety. The point coming back to abstraction and responsibility, in Rust, you can build abstraction that is sound and guarantee memory safety from there. There can be soundness bug inside your abstraction, but it will be a massively smaller surface for…

> There can be soundness bug inside your abstraction, but it will be a massively smaller surface for auditing and expert required to write such abstraction. If all of the Vec has to be "audited", or checked and reviewed, including all the code that is not inside unsafe blocks, how would the surface be any smaller? > The point coming back to abstraction and responsibility, in Rust, you can build abstraction that is so…

All of `Vec` is much smaller than all of the place using Vec. IIRC, Vec is around 3k LoC. And for even low level code like Oxide & Android core, they are observed less than 4% of their code is inside or related to unsafe, that’s a massive improvement.

Yes, Rust is not new in term of allow building hard to misuse abstraction, it’s just allow abstraction over memory safety without relying on GC or runtime checks. Rust achieve this by adding capability to enforce shared XOR mutability with its borrowck which C++ couldn’t.

Re: The state of the kernel Rust experiment

#120

Post by queejjd »

unrealhoang wrote: post #119
queejjd wrote: post #118

Earlier quoted context omitted.

> There can be soundness bug inside your abstraction, but it will be a massively smaller surface for auditing and expert required to write such abstraction. If all of the Vec has to be "audited", or checked and reviewed, including all the code that is not inside unsafe blocks, how would the surface be any smaller? > The point coming back to abstraction and responsibility, in Rust, you can build abstraction that is so…

All of `Vec` is much smaller than all of the place using Vec. IIRC, Vec is around 3k LoC. And for even low level code like Oxide & Android core, they are observed less than 4% of their code is inside or related to unsafe, that’s a massive improvement. Yes, Rust is not new in term of allow building hard to misuse abstraction, it’s just allow abstraction over memory safety without relying on GC or runtime checks. Rust…

[flagged]
Post reply on HN