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

Rust’s standard library was vulnerable for years and nobody noticed

medium.com

Post reply on HN
Print view View original

51–58 of 58 posts

Re: Rust’s standard library was vulnerable for years and nobody noticed

#51

Post by deepsun »

0xCMP wrote: post #6
d33 wrote: post #5

I don't really like the message. For me, it's not "boo, a bug was found after years", it's "yay, they managed to find it!". Bugs are inevitable, security bugs as well. What I don't understand though is how they ended up with that bug in deque implementation anyway. Does Rust use "unsafe" keyword for its major data structures? If so, why? I would assume that having Box would let you implement most of the ideas without…

Mentioned here > You see, Rust provides safe abstractions that let you do useful stuff without having to deal with the complexities of memory layouts and other low-level arcana. But dealing with those things is necessary to run code on modern hardware, so something has to deal with it. In memory-safe languages like Python or Go this is usually handled by the language runtime — and Rust is no exception. > In Rust, the…

Huh, Java didn't know it's necessary to be unsafe to implement a queue (ConcurrentLinkedQueue).

Re: Rust’s standard library was vulnerable for years and nobody noticed

#52

Post by dbaupp »

rurban wrote: post #48
steveklabnik wrote: post #47

Earlier quoted context omitted.

Note that RFC is not implemented and not stable; this means it’s not in Rust. If you can find memory unsafety in safe Rust, it would be a huge deal. Please file bugs. That doesn’t seem to be what you’re saying, though.

This issue outlines one of the problems with memory safety which is not fixed. Since you don't believe outsiders, look at your own tickets, where your own developers admit unsafety. There are probably more, this is just the first I found. But the general problem is that rust cannot be made memory safe at all with its current architecture. Overlarge alloca calls are unsafe by default (either accept compile-time failur…

I see no mention of memory safety or unsafety in the issue you linked. Could you be more specific?

Re: Rust’s standard library was vulnerable for years and nobody noticed

#53

Post by dbaupp »

deepsun wrote: post #51
0xCMP wrote: post #6

Earlier quoted context omitted.

Mentioned here > You see, Rust provides safe abstractions that let you do useful stuff without having to deal with the complexities of memory layouts and other low-level arcana. But dealing with those things is necessary to run code on modern hardware, so something has to deal with it. In memory-safe languages like Python or Go this is usually handled by the language runtime — and Rust is no exception. > In Rust, the…

Huh, Java didn't know it's necessary to be unsafe to implement a queue (ConcurrentLinkedQueue).

Java data structures are built on top of a pile of unsafe code (the JVM and especially the GC), in a similar manner to building things on top of the std data structures in Rust.

For concurrency in particular the JVM exposes a more restricted (slower) model than the hardware, to guarantee no unsafety no matter how wrong the code is. Rust can't make that trade-off and still reach its performance goals.

Re: Rust’s standard library was vulnerable for years and nobody noticed

#54

Post by rurban »

dbaupp wrote: post #52
rurban wrote: post #48

Earlier quoted context omitted.

This issue outlines one of the problems with memory safety which is not fixed. Since you don't believe outsiders, look at your own tickets, where your own developers admit unsafety. There are probably more, this is just the first I found. But the general problem is that rust cannot be made memory safe at all with its current architecture. Overlarge alloca calls are unsafe by default (either accept compile-time failur…

I see no mention of memory safety or unsafety in the issue you linked. Could you be more specific?

I don't need to be more specific. Read the ticket outlining the alloca problems. It cannot get more safety relevant.

"Unresolved questions:

* [ ] How can we mitigate the risk of unintended unsized or large allocas? Note that the problem already exists today with large structs/arrays. A MIR lint against large/variable stack sizes would probably help users avoid these stack overflows. Do we want it in Clippy? rustc?

* [ ] How do we handle truely-unsized DSTs when we get them? They can theoretically be passed to functions, but they can never be put in temporaries."

Re: Rust’s standard library was vulnerable for years and nobody noticed

#55

Post by Nullabillity »

leshow wrote: post #50
vanderZwan wrote: post #28

Earlier quoted context omitted.

> I just really don't understand the criticism against Rust here I think you are confusing two different narratives in the article: software development in general, and Rust the language/ecosystem/community. The article raises many points about how the former as a whole does not care enough about security. How we do not have the right incentives to fix memory safety bugs (the bug bounty thing) nor treat them as the s…

> "unsafe" by definition throws safety guarantees out the window I wish they had chosen a different keyword, it doesn't necessarily mean that. For instance, the type checker still runs on the contents of unsafe blocks, so does the borrow checker, the only thing you can do that you can't normally is dereference raw pointers. This is potentially unsafe, and you should be careful, but it absolutely does not "throw all g…

> the only thing you can do that you can't normally is dereference raw pointers.

The type checker still runs by default, but unsafe allows you to opt out of it selectively (with std::mem::transmute[0]). The same way that borrows are still checked, but unsafe allows you to opt out by using raw pointers (as you mentioned).

[0]: https://doc.rust-lang.org/std/mem/fn.transmute.html

Re: Rust’s standard library was vulnerable for years and nobody noticed

#56

Post by dbaupp »

rurban wrote: post #54
dbaupp wrote: post #52

Earlier quoted context omitted.

I see no mention of memory safety or unsafety in the issue you linked. Could you be more specific?

I don't need to be more specific. Read the ticket outlining the alloca problems. It cannot get more safety relevant. " Unresolved questions: * [ ] How can we mitigate the risk of unintended unsized or large allocas? Note that the problem already exists today with large structs/arrays. A MIR lint against large/variable stack sizes would probably help users avoid these stack overflows. Do we want it in Clippy? rustc? *…

That is a feature that is not yet implemented! Of course there may be unsolved questions.

Neither of those are memory safety relevant. (A stack overflow is a reliable crash, not memory corruption, in Rust.)

Re: Rust’s standard library was vulnerable for years and nobody noticed

#57

Post by deepsun »

dbaupp wrote: post #53
deepsun wrote: post #51

Earlier quoted context omitted.

Huh, Java didn't know it's necessary to be unsafe to implement a queue (ConcurrentLinkedQueue).

Java data structures are built on top of a pile of unsafe code (the JVM and especially the GC), in a similar manner to building things on top of the std data structures in Rust. For concurrency in particular the JVM exposes a more restricted (slower) model than the hardware, to guarantee no unsafety no matter how wrong the code is. Rust can't make that trade-off and still reach its performance goals.

Mmm, no, ConcurrentLinkedQueue uses the same RAM primitives as Rust can use (compare-and-set, compare-and-set etc) that are needed to implement concurrent queues. And it doesn't use Unsafe class (same as Rust's "unsafe" keyword) in it, it's easy to check.

Or maybe I just miss something?

Re: Rust’s standard library was vulnerable for years and nobody noticed

#58

Post by dbaupp »

deepsun wrote: post #57
dbaupp wrote: post #53

Earlier quoted context omitted.

Java data structures are built on top of a pile of unsafe code (the JVM and especially the GC), in a similar manner to building things on top of the std data structures in Rust. For concurrency in particular the JVM exposes a more restricted (slower) model than the hardware, to guarantee no unsafety no matter how wrong the code is. Rust can't make that trade-off and still reach its performance goals.

Mmm, no, ConcurrentLinkedQueue uses the same RAM primitives as Rust can use (compare-and-set, compare-and-set etc) that are needed to implement concurrent queues. And it doesn't use Unsafe class (same as Rust's "unsafe" keyword) in it, it's easy to check. Or maybe I just miss something?

Yes: a GC means the programmer can avoid thinking about object lifetimes and just pretend every object lives forever. The garbage collector is deeply unsafe (as in, bugs may cause memory corruption): if a GC fails to account for even a single pointer somewhere, it might deallocate an object too early, potentially leading to problems like use-after-free.

Additionally, the JVM ensures every read and write to memory has (minimal) synchronisation so that there is no risk of a data race, meaning no undefined behaviour, no matter how wrong the code is. And, even the reads and writes using proper synchronisation (compare-and-swap, etc.) have only one choice: sequential-consistency.

In Rust, a global built-in-to-the-language GC isn't appropriate, and managing object lifetimes properly, with shared memory, is hard. It is thus something that a library has to use `unsafe` for, to assert to the compiler that the programmer has got things right because it is unable to check. Similarly, using synchronised reads/writes everywhere isn't right for Rust, so it is up to the concurrent data structure author to use the right synchronisation (which can be weaker for performance: acquire/release, instead of only SeqCst) just for the rest of the code to be safe: this is also something a compiler can't check.

Post reply on HN