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

61–70 of 120 posts

Re: Smart pointers for the kernel

#61

Post by thayne »

jchw wrote: post #27
sfvisser wrote: post #21

Earlier quoted context omitted.

Isn’t the argument that by checking for NULL you can now safely crash/panic instead of going into undefined behavior and being a potential security hazard?

The potential for undefined behavior is, I will agree, potentially fairly serious, especially depending on specific circumstances... (In most cases it should reliably hit an unmapped page and cause an exception, but there are exceptions on weird targets or with huge offsets.) But, you can pretty much entirely ignore it if you can just guarantee that the pointer isn't NULL in the first place, which not only prevents y…

> In most cases it should reliably hit an unmapped page and cause an exception, but there are exceptions on weird targets or with huge offsets

Perhaps the most important exception is when the optimizer assumed the pointer was non-null, so optimized it in a way that produces completely unexpected behavior when it is null.

Also use-after-free and use of uninitialized pointers is more likely to point to incorrect, but mapped, locations.

Re: Smart pointers for the kernel

#62

Post by rcxdude »

stonethrowaway wrote: post #14

Anyone who wants to do kernel-level development should first do Embedded hardware/software interfacing. No RTOS, plain “Embedded C”, with some bit banging and dealing with voltage spikesc transients and people doing stupid shit to hardware (yes, really) and other things. Know the memory map and recite it from memory. Some might think I’m joking or being facetious - no, I’m pretty serious actually. I’d rather have an…

Plenty of people writing rust are coming from that background. And a substantial part of the reason for wanting it in linux is that the slapped-together C in linux drivers is often awful, both in terms of understanding of the hardware and in terms of the quality of the software. Rust can at least help the poor quality of the latter not affect the security and stability of the kernel so much.

Re: Smart pointers for the kernel

#63

Post by johnisgood »

im3w1l wrote: post #45
Rusky wrote: post #20

Earlier quoted context omitted.

It's not the same unwritten social contract: in Rust even the unsafe code has the same stricter type signatures as the safe code, so there is a formal way to judge which part of the program is at fault when the contract is broken. You might say the contract is now written. :-) In C, the type system does not express things like pointer validity, so you have to consider the system as a whole every time something goes w…

> In Rust, because the type system is sound Unfortunately, it's not. Now I do think it will be eventually fixed, but given how long it has taken it must be thorny. https://github.com/rust-lang/rust/issues/25860

That code looks horrendous.

Re: Smart pointers for the kernel

#64

Post by uecker »

Dylan16807 wrote: post #40
uecker wrote: post #32

Earlier quoted context omitted.

If you limited wrong to "memory safe" and also ignore that unsafe parts violating invariants can make safe parts of Rust to be wrong.

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

Re: Smart pointers for the kernel

#65

Post by [deleted] »

wbl wrote: post #5
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…

The difference is every line of C can do something wrong while very few lines of Rust can. It's much easier to scrutinize a small well contained class with tools like formal methods than a sprawling codebase.

[deleted]

Re: Smart pointers for the kernel

#66

Post by _flux »

simonask wrote: post #55
im3w1l wrote: post #45

Earlier quoted context omitted.

> In Rust, because the type system is sound Unfortunately, it's not. Now I do think it will be eventually fixed, but given how long it has taken it must be thorny. https://github.com/rust-lang/rust/issues/25860

In practice this is a compiler bug, though, and is treated as such, and not a soundness hole in the abstract design of the type system. There has also not been a single case of this bug being triggered in the wild by accident.

I take this to mean e.g. the Oxide project has proven the Rust type system sound?

There was a Git repository demontrating unsoundness issues in the compiler, but I seem to be unable to find it anymore :/. It seemed like there would be more than one underlying issue, but I can't really remember that.

Re: Smart pointers for the kernel

#67

Post by pornel »

foundry27 wrote: post #3
smodo wrote: post #2

I’m not very well versed in kernel development. But I am a Rust dev and have observed the discussion about Rust in Linux with interest… Having said that, this part of the article has me baffled: >> implementing these features for a smart-pointer type with a malicious or broken Deref (the trait that lets a programmer dereference a value) implementation could break the guarantees Rust relies on to determine when object…

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…

Building safe abstraction around unsafe code works, because it reduces the scope of the code that has to be reviewed for memory safety issues.

Instead of the whole codebase being suspect, and hunting for unsafety being like a million-line "Where's Waldo?", it reduces the problem to just verifying the `unsafe` blocks against safety of their public interface, "is this a Waldo?". This can still be tricky, but it has proven to be a more tractable problem.

Re: Smart pointers for the kernel

#68

Post by lertn »

Rusky wrote: post #20
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…

It's not the same unwritten social contract: in Rust even the unsafe code has the same stricter type signatures as the safe code, so there is a formal way to judge which part of the program is at fault when the contract is broken. You might say the contract is now written. :-) In C, the type system does not express things like pointer validity, so you have to consider the system as a whole every time something goes w…

This got me intrigued. Is there a soundness proof for the Rust type system?

The only language with such a proof that I am aware of is StandardML. Even OCaml is too complex for a soundness proof.

Re: Smart pointers for the kernel

#69

Post by a5c11 »

jendjdndn wrote: post #31
stonethrowaway wrote: post #14

Anyone who wants to do kernel-level development should first do Embedded hardware/software interfacing. No RTOS, plain “Embedded C”, with some bit banging and dealing with voltage spikesc transients and people doing stupid shit to hardware (yes, really) and other things. Know the memory map and recite it from memory. Some might think I’m joking or being facetious - no, I’m pretty serious actually. I’d rather have an…

You sound a lot like "kids these days!" What applicable skills would someone writing a kernel driver gain from reciting a memory map? Abstractions exist for a reason. The skill is in creating useful an performant abstractions.

The problem starts when the abstraction fails and you have to dive deeper, but no one taught you how to dive, only swim with a head above the water level. Those who can dive can also swim, it doesn't work the other way round, though.
Post reply on HN