Writing critical utilities in memory safe languages is probably a great idea. These are already fairly hardened and extremely complex code bases where the economics of developing a clever memory exploits is still rewarding.
For the rest of us mortals, I suggest you all harden your existing apps before rewriting everything. Broken access control, injections, and insecure design aren’t going to be saved by rust and are comparatively easy for any attacker to pull off compared to crafting a memory exploit and getting around ASLR, stack canaries, etc. If you’re stuck in c++, focus on functions that handle untrusted data, validate that data to death, and exclusively use memory safe constructs like strings and shared pointers.
> We believe that substantial improvements can be achieved through an incremental transition to a partially-memory-safe C++ language subset, augmented with hardware security features when available.
Google’s own Carbon language is positioning itself as C++ successor with an incremental path towards a memory-safe subset. It is odd that the article didn’t even mention it.
People might then discard the whole whitepaper as pushing Carbon, there are probably lots of other options that would be worthy of mention. Is Carbon an actual subset, because the syntax looks different to me in the Wikipedia page example?
I'd love to see a list of candidates and how they compare.
Hmm, this was exactly the talk where I got this information from! I thought that he specifically said that since the idioms were too different, it wouldn't be possible.
I don't think they do, specifically, they just know it exists.
I am probably one of the most likely people in the world to be tracking what Carbon is up to, yet I only really started paying attention last week. It's hard to keep up with many things.
The paper does mention it, if you read to the end. The blog post doesn't because according to the paper, Carbon's memory safety story isn't worked out.
> an incremental path towards a memory-safe subset
I was always extremely skeptical of this claim. Let me take the best case here: in a few years, a language called Carbon exists which interfaces seamlessly with C++ code while also having a subset no less safe than Rust. All of that seems possible.
That's putting aside the question of how safe they actually do plan to be, which could only threaten the value proposition further. I'm really giving them the best case here out of good faith.
What does that get us in practice? We may not have "bindings" as such, but we still need some hand-crafted safe adapter between unsafe types and safe types. The Carbon pitch deck presupposes that this is much better than safe wrappers for machine-generated bindings are today, without a single example of how it will be better.
The investment in easier C++ bindings for Rust will face similar challenges. Reusing existing C++ types can be made easier, but it's not clear how they can be made safer without hand-crafted safe wrappers. Once you have those safe wrappers, at least the rest of your code is in Rust, which famously already delivers on its ambitious promises.
In summary, while I am willing to believe a language can both be easier to interoperate with C++ and have a safe subset, I am skeptical that this means you can avoid having to create safe wrapper APIs for the unsafe C++/Carbon types. If you have to do that anyway, what remains of Carbon's value proposition in practice?
All I see is "you won't have a file of C++ bindings", which is a questionable benefit when tools make that file anyway, and there's a ton of investment -- including from Google itself -- into those tools.
> The responsibility is on our ecosystem, not the developer
I completely agree. "Rewrite it in Rust" is not the answer (it might be part of the answer).
After spending some time laying the groundwork, leadership at my employer is receptive to this idea. But now what? How do we transform our ecosystem? Anyone know of books, training, consultants worth paying?
I find the paper is really low on anything that other organizations relying on C++ heavily can take home as advice.
Like they still need their C++ systems [3]. They failed to make changes in their C++ systems that will make a difference [2]. And only progress they have is writing new peripheral or unimportant systems in other languages [1]. They do not believe that anything of importance will be following rewrite path on their side [3].
1. "gradual transition towards memory-safe languages like Java, Go, and Rust"
2. "We see no realistic path for an evolution of C++ into a language with rigorous memory safety guarantees"
3. "A large-scale rewrite of all existing C++ code into a different, memory-safe language appears very difficult and will likely remain impractical."
This blog, and the corresponding paper, is mostly a bunch of hand-wavy biased statements, which google (job) security team seems to be very pervasive about for the past few years. Secure by Design™ - right.
OTOH https://bughunters.google.com/blog/6368559657254912/llvm-s-r... is a very good read - while I don't agree with the premise of the article, it's a very good example showing how security concerns are addressed in real life with real life impact with real life problems to solve - by real engineers doing the meat work without cheap talk.
17 comments
[ 4.9 ms ] story [ 47.4 ms ] threadFor the rest of us mortals, I suggest you all harden your existing apps before rewriting everything. Broken access control, injections, and insecure design aren’t going to be saved by rust and are comparatively easy for any attacker to pull off compared to crafting a memory exploit and getting around ASLR, stack canaries, etc. If you’re stuck in c++, focus on functions that handle untrusted data, validate that data to death, and exclusively use memory safe constructs like strings and shared pointers.
Google’s own Carbon language is positioning itself as C++ successor with an incremental path towards a memory-safe subset. It is odd that the article didn’t even mention it.
I'd love to see a list of candidates and how they compare.
That said, Carbon’s definition of memory safety does not include data race safety, and so will not have a borrow checker.
>Best candidate for C++ is likely similar to Rust’s borrow checker
It is stated clearly in the talk that this is true for Carbon as well
[0] https://chandlerc.blog/slides/2023-cppnow-carbon-strategy/in...
[1] relevant timestamps:
https://youtube.com/watch?v=1ZTJ9omXOQ0&t=1h31m34s
https://youtube.com/watch?v=1ZTJ9omXOQ0&t=1h9m49s
I will have to re-watch it, thank you.
I think given that context, it makes sense that it’s not here, and when it becomes more real in a few years, it might get reevaluated then.
I am probably one of the most likely people in the world to be tracking what Carbon is up to, yet I only really started paying attention last week. It's hard to keep up with many things.
Meanwhile, the last public talks were about building the frontend.
I was always extremely skeptical of this claim. Let me take the best case here: in a few years, a language called Carbon exists which interfaces seamlessly with C++ code while also having a subset no less safe than Rust. All of that seems possible.
That's putting aside the question of how safe they actually do plan to be, which could only threaten the value proposition further. I'm really giving them the best case here out of good faith.
What does that get us in practice? We may not have "bindings" as such, but we still need some hand-crafted safe adapter between unsafe types and safe types. The Carbon pitch deck presupposes that this is much better than safe wrappers for machine-generated bindings are today, without a single example of how it will be better.
The investment in easier C++ bindings for Rust will face similar challenges. Reusing existing C++ types can be made easier, but it's not clear how they can be made safer without hand-crafted safe wrappers. Once you have those safe wrappers, at least the rest of your code is in Rust, which famously already delivers on its ambitious promises.
In summary, while I am willing to believe a language can both be easier to interoperate with C++ and have a safe subset, I am skeptical that this means you can avoid having to create safe wrapper APIs for the unsafe C++/Carbon types. If you have to do that anyway, what remains of Carbon's value proposition in practice?
All I see is "you won't have a file of C++ bindings", which is a questionable benefit when tools make that file anyway, and there's a ton of investment -- including from Google itself -- into those tools.
I completely agree. "Rewrite it in Rust" is not the answer (it might be part of the answer).
After spending some time laying the groundwork, leadership at my employer is receptive to this idea. But now what? How do we transform our ecosystem? Anyone know of books, training, consultants worth paying?
I find the paper is really low on anything that other organizations relying on C++ heavily can take home as advice.
Like they still need their C++ systems [3]. They failed to make changes in their C++ systems that will make a difference [2]. And only progress they have is writing new peripheral or unimportant systems in other languages [1]. They do not believe that anything of importance will be following rewrite path on their side [3].
1. "gradual transition towards memory-safe languages like Java, Go, and Rust"
2. "We see no realistic path for an evolution of C++ into a language with rigorous memory safety guarantees"
3. "A large-scale rewrite of all existing C++ code into a different, memory-safe language appears very difficult and will likely remain impractical."
OTOH https://bughunters.google.com/blog/6368559657254912/llvm-s-r... is a very good read - while I don't agree with the premise of the article, it's a very good example showing how security concerns are addressed in real life with real life impact with real life problems to solve - by real engineers doing the meat work without cheap talk.