2 years ago I did a PoC to run #rust 🦀 in the #pixel modem

Today it shipped in millions of devices!

They grow up to fast! 🥲

https://security.googleblog.com/2026/04/bringing-rust-to-pixel-baseband.html

#rust #security #smartphone #baseband

📰 Risky Biz News: The EU will make vendors liable for bugs

https://news.risky.biz/risky-biz-news-the-eu-will-make-vendors-liable-for-bugs/

this latest edition of "Android team posting nothing but Ws for adopting Rust" is super important because it identifies that:

*you don't have to actually rewrite all your old unsafe C/C++ code to get the benefits of adopting safe languages, in terms of reducing vulnerabilites*

because they identify that most bugs are in new/changed code (with exponential decay!), so if you preferentially write new code in a safe language, your vulnerabilities crater even though most of your code is still unsafe!

https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html

I’m super excited about this blogpost. The approach is so counterintuitive, and yet the results are so much better than anything else that we’ve tried for memory safety. We finally understand why.

https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html

Rust certainly isn't perfect for everything, but for low-level code, including firmware, I am not aware of any better languages at this time. You get all the control you need, and the biggest class of bugs and vulnerabilities is prevented at compile time.

Rewriting complex code bases from scratch is not a good idea for stability, and therefore the piece by piece conversation really seems like the best way forward if you have a lot of C/C++ legacy code (and no, there is no practical solution to make that code safer without changing to a memory safe language in the process, whichever one it may be).

This post by @lozano gives excellent practical advice on how to do that.

https://infosec.exchange/@lozano/113080200541762841

Hi everyone — especially browser security researchers! Today we’ve announced some pretty significant changes to the Chrome VRP reward structure and amounts. This was all built with the purpose of incentivizing deeper and ever more impactful research of Chromium security issues.

I wrote a little blog about it here: https://bughunters.google.com/blog/5302044291629056/chrome-vrp-reward-updates-to-incentivize-deeper-research

We wanted to acknowledge the challenges faced and skills required to find the more complex and impactful issues in Chrome, especially when it comes to demonstrating the full exploitability and impact.

We hope these changes are helpful inspiring to browser security researchers and signal our continued investment in working with you to make Chrome more secure for all users.

@dmnk and I wrote about how to incrementally adopt rust in existing firmware/bare-metal code bases.

https://security.googleblog.com/2024/09/deploying-rust-in-existing-firmware.html

#rust #firmwaresecurity #embeddedsecurity #cybersecurity #infosec #memorysafety