Google начала использовать библиотеку Hickory, написанную на Rust, в прошивке радиомодуля (baseband) смартфонов серии Pixel 10. В частности, переписан и заменён участок кода, отвечающий за обработку DNS-протокола: вместо старого C-кода теперь задействуется библиотека hickory-proto, являющаяся частью экосистемы DNS-сервера Hickory, давно применяемого в крупной инфраструктуре.
Зачем Rust в прошивке модема
Baseband‑модем - один из самых критичных компонентов смартфона: он напрямую взаимодействует с сотовой сетью, обрабатывает низкоуровневые протоколы и пакеты, поступающие извне и не заслуживающие доверия. Среди этих протоколов - и DNS, который используется в мобильных сетях, в том числе для таких задач, как переадресация вызовов.
DNS при этом считается сложным протоколом: формат сообщений допускает множество вариантов и расширений, приходится разбирать бинарные структуры, обрабатывать нестандартные и потенциально вредоносные ответы. Любые ошибки при ручной работе с памятью в таком коде могут приводить к уязвимостям - от утечек данных до удалённого выполнения кода.
У Google уже есть негативный опыт: в прошивках baseband‑модема устройств Pixel ранее находили уязвимости, связанные именно с обработкой DNS‑ответов. В 2024 году была выявлена проблема под идентификатором CVE-2024-27227 - переполнение буфера при разборе специально сформированных DNS‑пакетов. Подобные баги типичны для кода на C и C++, где безопасность памяти полностью зависит от аккуратности разработчика.
Почему выбор пал на Rust и Hickory
Rust изначально спроектирован как язык с безопасной моделью работы с памятью: большая часть ошибок, связанных с обращением к уже освобождённой памяти, выходом за пределы буфера или гонками данных, отсеивается на этапе компиляции. Для Google это означает возможность сократить целый класс уязвимостей без тотальной переписки всего стека модема.
Библиотека hickory-proto уже решает задачу парсинга и формирования DNS‑сообщений и поддерживает широкий спектр функциональности протокола. Вместо того чтобы поддерживать собственный, потенциально небезопасный и сложно тестируемый код, команда Pixel использует готовое, хорошо проверенное решение, адаптировав его к условиям работы прошивки.
Проект внедрения hickory-proto рассматривается не как единичный эксперимент, а как пилот для более масштабного перехода на языки с безопасной памятью в критичных компонентах. Если опыт окажется успешным, Rust‑модули могут появиться и в других частях прошивки модема, а затем и в соседних подсистемах.
Сокращение поверхности атаки
Ключевая цель - уменьшить "поверхность атаки" через DNS. Парсер протокола на Rust не делает код абсолютно неуязвимым, но:
- снижает вероятность банальных переполнений буфера;
- усложняет эксплуатацию ошибок, даже если они остаются логическими, а не "памятными";
- упрощает аудит и анализ: многие классы дефектов физически невозможны из-за ограничений языка.
Таким образом, не требуется полагаться только на дисциплину программистов и статический анализ C‑кода: сама платформа принуждает к более безопасным паттернам.
Обратная сторона: "жирный" код
Главная проблема, с которой столкнулась команда Google, связана с размером итогового бинарника. Hickory-proto изначально создавалась как библиотека для серверных систем, а не для жёстко ограниченных по ресурсам встроенных устройств. В результате:
- общий размер интегрированных компонентов достиг 371 КБ;
- из них около 350 КБ приходится на саму hickory-proto и её зависимости;
- примерно 17 КБ - это вспомогательные функции, фактически вынесенные из стандартной библиотеки под нужды встраиваемого окружения;
- ещё около 4 КБ занимает прослойка, адаптирующая библиотеку к обработке ответов DNS‑серверов в контексте прошивки модема.
Для модема в Pixel 10 дополнительные три сотни килобайт не критичны - аппаратная платформа позволяет "переварить" этот объём. Но в мире встроенных систем есть устройства, где каждый десяток килобайт на счету, и перенос подобного решения туда уже потребует заметной оптимизации.
Планы по оптимизации Hickory-proto
Разработчики библиотеки и инженеры Google понимают, что текущий размер кода - компромисс, а не идеальный вариант для embedded-сектора. В планах - внедрение более гибкой системы флагов компиляции, которая позволит:
- отключать неиспользуемые части функциональности DNS;
- убирать расширения и редкие типы записей, не нужные в конкретной прошивке;
- жёстче контролировать набор зависимостей.
Таким образом, прошивка сможет включать именно тот минимум, который необходим модему в сотовой сети, не таща за собой весь "серверный" багаж.
Почему вопрос размера так важен для Rust в embedded
Rust традиционно критикуют за относительно "тяжёлые" бинарники, особенно в сравнении с тщательно вылизанным C‑кодом, заточенным под микроконтроллеры и экономию каждого байта. У крупных производителей смартфонов есть запас по памяти и производительности, но:
- не все радиомодули обладают такими же ресурсами;
- в IoT‑устройствах, недорогих контроллерах и модемах для промышленного применения возможно гораздо более жёсткое ограничение по флеш‑памяти и ОЗУ;
- рост размера кода иногда тянет за собой и увеличение энергопотребления, что критично для автономных устройств.
Поэтому успешность эксперимента Google оценивается не только по показателю безопасности, но и по способности Rust‑стека вписаться в реальные рамки embedded‑мира.
Rust против C, C++ и альтернатив вроде Zig
История с hickory-proto ещё раз подсветила вечный спор: что важнее - компактность и контроль на уровне байта или гарантии безопасности памяти?
Традиционный подход с C и C++ даёт максимальную свободу и позволяет выжать из железа всё, но любая ошибка в указателях или арифметике может превратиться в критическую уязвимость, особенно когда речь идёт о сетевых протоколах и радио.
Rust предлагает другой компромисс: часть гибкости жертвуется ради строгой модели владения памятью и проверок компилятора. Да, иногда это приводит к более "толстому" бинарнику, особенно когда используются обширные библиотеки общего назначения. Зато разработчику значительно сложнее "прострелить себе ногу" в стиле классических переполнений и use-after-free.
Иногда в таких обсуждениях всплывает и Zig - язык, который пытается сохранить близость к C и ручной контроль, но при этом добавить более современные средства и сборку. У него есть преимущества в плане тонкой оптимизации и предсказуемости, но он пока не имеет такого уровня зрелой экосистемы и встроенных гарантий безопасности памяти, как Rust. Для компании масштаба Google приоритет сегодня очевиден: снизить риск уязвимостей в массовых устройствах, даже ценой увеличения размера кода.
Роль unsafe в Rust и миф о "магической защите"
Часть скепсиса по отношению к Rust связана с неправильным пониманием ключевого слова `unsafe`. В контексте системного программирования оно:
- не "защищает" и не "исцеляет" код;
- просто позволяет программисту сознательно обойти часть проверок и взять на себя ответственность за корректную работу с памятью;
- используется там, где необходимо напрямую взаимодействовать с железом, внешними библиотеками, специфичными протоколами.
В правильно спроектированных библиотеках `unsafe` концентрируется в небольших низкоуровневых "прослойках", а остальной код остаётся в безопасной зоне. Это значительно уменьшает объём потенциально опасной логики, в отличие от C, где весь код по сути "unsafe" по определению. В случае hickory-proto Google получает именно такой подход: максимум логики парсинга DNS находится под защитой модели Rust, а не растворён в огромном массиве неограниченного C‑кода.
Почему для Google это стратегический шаг
Использование Rust в прошивке модема Pixel 10 - не просто техническое новшество, а часть более широкой стратегии по переходу на языки с безопасной памятью в критичных компонентах платформы. Это даёт компании несколько долгосрочных преимуществ:
- сокращение количества уязвимостей, требующих срочных патчей и обновлений;
- повышение доверия к безопасности линейки устройств, особенно на фоне роста числа атак через модемы и радиоинтерфейсы;
- накопление опыта и инфраструктуры для Rust‑разработки на уровне "железа", что облегчает дальнейшие внедрения.
Одновременно этот шаг создаёт важный прецедент для всей индустрии: если крупный производитель смог встроить достаточно тяжёлую Rust‑библиотеку в baseband‑прошивку флагманского смартфона и уложиться в ограничения по ресурсам, значит, подобный путь становится реалистичным для других вендоров.
Что это означает для будущего прошивок и безопасных языков
Опыт с Hickory в Pixel 10 показывает, что эра полностью "чистого" C‑кода в прошивках постепенно подходит к концу. Там, где на кону - безопасность пользователя и устойчивость устройства к сетевым атакам, выигрыш от языков с безопасной моделью памяти начинает перевешивать стоимость дополнительных сотен килобайт.
Дальнейшее развитие, скорее всего, пойдёт по нескольким направлениям:
- появление специализированных облегчённых Rust‑библиотек для embedded, изначально спроектированных с учётом жёстких ресурсных ограничений;
- совершенствование средств оптимизации, линковки и обрезки неиспользуемого кода, чтобы минимизировать размер бинарников;
- комбинированные решения, где критичные участки (разбор протоколов, криптография, сложная логика) пишутся на Rust, а наиболее низкоуровневые слои остаются на C, но строго изолируются.
В конечном счёте, кейс с Pixel 10 демонстрирует главное: переход к более безопасным языкам в прошивках - не теоретический лозунг, а практический процесс, уже идущий в массовых потребительских устройствах. И чем больше подобных проектов будет доведено до продакшена, тем быстрее изменятся требования к качеству и архитектуре кода во всём embedded‑сегменте.
