Экспериментальные ОС — какие они бывают? Свежие проекты: от «ИБ-микроскопа» до «долгоиграющего» ядра на тысячелетия
Существует множество специализированных операционных систем, в том числе заточенных под задачи в области ИБ: Kali Linux — для пентеста, Qubes OS — для работы в изолированной среде. Мы в Beeline Cloud обсудим несколько свежих экспериментальных ОС с упором на инфобез и не только. Одна позволяет отслеживать работу процессора в, так сказать, почти лабораторных условиях, другая — противостоит программам-вымогателям, еще одна — предлагает потенциально автономную архитектуру для космических проектов.
Операции под микроскопом
Выявить аппаратные уязвимости вроде Meltdown и Spectre можно, исследуя процессы внутри чипа. Вот только большинство ОС общего назначения для подобных исследований не предназначены. В мае 2026 года команда из Лаборатории компьютерных наук и систем ИИ Массачусетского технологического института (MIT CSAIL) представила специализированное ядро ОС для изучения устройства процессоров и поиска уязвимостей — Fractal.
Система работает на x86-64, ARM64 и RISC-V, поддерживает набор вызовов POSIX и насчитывает более 31 тыс. строк кода. Fractal предоставляет примитивы для экспериментов с процессором — например, переключения уровней привилегий на лету. Свой подход авторы назвали «многопривилегированным параллелизмом», а решение — «электронным микроскопом для операционных систем». И его возможности уже опробовали на практике.
С помощью Fractal команда получила первое доказательство того, что процессор Apple M1 подвержен спекуляции вида Phantom, которую прежде находили только на чипах AMD и Intel. По умолчанию в M1 имеется защитный механизм CSV2, не позволяющий коду для одного уровня привилегий влиять на другие. Однако, как оказалось, пользовательский код все же может влиять на содержимое кешей ядра в обход этих ограничений. Авторы проекта поделились результатами эксперимента с Apple. В перспективе авторы рассчитывают, что Fractal станет для микроархитектурных исследований тем же, чем QEMU и FFmpeg стали для своих областей, — стандартным инструментом, который развивается силами сообщества.
Все есть таблица
Еще в 2020 году профессор MIT и создатель PostgreSQL Майкл Стоунбрейкер и Матей Захария, автор фреймворка Apache Spark, обсуждали проблему: как масштабировать планирование миллиона задач Spark, когда традиционные механизмы ОС с такой нагрузкой уже не справляются. Требовался принципиально иной стек, заточенный под масштабирование. Так и появилась концепция БД-ориентированной ОС — DBOS. Она работает по принципу «все — это таблица», когда полное состояние системы записывается в таблицы распределенной базы данных. Туда помещается информация о каждой задаче и файле, о сетевых соединениях и прочих компонентах ОС. Также сохраняется полная история изменений в системе, и эта история — одна из причин, почему предложенная архитектура оказалась более устойчивой к различным атакам вроде программ-вымогателей. Столкнувшись с тем же шифровальщиком, администратору достаточно откатить систему к раннему безопасному состоянию.
Такой принцип называется «безопасностью через устойчивость» (security through resilience): вместо того, чтобы пытаться предотвратить угрозы, система быстро адаптируется и восстанавливается с минимальными потерями [хотя, конечно, про гигиену пользовательских файлов все равно стоит помнить, чтобы не допустить заражения резервных копий]. Более того, DBOS позволяет ИБ-специалистам анализировать последствия атак или искать уязвимости в системе с помощью SQL-запросов. Достаточно поднять происхождение данных и логи в СУБД — и все изменения состояний приложений сразу становятся видны. К примеру, администратор может проверить систему на утечки данных (логи покажут, какие процессы к ним обращались).
Тысячелетия бесперебойной работы
Долгоживущие космические зонды, которые летят сквозь пространство на протяжении десятков лет, сталкиваются с аппаратной деградацией. В мае 2026 года независимый исследователь Уилл Биннс опубликовал вайтпейпер, в котором предложил концепцию операционной системы Mru, ориентированной на поддержание максимально долгой автономной и отказоустойчивой работы решений на борту. Текст работы размещен в том числе на GitHub под лицензией CC BY 4.0. Название, к слову, отсылает к японскому суффиксу «мару» (обозначает «круг», «полноту» или «защиту»), который в XII веке добавляли к именам морских судов в качестве оберега. Ключевая идея заключается в том, чтобы дать системе возможность обнаруживать программные и аппаратные сбои, локализовывать их, восстанавливать работоспособность в ходе многолетних космических миссий. Хотя автор понимает, что Mru, очевидно, не сможет устранить фактор деградации полностью.
Архитектура у Mru шестислойная, причем слои упорядочены по «праву на изменение». На нулевом уровне размещается «золотая копия» ядра вместе с ключевыми конфигурациями — это наиболее защищенный как от программных, так и внешних физических угроз слой системы, содержащий до пятисот базовых инструкций на no_std Rust-коде. Первый уровень следит за функционированием вспомогательных узлов, согласует их работу и в целом занимается мониторингом всей системы. Во второй уровень включены модули навигации, определяющие положение космического зонда, его скорость и ориентацию в пространстве.
Третий уровень включает инструментарий для автономного проведения научных экспериментов: аппарат должен сам решать, что достойно изучения, ведь он не всегда сможет «посоветоваться» с человеком [нейросети здесь не используются; вместо них — неизменяемые наборы правил с настраиваемыми параметрами]. Четвертый — слой связи, работающий с высокоэффективными видами кода для исправления ошибок вроде LDPC или турбокода. Пятый уровень отвечает за адаптацию системы к меняющимся условиям. Логика простая: система, которой предстоит длительная автономная работа, должна иметь возможность модифицировать поведение — но с определенными ограничениями.
Пока что проект — это, по сути, молодой концепт, который не продвинулся дальше симуляций. Хотя автор отмечает, что «тысячелетия» бесперебойной службы сегодня можно проверить только моделированием. Симулятор при этом опирается на физику реальных процессов вроде распада плутония-238 в РИТЭГе и темпы деградации памяти. Результаты сверяются с полувековой телеметрией «Вояджеров» — единственным реальным набором данных о том, как техника «угасает» без физического вмешательства на протяжении десятилетий.
Ядро с чистого листа
Если обратиться к ИБ-отчетам разных ИТ-компаний, обнаружится любопытная закономерность: значительная часть критических уязвимостей в системном ПО, так или иначе, связана с ошибками безопасности памяти. К примеру, в 2019 году на операционных системах Apple их доля составляла около 60–70%; идентичную статистику показало и исследование продуктов Microsoft — все те же 70%. Дискуссии о важности защиты памяти идут и в мире Linux. Часть разработчиков взялась внедрять Rust в ядро — его модель владений и заимствований отсекает целые классы ошибок памяти еще на этапе компиляции. Правда, идею поддержали не все. Например, мейнтейнер Кристоф Хеллвиг выступал против смешения C и Rust в одной кодовой базе, потому что сопровождать такой код — задача не из легких.
По-своему проблему решили китайские специалисты из Южного научно-технологического университета (SUSTech), Пекинского университета, Лаборатории Чжунгуаньцунь и ИТ-компании Ant Group. Они не стали смешивать языки, а с нуля написали ядро на Rust, — проект получил название Asterinas. В его основу легла архитектура framekernel, согласно которой операционная система должна функционировать в одном адресном пространстве, но с внутриядерным разделением привилегий. Весь низкоуровневый небезопасный (unsafe) код изолирован во фреймворке OSTD, а остальные компоненты ядра пишутся только на безопасном Rust и обращаются к «железу» исключительно через OSTD API.
На основе нового ядра уже построили дистрибутив Asterinas NixOS. Инженеров привлекла гибкость в настройке и богатая экосистема пакетов этой операционной системы. Разработчики считают, что уже в этом году Asterinas можно будет использовать для виртуализированных сред x86-64, а позже и в дата-центрах, автономных транспортных средствах и в системах воплощенного ИИ — нейросетевых роботах, которые взаимодействуют с окружением с помощью сенсоров, датчиков и манипуляторов. Исходный код проекта опубликован на GitHub под лицензией Mozilla Public License 2.0 (отдельные компоненты — под более разрешительными лицензиями). Если интересны технические подробности реализации, то ознакомиться с архитектурой и компонентами ядра можно в официальной документации.
Beeline Cloud — безопасный облачный провайдер. Разрабатываем облачные решения, чтобы вы предоставляли клиентам лучшие сервисы.
Что еще почитать у нас в блоге и на нашей ИТ-площадке:
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.