Google призывает лечить уязвимости по памяти в прошивках кодом на Rust

Google призывает лечить уязвимости по памяти в прошивках кодом на Rust

Google призывает лечить уязвимости по памяти в прошивках кодом на Rust

Компания Google ратует за развертывание Rust в низкоуровневых прошивках, продвигая перевод унаследованных кодов на этот язык как средство борьбы с багами, грозящими нарушением безопасности доступа к памяти.

В новой блог-записи команда Android утверждает, что переход с C или C++ на Rust в существующих прошивках даст гарантии безопасности по памяти на уровнях ниже ОС, не имеющих стандартов защиты.

По словам специалистов, потери производительности при этом ничтожны, величина Rust-кодов тоже сравнима, главное — проводить замену базовых кодов поэтапно, начав с новых и самых критичных. Процесс не потребует больших усилий, и со временем число уязвимостей доступа к памяти значительно сократится.

Чтобы облегчить переход, можно, к примеру, создать тонкую Rust-прослойку — предзагрузчик Shim, который будет копировать C API и осуществлять экспорт для существующей кодовой базы.

«Shim служит оболочкой API библиотеки Rust, соединяя существующий C API и Rust API, — поясняют эксперты. — Так обычно и делают, переписывая библиотеки или заменяя их Rust-альтернативой».

По признанию Google, до недавнего времени баги безопасности по памяти были основным источником уязвимостей в Chrome и Android. Благодаря развертыванию языков программирования, способных избавить продукты от этой напасти, в период с 2019 года по 2022-й ежегодный урожай таких ошибок в мобильной ОС удалось сократить с 223 до 85.

 

В прошлом году Microsoft запустила процесс перевода ядра Windows на Rust. Вышедшая в мае 2023 года сборка ОС версии 11 содержала драйверы на этом языке; тогда же стало известно о планах техногиганта аналогичным образом повысить защищенность процессора Pluton, который пока не нашел широкого применения.

Линус Торвальдс разнёс баг-хантеров с ИИ за спам в рассылке Linux

Линус Торвальдс снова недоволен. В еженедельном сообщении о Linux 7.1-rc4 он заявил, что управлять отчётам о безопасности ядра стало почти невозможно из-за потока репортов о багах, найденных ИИ-инструментами. Проблема не в том, что ИИ ищет баги. Проблема в том, что десятки людей запускают похожие инструменты, находят одни и те же проблемы, а потом несут их в приватную рассылку.

В итоге мейнтейнеры тратят время не на исправления, а на сортировку дублей и ответы в стиле «это уже починили неделю назад».

Торвальдс отдельно подчеркнул: баги, найденные ИИ, по определению редко бывают секретом. Если один инструмент нашёл проблему у одного исследователя, с большой вероятностью тот же инструмент уже нашёл её ещё у пяти человек. А когда всё это уходит в закрытую рассылку, авторы даже не видят отчёты друг друга.

Посыл Торвальдса простой: хотите быть полезными — не кидайте сырой ИИ-репорт. Прочитайте документацию, проверьте проблему, разберитесь, сделайте патч. Добавьте хоть какую-то человеческую работу поверх того, что сгенерировала машина. Иначе это не вклад в безопасность Linux, а спам с претензией на ресёрч.

При этом сам Торвальдс не объявляет войну ИИ. Он признаёт, что инструменты могут быть полезны, но только если они помогают проекту, а не создают имитацию деятельности.

Забавно, что позиция Торвальдса звучит жёстче, чем недавние оценки Грега Кроа-Хартмана, который говорил, что ИИ становится всё более полезным инструментом для FOSS-сообщества. Но противоречия тут почти нет: полезный ИИ — это когда он приводит к патчу. Бесполезный ИИ — это когда он превращает рассылку Linux в свалку одинаковых срочных находок.

RSS: Новости на портале Anti-Malware.ru