Уникернелы были сложными. Ключевое слово — были
Unikernels were hard. key word: were
Джеффри Хантли и Джастин Кормак обсуждают возрождение уникернелов: теперь ИИ снимает барьеры, которые делали их непрактичными. Хантли рассказывает, как за неделю портировал Orleans на OCaml и собрал распределённую уникернел-ОС, а Кормак с помощью агента написал mkfs.xfs на Rust. Они спорят о сокращении поверхности атаки, Nix, S3 как хранилище и о том, почему уникернелы снова актуальны.
Уникернелы были сложными. Ключевое слово: были. Теперь у нас есть ИИ.
- RantyDave
У меня был ограниченный опыт в embedded-разработке, и в рамках этого я стал фанатом Zephyr (http://www.zephyrproject.org) и задумался о его потенциальном применении в качестве unikernel.
С плюсами: это unikernel. Вы компилируете его вместе с вашим приложением и получаете бинарник. Он поддерживает работу на виртуальном оборудовании (https://docs.zephyrproject.org/latest/hardware/virtualizatio...), а virtio — это новые bios, верно?
С минусами: я думаю, портирование «традиционного» софта — скажем, Nginx — на него будет мучительным. И я не могу давать никаких гарантий по его производительности — так же, как контейнерные образы Alpine Linux не обязательно быстрые.
Но есть целая цепочка инструментов, отладка, драйверы и т.д. для того, что компилируется в крошечный размер и запускается практически мгновенно. Разве это не должно быть для чего-то полезно?
- scrubs
Естественным проектом для R&D был бы высокочастотный OMS или что-то вроде менеджера книги заявок/цен NYSE.
Такие приложения в любом случае обычно делают kernel bypass для сетевого ввода-вывода после жёсткой чистки ОС, чтобы убрать как можно больше прерываний и прочего лишнего джиттера, который OMS не нужен.
Однако я полагаю, что низкоуровневый код kernel bypass (например, dpdk, libfabric) зависит от Linux, чтобы дисциплинированно общаться с железом.
Кто-нибудь знает лучше?
Существенно более быстрый OMS таким способом мог бы стать практичной альтернативой FPGA, которые мы иногда видим в этой области. (железо, конечно, будет размещено рядом)
- ianseyler
Приятно это видеть! Я предлагаю облачный сервис для хостинга unikernel'ов на основе моего ядра BareMetal.
~$0.005 CAD/ч за небольшую VM с сетью, 4MiB RAM и без диска.
- angry_octet
Если у вас серьёзные цели по минимизации поверхности атаки, вам нужно embrace FOGAs. Unikernel'ы, написанные LLM, имеют слишком много раздутости.
Части Zynq UltraScale+ сочетают жёсткий ARM CPU с FPGA-фабрикой. Вы можете постепенно изолировать быстрый путь и высокозащищённые компоненты в логике. LLM становятся довольно хороши в использовании инструментов синтеза.
https://www.amd.com/en/products/system-on-modules/kria/k26/k...
- eyberg
Уменьшение поверхности атаки — определённо плюс, но это далеко не главная выгода для безопасности от запуска unikernel'ов.
Вот почему мне никогда особо не нравилось говорить о «сокращении поверхности атаки» так много, потому что люди неизбежно сводят всё к строкам и коду, и хотя сокращение — это хорошо, это просто не передаёт, в чём на самом деле самая большая проблема.
Эксплуатация уязвимостей — это точка входа номер один для утечек данных, а инъекция команд ОС — это CWE номер один в CISA Kev за прошлый год.
Вторжение в систему повторялось что-то вроде 64 раз в прошлогоднем DBIR.
Сама операционная система буквально и есть проблема, поскольку она по своей сути предназначена для запуска множества разных программ, тогда как unikernel'ы запускают только одну.