3 ms·

I hope this effort can also translate into more Rust in Linux, rather than potentially Android on a different OS.

vlovich123 2y ago
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).
- monocasa 2y ago
  This is a very similar environment to the Linux kernel, and most of what this blog post suggests applies to Rust in Linux.
  - vlovich123 2y ago
    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.
    - sophacles 2y ago
      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.
      - monocasa 2y ago
        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.
      - vlovich123 2y ago
        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)
    - monocasa 2y ago
      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.
- yazaddaruvala 2y ago
  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.
  - vlovich123 2y ago
    > 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.
    - gpm 2y ago
      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. [1] https://www.memorysafety.org/blog/supporting-miguel-ojeda-rust-in-linux/ https://www.memorysafety.org/blog/supporting-miguel-ojeda-ru... [2] https://rust-for-linux.com/ https://rust-for-linux.com/

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

monocasa 2y ago
This is a very similar environment to the Linux kernel, and most of what this blog post suggests applies to Rust in Linux.
- vlovich123 2y ago
  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.
  - sophacles 2y ago
    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.
    - monocasa 2y ago
      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.
    - vlovich123 2y ago
      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)
  - monocasa 2y ago
    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.
yazaddaruvala 2y ago
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.
- vlovich123 2y ago
  > 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.
  - gpm 2y ago
    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. [1] https://www.memorysafety.org/blog/supporting-miguel-ojeda-rust-in-linux/ https://www.memorysafety.org/blog/supporting-miguel-ojeda-ru... [2] https://rust-for-linux.com/ https://rust-for-linux.com/