Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Sunday December 04, @05:17AM   Printer-friendly
from the rust-never-sleeps dept.

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


Original Submission

This discussion was created by janrinok (52) for logged-in users only, but now has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 5, Insightful) by Captival on Sunday December 04, @05:37AM (3 children)

    by Captival (6866) on Sunday December 04, @05:37AM (#1281098)

    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

      by r1348 (5988) on Sunday December 04, @09:43AM (#1281109)

      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

      by Anonymous Coward on Monday December 05, @08:54AM (#1281233)

      You should ask the customers about that (you are the product).

    • (Score: 2) by PiMuNu on Monday December 05, @11:51AM

      by PiMuNu (3823) on Monday December 05, @11:51AM (#1281238)

      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)

    by canopic jug (3949) on Sunday December 04, @07:42AM (#1281104) Journal

    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

      by Beryllium Sphere (r) (5062) on Sunday December 04, @07:57AM (#1281105)

      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)

      by Anonymous Coward on Sunday December 04, @08:58AM (#1281108)

      Guess you haven't been paying attention to the real world for the past few decades?

      it is disingenuous to try to claim the general benefits of a full refactor as being specific to any particular language,

      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)

        by Anonymous Coward on Sunday December 04, @02:39PM (#1281137)

        Perhaps the 2nd group should switch careers to the janitorial field.

      • (Score: 2) by Beryllium Sphere (r) on Sunday December 04, @08:46PM

        by Beryllium Sphere (r) (5062) on Sunday December 04, @08:46PM (#1281186)

        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)

        by tangomargarine (667) on Monday December 05, @06:24AM (#1281227)

        C++ is like driving a manual transmission car without a clutch: https://www.youtube.com/watch?v=WWhI6VoTj_s [youtube.com]

        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]

        The most skillful drivers can shift non-synchronous transmissions without using the clutch by bringing the engine to exactly the right RPM in neutral before attempting to complete a shift. If done improperly, it can damage or destroy a transmission.

        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

          by tangomargarine (667) on Monday December 05, @06:33AM (#1281228)

          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)

      by janrinok (52) Subscriber Badge on Sunday December 04, @09:44AM (#1281110) Journal

      while focusing on reducing memory-related flaws?

      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

        by kazzie (5309) Subscriber Badge on Sunday December 04, @01:14PM (#1281129)

        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

      by RamiK (1813) on Sunday December 04, @06:23PM (#1281164)

      simply by having skilled C or C++ programmers

      If Google can't get them, no one else in the market can.

      do a similarly thorough, full refactoring of the code base...it is disingenuous to try to claim the general benefits of a full refactor

      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] )

      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.

      Well, this is what their blog has to say:

      In Android 13, about 21% of all new native code (C/C++/Rust) is in Rust. There are approximately 1.5 million total lines of Rust code in AOSP across new functionality and components such as Keystore2, the new Ultra-wideband (UWB) stack, DNS-over-HTTP3, Android’s Virtualization framework (AVF), and various other components and their open source dependencies. These are low-level components that require a systems language which otherwise would have been implemented in C++.

      To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code.

      We don’t expect that number to stay zero forever, but given the volume of new Rust code across two Android releases, and the security-sensitive components where it’s being used, it’s a significant result. It demonstrates that Rust is fulfilling its intended purpose of preventing Android’s most common source of vulnerabilities. Historical vulnerability density is greater than 1/kLOC (1 vulnerability per thousand lines of code) in many of Android’s C/C++ components (e.g. media, Bluetooth, NFC, etc). Based on this historical vulnerability density, it’s likely that using Rust has already prevented hundreds of vulnerabilities from reaching production.

      They also noted certain design-related performance gains that wouldn't have been viable when using C/C++ due to safety concerns:

      Using Rust in Android allows us to optimize both security and system health with fewer compromises. For example, with the new UWB stack we were able to save several megabytes of memory and avoid some IPC latency by running it within an existing process. The new DNS-over-HTTP/3 implementation uses fewer threads to perform the same amount of work by using Rust’s async/await feature to process many tasks on a single thread in a safe manner.

      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)

    by Anonymous Coward on Sunday December 04, @02:36PM (#1281136)

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

      by Beryllium Sphere (r) (5062) on Sunday December 04, @08:52PM (#1281187)

      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

        by Anonymous Coward on Monday December 05, @09:01AM (#1281234)

        And you call yourself a programmer *spit*

  • (Score: 5, Funny) by Gaaark on Sunday December 04, @03:35PM

    by Gaaark (41) Subscriber Badge on Sunday December 04, @03:35PM (#1281144) Journal

    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)

    by PiMuNu (3823) on Monday December 05, @11:57AM (#1281239)

    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 crm114 on Monday December 05, @07:22PM (1 child)

    by crm114 (8238) Subscriber Badge on Monday December 05, @07:22PM (#1281306)

    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.

(1)