🦀 Google затащили Rust туда, где его реально ждали - прямо в cellular baseband у Pixel 10.
Не в приложение, не в системный сервис и даже не в очередную утилиту, а в прошивку модема. Это уже совсем другой уровень.
Первым шагом заменили DNS-парсер, который раньше был написан на C и регулярно оставался источником memory-safety проблем. Теперь там Rust на базе hickory-proto: bare-metal, no_std, FFI к существующим C-аллокаторам - все по-взрослому.
И самое важное тут даже не сам DNS-парсер. Главное, что Google уже протащили Rust в build system baseband. А значит, это не разовая демонстрация, а начало нормальной поэтапной миграции.
Вот так и выглядит реальное внедрение Rust в критическую инфраструктуру: без громких лозунгов, но с максимальной пользой. Сначала один опасный компонент, потом еще один, а дальше язык постепенно заходит в самые уязвимые части системы.
Rust все чаще идет не в новые игрушечные проекты, а в старые и сложные куски железа, где цена ошибки слишком высокая.
security.googleblog.com/2026/04/bringing-rust-to-pixel-baseband.html
#Rust #RustLang #MemorySafety #EmbeddedSystems #Android
Не в приложение, не в системный сервис и даже не в очередную утилиту, а в прошивку модема. Это уже совсем другой уровень.
Первым шагом заменили DNS-парсер, который раньше был написан на C и регулярно оставался источником memory-safety проблем. Теперь там Rust на базе hickory-proto: bare-metal, no_std, FFI к существующим C-аллокаторам - все по-взрослому.
И самое важное тут даже не сам DNS-парсер. Главное, что Google уже протащили Rust в build system baseband. А значит, это не разовая демонстрация, а начало нормальной поэтапной миграции.
Вот так и выглядит реальное внедрение Rust в критическую инфраструктуру: без громких лозунгов, но с максимальной пользой. Сначала один опасный компонент, потом еще один, а дальше язык постепенно заходит в самые уязвимые части системы.
Rust все чаще идет не в новые игрушечные проекты, а в старые и сложные куски железа, где цена ошибки слишком высокая.
security.googleblog.com/2026/04/bringing-rust-to-pixel-baseband.html
#Rust #RustLang #MemorySafety #EmbeddedSystems #Android
🔥55❤19👍13💊3🥰2👏2🥱2😍1💯1
Но тут есть важная разница.
В C, если вы вызвали функцию не так, например передали
NULL туда, где библиотека этого не ждала, и получили segfault, это часто называют неправильным использованием API.То есть ответственность перекладывается на разработчика: сам виноват, надо было читать документацию.
В Rust логика другая.
Если функция помечена как safe, она не должна приводить к memory bugs. Даже если вы передали странные данные, даже если сценарий неидеальный. Safe Rust по контракту обязан оставаться memory-safe.
Поэтому если safe-функция в Rust падает с segfault или приводит к проблеме памяти, это уже не «ты неправильно использовал API». Это баг библиотеки. И такой случай действительно может стать CVE.
Сырые числа CVE у Rust и C/C++ нельзя сравнивать напрямую.
В C/C++ огромный класс проблем считается нормальным риском неправильного использования. В Rust тот же класс проблем считается нарушением гарантий safe API.
Именно поэтому CVE в Rust часто говорит не «Rust такой же небезопасный», а наоборот: экосистема строже относится к тому, что safe-код вообще не должен ломать память.
Хороший разбор от Jakub Beránek из команды разрабов компилятора Rust:
http://kobzol.github.io/rust/2026/06/15/how-memory-safety-cves-differ-between-rust-and-c-cpp.html
#Rust #RustLang #MemorySafety #Security #CVE
Please open Telegram to view this post
VIEW IN TELEGRAM
👍32❤13🔥6🥰2🤗1
LLM уже находят реальные memory safety баги в Rust-коде.
И, что неожиданно, это работает очень хорошо.
Сергей Давыдов, руководитель Rust Secure Code Working Group, использовал GPT-5.5 и Claude Opus для аудита unsafe-блоков в популярных Rust-крейтах.
В итоге нашлись десятки реальных багов:
• use-after-free
• чтение за пределами буфера
• data races
• неправильные реализации Send / Sync
Все находки проверялись через miri, чтобы убрать ложные срабатывания.
Почему в Rust это работает лучше, чем в C?
• unsafe явно помечен и изолирован, поэтому LLM сразу понимает, где искать
• miri может точно подтвердить, настоящий баг или нет
• не нужно отслеживать data flow по всей кодовой базе, как часто бывает в C
Получается, дизайн Rust случайно сделал его почти идеальным языком для LLM-аудита безопасности.
Стоит прочитать всем, кто думает про AI в security tooling.
https://gist.github.com/Shnatsel/eb0a4be79a0657e4eb67c4f085f991bc
https://shnatsel.medium.com/the-unreasonable-effectiveness-of-llms-for-auditing-rust-code-d4df8bf0afd3
#Rust #RustLang #MemorySafety #Security #LLM
И, что неожиданно, это работает очень хорошо.
Сергей Давыдов, руководитель Rust Secure Code Working Group, использовал GPT-5.5 и Claude Opus для аудита unsafe-блоков в популярных Rust-крейтах.
В итоге нашлись десятки реальных багов:
• use-after-free
• чтение за пределами буфера
• data races
• неправильные реализации Send / Sync
Все находки проверялись через miri, чтобы убрать ложные срабатывания.
Почему в Rust это работает лучше, чем в C?
• unsafe явно помечен и изолирован, поэтому LLM сразу понимает, где искать
• miri может точно подтвердить, настоящий баг или нет
• не нужно отслеживать data flow по всей кодовой базе, как часто бывает в C
Получается, дизайн Rust случайно сделал его почти идеальным языком для LLM-аудита безопасности.
Стоит прочитать всем, кто думает про AI в security tooling.
https://gist.github.com/Shnatsel/eb0a4be79a0657e4eb67c4f085f991bc
https://shnatsel.medium.com/the-unreasonable-effectiveness-of-llms-for-auditing-rust-code-d4df8bf0afd3
#Rust #RustLang #MemorySafety #Security #LLM
👍35🤔8💊7🔥5