I hope this effort can also translate into more Rust in Linux, rather than potentially Android on a different OS.
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).
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.
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.
> 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.
[1] https://www.memorysafety.org/blog/supporting-miguel-ojeda-ru...
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.
This can simplify a bunch when using Rust but also better documents the internals for C.
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).
This effort may ne new for Android, but its not a "break into a new area" type thing.
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.