Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Android Google Security

Google Reports Decline In Android Memory Safety Vulnerabilities As Rust Usage Grows (9to5google.com) 23

Posted by BeauHD from the encouraging-trends dept.
Last year, Google announced Android Open Source Project (AOSP) support for Rust, and today the company provided an update, while highlighting the decline in memory safety vulnerabilities. 9to5Google reports: Google says the "number of memory safety vulnerabilities have dropped considerably over the past few years/releases."; Specifically, the number of annual memory safety vulnerabilities fell from 223 to 85 between 2019 and 2022. They are now 35% of Android's total vulnerabilities versus 76% four years ago. In fact, "2022 is the first year where memory safety vulnerabilities do not represent a majority of Android's vulnerabilities."

That count is for "vulnerabilities reported in the Android security bulletin, which includes critical/high severity vulnerabilities reported through our vulnerability rewards program (VRP) and vulnerabilities reported internally." During that period, the amount of new memory-unsafe code entering Android has decreased: "Android 13 is the first Android release where a majority of new code added to the release is in a memory safe language. "

Rust makes up 21% of all new native code in Android 13, including the Ultra-wideband (UWB) stack, DNS-over-HTTP3, Keystore2, Android's Virtualization framework (AVF), and "various other components and their open source dependencies." Google considers it significant that there have been "zero memory safety vulnerabilities discovered in Android's Rust code" so far across Android 12 and 13. Google's blog post today also talks about non-memory-safety vulnerabilities, and its future plans: "... 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.
This discussion has been archived. No new comments can be posted.

Google Reports Decline In Android Memory Safety Vulnerabilities As Rust Usage Grows More

Google Reports Decline In Android Memory Safety Vulnerabilities As Rust Usage Grows

Comments Filter:

  • Is Java then not memory-safe? (Score:4, Informative)

    by RUs1729 ( 10049396 ) on Thursday December 01, 2022 @08:51PM (#63095580)
    I thought that Android apps were, for the most part, Java apps - and Java, supposedly, does not suffer from the same memory safety problems as C++. Or does it?

    • You can write in C/CPP/Rust, and use the JNI.

      • You can write in C/CPP/Rust, and use the JNI.

        There also are rumors of a rust to JVM-bytecode compiler.

        • Why put a bare metal language inside of a fat runtime that forces a garbage collector on you? Especially one that you have zero control over. If you MUST use the JVM, then I think kotlin is a much better choice. It has native access to Java libraries, but unlike Java, it isn't a big pile of shit.

    • Android itself is not written in Java. C, C++ and now Rust.

    • They're talking about the Android OS itself, not the apps on it.

    • The OS is mostly written in C.

    • "21% of all new native code"

    • I believe it is but here they're talking of the memory safety of native components: Those compiled as binaries run directly by the OS loader. That has meant mostly C and C++ code before. Now, they're writing most of the new native code in Rust and that has decreased the number of vulnerabilities due to wrong usage of memory

    • Re: (Score:3)

      by ledow ( 319597 )

      Android apps are.
      Android is not.

      You can tell that because Android, by necessity, would have to run a Java JVM for the apps to operate inside. That Java JVM isn't written in Java, and the chips in Android phones are not using "Java opcodes" to operate.

      Apps can always be written in safe languages. OS basically never can be entirely written in safe languages - device drivers and things like DMA and the like require you to make assumptions about what the underlying memory actually represents, and that's where

      • You're right specifically about Android and Java. But there are high-quality level plants that use VMs that are written in itself. For example SmallTalk is almost always VM based, but multiple implementations have compilers and runtimes written in SmallTalk itself.

      • You're way overstating this. Unsafe isn't needed literally everywhere, nor does everything around it become somehow tainted and therefore unsafe itself. Furthermore, unsafe doesn't let you ignore all of the memory safety features of rust, pretty much the only significant thing it lets you do is dereference raw pointers. Yeah, you can screw things up with that, but it turns out that it's pretty hard to, and when you do it's often pretty obvious.

        Also, the use of unsafe in code running bare metal (i.e. kernel

        • ... nor does everything around it become somehow tainted and therefore unsafe itself.

          Yes it does [rust-lang.org]:

          Undefined behavior affects the entire program. For example, calling a function in C that exhibits undefined behavior of C means your entire program contains undefined behaviour that can also affect the Rust code. And vice versa, undefined behavior in Rust can cause adverse affects on code executed by any FFI calls to other languages.

          Said another way, once you have undefined behavior, your entire program is un

          • Sure, if you're calling into other code then you're kind of at the mercy of what that other code does, but if you're talking about dereferencing in order to unmarshal bytes from hardware input into structured memory, which is what we're talking about here, then no, you don't have that problem.

            • You can have race conditions (which are undefined behavior) even in pure Rust code. (I'm no Rust expert, but there may be other undefined behaviors you can do in pure Rust.)

              • Race conditions are not undefined behavior in any language. Data races can be, depending on the context.

              • Oh, and you're not doing to have data races in pure rust code. That's actually one of the guarantees provided by the borrow checker. Although technically you could create a data race in pure unsafe rust, it's not going to be something you'll ever do on accident. You'd literally have to create and dereference pointers from code that runs in parallel deliberately within the same memory space, using the same pointers, which is something that rust doesn't make easy, even in unsafe. Nor can I think of any reason

                • Oh, and you're not doing to have data races in pure rust code. That's actually one of the guarantees provided by the borrow checker.

                  I wish people would stop trying to make these silly distinctions between data races and race conditions. There is no meaningful real world difference between the two. Data races are a subset of race conditions and they all result in wrong answers. One is not any inherently better or worse than the other. Asserting things like there are no data races has no real world import.

                  I could say the memory controller provides guarantee against data races up to the word size of the processor. If I have two separ

                  • It's a very relevant distinction actually. Data races can lead to undefined behavior. Race conditions outside of data races do not. That is exactly why the distinction exists, even among C programmers. Generally, race condition means behavior that can be predicted at runtime, where data race means behavior that cannot be predicted at runtime.

  • Rather than morsels written in rust.

  • > We're implementing userspace HALs in Rust

    I'm sorry Dave, I'm afraid I can't do that.

  • But explaining that to programmers is pointless.

    • As the fifth paragraph of the original article says "While correlation doesn’t necessarily mean causation,".

      Perhaps explaining this is pointless because it is already know.

Slashdot Top Deals

Neutrinos have bad breadth.

Close