Secure by Design: Google's Perspective on Memory Safety(security.googleblog.com)
security.googleblog.com
Secure by Design: Google's Perspective on Memory Safety
https://security.googleblog.com/2024/03/secure-by-design-googles-perspective-on.html
17 comments
https://www.youtube.com/watch?v=lgivCGdmFrw
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.
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.
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.
The Carbon folks are very clear that it is nowhere near ready, an experiment, and that it may not even work out. They suggest using Rust if you can.
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 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 really don't get where people get the "Carbon is production ready" vibe from.
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.
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.
Usually the remarks tend to be as if they already had a compiler ready and were building stuff with it.
Meanwhile, the last public talks were about building the frontend.
Meanwhile, the last public talks were about building the frontend.
> 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.
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 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.
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.
I'd love to see a list of candidates and how they compare.
Carbon is not a subset of C++, it will have a memory safe subset of itself, like Rust does.
That said, Carbon’s definition of memory safety does not include data race safety, and so will not have a borrow checker.
That said, Carbon’s definition of memory safety does not include data race safety, and so will not have a borrow checker.
Unless something has chnaged since this talk[0][1], I don't think that is accurate.
>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
>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
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 will have to re-watch it, thank you.
I will have to re-watch it, thank you.
> 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 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?
How to transform which ecosystem? What do you need help with, exactly?
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.
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.
disclaimer i am working in gamedev and using C++.
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."
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."