
В конце ноября 2025 года проект Moss представил прототип Unix-подобного ядра, написанного на Rust. Это попытка создать ядро, которое умеет запускать Linux-приложения, но работает уже по новым правилам — с упором на асинхронность и современные подходы к системному коду. За восемь месяцев команда добилась того, что ядро работает на реальном оборудовании, поддерживает базовые системные вызовы и запускает командную оболочку Bash. В этой статье разберем, что такое Moss, как оно устроено, где пока недотягивает и какие у него перспективы.
Что такое Moss и зачем он нужен
Moss — это Unix-подобное ядро, написанное на Rust, известном своей строгой типизацией и защитой от ошибок памяти. Проект ориентирован на архитектуру Aarch64 и уже протестирован на платах вроде Raspberry Pi 4, Jetson Nano, AMD Kria и iMX8. То, что ядро реально работает на железе, впечатляет, ведь пока что это лишь прототип.
Разработчики выбрали Rust не случайно. В отличие от C, который доминирует в ядрах вроде Linux, Rust помогает избежать уязвимостей, связанных с управлением памятью, таких как переполнение буфера. Это особенно важно для ядра, где ошибка может обрушить всю систему. Код открыт под лицензией MIT, что делает его доступным для всех, кто хочет изучить или доработать проект. На GitHub уже есть репозиторий, где можно посмотреть исходники или предложить свои изменения.
Особенность Moss — использование асинхронной модели программирования с async/await. Асинхронная модель позволяет ядру обрабатывать операции без лишних блокировок, разгружая выполнение и повышая отзывчивость системы. Такой подход встречается редко в системном программировании, и он выделяет проект среди других экспериментов с ядрами. Важно отметить, что асинхронность в Moss — это не просто модная фишка, а способ упростить сложные операции вроде системных вызовов, хотя конкретных данных о том, как это влияет на производительность, пока нет.
Еще одна сильная сторона — модульность. Ядро использует прослойку HAL (Hardware Abstraction Layer), которая упрощает адаптацию к новым архитектурам, например, x86_64 или RISC-V. Пока поддерживается только Aarch64, но HAL дает надежду на будущую портируемость. Также есть библиотека libkernel, которая выносит основную функциональность в независимый слой, не привязанный к конкретному оборудованию. Это делает код чище и проще для поддержки.

Бесплатный курс «Системный администратор Linux с нуля»
Освойте администрирование Linux на SelectOS и станьте востребованным специалистом.
Что Moss уже умеет
На момент анонса Moss поддерживает 51 системный вызов Linux. Это немного, но достаточно, чтобы запускать Bash и большинство утилит BusyBox. Ядро включает несколько ключевых компонентов, которые показывают, что разработчики не просто экспериментируют, а строят продуманную систему.
Управление памятью — одна из сильных сторон. Ядро поддерживает страницы памяти с режимом Copy-on-Write, что экономит ресурсы при создании процессов. Есть таблицы страниц и обработка исключений (page fault) как на уровне ядра, так и в пользовательском пространстве.
Подсистема процессов тоже на уровне. Планировщик задач поддерживает миграцию процессов между процессорами через межпроцессорные прерывания (IPI), что важно для многоядерных систем. Системный вызов clone() позволяет создавать новые процессы, а поддержка сигналов обеспечивает взаимодействие между процессами и потоками. Это минимальный, но рабочий набор для многозадачности, который делает ядро пригодным для запуска простых приложений.
Файловая система пока, увы, ограничена, но уже имеет базовые возможности. Виртуальная файловая система (VFS) работает асинхронно, что соответствует общей философии проекта. Поддерживается ramdisk, устройство devtmpfs для файлов устройств и драйвер FAT32, но только в режиме чтения. Это позволяет взаимодействовать с файлами и запускать утилиты, хотя для полноценной работы с данными нужно больше.
В репозитории уже есть больше двух сотен тестов, которые проверяют память, работу процессов и базовые файловые операции. Для прототипа это нетипично: многие проекты на ранней стадии обходятся минимальными проверками. Здесь же тесты позволяют удерживать систему в рабочем состоянии по мере роста кода и дают представление о том, как именно разработчики строят архитектуру и контролируют её поведение.
Где Moss пока слаб
Moss — молодой проект, и его ограничения хорошо видны. Самая заметная проблема сейчас — отсутствие сетевой подсистемы: без TCP/IP ядро не может запускать сетевые приложения, что в 2025 году сильно сужает область применения. Разработчики пока не объявляли планы по реализации сети, но очевидно, что без нее проект далеко не уйдет.
Файловые системы тоже в зачаточном состоянии. Единственный рабочий драйвер — FAT32, и то, как уже сказано, только в режиме чтения. Более сложные системы хранения пока недоступны, что усложняет работу с постоянными данными и внешними носителями. Для прототипа это ожидаемо, но на практическое использование не тянет.
Планировщик задач функционирует, однако его возможности ограничены: неизвестно, есть ли у него механизмы распределения нагрузки на многоядерных системах. Это важная часть многозадачности, и ее отсутствие может сказаться на производительности, хотя конкретных деталей разработчики пока не раскрывали.
Поддержка архитектур тоже минимальная. Сейчас Moss работает только на Aarch64, и хотя HAL-прослойка упрощает перенос на x86_64 или RISC-V, реальная адаптация потребует времени. До широты аппаратной поддержки, которой обладают зрелые ядра, проекту ещё далеко.
Перспективы проекта
Moss пока на ранней стадии, но у него есть потенциал. Разработчики планируют расширять число системных вызовов, чтобы увеличить совместимость с Linux-приложениями. Скорее всего, в приоритете будут сетевые возможности и полноценные файловые системы, хотя конкретных планов в анонсе нет. Если проект продолжит развиваться, он может найти нишу в IoT или встраиваемых системах, где легковесность и безопасность особенно важны.
Но есть и риски. Ядро — это сложный продукт, и без активного сообщества Moss может остаться экспериментом. Linux стал успешным благодаря тысячам контрибьюторов, а Moss пока поддерживает небольшая команда. Открытая лицензия и выбор Rust могут привлечь разработчиков, но для этого нужны документация, примеры и активная коммуникация. Пока проект выглядит скорее как песочница для энтузиастов, чем как конкурент Linux.
Еще один вопрос — позиционирование. Совместимость с Linux — полезная цель, но полностью повторить его API небольшой команде будет непросто. Возможно, Mossу имеет смысл сосредоточиться на своих сильных сторонах, например на асинхронной архитектуре, и развивать проект в сторону более узкой и понятной ниши. Для сравнения: Redox OS, тоже написанная на Rust, делает ставку на микроядро и собственную модель системы, а не пытается копировать Linux. Moss пока находится в точке выбора и только ищет свой путь.
Moss кажется любопытным экспериментом. Пока что до уровня, где его можно использовать в реальных задачах, еще далеко. Но для тех, кто интересуется системным программированием, проект может стать отличной площадкой для экспериментов. Код уже доступен, его можно запустить в QEMU или на реальном железе.
Если вдруг опробуете на деле, пишите в комментариях, что думаете.
Комментарии (18)

CrazyOpossum
01.12.2025 09:23MIT лицензия - наконец стартовал EEE ядра? Никто не верил, и вот он наконец.

Kelbon
01.12.2025 09:23"безопасность"
fn упоминается в 150 файлах проекта (так начинается любая функция в Rust)
unsafe упоминается в 76 файлах проекта и не по одному разу в каждом. Безопасно.

okhsunrog
01.12.2025 09:23Расскажите нам, как писать ядро без ключевого слова unsafe, нам очень интересно. А как вы понимаете значение этого ключевого слова, кстати?

Kelbon
01.12.2025 09:23я к тому, что на С это ядро было бы читаемее, но без рекламных заголовков типа "на раст написали ОС, вся из себя такая безопасная"

misha_erementchouk
01.12.2025 09:23Наблюдение. "Безопасность" в Ваших двух комментариях здесь на странице употребляется в полтора раза больше, чем в самой заметке, пресс-релизе, на который она ссылается, и README.md корневой страницы репозитория проекта вместе взятых.

Cfyz
01.12.2025 09:23Хотя я тоже не в восторге от хайпа вокруг Rust, но вы фактически говорите что раз 100% безопасности добиться нельзя, то не стоит даже пытаться минимизировать вынужденно небезопасный код.
Некоторые умудряются довести эту идею до полного абсурда и, увидев завёрнутые в unsafe чтение-запись регистров ввода-вывода, делают вывод что раз unsafe, значит не безопасно, а значит смысла писать на Rust нет.
без рекламных заголовков типа "на раст написали ОС, вся из себя такая безопасная"
И справедливости ради, нигде и нет таких рекламных заголовков -- ни в статье, ни в описании проекта. Отмечается лишь большая безопасность за счёт использования инструментария с более строгими проверками.

Astrowalk
01.12.2025 09:23Да, частенько критикуют без понимания. Такое впечатление, что некоторых пугает само слово "unsafe". А между тем это ключевое слово используется в двух контекстах (в объявлении функции и при выполнении блока), где имеет разное значение. И в сообществе высказывалось мнение, что это ошибка дизайна, и во втором контексте лучше было бы применить слово "trusted":
https://github.com/rust-lang/rfcs/pull/117
black_warlock_iv
01.12.2025 09:23Есть ещё третий контекст. В случае с встраиваемым ассемблером и, возможно, атрибутом
no_mangle, нельзя получить unsound код, что бы ты ни делал. Так в этом контекстеunsafeобозначает не "я проверил, гарантии выполняются" и не "нужно проверить, что гарантии выполняются", а просто что-то вроде "я не боюсь!"

andreylartsev
01.12.2025 09:23тут явная подмена декларируемой и реальной целей. люди хотят писать на Rust, он им нравится ) но они не могут написать "вот мы решили написать свое ядро на Rust, потому что Rust выбросили из ядра", это же никому кроме них самих интересно не будет )
то что безопасность не сводится к безопасному управлению памятью, и в целом к использованию везде паттерна RII, они скромно умалчивают, хотя, конечно могут и добросовестно заблуждаться...

Kapsa-sa
01.12.2025 09:23Ну да прямые Win32 API живы-здоровы, просто в проде ими редко занимаются. Отсюда и ощущение магии

litalen
01.12.2025 09:23Код открыт
конкретных деталей разработчики пока не раскрывали
У вас как это в одной и той же статье оказалось?

select26
01.12.2025 09:23В отличие от C, который доминирует в ядрах вроде Linux, Rust помогает избежать уязвимостей, связанных с управлением памятью, таких как переполнение буфера.
Ну зачем так передергивать? С что ли не позволяет писать без таких уязвимостей? А, думать нужно? А про MISRA C не слышали?
Как обычно, на все готовы, лишь бы избавиться отзависимости результата от компетенции испоолнителя.
Это особенно важно для ядра, где ошибка может обрушить всю систему.
А если приложение упало - то и .. с ним? Вместо покрытия тестами, обучения и применения анализаторов дружно идем на.. Rust? С потерей производительности.
Подход - просто чума!
unC0Rr
01.12.2025 09:23компетенции испоолнителя
А исполнитель не человек и никогда не ошибается? Ему не нужна помощь тулинга, он готов быстро писать большие системы без единой ошибки?
Вместо покрытия тестами, обучения и применения анализаторов дружно идем на.. Rust?
Rust - это и есть анализатор в некотором смысле. Который анализирует вашу программу на соответствие некоторым принципам, позволяющим исключать обширные классы ошибок.
С потерей производительности.
Производительности чего? Компиляции, что ли?

qwerty19106
01.12.2025 09:23Ну зачем так передергивать? С что ли не позволяет писать без таких уязвимостей? А, думать нужно? А про MISRA C не слышали?
А как же ложно-положительные и ложно-отрицательные срабатывания? Проверки на уровне компилятора почти не допускают ложных срабатываний (особенно отрицательных). По-этому в статье и написано, что С не помогает. Хотя написать код без уязвимостей конечно можно.
Rust? С потерей производительности.
И у вас есть соответствующий бенчмарк?
benjik
Понаблюдаем.
Есть ещё https://github.com/asterinas/asterinas - чуть более зрелый и с немного другими целями, но тоже somewhat-linux-compatible и на rust.