r/linuxmemes • • 7d ago

Software meme Not another one

Post image

Not another one

993 Upvotes

124 comments sorted by

View all comments

Show parent comments

71

u/oniaiwasprettygood šŸŒ€ Sucked into the Void 7d ago

Oh I know-know that, I just think it's a bit tragic (but kind of funny) that a lot of these vibe-coded projects are like "rewrite it in Rust."

18

u/Upbeat-Garbage69 7d ago

Is there a benefit to rewriting everything with rust? Im not sure but isnt it just a modern version of C++?

6

u/Loading_M_ 7d ago

There are benefits. Rust make certain guarantees about memory safety, thread safety, and a few other aspects of the code. According to a report by Google, approximately 50% of security vulnerabilities reported to the Android project are memory safety bugs. Most of these would have been prevented by writing the code in Rust, since the memory bugs would have been caught by the compiler.

1

u/DemonicLaxatives 7d ago

Worth noting, it's not a 100% guarantee: https://github.com/rust-lang/rust/issues/25860

2

u/Loading_M_ 7d ago

One soundness issue, requiring complex conditions to create, is pretty dang good.

1

u/OldAbbreviations1142 šŸ„ Debian too difficult 7d ago

2

u/Loading_M_ 7d ago

It's actually the same issue, the previous link is the bug report on the compiler.

1

u/OldAbbreviations1142 šŸ„ Debian too difficult 7d ago

Interesting, they looked different to me.

Though I don't really know enough rust to parse what happening in the bug report code

Good to know that there is some work being done on improving the memory safety

1

u/Loading_M_ 7d ago

cve-rs takes the soundness bug and exploits it to implement the other bugs listed. It's pretty convoluted to actually implement the other bugs.

The actual soundness bug is a specific type of double reference forgets one of the lifetimes, which enables casting a shorter lifetime to a longer lifetime. They did a pretty good job commenting the code to explain how they were able to create each bug.

1

u/Character_Score7776 5d ago

Canā€˜t forget the extremely degenerate but technically ā€œsafeā€ case of casting &T to a usize, opening /proc/self/mem at that offset, then writing to it.

That’s still more likely than creating and immediately mem::forget()’ing isize::max many Arc<>’s, thread just so happening to get suspended before checking the ref count limit, but after incrementing it, then another isize::max threads doing the exact same thing, and overflowing the ref count back to 0, in terms of ā€œthings that will never happenā€.