Совсем недавно мы вспоминали, как Rust вырос из стартапа до языка, у которого серьезные планы на Linux. И вот свежие новости: на Maintainers Summit 2025 года разработчики ядра решили, что Rust доказал свою пользу и можно расширить сценарии его использования. Это не значит, что он теперь на равных с C, но проект вышел за рамки «просто эксперимент». Давайте разберем, как все происходило, зачем нужно, почему были споры и что это сулит для будущего ядра. Поехали!

Как Rust пробирался в ядро

Ядро Linux всегда держалось на C — языке 1972 года. Он стал его основой во многом благодаря возможности работать максимально близко к железу. Его дополняет ассемблер, используемый в самых низкоуровневых частях системы. В 2010-х годах в сообществе разработчиков ядра и вокруг него начали появляться обсуждения возможности использования Rust — сначала на уровне идей и отдельных экспериментов. На фоне уже отлаженной кодовой базы это воспринималось как попытка добавить новый инструмент в мастерскую, где и без того все давно работает.

Идея использовать Rust в ядре Linux возникла как реакция на давнюю проблему языка C — уязвимости и сбои, связанные с управлением памятью. Rust изначально проектировался так, чтобы отлавливать подобные ошибки на этапе компиляции, и именно это привлекло внимание части разработчиков ядра. Язык использует строгую систему типов и проверки на этапе компиляции, которые ловят такие проблемы до запуска кода. Это не делает программы неуязвимыми на 100%, но снижает количество багов, особенно в новых модулях, где надежность критична.

Кроме того, Rust упрощает отладку за счет выявления многих ошибок еще на этапе компиляции. То, что в C часто обнаруживается только при запуске или в ходе эксплуатации, в Rust отсеивается заранее. Для ядра Linux это важно: каждый дефект требует долгого анализа и может проявляться в самых неожиданных местах. Особенно это актуально для драйверов, которые работают напрямую с оборудованием и нередко становятся источником нестабильности. C по-прежнему дает максимальный контроль и гибкость при работе с железом, но Rust снижает риск случайных ошибок и делает поведение системы более предсказуемым.

Впрочем, давайте признаем, что минусы у Rust тоже есть. Его синтаксис непривычен для тех, кто всю жизнь писал на C, а освоение требует времени. Но для ядра важен прагматизм, а Rust решает конкретные задачи, и это главное.

Однако от интереса до практики прошло немало времени: в течение 2010-х годов обсуждения в основном оставались теоретическими и сопровождались лишь отдельными экспериментами. Реальный шаг сделали в 2022 году, когда в ядре версии 6.1 официально разрешили использовать Rust для написания драйверов и модулей. Разработчики подчеркивали, что речь идет о контролируемом эксперименте без вмешательства в основную кодовую базу.

Источник.

За три года было создано несколько экспериментальных проектов: например, абстракции для драйверов видеокарт, сетевых устройств и USB. Эти компоненты пока не попали в основную ветку ядра, но показали, что Rust работает стабильно и не мешает коду на C. На Maintainers Summit 2025 года разработчики подвели итоги нескольких лет работы с Rust в ядре. Выяснилось, что Rust не вызывает проблем со сборкой и архитектурой ядра и может быть полезен в отдельных задачах, прежде всего там, где важна безопасность. На этом основании было решено пересмотреть его роль и расширить допустимые сценарии применения, сохранив осторожный подход и не затрагивая основную кодовую базу.

Заберите максимум новогодних подарков с 15 по 23 декабря?

Один день — один сюрприз: адвент-календарь со скидками до 100% на IT-инфраструктуру.

Подробнее →

Что теперь будет с ядром

Когда Rust только начали продвигать в ядре, часть разработчиков отнеслась к этому скептически. Они годами писали на C, отточили процессы, и идея добавить новый язык казалась лишней сложностью. Некоторые опасались, что два языка в одном проекте приведут к проблемам с поддержкой, или что Rust пытаются навязать как универсальное решение. Обсуждения порой становились очень жаркими, с аргументами, что проверенные методы на C вполне справляются.

Линус Торвальдс изначально критиковал не столько сам Rust, сколько попытки внедрить его без четкого плана. Со временем, когда эксперименты показали рабочие результаты, его позиция смягчилась. Он признал, что язык может быть полезен в ограниченных областях, если все делать с умом.

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

Источник.

Для обычных пользователей Linux изменения в ближайшее время останутся незаметными. Сам по себе факт появления Rust в ядре — это еще не гарантия повышения скорости или стабильности дистрибутивов. Эффект может проявиться со временем и точечно. Скажем, если новые драйверы и модули, написанные на Rust, действительно окажутся более надежными, это снизит количество сбоев и уязвимостей в тех частях системы, которые традиционно считаются проблемными.

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

Для индустрии в целом это сигнал, что Linux, как один из главных open-source проектов, готов пробовать новые подходы. Если Rust закрепится в ядре, это подтолкнет его использование в других системных задачах. Но пока это только начало, и сообществу предстоит найти, как лучше сочетать старое и новое.

Что в итоге

Признание Rust в ядре Linux нельзя назвать революцией и не попытка все переписать заново. Сказать, что это какое-то очередное модное веяние, тоже язык как-то не поворачивается. Ядро по-прежнему держится на C, но теперь у разработчиков появился еще один инструмент для ряда конкретных задач. Если Rust действительно поможет сделать драйверы и модули надежнее, от этого выиграют все. А сам факт, что Linux аккуратно впускает новый язык, показывает, что ОС умеет развиваться, не ломая того, что и так работает.

Комментарии (14)


  1. Nuflyn
    17.12.2025 08:19

    Менее одной тысячной кодовой базы ядра написано на Rust. Но, как говориться с почином!


  1. hex_coder
    17.12.2025 08:19

    Мне как пользователю всё равно, на чём там написана система, главное - чтобы работало. Но что-то я подозреваю, что чем больше таких изменений, тем больше будет обрубаться "старого" и "ненужного". Это, конечно, постоянно так происходит в мире СПО, но тут фундаментальные изменения. Да, делают заявления, что сразу всё переписывать не будут. И это правда. Пока правда. Потом что-то популярное перепишут. И у кого-то обязательно начнутся проблемы.


    1. MechanicZelenyy
      17.12.2025 08:19

      Я вас удивлю, но в ядре и без "ржавого" постоянно обрубается старое и ненужное, либо что-то переписывается, есть даже релизы ядра в которых кода удаленно больше чем добавлено (чем разработчики очень довольны) --- из ядра постоянно выкидываются древние драйверы и переписываются подсистемы для повышения их перформанса/секьюрности.


  1. V1tol
    17.12.2025 08:19

    Нужно упомянуть, что существует минимум два крупных драйвера, которые широко используются "в дикой природе". Android Binder, полностью вмерженный в апстрим совсем недавно в 6.18 и Apple AGX GPU, который пока за пределами апстрима. Из интересного в разработке есть Nova для невидий свежее 2ххх серии включительно.


  1. GlebSemenov
    17.12.2025 08:19

    Почин вышел не очень. Первая уязвимость в binder таки уже найдена.: Race condition that can occur due to some noted unsafe Rust code.

    https://www.phoronix.com/news/First-Linux-Rust-CVE


    1. mixsture
      17.12.2025 08:19

      А есть вообще инструменты уровня компиляции, чтобы ошибки race condition отлавливали? я как-то даже не представляю таких


      1. GlebSemenov
        17.12.2025 08:19

        Гонки проявляются только при исполнении чего-то. Как можно проверить статически условие "переменная x должна быть прочитана потоком A не раньше, чем ее запишет поток B"? Допустим, переменная x обвешана атомарными рефкаунтером и поток В честно его поднимает. И поток А читает рефкаунтер. Ну и как это статически проверить? Статически можно только написать анализатору "процедура обязана прочитать рефкаунтер". Или проверить, что критическая секция обвешана мьютексами.

        В случае ядра это могут быть не только потоки, но и обработчики прерываний, например.
        Есть всякие динамические анализаторы на темпоральной и прочей логики разделения, см сюда -- https://iris-project.org/


  1. Dhwtj
    17.12.2025 08:19

    За такую долгую тупость от Линукс я на месте создателей Раст давно бы обиделся и пошёл развивать его в другом направлении

    Будет ли variadic generics в Rust? Как пример накопившихся RFC

    И вообще, от языка где нет хорошего финансирования команды разработки компилятора я бы не ждал ничего хорошего в смысле развития. Вот как есть так и используйте. Или не используйте


    1. Jijiki
      17.12.2025 08:19

      можно имитировать на виртуальной машине или делать проверку подобно той что делает Раст, и писать на С на живой системе

      Скрытый текст
      --- SafeC-Lisp-Forth Hybrid Shell 2025 ---
      Формат: int name(arg1, arg2) { return выражение } 
      Команды: 'run' - скомпилировать всё в Си и запустить.
      
      safec> int square(x) { return x * x; }
      [CHECK] Проверка безопасности функции 'square'...
      [META] Переменная 'x' помечена как MOVED
      [OK] Функция 'square' скомпилирована.
      safec> run
      [SYSTEM] Вызов GCC и запуск...
      Результат исполнения: 25
      safec> 
      

      уже есть то чем чекать всё это можно, просто парсим, стекаем, лиспаем если нужен аст и тд. и код можно оставить читаемым

      это помимо старых решений в лоб через стековую вм, парсинг аст и компиляцию и прочее

      для этого надо скрестить лисп и форт и это получается альтернатива, нужен стек функций точно, а дальше уже по удобству там смотреть надо, но есть некий мета-стек, в котором можно делать проверку подобно бороу чекеру на лету в момент регистрации функции условно


      1. Dhwtj
        17.12.2025 08:19

        Похожие попытки есть: статические анализаторы для C (Coverity, Infer от Facebook). Полезны, но до гарантий Rust не дотягивают


        1. Jijiki
          17.12.2025 08:19

          в момент нанослова int или int[] метастек может проверить границы, но да с гонкой тут придётся попотеть, но красота форта в том, что он не может делать тех слов каких в нём нет, а то что есть можно проверить мета-стеком, так что в любом случае можно попасть в подмножество С делая его безопасным, учитывая реализацию конечную например на гцц, а это уже безопаснее

          тоесть наверняка есть безопасные паттерны даже на указателях и там есть пачка проверок,

          тоесть форт может дать С вторую жизнь как языку, который вылезает на уровень скрипта, и запаковывается обратно подмножеством


          1. Jijiki
            17.12.2025 08:19

            вообще сегодня это можно выродить в стековую машину, тогда мы приходим к тому что есть точка входа, она имеет в момент написания контракт - потомучто она функция, мы сейчас в парадигме С, соотв любая функция просящая кадр стека и давая возврат это контракт,

            соотв любой опкод, с окружением это просто эмуляция контракта, тоесть тут интересен только механизм мета-стека, он работает как алгоритм дейкстры но в своём стеке по всему контракту


  1. Jijiki
    17.12.2025 08:19

    такими темпами можно было в ядро ввести "лиспофорт на анси С"


  1. GDLearn
    17.12.2025 08:19

    А все для того, чтобы лицензия на модули была MIT и компании могли делать проприетарщину на их основе и постепенно заменять эти модули. А замена будет, поскольку деньги будут в проприетарщину вкладывать и она работать будет лучше.