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

Smart pointers for the kernel

lwn.net

Post reply on HN
Print view View original

81–90 of 120 posts

Re: Smart pointers for the kernel

#81

Post by jchw »

eru wrote: post #80
jchw wrote: post #74

Earlier quoted context omitted.

Depends a lot on the system, but I don't think this is much of a problem with modern Linux systems. Looking on my machine, vm.mmap_min_addr is set to 65536, not to mention the mitigations modern CPUs have for preventing unintended access to user pages. Just as in userspace, a null dereference on a modern Linux system is almost guaranteed to hit a trap. That said, a potentially bigger problem is what happens when hand…

See https://lwn.net/Articles/342330/

We're really going far out into the unrelated weeds now, but this relied on a myriad of bugs that were since fixed (like MMAP_PAGE_ZERO overriding mmap_min_addr, and MMAP_PAGE_ZERO not being cleared when exec'ing a setuid/setgid binary) and would be thwarted by modern processor mitigations (like SMAP and SMEP) which make this entire class of exploit usually impossible. You have to work a lot harder to have an exploitable null pointer dereference these days, and when you do, it's usually not related to the null pointer dereference itself, but actually what happens after trapping.

Re: Smart pointers for the kernel

#82

Post by ArtixFox »

lertn wrote: post #71
kelnos wrote: post #8

Earlier quoted context omitted.

I don't think you're giving Rust enough credit here. For those projects that don't use any unsafe, we can say -- absent compiler bugs or type system unsoundness -- that there will be no memory leaks or data races or undefined behavior. That's useful! Very useful! For projects that do need unsafe, that unsafe code can be cordoned off into a corner where it can be made as small as possible, and can be audited. The rest…

With C you can take proven algorithms from CLRS and translate them directly without boilerplate. The same algorithms already become ugly/obfuscated in idiomatic C++. Looking at the macro in the LWN article, the approach of Rust of using wrappers and boxes and complex macros to emulate features appears to go into the same direction as C++. Still in 2024, gdb is far less useful for C++ than for C. C++ error messages ar…

With C, you are not 100% sure that ur code will work. You have to verify and extensively test it. With C++ you have some very vague guarantees about ur code but you can easily transition from C and even have some interesting type safety like mp-units. with Rust, you have some good guarantees that ur code wont have UAF, will be threadsafe, etc etc and you can probably invent some interesting typesafety like mp-units.

In all 3, you gotta verify [frama-C, astree,bedrock, the many projects working on rust, esp the coq one] and extensively test it.

But by default, all 3 provide a different level of gurantees

Re: Smart pointers for the kernel

#83

Post by hansvm »

simonask wrote: post #54
hansvm wrote: post #36

Earlier quoted context omitted.

This is giving Rust a bit too much credit though. - Memory leaks are not just possible in Rust, they're easy to write and mildly encouraged by the constraints the language places on you. IME I see more leaks in Rust in the wild than in C, C#, Python, C++, ... - You can absolutely have data races in a colloquial sense in Rust, just not in the sense of the narrower definition they created to be able to say they don't h…

Wait, when exactly did the soundness rules change since 1.0? When have you had to re-audit unsafe code? The Rustonomicon [1] serves as a decent introduction to what you can or can't do in unsafe code, and none of that changed to my knowledge. I agree that it's sometimes challenging to contain `unsafe` in a small blast zone, but it's pretty rare IME. [1]: https://doc.rust-lang.org/nomicon/intro.html

> Wait, when exactly did the soundness rules change since 1.0? When have you had to re-audit unsafe code?

At a minimum you have to check that the rules haven't changed for each version [0].

The issue with destructors just before 1.0 dropped [1] would have been something to scrutinize pretty closely. I'm not aware of any major changes since then which would affect previously audited code, but new code for new Rust versions (e.g., when SIMD stabilized) needs to be considered with new rules as well.

> none of that changed to my knowledge

This is perhaps a bit pedantic, but the nomicon has bug fixes all the time (though the underlying UB scenarios in the compiler remain stable), and it's definitely worth re-examining your unsafe Rust when you see changes which might have incorrectly led a programmer to write some UB.

[0] https://doc.rust-lang.org/reference/behavior-considered-unde... [1] https://cglab.ca/~abeinges/blah/everyone-poops/

Re: Smart pointers for the kernel

#84

Post by Filligree »

uecker wrote: post #64
Dylan16807 wrote: post #40

Earlier quoted context omitted.

> If you limited wrong to "memory safe" Yes, because this is a discussion about the value of "unsafe", so we're only talking about the wrongs that are enabled by "unsafe". > and also ignore that unsafe parts violating invariants can make safe parts of Rust to be wrong. If I run a line of code that corrupts memory, and the program crashes 400 lines later, I don't say the spot where it crashes is wrong, I say the memor…

It does not invalidate an argument that you do not want to talk about it. Regarding the second point: yes, you can then blame the "unsafe" part but the issue is that the problem might not be so localized as the notion of "only auditing unsafe blocks is sufficient" implies. You may need to understand the subtle interaction of unsafe blocks with the rest of the program.

Unsafe blocks have a specific set of requirements they have to abide by.

Assuming they successfully do so, it is then guaranteed that no safe code is able to trigger undefined behaviour by calling the unsafe code.

Importantly, this can be checked without ever reading any of the safe code.

Re: Smart pointers for the kernel

#85

Post by tialaramex »

weinzierl wrote: post #44
kelnos wrote: post #8

Earlier quoted context omitted.

I don't think you're giving Rust enough credit here. For those projects that don't use any unsafe, we can say -- absent compiler bugs or type system unsoundness -- that there will be no memory leaks or data races or undefined behavior. That's useful! Very useful! For projects that do need unsafe, that unsafe code can be cordoned off into a corner where it can be made as small as possible, and can be audited. The rest…

"For projects that do need unsafe, that unsafe code can be cordoned off into a corner, where it can be made as small as possible, and can be audited. The rest of the code base is just as safe as one with no unsafe at all. This is also very useful!" Exactly this, and very well put! I'd just like to add one small but important detail. It's one of the things that is so obvious to one group that they rarely even mention…

An important element of Rust's culture of safety, which is if anything more important than its safety technology which merely enables that culture to flourish, is as follows:

It is categorically the fault of that unsafe code when the bomb goes off. In a language like C++ it is very tempting for the person who planted the bomb to say "Oh, actually in paragraph sixteen of the documentation it does tell you about the bomb so it's not my fault" but nobody reads documentation, so Rust culturally requires that they mark the function unsafe, which is one last reminder to go read that documentation if you must use it.

Because this is a matter of culture not technology we can expect further refinement both in terms of what the rules are exactly and the needed technology to deliver that. Rust 1.82 which shipped yesterday adds unsafe extern (previously all the extern functions were unsafe, but er, maybe we should flag the whole block? This will become usual going foward) and unsafe attributes (the attributes which meddle with linking are not safe to just sprinkle on things for example, again this will become usual for those attributes)

Re: Smart pointers for the kernel

#86

Post by steveklabnik »

I_AM_A_SMURF wrote: post #48
GolDDranks wrote: post #24

Earlier quoted context omitted.

I’ll propose that ALL Rust projects that do useful work depend on unsafe code. If one claims otherwise, I say they have no understanding of Rust. But also, if one helds that against Rust's value promise, I, again, say that they have no understanding of Rust.

It's definitely all of them. Even HashMap uses unsafe.

It’s more fundamental than that: the Rust language does not encode hardware specifics into the language, and so way deep down there, you have to write down bytes to an address that Rust considers arbitrary. Unless you only want to run programs that accept no input and take no output, which is not exactly a useful subset of programs.

Re: Smart pointers for the kernel

#87

Post by steveklabnik »

simonask wrote: post #54
hansvm wrote: post #36

Earlier quoted context omitted.

This is giving Rust a bit too much credit though. - Memory leaks are not just possible in Rust, they're easy to write and mildly encouraged by the constraints the language places on you. IME I see more leaks in Rust in the wild than in C, C#, Python, C++, ... - You can absolutely have data races in a colloquial sense in Rust, just not in the sense of the narrower definition they created to be able to say they don't h…

Wait, when exactly did the soundness rules change since 1.0? When have you had to re-audit unsafe code? The Rustonomicon [1] serves as a decent introduction to what you can or can't do in unsafe code, and none of that changed to my knowledge. I agree that it's sometimes challenging to contain `unsafe` in a small blast zone, but it's pretty rare IME. [1]: https://doc.rust-lang.org/nomicon/intro.html

There was at least one in the first year after 1.0, we had warnings on for like nine months and then finally broke the code later.

That I only remember such things vaguely and not in a “oh yeah here’s the last ten times this happened and here’s the specifics” speaks to how often it happens, which is not often.

Lots of times soundness fixes are found by people looking for them, not for code in the wild. Fixing cve-rs will mean a “breaking” change in the literal sense that that code will no longer compile, but outside of that example, no known code in the wild triggers that bug, so nobody will notice the breakage.

Re: Smart pointers for the kernel

#88

Post by steveklabnik »

_flux wrote: post #78
Measter wrote: post #76

Earlier quoted context omitted.

You might be thinking of CVE-RS[0] which is exploiting bugs in the compiler. [0] https://github.com/Speykious/cve-rs

You are quite likely correct. My search term included "unsound", and it missed this one. But this time I've starred and cloned it! I didn't quite see if this actually exploits multiple bugs or leverages just one, though.

Just one. It’s a compiler bug and not a soundness hole.

Re: Smart pointers for the kernel

#89

Post by steveklabnik »

stackghost wrote: post #15
foundry27 wrote: post #3

Earlier quoted context omitted.

Rust’s whole premise of guaranteed memory safety through compiletime checks has always been undermined when confronted with the reality that certain foundational operations must still be implemented using unsafe. Inevitably folks concede that lower level libraries will have these unsafe blocks and still expect higher level code to trust them, and at that point we’ve essentially recreated the core paradigm of C: trust…

I'm not a rust fanboy but isn't the point of rust to dramatically decrease the area in which null pointer dereferences and friends can occur, and thus make them more likely to be spotted?

Not just spotted, but easier to find after the fact when the problematic behavior happens.

Re: Smart pointers for the kernel

#90

Post by pornel »

acbits wrote: post #12

https://github.com/acbits/reftrack-plugin I wrote this GCC plugin for this exact reason. Let's see whether the kernel team is interested in adopting it.

That's cool, but it'd be nice to also have a distinction between a get and a copy (like ObjC) or borrow/move (like Rust) to avoid redundant increments and decrements.
Post reply on HN