6 ms·

> For system-level folks, Rust is one of the most exciting security developments of the past few decades. It elegantly solves problems which smart people were s

> For system-level folks, Rust is one of the most exciting security developments of the past few decades. It elegantly solves problems which smart people were saying could not be solved. Fuchsia has a lot of code, and we made sure that much of it (millions of LoC) was in Rust. > Our kernel, Zircon, is not in Rust. Not yet anyway. But it is in a nice, lean subset of C++ which I consider a vast improvement over C. A few thoughts on this. 1. Why is it that Chrome hasn't had more Rust adoption? It's so obvious - Chrome constantly has to make the tradeoff of security vs performance with regards to things like parsing in sandboxed code. There's so much potential - Firefox started with the obvious place, encoding and decoding, which are too dangerous for C/C++ but too performance sensitive for OOP. Feels like it's gotta be organizational, and somehow Fuschia has managed to break off from the part of Google that's still clutching to C++. 2. I'd be interested in hearing more about the design of Fuschia. Rust in userland is cool, or kernel modules too, but a memory unsafe kernel is an unfortunate thing. Even just the teaser of "not yet at least" is changing my view on the OS (I find the idea of another memory unsafe kernel/userland more depressing than exciting, even if there are neat things like capabilities). 3. Also curious to hear about their experience with a strict subset of C++. Again, looking at Chrome, we now see common ITW exploits - and Chrome is perhaps the single most fuzzed piece of software in the world, and leverages many modern C++ techniques (or the Google equivalent of them). As for the rest, verified execution seems interesting - is this like what iOS does, where it's basically impossible to RWX (except with an escape hatch for JITs, but behind a permission boundary)? TBH if Google pivots Fuschia to do something interesting like bottom-up memory safety with novel isolation mechanisms, I'll bite. Until then, I'll wallow in this awful pit we continue to dig ourselves into.

gostsamo 5y ago
Actually, Chrome were evaluating rust for there case. They were pretty much for it but they had to make it interface with the existing C++ codebase. Here is the relevant discussion: https://news.ycombinator.com/item?id=24211691 https://news.ycombinator.com/item?id=24211691
- staticassertion 5y ago
  Yeah they've been evaluating it for years, and then I read that document and it frankly felt like a poison pill. Reading that document it sounds very much like it's "how do we keep writing C++ while addressing the growing interest in rust".
  - olliej 5y ago
    No, the problem here is very real - rust doesn't have a reasonable c++ interop story, which means you have to rewrite potentially very large amounts of code at once and hope you don't regress anything. At the same time you have to continue normal development work, which is necessarily still C++, because again, you can't adopt rust in small sections. Basically to rewrite one DOM feature in rust would have a high likelihood of requiring rewriting the entire DOM implementation in rust, which would also require rearchitecting. While doing that other people would be wanting to continue working, but they don't have a rust build to work on so they have to continue in c++, thus sadness and conflicts. The other solution is to implement features in rust, and use a c++ wrapper to interface with that rust implementation, but now you've lost the memory safety advantages of rust (most of which are lifetime related, not bounds checking), and the C++ interface itself could be exciting as it could end up having to marshal other types.
    - staticassertion 5y ago
      Replacing small components like a single codec or parser wouldn't require anywhere near what Google is asking for in that document. I'm not saying to replace V8 with Rust. > but now you've lost the memory safety advantages of rust No you haven't.
      - jsnell 5y ago
        But replacing small isolated components is not a very interesting option. It means you're paying the costs of a multi-language codebase, in terms of build complexity, having to duplicate infrastructure, and siloing of developers. In return you'll only be getting limited benefits from it, since the usage will only be restricted to few cases and a full migration can never happen. Every single decision on what language to use for a component in becomes a hard to reverse ("will this component always remain a leaf node with a really simple interface?"), slowing down decision making and ossifying the architecture.
pronlover723 5y ago
> Why is it that Chrome hasn't had more Rust adoption? Mostly likely because Chrome started in C++ (WebKit) and so there is millions of lines of existing C++. Fuchsia, being new, didn't have that legacy. Note: they're looking into it https://www.chromium.org/Home/chromium-security/memory-safety/rust-and-c-interoperability https://www.chromium.org/Home/chromium-security/memory-safet...
- deleted 5y ago
  [deleted]
- pkulak 5y ago
  Not WebKit, KHTML. ;)
- fulafel 5y ago
  Fuchsia's kernel (Zircon) is based on LK [0] [1] ("Little Kernel"), it's not a from scratch thing. Would be interesting to know when LK started, the first commit[2] in the git repo is a big code drop so doesn't tell the story. [0] https://fuchsia.dev/fuchsia-src/concepts/kernel/zx_and_lk https://fuchsia.dev/fuchsia-src/concepts/kernel/zx_and_lk [1] https://github.com/littlekernel/lk https://github.com/littlekernel/lk [2] https://github.com/littlekernel/lk/commit/1d0df6996457273367e6d9d9d08bf6adb0fc9b65 https://github.com/littlekernel/lk/commit/1d0df6996457273367...
esprehn 5y ago
The web platform code in Chromium uses a C++ garbage collector [1] which gets a lot of benefits of a memory safe language and integrates well with V8/JS. That fixed the vast majority of issues without having to rewrite any of the code in another language. [1] https://chromium.googlesource.com/chromium/src/+/refs/heads/main/third_party/blink/renderer/platform/heap/BlinkGCAPIReference.md https://chromium.googlesource.com/chromium/src/+/refs/heads/... See also the recent posts from the V8 team, ex. https://v8.dev/blog/high-performance-cpp-gc https://v8.dev/blog/high-performance-cpp-gc
- staticassertion 5y ago
  Oh, I totally disagree with you. I'm well aware of how Chromium's C++ code works, and I'm aware of oilpan, I don't think it's fair at all to say it solves memory safety issues. Proof's in the pudding. ITW exploits are there.
  - pjmlp 5y ago
    While Rust has safer defaults, exploits are still possible depending on how well unsafe {} blocks are manually checked for correctness.
    - staticassertion 5y ago
      Yes, which means you can grep for vulnerabilities.
      - pjmlp 5y ago
        Logic errors in unsafe blocks usually aren't grepable. Speaking from experience using managed languages, and almost safe systems languages, with unsafe blocks support.
        staticassertion 5y ago
        Yes they are, you just grep for "unsafe". Speaking from a career in information security, vuln research, and as a rust engineer.
fdjm 5y ago
"why wasn't Zircon written in Rust": https://twitter.com/cpuGoogle/status/1397265884251525122?s=20 https://twitter.com/cpuGoogle/status/1397265884251525122?s=2...
- staticassertion 5y ago
  Thanks, I appreciate the context here although I didn't actually ask that question.
- rvz 5y ago
  The actual reason: > In conclusion. Too early, lack of experts, rapid evolution pains. It was stacking risk on top of an already risky project. Rust was extremely immature and too early to be used in an OS at the time. It just hit 1.0. By then, Fuchsia already wrote its kernel Magenta (now Zircon) in C++. In short, it did not make sense to write the OS kernel in Rust from both a technical and business standpoint at the time.
  - fulafel 5y ago
    Rust is not the only game in town though, there are the traditional estabilished safer alternatives to C++.
    - chakkepolja 5y ago
      Dude it's a kernel. What other alternatives do you suggest? ATS and all sound nice for academic projects but it's an industry project (even if some research purpose is there) they have different tradeoffs.
      - the_why_of_y 5y ago
        Ada has been around since the 1980s and works in this space; see for example Muen separation kernel: https://muen.sk/ https://muen.sk/
        5y ago
vinkelhake 5y ago
Re parsing: there's work being done on Wuffs which is meant for decoding data formats safely and efficiently. It's a new language, but it's one that compiles into C code. It's a Google project, and I wouldn't be surprised if it eventually makes its way into Chrome. https://github.com/google/wuffs https://github.com/google/wuffs
- tylerhou 5y ago
  Wuffs is not a Google project; it's a project whose code happens to be owned by Google. Most likely it's some engineer's side project and while I wouldn't be surprised if it was incorporated into a Google project, it's definitely not inevitable. It has probably the same odds as any other well-maintained open source project.
  - vinkelhake 5y ago
    I fully acknowledge that the README says that it's not an official Google product. But rather than debating the exact "Google status" of the project, here's the tracking bug[1] for its integration into Skia (the low level graphics library in Chromium). Here's the tracking bug[2] for its integration into Flutter. [1] https://bugs.chromium.org/p/skia/issues/detail?id=8235 https://bugs.chromium.org/p/skia/issues/detail?id=8235 [2] https://github.com/flutter/flutter/issues/23838 https://github.com/flutter/flutter/issues/23838
fpoling 5y ago
Chromium still uses C++14, not even C++17, due to binary comparability with PNaCl plugins. In 2022 the support for those will be retired, then more options will be possible.
- formerly_proven 5y ago
  So PNaCl is a plugin API that depends on the C++ ABI? What a spectacularly bad idea.
kaba0 5y ago
I read a possibly dated view by a security researcher that slowly introducing Rust into a C/C++ codebase may actually make the codebase less secure — since the C part can be made aware/can mitigate memory errors while in pure Rust, there is no such thing due to lack of need - so a buffer overflow can potentially cause bigger problems this way. If someone with more knowledge on C and Rust compilers and security, I would be interested in their opinion on this.
- steveklabnik 5y ago
  It is unclear to me exactly what you’re saying, so it’s hard to give an opinion. Do you happen to have a link?
- staticassertion 5y ago
  I'm knowledgeable on C and Rust and security and it sounds like a red herring to me. It's unclear what they're trying to say, but a charitable interpretation would be that C code assumes unsafety, therefor mitigations are in place. But it's actually the opposite situation - rustc is generally quite aggressive about turning mitigations on, and adopts them very quickly.
- est31 5y ago
  > slowly introducing Rust into a C/C++ codebase may actually make the codebase less secure I think to some extent this used to be true, and to some extent still is. Rust didn't always have MIRI support which points out if you try to do some unsound thing. Maybe 4 years ago you would have been the first person to use a specific niche static analyzer that builds on LLVM with Rust, so there would have been bugs inevitably. Same goes for wanting to analyze both the C and Rust that call each other. So static analyzer support has improved I think. Also, C is better understood while in Rust it's less obvious how things need to look like. With better understood I don't mean by the developers who write the code, but from a language specification point of view. E.g. views have evolved on how accessible uninitialized memory should be in unsafe Rust, so MaybeUninit has been added. It's only two years old at this point. Also there is the issue of safe interfaces between languages. In the days before cxx, if you had a "safe" cpp smart pointer, moving it to Rust and back would have involved possibly more unsafety than operating on that smart pointer yourself. There has also been the long standing issue of unwinding at FFI boundaries. If you have a codebase with 5 thousand lines of cpp and now replace 1 thousand lines with a Rust component of 500 lines, it might still be a better idea to just keep the old solution and give it a thorough review. It's different I think if you have a codebase with 5 million lines of cpp though and replace one component of 50k lines that has a clean interface but is an extreme source of vulnerabilities. It's a question of how dangerous "surface" is between the two languages. Does all of this mean you shouldn't invest into Rust? Absolutely no. If it's a 5k lines codebase, you can rewrite it completely. If it's a 5 million lines codebase, I'm sure you'll find a security bug ridden component that is well isolated that you can replace.
deleted 5y ago
[deleted]
jillesvangurp 5y ago
Very simple, the Chrome and ChromeOS code bases mostly predate Rust becoming a thing. It's a complex code base. Replacing any of it is a big task. It took Mozilla many years to develop Rust and use it in their own browser, which is likely to be ongoing work for many years to come. Additionally, developers familiar with the Chrome/ChromeOS code base are probably very hard core C++ developers. Switching to Rust is not going to happen just like that. They'd have to want it and agree on doing it. And then they'd have to learn it and get productive with it. Fuchsia development has been ongoing for quite long as well but most of the code base is from more recent times. When they first announced Fuchsia, they did not talk about Rust at all. But obviously they managed to attract some Rust developers since then and perhaps made a conscious choice to not use C++ for new development and try to contain what they had already as much as they could where it was already there. It's one of those high level technology choices that kind of became an obvious one a few years ago. If your goal is to develop fast and secure software, Rust seems the preferable language. Google has the track record to prove that C & C++ are inherently risky since despite decades of trying to prevent issues, they regularly have to deal with them still. Including in new code. I imagine somebody at a high level just drew a line in the sand and put a stop to most new C++ development on Fuchsia. Do it right the first time. Or something like that.
benreesman 5y ago
Where is this big, heavy, commercially important piece of software written in Rust? What am I missing?
- staticassertion 5y ago
  I don't really know why you're asking this, but there are many.

gostsamo 5y ago

Actually, Chrome were evaluating rust for there case. They were pretty much for it but they had to make it interface with the existing C++ codebase. Here is the relevant discussion: https://news.ycombinator.com/item?id=24211691 https://news.ycombinator.com/item?id=24211691

staticassertion 5y ago
Yeah they've been evaluating it for years, and then I read that document and it frankly felt like a poison pill. Reading that document it sounds very much like it's "how do we keep writing C++ while addressing the growing interest in rust".
- olliej 5y ago
  No, the problem here is very real - rust doesn't have a reasonable c++ interop story, which means you have to rewrite potentially very large amounts of code at once and hope you don't regress anything. At the same time you have to continue normal development work, which is necessarily still C++, because again, you can't adopt rust in small sections. Basically to rewrite one DOM feature in rust would have a high likelihood of requiring rewriting the entire DOM implementation in rust, which would also require rearchitecting. While doing that other people would be wanting to continue working, but they don't have a rust build to work on so they have to continue in c++, thus sadness and conflicts. The other solution is to implement features in rust, and use a c++ wrapper to interface with that rust implementation, but now you've lost the memory safety advantages of rust (most of which are lifetime related, not bounds checking), and the C++ interface itself could be exciting as it could end up having to marshal other types.
  - staticassertion 5y ago
    Replacing small components like a single codec or parser wouldn't require anywhere near what Google is asking for in that document. I'm not saying to replace V8 with Rust. > but now you've lost the memory safety advantages of rust No you haven't.
    - jsnell 5y ago
      But replacing small isolated components is not a very interesting option. It means you're paying the costs of a multi-language codebase, in terms of build complexity, having to duplicate infrastructure, and siloing of developers. In return you'll only be getting limited benefits from it, since the usage will only be restricted to few cases and a full migration can never happen. Every single decision on what language to use for a component in becomes a hard to reverse ("will this component always remain a leaf node with a really simple interface?"), slowing down decision making and ossifying the architecture.

pronlover723 5y ago

> Why is it that Chrome hasn't had more Rust adoption? Mostly likely because Chrome started in C++ (WebKit) and so there is millions of lines of existing C++. Fuchsia, being new, didn't have that legacy. Note: they're looking into it https://www.chromium.org/Home/chromium-security/memory-safety/rust-and-c-interoperability https://www.chromium.org/Home/chromium-security/memory-safet...

deleted 5y ago
[deleted]
pkulak 5y ago
Not WebKit, KHTML. ;)
fulafel 5y ago
Fuchsia's kernel (Zircon) is based on LK [0] [1] ("Little Kernel"), it's not a from scratch thing. Would be interesting to know when LK started, the first commit[2] in the git repo is a big code drop so doesn't tell the story. [0] https://fuchsia.dev/fuchsia-src/concepts/kernel/zx_and_lk https://fuchsia.dev/fuchsia-src/concepts/kernel/zx_and_lk [1] https://github.com/littlekernel/lk https://github.com/littlekernel/lk [2] https://github.com/littlekernel/lk/commit/1d0df6996457273367e6d9d9d08bf6adb0fc9b65 https://github.com/littlekernel/lk/commit/1d0df6996457273367...

esprehn 5y ago

The web platform code in Chromium uses a C++ garbage collector [1] which gets a lot of benefits of a memory safe language and integrates well with V8/JS. That fixed the vast majority of issues without having to rewrite any of the code in another language. [1] https://chromium.googlesource.com/chromium/src/+/refs/heads/main/third_party/blink/renderer/platform/heap/BlinkGCAPIReference.md https://chromium.googlesource.com/chromium/src/+/refs/heads/... See also the recent posts from the V8 team, ex. https://v8.dev/blog/high-performance-cpp-gc https://v8.dev/blog/high-performance-cpp-gc

staticassertion 5y ago
Oh, I totally disagree with you. I'm well aware of how Chromium's C++ code works, and I'm aware of oilpan, I don't think it's fair at all to say it solves memory safety issues. Proof's in the pudding. ITW exploits are there.
- pjmlp 5y ago
  While Rust has safer defaults, exploits are still possible depending on how well unsafe {} blocks are manually checked for correctness.
  - staticassertion 5y ago
    Yes, which means you can grep for vulnerabilities.
    - pjmlp 5y ago
      Logic errors in unsafe blocks usually aren't grepable. Speaking from experience using managed languages, and almost safe systems languages, with unsafe blocks support.
      - staticassertion 5y ago
        Yes they are, you just grep for "unsafe". Speaking from a career in information security, vuln research, and as a rust engineer.

fdjm 5y ago

"why wasn't Zircon written in Rust": https://twitter.com/cpuGoogle/status/1397265884251525122?s=20 https://twitter.com/cpuGoogle/status/1397265884251525122?s=2...

staticassertion 5y ago
Thanks, I appreciate the context here although I didn't actually ask that question.
rvz 5y ago
The actual reason: > In conclusion. Too early, lack of experts, rapid evolution pains. It was stacking risk on top of an already risky project. Rust was extremely immature and too early to be used in an OS at the time. It just hit 1.0. By then, Fuchsia already wrote its kernel Magenta (now Zircon) in C++. In short, it did not make sense to write the OS kernel in Rust from both a technical and business standpoint at the time.
- fulafel 5y ago
  Rust is not the only game in town though, there are the traditional estabilished safer alternatives to C++.
  - chakkepolja 5y ago
    Dude it's a kernel. What other alternatives do you suggest? ATS and all sound nice for academic projects but it's an industry project (even if some research purpose is there) they have different tradeoffs.
    - the_why_of_y 5y ago
      Ada has been around since the 1980s and works in this space; see for example Muen separation kernel: https://muen.sk/ https://muen.sk/
      - 5y ago

vinkelhake 5y ago

Re parsing: there's work being done on Wuffs which is meant for decoding data formats safely and efficiently. It's a new language, but it's one that compiles into C code. It's a Google project, and I wouldn't be surprised if it eventually makes its way into Chrome. https://github.com/google/wuffs https://github.com/google/wuffs

tylerhou 5y ago
Wuffs is not a Google project; it's a project whose code happens to be owned by Google. Most likely it's some engineer's side project and while I wouldn't be surprised if it was incorporated into a Google project, it's definitely not inevitable. It has probably the same odds as any other well-maintained open source project.
- vinkelhake 5y ago
  I fully acknowledge that the README says that it's not an official Google product. But rather than debating the exact "Google status" of the project, here's the tracking bug[1] for its integration into Skia (the low level graphics library in Chromium). Here's the tracking bug[2] for its integration into Flutter. [1] https://bugs.chromium.org/p/skia/issues/detail?id=8235 https://bugs.chromium.org/p/skia/issues/detail?id=8235 [2] https://github.com/flutter/flutter/issues/23838 https://github.com/flutter/flutter/issues/23838

fpoling 5y ago

Chromium still uses C++14, not even C++17, due to binary comparability with PNaCl plugins. In 2022 the support for those will be retired, then more options will be possible.

formerly_proven 5y ago
So PNaCl is a plugin API that depends on the C++ ABI? What a spectacularly bad idea.

kaba0 5y ago

I read a possibly dated view by a security researcher that slowly introducing Rust into a C/C++ codebase may actually make the codebase less secure — since the C part can be made aware/can mitigate memory errors while in pure Rust, there is no such thing due to lack of need - so a buffer overflow can potentially cause bigger problems this way. If someone with more knowledge on C and Rust compilers and security, I would be interested in their opinion on this.

steveklabnik 5y ago
It is unclear to me exactly what you’re saying, so it’s hard to give an opinion. Do you happen to have a link?
staticassertion 5y ago
I'm knowledgeable on C and Rust and security and it sounds like a red herring to me. It's unclear what they're trying to say, but a charitable interpretation would be that C code assumes unsafety, therefor mitigations are in place. But it's actually the opposite situation - rustc is generally quite aggressive about turning mitigations on, and adopts them very quickly.
est31 5y ago
> slowly introducing Rust into a C/C++ codebase may actually make the codebase less secure I think to some extent this used to be true, and to some extent still is. Rust didn't always have MIRI support which points out if you try to do some unsound thing. Maybe 4 years ago you would have been the first person to use a specific niche static analyzer that builds on LLVM with Rust, so there would have been bugs inevitably. Same goes for wanting to analyze both the C and Rust that call each other. So static analyzer support has improved I think. Also, C is better understood while in Rust it's less obvious how things need to look like. With better understood I don't mean by the developers who write the code, but from a language specification point of view. E.g. views have evolved on how accessible uninitialized memory should be in unsafe Rust, so MaybeUninit has been added. It's only two years old at this point. Also there is the issue of safe interfaces between languages. In the days before cxx, if you had a "safe" cpp smart pointer, moving it to Rust and back would have involved possibly more unsafety than operating on that smart pointer yourself. There has also been the long standing issue of unwinding at FFI boundaries. If you have a codebase with 5 thousand lines of cpp and now replace 1 thousand lines with a Rust component of 500 lines, it might still be a better idea to just keep the old solution and give it a thorough review. It's different I think if you have a codebase with 5 million lines of cpp though and replace one component of 50k lines that has a clean interface but is an extreme source of vulnerabilities. It's a question of how dangerous "surface" is between the two languages. Does all of this mean you shouldn't invest into Rust? Absolutely no. If it's a 5k lines codebase, you can rewrite it completely. If it's a 5 million lines codebase, I'm sure you'll find a security bug ridden component that is well isolated that you can replace.

deleted 5y ago

[deleted]

jillesvangurp 5y ago

Very simple, the Chrome and ChromeOS code bases mostly predate Rust becoming a thing. It's a complex code base. Replacing any of it is a big task. It took Mozilla many years to develop Rust and use it in their own browser, which is likely to be ongoing work for many years to come. Additionally, developers familiar with the Chrome/ChromeOS code base are probably very hard core C++ developers. Switching to Rust is not going to happen just like that. They'd have to want it and agree on doing it. And then they'd have to learn it and get productive with it. Fuchsia development has been ongoing for quite long as well but most of the code base is from more recent times. When they first announced Fuchsia, they did not talk about Rust at all. But obviously they managed to attract some Rust developers since then and perhaps made a conscious choice to not use C++ for new development and try to contain what they had already as much as they could where it was already there. It's one of those high level technology choices that kind of became an obvious one a few years ago. If your goal is to develop fast and secure software, Rust seems the preferable language. Google has the track record to prove that C & C++ are inherently risky since despite decades of trying to prevent issues, they regularly have to deal with them still. Including in new code. I imagine somebody at a high level just drew a line in the sand and put a stop to most new C++ development on Fuchsia. Do it right the first time. Or something like that.

benreesman 5y ago

Where is this big, heavy, commercially important piece of software written in Rust? What am I missing?

staticassertion 5y ago
I don't really know why you're asking this, but there are many.