SoylentNews is people
SoylentNews
Google: After using Rust, we slashed Android memory safety vulnerabilities:
Google's decision to use Rust for new code in Android in order to reduce memory-related flaws appears to be paying off. Memory safety vulnerabilities in Android have been more than halved -- a milestone that coincides with Google's switch from C and C++ to the memory-safe programming language, Rust.
This is the first year that memory safety vulnerabilities are not the biggest category of security flaws, and comes a year after Google made Rust the default for new code in the Android Open Source Project (AOSP).
Other memory-safe languages Google has used for Android include Java and Java-compatible Kotlin. C and C++ are still dominant languages in AOSP, but Android 13 is the first version where most of the new code is from memory-safe languages. After Google adopted it for AOSP in April 2021, Rust now accounts for about 21% of new code. The Linux kernel project this year adopted Rust as the new official second language to C.
Android version 10 from 2019 had 223 memory safety bugs, while Android 13 has 85 known memory safety issues.
Over that period, memory safety vulnerabilities have dropped from 76% down to 35% of Android's total vulnerabilities, notes Android security software engineer Jeffrey Vander Stoep. With this drop in memory safety vulnerabilities, Google is also seeing a decline in critical and remotely exploitable flaws.
Vander Stoep notes that this change was not driven by "heroics" — just developers using the best tools for the job. The Android team plans to step up usage of Rust, although there are no plans to get rid of C and C++ for its systems programming.
"If I had to identify a single characteristic that makes this possible, I would say 'humility'. There's a willingness within all levels of the Android team to say 'How can we do better?' along with the fortitude to follow through and make changes, including systemic changes," he noted in a tweet.
"Humility needs to go both ways though. Rust doesn't solve all problems, and there are areas where C/C++ will continue to be the most practical option for development, at least for a while. That's OK."
(Score: 5, Insightful) by Captival on Sunday December 04, @05:37AM (3 children)
How have I just bought a new mid range Android phone only to have 70% of the space taken up by the operating system on day 1? It's insane how bloated this thing has gotten and then it also protects itself so you can't remove any of it, even the apps you don't want and never use.
(Score: 4, Informative) by r1348 on Sunday December 04, @09:43AM
Sounds like you chose your phone poorly.
Mid-range phones in 2022 come with 128GB of storage, I cannot think of enough bloatware to fill 70% of that.
(Score: 0) by Anonymous Coward on Monday December 05, @08:54AM
You should ask the customers about that (you are the product).
(Score: 2) by PiMuNu on Monday December 05, @11:51AM
You also can't access your data (you need to install a third party program to e.g. backup your address book)
(Score: 5, Funny) by canopic jug on Sunday December 04, @07:42AM (10 children)
How much of the same result could have been achieved simply by having skilled C or C++ programmers do a similarly thorough, full refactoring of the code base while focusing on reducing memory-related flaws? I suspect that Google is simply looking to rationalize an otherwise arbitrary decision to migrate to Rust by marketing the language as a miracle cure good for what ails you. That's fine, at least the part about it being up to Google to choose their working language. It's their project they can have their programmers write in the language of the company's choice, but it is disingenuous to try to claim the general benefits of a full refactor as being specific to any particular language, no matter how shiny and trendy.
Money is not free speech. Elections should not be auctions.
(Score: 4, Insightful) by Beryllium Sphere (r) on Sunday December 04, @07:57AM
Human error is almost impossible to eliminate. But the question is a sound one. If you use C++ the way it's intended, with RAII and smart pointers and safe standard library containers, what if any memory safety issues do you still have?
(Score: 4, Insightful) by Anonymous Coward on Sunday December 04, @08:58AM (5 children)
Guess you haven't been paying attention to the real world for the past few decades?
If you use the correct tools some errors become impossible or require extra effort from the programmers to shoot their own feet or others.
C++ is a bad tool for most people and most cases. It's unsafe in most hands.
C++ is like driving a manual transmission car without a clutch: https://www.youtube.com/watch?v=WWhI6VoTj_s [youtube.com]
There's probably a bunch of people in the world who can consistently use it safely. But there's a much larger group who merely think they can do it safely but they actually can't (the proof can be seen regularly in CERT). Those people should be using/doing something else where possible.
(Score: 0) by Anonymous Coward on Sunday December 04, @02:39PM (1 child)
Perhaps the 2nd group should switch careers to the janitorial field.
(Score: 4, Touché) by turgid on Sunday December 04, @05:10PM
I've got better things on which to expend my brain power, thanks. I also have a machine for washing dishes.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by Beryllium Sphere (r) on Sunday December 04, @08:46PM
Everyone will have noticed I posted a specific request for information which went unanswered.
Here's an answer. It didn't take long to find an example of someone getting a double free while (mis)using smart pointers. Avoidable, of course, but only by having an accurate understanding of the language design and the intended use of the features.
https://stackoverflow.com/questions/39987897/double-free-or-corruption-with-shared-pointers [stackoverflow.com]
Another one is that std::vector is only guaranteed to protect against out of bounds errors if you use .at(). operator[] is not required to do anything desirable with an out of bounds reference.
And here is an entertaining debate about Rust versus modern C++.
https://www.quora.com/Is-modern-C-20-as-safe-as-Rust-if-I-program-according-to-the-latest-standards-and-keep-all-the-guidelines-SEI-CERT-etc [quora.com]
(Score: 2) by tangomargarine on Monday December 05, @06:24AM (1 child)
Not 100% sure what your intention with this analogy is, but thought I should mention...after watching that video my first throught was "this definitely isn't destroying your gearbox in the process..."
https://en.wikipedia.org/wiki/Float_shifting [wikipedia.org]
Driving a manual transmission is sort of an example case of "if it sounds too good to be true, it probably is." Yes there are shortcuts, but you should only take them if you really know what you're doing. (Spoiler: you probably don't.)
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by tangomargarine on Monday December 05, @06:33AM
Also, supposedly--depending on model--it's possible to *start* a manual transmission vehicle without using the clutch (or a downhill slope), by cranking your starter in first. Although of course your transmission will hate you.
https://www.reddit.com/r/cars/comments/j07wip/i_accidentally_learned_to_float_shift_but_im_not/ [reddit.com]
Always learning new weird facts about stick shift, and how many different ways they've been built over the years.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 3, Interesting) by janrinok on Sunday December 04, @09:44AM (1 child)
Haven't the programmers supposed to have been writing code that way since they started in the first place? All the evidence suggests that either a) they haven't been, or b) they have but it is not as simple as some think it is.
So Google tried something different and lo, it seems to have worked. Of course, as they admit in TFA correlation is not causation but they don't really care whether it is because they are using Rust or whether it is because everyone has started wearing pink socks or eating avocado on toast for breakfast. For the moment they have reduced the number of memory errors and, over time, they can analyse whatever data they collect and see if they can confirm that Rust is the reason for the improvement in the code.
... but now might be a good time to invest in pink socks or avocado, just in case.
(Score: 3, Interesting) by kazzie on Sunday December 04, @01:14PM
One could make the argument that the programmers are more attentive when coding in Rust because they're not used to it, and thus making fewer slipups.
(I have no idea if this is indeed the case, but echo the need for further data gathering.)
(Score: 3, Informative) by RamiK on Sunday December 04, @06:23PM
If Google can't get them, no one else in the market can.
The amount of C/C++ code they rewrote in Rust is minuscule and the refactoring they did wasn't related to Rust. Around 2019 (Android 10) Google started switching to memory safe languages (Java, Kotlin and, most recently, Rust) where possible for new code. The result has been a steady decline in memory safety vulnerabilities: "From 2019 to 2022 it has dropped from 76% down to 35% of Android’s total vulnerabilities" ( https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html [googleblog.com] )
Well, this is what their blog has to say:
They also noted certain design-related performance gains that wouldn't have been viable when using C/C++ due to safety concerns:
So, at least when it comes to memory safety, it does seem to be a cure all even if they're being very conservative about it in their writing.
compiling...
(Score: 0) by Anonymous Coward on Sunday December 04, @02:36PM (2 children)
"After using a language that compensates our lack of skill, we were able to ignore the bugs in our sh*tty code!"
(Score: 4, Touché) by Beryllium Sphere (r) on Sunday December 04, @08:52PM (1 child)
There's a qualitative difference between "skilled" and "writes bug free code". I'm not too proud to wear a seat belt or use a language that checks things for me.
(Score: 0) by Anonymous Coward on Monday December 05, @09:01AM
And you call yourself a programmer *spit*
(Score: 5, Funny) by Gaaark on Sunday December 04, @03:35PM
with all their source code but ended up with only the comments showing as non-vulnerable and had to abandon the effort.
--- Please remind me if I haven't been civil to you: I'm channeling MDC. ---Gaaark 2.0 ---
(Score: 2) by PiMuNu on Monday December 05, @11:57AM (1 child)
No doubt somewhere in google there are still some software folks, with a heart of gold, doing their best to deliver the best products. However, google has abandoned "do no evil". They seem to be pushing rust quite hard, and cynical scepticism is reasonably. so what is in it for google?
(Score: 2) by turgid on Monday December 05, @08:24PM
A bandwagon has started to roll. Perhaps they want on early with all that implies?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by crm114 on Monday December 05, @07:22PM (1 child)
Go / Golang was developed by Google
Rust was developed by Mozilla
Why push something other than your own language?
(quick hits from google:)
"how much malware is programmed in Go or golang": About 349,000 results
"how much malware is programmed in Rust": About 849,000 results
I don't get it. Some one educate me please.
(Score: 2) by turgid on Monday December 05, @08:23PM
How about using the best language for the job regardless of who invented it?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].