Secure by Design: Google's Perspective on Memory Safety

https://security.googleblog.com/2024/03/secure-by-design-googles-perspective-on.html

by weinzierl • 2 years ago

60 17 2 years ago

security.googleblog.com

goalieca• 2 years ago

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.

majido• 2 years ago

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.

luke-stanley• 2 years ago

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.

steveklabnik4• 2 years ago

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.

steveklabnik4• 2 years ago

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.

pjmlp2• 2 years ago

I really don't get where people get the "Carbon is production ready" vibe from.

mike_hearn• 2 years ago

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.

fl0ki• 2 years ago

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.

Kon-Peki• 2 years ago

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?

pdimitar• 2 years ago

How to transform which ecosystem? What do you need help with, exactly?

SleepyMyroslav• 2 years ago

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."

menaerus• 2 years ago

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.

tevelee• 2 years ago

https://www.youtube.com/watch?v=lgivCGdmFrw

Secure by Design: Google's Perspective on Memory Safety

Related Stories