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

Bugs Rust won't catch

corrode.dev

Post reply on HN
Print view View original

111–120 of 395 posts

Re: Bugs Rust won't catch

#111

Post by einpoklum »

hombre_fatal wrote: post #23

One thing that's hard about rewriting code is that the original code was transformed incrementally over time in response to real world issues only found in production. The code gets silently encumbered with those lessons, and unless they are documented, there's a lot of hidden work that needs to be done before you actually reach parity. TFA is a good list of this exact sort of thing. Before you call people amateur fo…

> The code gets silently encumbered with those lessons, and unless they are documented, there's a lot of hidden work that needs to be done before you actually reach parity.

It should be stressed that failure to document such lessons, or at least the bugs/vulnerabilities avoided, is poor practice. Of course one can't document the bugs/vulnerabilities one has avoided implicitly by writing decent code to begin with, but it is important to share these lessons with the future reader, even if that means "wasting" time and space on a bunch of documentation such as "In here we do foo instead of bar because when we did bar in conditions ABC then baz happens which is bad because XYZ."

Re: Bugs Rust won't catch

#112

Post by emmelaich »

misja111 wrote: post #59

The root cause of some of the bugs seems to be the opaque nature of some of the Unix API. E.g. > The trap is that get_user_by_name ends up loading shared libraries from the new root filesystem to resolve the username. An attacker who can plant a file in the chroot gets to run code as uid 0. To me such a get_user_by_name function is like a booby trap, an accident that is waiting to happen. You need to have user data,…

Rather, I think that using a functional safe language tricks people into thinking that the data it deals with is stateless. Whereas many many things change in operating systems all the time.

Until we have a filesystem that can present a snapshot, everything has to checked all the time.

i.e. we need an API which gives input -> good result or failure. Not input -> good result or failure or error.

Re: Bugs Rust won't catch

#113

Post by 12_throw_away »

Joeboy wrote: post #101
tdiff wrote: post #93

Ok if there were some rust guys rewriting coreutils with no experience in linux, but how come Ubuntu accepted it into its mainline?

Because it's Ubuntu policy to replace some foundational part of the system with some janky unfinished experiment in every release. I agree with you that that's more the story here than "OMG, somebody wrote Rust code with bugs in it".

Right? Canonical wanted (still wants?) to use a coreutils implementation where "rm ./" would print "invalid input" while silently deleting the directory anyway.

I don't really care that some very amateur enthusiasts wrote some bad code for fun, but how in the world did anyone who knows anything about linux take this seriously as a coreutils replacement?

Re: Bugs Rust won't catch

#114

Post by awesome_dude »

dapperdrake wrote: post #26
collinfunk wrote: post #6

Hi, I am one of the maintainers of GNU Coreutils. Thanks for the article, it covers some interesting topics. In the little Rust that I have used, I have felt that it is far too easy to write TOCTOU races using std::fs. I hope the standard library gets an API similar to openat eventually. I just want to mention that I disagree with the section titled "Rule: Resolve Paths Before Comparing Them". Generally, it is better…

First of all, thank you for presenting a succinct take on this viewpoint from the other side of the fence from where I am at. So how can I learn from this? (Asking very aggressively, especially for Internet writing, to make the contrast unmistakable. And contrast helps with perceiving differences and mistakes.) (You also don’t owe me any of your time or mental bandwidth, whatsoever.) So here goes: Question 1: How com…

> Question 2:

> Does throughput really matter more than latency in everyday application?

IME as a user, hell yes

Getting a video I don't mind if it buffers a moment, but once it starts I need all of that data moving to my player as quickly as possible

OTOH if there's no wait, but the data is restricted (the amount coming to my player is less than the player needs to fully render the images), the video is "unwatchable"

Re: Bugs Rust won't catch

#115

Post by kibwen »

orlp wrote: post #103
cyberax wrote: post #34

Earlier quoted context omitted.

To be fair, Vec::set_len bug in Rust was in 2021. And even then it had to be annotated as `unsafe`. It was then deprecated and a linter check was added: https://github.com/rust-lang/rust-clippy/issues/7681

Vec::set_len is by no means deprecated. The lint you linked only covers a very specific unsound pattern using set_len.

Indeed, and it doesn't need to be deprecated, because it's an API explicitly designed to give you low-level control where you need it, and because it is appropriately defined as an `unsafe` function with documented safety invariants that must be manually upheld in order for usage to be memory-safe. The documentation also suggests several other (safe) functions that should be used instead when possible, and provides correct usage examples: https://doc.rust-lang.org/std/vec/struct.Vec.html#method.set... .

Re: Bugs Rust won't catch

#116

Post by eb08a167 »

I'm totally fine with people experimenting and making amateur attempts at what adult people do. After all, that's how we grow. What I'm actually curious about is how the decision-making chain at Ubuntu got so messed up that this made it into production.

Re: Bugs Rust won't catch

#118

Post by Cthulhu_ »

AlotOfReading wrote: post #9
wahern wrote: post #2

> What’s notable is that all of these bugs landed in a production Rust codebase, written by people who knew what they were doing They knew how to write Rust, but clearly weren't sufficiently experienced with Unix APIs, semantics, and pitfalls. Most of those mistakes are exceedingly amateur from the perspective of long-time GNU coreutils (or BSD or Solaris base) developers, issues that were identified and largely hash…

Someone once coined a related term, "disassembler rage". It's the idea that every mistake looks amateur when examined closely enough. Comes from people sitting in a disassembler and raging the high level programmers who had the gall to e.g. use conditionals instead of a switch statement inside a function call a hundred frames deep. We're looking solely at the few things they got wrong, and not the thousands of correc…

Thing is, these tools are so critical that even one error may cause systems to be compromised; rewriting them should never be taken lightly.

(Actually ideally there's formal verification tools that can accurately test for all of the issues found in this review / audit, like the very timing specific path changes, but that's a codebase on its own)

Re: Bugs Rust won't catch

#119

Post by aykutseker »

cataflutter wrote: post #106
aykutseker wrote: post #97

Earlier quoted context omitted.

good example from the article: the chroot+nss CVE. the rule that nss is dynamic and dlopens libraries from inside the chroot isn't anywhere obvious. it's encoded in 25+ years of sysadmins finding it out. clean-room rewrites end up re-learning that, usually as new CVEs. and LLM ports of the same code inherit the problem: the function signature is what they read, but the scars are what they need.

> the function signature is what they read, but the scars are what they need. This feels like a golden quote. Don't know if you intended for it to rhyme, but well done :D

thanks. honestly didn't catch the rhyme, accidental aphorism :D

Re: Bugs Rust won't catch

#120

Post by lionkor »

I struggle to find anything on this post that wouldn't be caught by some kind of unit test or manual review, especially when comparing with the GNU source for the coreutils. The whole coreutils rewrite is a terrible idea[1] and clearly being done in the wrong way (without the knowledge gained from the previous software).

If you do a rewrite, you should fully understand and learn from the predecessor, otherwise youre bound to repeat all the mistakes. Embarassing.

To be clear; I love Rust, I use it for various projects, and it's great. It doesn't save you from bad engineering.

[1]: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Post reply on HN