4 ms·

There are two very broad set of features: 1) Memory safety. If you live in the world of kernels and embedded code, your options are mostly C, C++, and (as of j

There are two very broad set of features: 1) Memory safety. If you live in the world of kernels and embedded code, your options are mostly C, C++, and (as of just the last few years) Rust. Of those, only Rust reliably prevents memory corruption mistakes like use-after-free. 2) Being a 21st century language. Rust has a lot of features that any new language would be expected to have these days: a unified build system, a library ecosystem that the build sytem knows about, slices over arrays and vectors, UTF-8 strings, convenient ways to de/serialize JSON, something like async/await, etc. This makes it competitive with languages like Java and Python for doing "everyday stuff", where realistically ~no one would use C. The main downside of Rust in a Java/Python sort of context is that the learning curve is a lot steeper. A couple other notes: - Some of nice 21st century features (like JSON) go away when you're writing embedded/kernel code, but others still work. Embedded ("no_std") Rust still has enums, error handling, slices, iterators, and sometimes even async/await. Those quality-of-life features are hard to replicate in C, even if you believe your code is 100% bug free :) - If you know you're going to be writing multithreaded code, Rust's thread safety features are really unmatched. A lot of the same machinery that gets used for memory safety also turns out to be useful for thread safety. Libraries like Rayon make it surprisingly convenient to write multithreaded code, while also catching a huge percentage of mistakes at compile time. (Deadlocks are still possible though.)

hartator 3y ago
> Memory safety Another very naive question. Are memory safety concerns from a cybersecurity standpoint or from less-dev error standpoint?
- eloisant 3y ago
  Mostly from a less-dev error standpoint but I think you gain in cybersecurity as well, as the language won't let you write code that accesses memory in places it's not supposed to.
  - masklinn 3y ago
    It's mostly from the cybersecurity standpoint actually, at least for large projects / companies. MS, Chromium, Project Zero, Mozilla, have pretty consistently found that north of 70% of vulnerabilities were rooted in memory safety. The dev-error is broader language guarantees, which dovetail into memory safety but are useful on their own e.g. data race safety, rich type system, ...
- CharlesW 3y ago
  Both, and they're related in the sense that software errors can become exploitable vulnerabilities. This is a handy summary by the NSA: https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...
- oconnor663 3y ago
  Both for sure, and which one is a bigger deal depends a lot on context. Cybersecurity issues make Rust a good choice for writing parsers for example. File format parsers handle scary data from the internet (JPEG, X.509, etc), and those often contain addresses and offsets that turn into raw pointers in the implementation, so they're a common source of security bugs. At the same time, they're usually isolated behind a reasonably tight API, so it can be practical to rewrite them in Rust even when all the calling code is still C or C++ or even Python. On the other hand, fewer-mistakes-sucking-up-dev-time is an especially big deal in multithreaded code. There was a story from Mozilla about how they'd tried to add threading to part of Firefox (I think it might've been the CSS engine?) and failed multiple times, but then they succeeded in Rust. Threading bugs tend to be painful to reproduce, and Rust's compile-time checks are extremely valuable there.
- brobinson 3y ago
  Microsoft, Google, and other companies have all determined that about 70% of CVEs are memory-related. Here's the US government's take: https://www.cisa.gov/news-events/news/urgent-need-memory-safety-software-products https://www.cisa.gov/news-events/news/urgent-need-memory-saf... These memory-related exploits disappear with Rust aside from in "unsafe" blocks (possibly the worst named keyword in any language... it should have been called "trusted"), and that means you have a smaller and more easily auditable attack surface for these types of memory-related exploits. Some code (e.g., FFI) can't be verified as memory-safe by the Rust compiler at compilation time so "unsafe" is there as an escape hatch. I've written a bunch of Rust since 2014 building things like webservers, realtime futures processing algorithms, MEV bots, etc., and I've only had to use "unsafe" a few times. I've also worked in security on products at Fortune 100 companies, and C is a constant nightmare for CVEs. I think I have PTSD from having to update libcurl. The more software we have written in memory safe languages, the better off we all are.
  - wredue 3y ago
    Just to avoid any “cyclist rides more aggressively when wearing helmet” type behaviour: It’s probably worth nothing that that vast majority of, and of large scale attacks, is basic shit that has nothing to do with memory safety. There’s benefit to memory safety, but just cause you’re wearing a helmet doesn’t mean you’re completely safe. Additionally, it’s not Google overall, but chromium project that find this, as well as not Microsoft overall, but specifically Windows. These are two projects that will naturally see a much higher rate of memory safety issues.
    - steveklabnik 3y ago
      > not Microsoft overall, but specifically Windows This isn't the case: https://msrc.microsoft.com/blog/2019/07/a-proactive-approach-to-more-secure-code/ https://msrc.microsoft.com/blog/2019/07/a-proactive-approach... > Since 2004, the Microsoft Security Response Centre (MSRC) has triaged every reported Microsoft security vulnerability. They've never qualified it as Windows only, to my knowledge.
    - deleted 3y ago
      [deleted]
- logicprog 3y ago
  Both. On the one hand, what Rust essentially forces you to do is just to program according to proper RAII principles that an experienced C++ programmer would already know and should already be using (especially once polonius lands), it's just better at checking failure to do so than any sanitizer or linter could ever be, so it's a way to avoid having to deal with annoying, hard to track down memory bugs. And in fact, the greater confidence static lifetime guarantees give you allows you to do things like using move semantics more where C++ programmers would have to use copies out of defensive programming. That's predominantly why I personally use it, as far as memory safety goes. On the other hand, [around 60-70% of serious security bugs have been proven to be caused by memory safety across many different projects](https://alexgaynor.net/2020/may/27/science-on-memory-unsafety-and-security/ https://alexgaynor.net/2020/may/27/science-on-memory-unsafet...) so if you do care about security in what you're doing, it's a boon there too.
- kstrauser 3y ago
  Tomato, tomato.

hartator 3y ago

> Memory safety Another very naive question. Are memory safety concerns from a cybersecurity standpoint or from less-dev error standpoint?

eloisant 3y ago
Mostly from a less-dev error standpoint but I think you gain in cybersecurity as well, as the language won't let you write code that accesses memory in places it's not supposed to.
- masklinn 3y ago
  It's mostly from the cybersecurity standpoint actually, at least for large projects / companies. MS, Chromium, Project Zero, Mozilla, have pretty consistently found that north of 70% of vulnerabilities were rooted in memory safety. The dev-error is broader language guarantees, which dovetail into memory safety but are useful on their own e.g. data race safety, rich type system, ...
CharlesW 3y ago
Both, and they're related in the sense that software errors can become exploitable vulnerabilities. This is a handy summary by the NSA: https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...
oconnor663 3y ago
Both for sure, and which one is a bigger deal depends a lot on context. Cybersecurity issues make Rust a good choice for writing parsers for example. File format parsers handle scary data from the internet (JPEG, X.509, etc), and those often contain addresses and offsets that turn into raw pointers in the implementation, so they're a common source of security bugs. At the same time, they're usually isolated behind a reasonably tight API, so it can be practical to rewrite them in Rust even when all the calling code is still C or C++ or even Python. On the other hand, fewer-mistakes-sucking-up-dev-time is an especially big deal in multithreaded code. There was a story from Mozilla about how they'd tried to add threading to part of Firefox (I think it might've been the CSS engine?) and failed multiple times, but then they succeeded in Rust. Threading bugs tend to be painful to reproduce, and Rust's compile-time checks are extremely valuable there.
brobinson 3y ago
Microsoft, Google, and other companies have all determined that about 70% of CVEs are memory-related. Here's the US government's take: https://www.cisa.gov/news-events/news/urgent-need-memory-safety-software-products https://www.cisa.gov/news-events/news/urgent-need-memory-saf... These memory-related exploits disappear with Rust aside from in "unsafe" blocks (possibly the worst named keyword in any language... it should have been called "trusted"), and that means you have a smaller and more easily auditable attack surface for these types of memory-related exploits. Some code (e.g., FFI) can't be verified as memory-safe by the Rust compiler at compilation time so "unsafe" is there as an escape hatch. I've written a bunch of Rust since 2014 building things like webservers, realtime futures processing algorithms, MEV bots, etc., and I've only had to use "unsafe" a few times. I've also worked in security on products at Fortune 100 companies, and C is a constant nightmare for CVEs. I think I have PTSD from having to update libcurl. The more software we have written in memory safe languages, the better off we all are.
- wredue 3y ago
  Just to avoid any “cyclist rides more aggressively when wearing helmet” type behaviour: It’s probably worth nothing that that vast majority of, and of large scale attacks, is basic shit that has nothing to do with memory safety. There’s benefit to memory safety, but just cause you’re wearing a helmet doesn’t mean you’re completely safe. Additionally, it’s not Google overall, but chromium project that find this, as well as not Microsoft overall, but specifically Windows. These are two projects that will naturally see a much higher rate of memory safety issues.
  - steveklabnik 3y ago
    > not Microsoft overall, but specifically Windows This isn't the case: https://msrc.microsoft.com/blog/2019/07/a-proactive-approach-to-more-secure-code/ https://msrc.microsoft.com/blog/2019/07/a-proactive-approach... > Since 2004, the Microsoft Security Response Centre (MSRC) has triaged every reported Microsoft security vulnerability. They've never qualified it as Windows only, to my knowledge.
  - deleted 3y ago
    [deleted]
logicprog 3y ago
Both. On the one hand, what Rust essentially forces you to do is just to program according to proper RAII principles that an experienced C++ programmer would already know and should already be using (especially once polonius lands), it's just better at checking failure to do so than any sanitizer or linter could ever be, so it's a way to avoid having to deal with annoying, hard to track down memory bugs. And in fact, the greater confidence static lifetime guarantees give you allows you to do things like using move semantics more where C++ programmers would have to use copies out of defensive programming. That's predominantly why I personally use it, as far as memory safety goes. On the other hand, [around 60-70% of serious security bugs have been proven to be caused by memory safety across many different projects](https://alexgaynor.net/2020/may/27/science-on-memory-unsafety-and-security/ https://alexgaynor.net/2020/may/27/science-on-memory-unsafet...) so if you do care about security in what you're doing, it's a boon there too.
kstrauser 3y ago
Tomato, tomato.