this post was submitted on 03 Jan 2024
353 points (96.8% liked)
Technology
58303 readers
8 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
If you want a real answer, it's mostly advocacy, the same reason Linux enthusiasts show up to every negative-sounding Windows thread to tell you to install Linux instead. And if it is less obnoxious, it's only because there's fewer Rust enthusiasts.
There are, also, advantages to a Rust implementation that you can claim simply by virtue of something being implemented in Rust, as entire categories of problem that cause C projects to hemorrhage security vulnerabilities simply don't exist for Rust.
But mostly it's people wanting you to be excited about and interested in Rust.
Is there something inherently safer with how rust does things, or is it just a case of it being new, so the vulnerabilities haven't been found yet?
Yes, it is inherently safer than C. Unless you write code in an
unsafeblock, Rust will handle many aspects of memory allocation and management for you, and ensure their safety. It is memory safe and thread safe by default.C doesn’t have any of these safety checking features, so it would be equivalent to unsafe Rust, but all the time. It lets you do whatever you want with pointers for example, including making them point outside of the memory bounds. In program code, this will cause an illegal memory access exception, but in kernel code, all memory access is legal. Therefore, you could write a driver that accidentally overwrites the kernel’s own code in memory. That would likely cause a kernel panic and bring the whole system down. Whereas, in Rust, you can only do that within an
unsafecode block.Here's the summary for the wikipedia article you mentioned in your comment:
Thread safety is a computer programming concept applicable to multi-threaded code. Thread-safe code only manipulates shared data structures in a manner that ensures that all threads behave properly and fulfill their design specifications without unintended interaction. There are various strategies for making thread-safe data structures.A program may execute code in several threads simultaneously in a shared address space where each of those threads has access to virtually all of the memory of every other thread. Thread safety is a property that allows code to run in multithreaded environments by re-establishing some of the correspondences between the actual flow of control and the text of the program, by means of synchronization.^article^ ^|^ ^about^
Rust has many safeguards against some common errors that may cause security vulnerabilities. It’s by no means bulletproof against all vulnerabilities, but it’s something.
I only know the hype. But the hype says that Rust's ownership system makes memory usage much safer by forcing the coder to deal with data. Your values will eventually go out of scope, and you have to dictate when that will happen or else it won't compile.
...or something like that.
Well rust has a borrow checker which does make some memory bugs harder to create but to say that rust solved any of the known open problems in computer security. The answer is clearly no. It just copied some good ideas from ocaml into C++ and got some good marketing.
borrow checkers also already exist for C/C++/etc [just most people don't use them]
so, slightly safer defaults than C/C++ but doesn't contain any new/unique security magic.
I feel like this is an example of innovation vs invention. Rust did not invent borrow checking. It did, however, make the borrow checker an integral part of the language and compiler. Making memory safety the default behavior is innovative and makes it the path of least resistance.
Memory safety issues are responsible not just for crashes and perf degredation but are a significant attack vector for exploits. Making it harder to land there makes these exploitable conditions less common. The mechanism is not unique but its integral place in the language is.
It kinda really pioneered its particular kind of memory management. There's some theoretical ancestry involving ML-based research languages with region typing, stuff like this, but those are ultimately quite different. The rest of the type system is basically a cut-down Haskell (Hindley-Milner with qualified types (typeclasses/traits)), with some minor titbits and fiddling.
not exactly, as there are rust compilers like mrust that don't actually have borrow checkers and virtually none of those safety checks actually occur and there is a question of if the gcc rust compiler would be implementing that feature into the compiler.
So, that would be an attribution failure; as it isn't required by the language but the most popular rust compiler does include that feature.
But yes, more compilers would likely benefit the languages they support by also adopting that feature by default.
Borrow checking is part of the language specification, and a compiler that does not include it is, by definition, incomplete. The authors of mrust even state this in the project README.
Your claim is roughly equivalent to saying a C compiler which does not produce an error when a program calls an undeclared function means that C as a language does not ensure that your code doesn’t call functions that don’t exist - i.e., nonsense at worst, and irrelevant at best.
But it also has a cool name. You forgot to mention that very important aspect.