Deploying Rust in existing firmware codebases

Reaction to Google’s firmware Rust guide

• Several see the post as a practical “how‑to” for Android integrators, not the deeper “lessons learned” they wanted.
• Some find the title ambiguous/misleading, expecting more on real‑world tradeoffs and the necessity of unsafe at firmware/HAL level.
• Others argue it’s reasonable as a starting point and doesn’t claim to be more than that.

Rust safety, unsafe, and firmware realities

• Strong debate on how much unsafe is needed in firmware.
  • Some report writing entire firmware in Rust with unsafe isolated inside HAL crates.
  • Others stress that firmware often includes writing the HAL itself, which necessarily involves substantial unsafe.
• One side: if a “safe” abstraction allows memory-unsafe behavior, that abstraction is buggy; Rust’s promise is that memory corruption cannot originate from safe code.
• Counterpoint: “safety” is broader than memory safety (e.g., FD reuse, logic bugs). Some safety issues may be hard or impossible to fully encode in Rust’s type system.
• Comparison with C: Rust still seen as a strict improvement because only small, explicit regions are unsafe, versus all of C being implicitly unsafe.

Embedded Rust ecosystem, HALs, and PACs

• Many recommend starting from embedded-hal/embassy rather than from scratch; HALs are described as thin, understandable, and already mature across many MCUs.
• Some concern that low‑level PAC crates exposing raw hardware registers as “safe” (e.g., DMA configuration) undermines Rust’s safety guarantees, though HALs above them aim to be sound.
• View that true bare‑metal work can be “hairy,” but existing community HALs often mean application firmware rarely needs its own unsafe.

Cargo, dependencies, and supply-chain risk

• Rust’s ecosystem is praised for reuse but criticized for deep dependency trees (e.g., tokio pulling many crates).
• Contrast with C culture: using one large, vetted library (GLib/APR) or in‑house code, minimizing the number of distinct maintainers to trust.
• Concerns:
  • Pinning versions risks missing security fixes.
  • Not pinning introduces risk of transient malicious releases on crates.io.
• Others note similar issues exist in C (e.g., xz backdoor); cargo.lock, vendoring, and potential trust tooling can mitigate but not eliminate risk.

Rust in Linux and broader firmware efforts

• Thread clarifies this Android firmware work is separate from, but conceptually similar to, Rust in the Linux kernel.
• Rust‑for‑Linux aims to allow new kernel components in Rust, not rewrite the kernel wholesale; much work is about safe bindings over existing C.
• Large-scale Android deployments make this firmware work notable, even though Rust in embedded has existed for years.

Binary size and FFI/string interop

• Using no_std Rust keeps firmware images small; with care, sizes can match C.
• FFI with C strings is seen as painful:
  • Rust String vs C null‑terminated strings require conversions and often allocations.
  • Varargs C functions (e.g., printf) are callable, but still need explicit CString/CStr handling.
• Some mention third‑party crates and custom allocators as partial mitigations, but acknowledge the friction.

Issues with the Google blog page itself

• Many report the page loading blank or slowly in Firefox (desktop and Android); sometimes fixed by disabling JS, using Reader mode, or whitelisting specific scripts.
• Root cause discussed as a problematic regex causing “too much recursion” in Firefox, triggering a JS error.
• Broader frustration over heavy, brittle JS on what should be a simple text blog, and concerns about Chrome‑centric web behavior.