Their notes about vulnerability severity are particularly interesting.

Defenders of C/C++ frequently note that memory safety bugs aren't a significant percentage of the total bug count, and argue that this means it's not worth the hassle of switching to a new language.

Google's data suggests that while this is true, almost all severe vulnerabilities are related to memory safety. Their switch to memory-safe languages has led to a dramatic decrease in critical-severity and remotely-exploitable vulnerabilities even as the total number of vulnerabilities has remained steady.

> Safety measures make memory-unsafe languages slow > > Mobile devices have limited resources and we’re always trying to make better use of them to provide users with a better experience (for example, by optimizing performance, improving battery life, and reducing lag). Using memory unsafe code often means that we have to make tradeoffs between security and performance, such as adding additional sandboxing, sanitizers, runtime mitigations, and hardware protections. Unfortunately, these all negatively impact code size, memory, and performance.

Even more evidence that the negative performance impact of bounds checking is minimal, nay, it can even be positive.

Glad to see robust work here. This strongly supports what should already be obvious, but sadly is not always understood; that memory safe languages are radically safer than memory unsafe languages. The impact is blatantly demonstrated here.
For me the biggest features of rust are:

- great standard library, especially all the iter methods. having 'obscure' stuff like `try_for_each` just makes me so happy as a dev

- unit tests built into the lang

- tooling is great

- docs are top notch

The memory safety aspect is... sometimes helpful, sometimes irritating. I prefer zig solution (BYO allocator, special one for testing that reports errors) over rusts, which simplifies a lot of stuff and lets you make cyclical data structures without a lot of hoop jumping.

> This matches the expectations published in our blog post 2 years ago about the age of memory safety vulnerabilities and why our focus should be on new code, not rewriting existing components.


> As we noted in the original announcement, our goal is not to convert existing C/C++ to Rust, but rather to shift development of new code to memory safe languages over time.

For those working on C/C++ code bases, how does the incremental addition of Rust work in practice? What strategies and tools come in handy? Also, what are some good case studies where Rust was introduced to add new features, but still needed to work within a system mainly composed of C/C++? I've seen some of the first steps with Linux, but I'm thinking of a project where more substantial additions have been made.

Nice: "it’s likely that using Rust has already prevented hundreds of vulnerabilities from reaching production"
Not being aware of how vulnerabilities are detected and despite being a big fan of Rust, I wonder if there are other variables that drive down the ability to find bugs in the short term. If a researcher is only familiar with C and C++, is it possible that they're just ill equipped to find similar bugs in Rust?
From the bottom of the article:

> As Android migrates away from C/C++ to Java/Kotlin/Rust, we expect the number of memory safety vulnerabilities to continue to fall. Here’s to a future where memory corruption bugs on Android are rare!

I'm surprised that Kotlin is such a small fraction. I thought Google was trying to make Kotlin preferred over Java for Android development.

(Not that it's easy to tell from the pie chart, which colors one orange and the other red, in similar shades. Do better, guys.)

"Migrating away from C/C++ is challenging, but we’re making progress. Rust use is growing in the Android platform, but that’s not the end of the story.

To meet the goals of improving security, stability, and quality Android-wide, we need to be able to use Rust anywhere in the codebase that native code is required. We’re implementing userspace HALs in Rust. We’re adding support for Rust in Trusted Applications. We’ve migrated VM firmware in the Android Virtualization Framework to Rust.

With support for Rust landing in Linux 6.1 we’re excited to bring memory-safety to the kernel, starting with kernel drivers."

The push for Rust to replace C and C++ continues.

This is confirmation of the NSA recommendation to discontinue using C and C++:

If you do not know Rust, now is the time to learn:

Here are some fun holiday-themed exercises to learn with:

I plan on doing Advent of Code in Rust this year.

I didn't realize there was so much C and C++ in Android, I thought most of it was Java. Maybe they are just talking about the core system (including the Linux kernel and Java runtime) and not all the builtin apps.
How does Swift compare to Rust in safety? I read that Swift is only memory safe in single threaded environments, which is not ideal.

I was very enthusiastic about Rust about 4 years ago but decided to learn Swift instead as a new “cool non-Lisp language” to learn. Seeing an recent article on writing Python in Rust made me wish that I had chosen differently.

I found this article made me feel better about security. I expect that increasing use of memory safe languages will lock down public infrastructure and software, making everyone safer.

Well, it looks like Google has finally figured out the solution to all of their security woes: just switch to Rust and watch the vulnerabilities vanish! I'm sure that every other company facing similar issues will be rushing to follow suit. #RustToTheRescue

Memory safety, oh so sweet

Reducing vulnerabilities, a feat

Google switches to Rust

Security improved, a must

Memory corruption, a thing of the past

Safe coding, a task at last

Good to see some concrete evidence comparing memory unsafe languages to memory safe languages in an existing product. I just watched the Lex Fridman Guido Van Rossum episode and Rust vs C/C++ appears to be mirroring the trajectory Perl vs Python took in the ML/Bioinformatics space. Only time will tell whether Rust will reach the critical mass necessary to displace C/C++ in most new low level projects, but it appears clear to me that Memory Safe Languages which ever they may be are the future.

I don't need to program in an environment where a systems programming language is required, so for me a languages debugability and introspective capabilities are the most important. So far I think Pharo hits the sweet spot for me, but it still has a long way to go documentation wise before I think it will see any sort of adoption. I'm rooting for it though.

I wonder if their efforts to leverage modern chip capabilities to address memory safety (e.g: ARM memory tagging) contributed to that drop of memory safety vulnerabilities
The more interesting part of this article for me is that in 2022, Java is still the number 1 language that new pieces of Android are made out of. It probably has to be this way for compatibility, and I personally have no problem with Java. But the hype train would not have you believe this.
Anecdotal, but our apps that used to have 0 ANRs for years, have all had them start sprinkling in despite node code changes from us. Maybe ANR reporting got more strict, or maybe it's something else...
So 80% of new native code is C/C++. Not surprising and of course Rust advocates will try to defend this as a win.
Another failure for Kotlin Native, what a sad shitshow..

They were warned many years ago about ownership/concurrency/compile speed, they didn't listen at all

A vision alone doesn't matter, you need skilled engineers and a dedicated team who understand what "taste" for great things is

What could have been the Swift for android will end up just being the "java" alternative, i suspect they'll get rid of the JVM, or whatever the tech is, altogether and focus on Rust for whatever they plan next (maybe Fuschia), maybe there is still hope for Swift, we'll see

Why no Go?
Notably absent from said list of languages: Google's Go
Just curious, why wasn’t Dart mentioned?
No mention of Carbon among the new memory safe languages. I wonder what inside baseball is at play with language selection.
No language can fix maliciously poor design. cough Pixel unlock cough. Maybe separate your views with a layer of security...
Who cares about memory safety when the entire platform is already an advertising shitshow full of spyware?
Who remembers Jean-Yves Girard? His linear logic was the foundation of Rust. We live in a world where people who got participation awards in school need training wheels now. Wake me up when sqlite is rewritten in Rust.
Rust doesn't check for overflow in arithmetic operations in release mode so there are lot of opportunities to create vulnerabilities in Rust.
They're just making it harder for you to root and own the general-purpose computer you paid for.

Until "the nukes are on our side", I don't think this should be celebrated or praised.

No such luck in having some technical discussion or at least a link to the sources.

If the Rust community can be insufferable when trying to sell Rust at any and every opportunity, Lord have mercy when they see any kind of success because the preening and puffing will have no end. This blog post will live forever in the annals of Rust.

On the other hand I’m not surprised to see that it’s written by the security team and not a development team. Same pattern as with Microsoft: security specialists tend to get obsessed by their subject matter (just like many Rust programmers), end up hating C and C++ and see them as the source of all problems (just like many Rust programmers).

In reality, C and C++ were the saviors of Android and Google reluctantly had to conjure the NDK to make up for a severe lack of performance compared to the iPhone. Note how even in the current Android they mention improving the UI performance and having less “jank”. Without C++ Android would have been DoA, but it doesn’t look like there will be a blog post thanking C++ any time soon :-)

I can’t take seriously reports about the benefits of a tool that don’t mention any of the downsides. When the devs post a blog cursing the troubles they had getting Java and C++ and Rust to work together and pitying themselves for having to read both C++ and Rust, then we’ll be getting closer to the truth.

Rust apologists believe they are going to save the world. In order for them to do so, they have to uproot, destroy (deem it unsafe and insecure), and rewrite a lot of things they don't yet have influence over. A lot of people who are pushing back against Rust are doing so because they can sense this coercion, not because the language is ugly or "memory safety" issues aren't as significant as they are made out to be, or whatever other arguments the stupid "c-niles" always use.
As an Android user ever since the T-Mobile G1, I'm a fan of not having my phone remotely exploited via WebView, or with an SMS, or the other million ways there are to interact with a device, so I absolutely celebrate this progress.

As an Android developer though, I have to be the one bitter old man yelling at cloud. I was spoiled by Java and Kotlin to the point where I cannot look at Rust and think it's a nice modern language.

Yes, I will start a language war today. Rust is like a truck driver who tried to make a race car that doesn't blow up. It's safe but it does not look refined. I wish you knew how weird Rust looks to me. I tried to learn it 3 times and had to give up after all the WTFs. I said it in the past, and I'll say it again:

* What the hell kind of language choice is to force everyone to type "#[derive(Debug)]" for annotations? I'd rather write past the end of an array and have someone steal my Bitcoin wallet than press "shift 3 bracket shift 9 shift 0 bracket" at the top of my structs. What's wrong with @? Nothing. @derive(debug). 2java4u? Ok, [derive debug] then.

* What's with the ' everywhere? Not the quote, the piece of dirt on your display. Why are our displays so dirty?

* Going for super short keywords "let", "fn", "mod", but then, "let mut" could have been "var". When is typing speed the bottleneck in writing software where you can't take the time to type out "module" or even 'function'? Come on now.

* print! now! fast! it's! a! macro! why! are! we! yelling!

* Passing "self" as the first argument was bullshit in Python, and it's bullshit in Rust too. Don't look at me like that - the compiler can inject it as the first parameter without requiring you to type it in.

* What does "::" do that "." can't? That's right. Nothing. All hail D.

D got language design right. Syntax better than Rust. CTFE better than Rust. Templates better than Rust. Marketing worse than Rust, though.

I'll try to learn Rust a 4th time now to stay relevant in the Android world, because I have bills to pay, but I want you to know that I blame each and everyone of you weirdos for not holding language designers to a higher bar.

Edit: if you downvote, reply with a link to the last compiler you wrote.

is this a good way to spend developer time? How about *removing* all of the middle-man bloatware instead of wasting how many dev-years rewriting it (edit: and effectively making it even LESS maintainable now that it's in some new niche language with a vastly smaller dev pool). just give me the direct linux experience we all deserve instead of this garbo spamflinger middlewear that google leverages to keep you dependent on their build methodology and discourage cooperation with other competitive linux-based system.

edit2: wow mods hard at work, already removed one dissenting post.

programming language developers always made compilers to just do that - compile the code. without actually checking the code for problems and allowed programmers to write faulty code. and now we have accepted these memory leaks and shooting oneself into one's foot as normal. so instead of investing time to make compilers output safe programs we had to wait for rust to come by and its "first time in history" compiler while it limits the programmers tremendously to do that along with the ugliest syntax ever invented. when a programmer looks at faulty code, the bug can be seen. sometimes easily, other time not as easy but it can be identified nevertheless. that means we, humans, can detect them. so why can't programs do the same while having way more computing power at their disposal for that particular task, along with language definition and type system? everyone keeps writing new languages and trying to reinvent the wheel in blue, red, purple color instead of solving the actual problem.
I'll be downvoted for pointing out that comparing C++ with Rust without further context can be made into a false dichotomy.

Some people are posting the article around the Internet as evidence that Rust solved security. Instead, there are many other memory safe languages around and there has been thousands in the past. Additionally, many security issues are not due to memory safety. Please keep that in mind when making comparisons.

EDIT: of course, 2 minutes and I'm downvoted down to -2

I am not a Rust or C++ fanboy, and I am happy that we are moving towards a future where there are less memory bugs, but… are we really?



And you can find online similar links and research on the topic.

All it takes is that you use that specific piece of code at the wrong time, and that’s it: your system which you once believed to be safe is not anymore safe. And you know what? You don’t even know what a sanitizer is, because they told you that Rust is a memory safe language and you don’t need anything else than the rust compiler - this is how I find 99% of today’s articles about Rust.

Sure, today being Rust less used than C/C++ will clearly show less CVEs.

The question is … once it’s in the wild (and by this I mean “major” libs or serious shit done in Rust) how can you prevent such bugs without a runtime sanitizer?

Beware that such CVEs can affect Rust Standard library as well, not just an unknown library.

Again, there is no way of escaping bad programming and bad practices, no matter which language you use. Someone might argue that in Python or Java you can still do bad stuff, however, the likelihood is way lower, especially because most of your Java libraries will very likely be written in Java - unless you know it’s using JNI under the hood etc.