This isn’t relevant to either thing you’ve said. The post is about taking the firmware code that’s on various peripherals (eg the microcontroller the IMU is connected to which Android then talks to or the WiFi/BT microcontroller that talks to the actual PHY radio).
Rust in Linux is about the Linux kernel having more rust code but Linux is not firmware in the traditional sense (unless you’re talking about ucLinux which no one in my experience uses) and this would have nothing to do with porting Android to another kernel which I can’t see happening considering how much custom kernel code there is (unless you are talking about fuschia but fuschia is not Android even though it implements an Android compat layer).
Once 100% of the firmware is migrated to Rust. What do you think will be this Google teams’ next steps?
Very likely if Firmware is successful they would use the current positive talking points from this blog post and lessons learned and keep trying to secure Android.
My guess would be the kernel and/or JVM are on the next step list.
> My guess would be the kernel and/or JVM are on the next step list
I wouldn't bother integrating Rust into the JVM because there's limited security value. There may be ergonomic advantages in terms of project management but my hunch is that those are limited for something mature like Dalvik. If they rewrote it to use Futamura projections like Truffle, then Rust would be much more interesting as it would reduce the possibility of JIT bugs AND basically make it impossible to do a sandbox escape (most sandbox escapes target the JIT and thus other memory safety issues are rare & unlikely). Finally Dalvik security is unlikely to matter all that much because they rely on process isolation as the security model (Chrome does too but sometimes it loads multiple V8 isolates in a single process so V8 escapes are more valuable).
> My guess would be the kernel
There's already a Rust in Linux project & if you missed the news there's a lot of political in-fighting on the LKML. It's unlikely that Google has much sway here because even though they employ maintainers like Ted Tso, I suspect their influence on this matter is limited given how staunchly opposed he is & I doubt they'd be firing engineers like Ted over this. The Android team is going to have limited additional influence beyond what's already going on, but the Linux kernel itself is under no threat of being rewritten in Rust any time soon & Android isn't migrating to another kernel any time soon.
The goal of rust for linux isn't to wholesale translate linux into rust, but simply to be able to write pieces of linux (largely new ones) in rust. I think it's very unlikely anyone (including google) will take on a wholesale translation anytime soon. That said
> It's unlikely that Google has much sway here
Google has helped fund the rust for linux project pretty much from the start [1], they're one of three organizations mentioned on the homepage due to their sponorship [2]. They're actively involved in it, and have already ported their android "binder" driver into it with the intent to ship it in android. This strikes me as a very weird take.
Google is a contributor but you’re going to have a bad time if you think that Google is some monolithic entity. While a part of Google is funding it, other Googlers may be maintainers that are opposed to helping the project (eg look at the article about the rust for Linux maintainer stepping down due to burnout from politics and the comments made my Ted Tso a Google employee against the R4L project).
But yes, R4L is a thing that’s still going on but it’s unrelated to rust in firmware unless you bucket everything Rust together. R4L is adapting Rust and establishing conventions and build systems relevant only to the Linux kernel and that’s not necessarily a whole lot in common with firmware projects which are typically managed and maintained very differently with very different build systems.
One of the really nice parts of the Rust linux project is that the new Rust code is getting a some of the memory management patterns in the C code actually written down rather than just being in the heads of the programmers.
Can you please explain what this means ? Isn't it now just in Rust code instead of C code ? Or is there some design documentation being written around this ?
Rust bindings for it are being written so you can call the C code from safe rust. The C code still exists and only the api is duplicated into rust.
The convenient side effect of that is that you need to know what constraints you have to enforce to make that memory safe, and generally memory safe here is going to translate to knowing how to properly call the api and enforcing that.
Very little C code is actually being rewritten in rust. None of the core C code that is really at issue here (but, for example, android's binder driver has been rewritten).
Kind of, but Rust in Linux is already an effort that's way ahead of what this blog is talking about and has adapted itself to things specific to the Linux kernel whereas firmware environments are typically even more barebones.
Honestly this is way closer to a conventional Rust environment than the kernel gives you. In the kennel external crates are pretty much verboten, large chunks of alloc are verboten, no panicking is allowed, etc.
Firmware is not new territory for rust at all. Oxide compiter has been making their firmware in rust for a few years, they even have an embedded OS (called hubris).
This effort may ne new for Android, but its not a "break into a new area" type thing.
And in fact I've been giving more or less annual "State of Embedded Software on Rust" talks since 2017, and every time it has been running as slides on the Nintendo 64 written in Rust.
Embedded software in Rust is pretty much as mature as C and C++ at this point. The vendor won't give you examples in Rust, but honestly their code generally barely works anyway and you end up rewriting it. Might as well rewrite for your use case in Rust.
With all due respect to the Oxide folks who are doing fantastic work and blazing the trail on rust development, the scale of Android devices is inherently much larger (potentially billions of devices will end up running this code)
Rust in Linux is about the Linux kernel having more rust code but Linux is not firmware in the traditional sense (unless you’re talking about ucLinux which no one in my experience uses) and this would have nothing to do with porting Android to another kernel which I can’t see happening considering how much custom kernel code there is (unless you are talking about fuschia but fuschia is not Android even though it implements an Android compat layer).