6 ms·

Makes you think about choosing to write software in C / C++ / other non-memory-safe languages when you need 25000 cores churning away to ensure you don’t make m

Makes you think about choosing to write software in C / C++ / other non-memory-safe languages when you need 25000 cores churning away to ensure you don’t make mistakes that could cause serious security issues. It makes me wonder why Google wouldn’t put their efforts into using Rust, for example. Of course, server power is cheap, but not for our planet.

tracker1 8y ago
Well, don't most of their internal systems already run tooling that is already written using Linux and Gnu libraries? Wouldn't it make sense to do testing on what they already have available instead of some theoretical ground up replacement effort? Not to say there isn't work on replacement efforts, only that testing what is in use is a practical thing, even if the scale is surprising.
twblalock 8y ago
I know some embedded/kernel devs and they don't take Rust very seriously. I don't think it has a lot of mindshare in industry among the kind of people who currently write C. Even if all new code was written in safe languages we would still need to do fuzzing until all legacy code was rewritten -- operating systems, SSL libraries, browsers, load balancers, etc.
- pcwalton 8y ago
  I know lots of embedded/kernel devs (I am one) and lots of them are at least interested in Rust. It does have mindshare.
- master-litty 8y ago
  I truly believe that's the only reason people aren't using Rust as a replacement for C / C++ immediately. The adoption isn't widespread, but I'm rather optimistic it will be. It's getting there.
  - twblalock 8y ago
    I don't think it's the only reason. My C programmer friends like the dangerous features of the language and want to use them. Their programs are designed around the assumption that they can mutate anything in memory whenever they want to. They use mutable global variables. They would strongly dislike Rust's memory protections and ownership concept, and its other safety features.
    - feanaro 8y ago
      To what purpose? It sounds like they are being reckless just for the heck of it, because that's how the big boys do it and they can't be bothered to learn a new skill.
timClicks 8y ago
It's present in some newer projects, notably Fuchsia.
rifung 8y ago
> It makes me wonder why Google wouldn’t put their efforts into using Rust, for example. Well some newer projects in Chrome/Chromium are written in Rust so for what it's worth there is some effort. I believe just yesterday the security team published a document which recommended avoiding unsafe languages for safety critical code: https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md https://chromium.googlesource.com/chromium/src/+/master/docs...
- fabrice_d 8y ago
  I don't see Rust in the list of approved safe languages for chromium at https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md#safe-languages https://chromium.googlesource.com/chromium/src/+/master/docs...
  - deleted 8y ago
    [deleted]
  - Jwarder 8y ago
    Is there an actual list of approved languages? Rust is listed a little higher in that link in the section about avoiding unsafe implementation languages. Given that they list it as a counterexample of things to avoid I would assume that means it is good, but that is no sure thing.
  - rifung 8y ago
    I don't think that's a list of approved languages but "likely candidates"? But apologies perhaps I confused Chromium for Chromium OS: https://chromium.googlesource.com/chromiumos/docs/+/master/rust_on_cros.md https://chromium.googlesource.com/chromiumos/docs/+/master/r...
htfy96 8y ago
Have to say that nothing can make your program automatically safe (defined by common sense, not "memory leaks are also memory safe"[0]) without any effort, and the trend to claim some languages are inherently "safe" while others are not is definitely a hype. Modern C++ plus static analyzing (Chromium rolled out their own Clang plugins to do that) provides better flexibility. [0]: http://huonw.github.io/blog/2016/04/memory-leaks-are-memory-safe/ http://huonw.github.io/blog/2016/04/memory-leaks-are-memory-...
- pcwalton 8y ago
  Virtually nobody in security agrees with you. Memory-safe languages do effectively mitigate some of the most critical security issues. C++ static analysis is helpful, but it is not memory safe. Modern C++ doesn't really help. In fact, in my opinion, modern C++ tends to be less memory safe than "classic" C++, because it adds all sorts of new fun ways to get use-after-free.
  - daeken 8y ago
    People drastically underestimate the prevalence and impact of UAF attacks. They're extremely common in complex applications and often lead to everything from information leaks to code execution. That's why almost every browser exploit (of the last ~10 years at least) uses at least one UAF in their chain.
    - saagarjha 8y ago
      > That's why almost every browser exploit (of the last ~10 years at least) uses at least one UAF in their chain. That's usually because the "low-hanging fruit" is mostly gone due to protections like stack canaries, CFI checks, address randomization, and sandboxing, which makes things like buffer overflows or jumping to shellcode more difficult.
      - pjmlp 8y ago
        Yet the Linux Kernel Self Preservation project is still in a getting there kind of state.
rixrax 8y ago
Even if you use Rust (or other memory safe(r) languages), you still have a variety of failure modes that they don’t protect against, with which fuzzing may be helpful: poor resource handling (e.g. massive memory allocations), logic problems in program, busy loops, all kinds of assertions, exceptions, etc. triggering of which may lead to DoS, or other undefined behaviors. Sure: not as critical , depending your threat model , as remote code execution, but things that should be found and fixed from any code base that is part of something that people use.
steveklabnik 8y ago
Google is putting effort into using Rust, but in more greenfield work, like Fuchsia. Integrating a new language into a new codebase is a lot of work; it would be great if Chromium started using it, but I also understand why it may be a harder sell there. Engineering is all about tradeoffs.

tracker1 8y ago

Well, don't most of their internal systems already run tooling that is already written using Linux and Gnu libraries? Wouldn't it make sense to do testing on what they already have available instead of some theoretical ground up replacement effort? Not to say there isn't work on replacement efforts, only that testing what is in use is a practical thing, even if the scale is surprising.

twblalock 8y ago

I know some embedded/kernel devs and they don't take Rust very seriously. I don't think it has a lot of mindshare in industry among the kind of people who currently write C. Even if all new code was written in safe languages we would still need to do fuzzing until all legacy code was rewritten -- operating systems, SSL libraries, browsers, load balancers, etc.

pcwalton 8y ago
I know lots of embedded/kernel devs (I am one) and lots of them are at least interested in Rust. It does have mindshare.
master-litty 8y ago
I truly believe that's the only reason people aren't using Rust as a replacement for C / C++ immediately. The adoption isn't widespread, but I'm rather optimistic it will be. It's getting there.
- twblalock 8y ago
  I don't think it's the only reason. My C programmer friends like the dangerous features of the language and want to use them. Their programs are designed around the assumption that they can mutate anything in memory whenever they want to. They use mutable global variables. They would strongly dislike Rust's memory protections and ownership concept, and its other safety features.
  - feanaro 8y ago
    To what purpose? It sounds like they are being reckless just for the heck of it, because that's how the big boys do it and they can't be bothered to learn a new skill.

timClicks 8y ago

It's present in some newer projects, notably Fuchsia.

rifung 8y ago

> It makes me wonder why Google wouldn’t put their efforts into using Rust, for example. Well some newer projects in Chrome/Chromium are written in Rust so for what it's worth there is some effort. I believe just yesterday the security team published a document which recommended avoiding unsafe languages for safety critical code: https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md https://chromium.googlesource.com/chromium/src/+/master/docs...

fabrice_d 8y ago
I don't see Rust in the list of approved safe languages for chromium at https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md#safe-languages https://chromium.googlesource.com/chromium/src/+/master/docs...
- deleted 8y ago
  [deleted]
- Jwarder 8y ago
  Is there an actual list of approved languages? Rust is listed a little higher in that link in the section about avoiding unsafe implementation languages. Given that they list it as a counterexample of things to avoid I would assume that means it is good, but that is no sure thing.
- rifung 8y ago
  I don't think that's a list of approved languages but "likely candidates"? But apologies perhaps I confused Chromium for Chromium OS: https://chromium.googlesource.com/chromiumos/docs/+/master/rust_on_cros.md https://chromium.googlesource.com/chromiumos/docs/+/master/r...

htfy96 8y ago

Have to say that nothing can make your program automatically safe (defined by common sense, not "memory leaks are also memory safe"[0]) without any effort, and the trend to claim some languages are inherently "safe" while others are not is definitely a hype. Modern C++ plus static analyzing (Chromium rolled out their own Clang plugins to do that) provides better flexibility. [0]: http://huonw.github.io/blog/2016/04/memory-leaks-are-memory-safe/ http://huonw.github.io/blog/2016/04/memory-leaks-are-memory-...

pcwalton 8y ago
Virtually nobody in security agrees with you. Memory-safe languages do effectively mitigate some of the most critical security issues. C++ static analysis is helpful, but it is not memory safe. Modern C++ doesn't really help. In fact, in my opinion, modern C++ tends to be less memory safe than "classic" C++, because it adds all sorts of new fun ways to get use-after-free.
- daeken 8y ago
  People drastically underestimate the prevalence and impact of UAF attacks. They're extremely common in complex applications and often lead to everything from information leaks to code execution. That's why almost every browser exploit (of the last ~10 years at least) uses at least one UAF in their chain.
  - saagarjha 8y ago
    > That's why almost every browser exploit (of the last ~10 years at least) uses at least one UAF in their chain. That's usually because the "low-hanging fruit" is mostly gone due to protections like stack canaries, CFI checks, address randomization, and sandboxing, which makes things like buffer overflows or jumping to shellcode more difficult.
    - pjmlp 8y ago
      Yet the Linux Kernel Self Preservation project is still in a getting there kind of state.

rixrax 8y ago

Even if you use Rust (or other memory safe(r) languages), you still have a variety of failure modes that they don’t protect against, with which fuzzing may be helpful: poor resource handling (e.g. massive memory allocations), logic problems in program, busy loops, all kinds of assertions, exceptions, etc. triggering of which may lead to DoS, or other undefined behaviors. Sure: not as critical , depending your threat model , as remote code execution, but things that should be found and fixed from any code base that is part of something that people use.

steveklabnik 8y ago

Google is putting effort into using Rust, but in more greenfield work, like Fuchsia. Integrating a new language into a new codebase is a lot of work; it would be great if Chromium started using it, but I also understand why it may be a harder sell there. Engineering is all about tradeoffs.