KasperskyOS, позиционирование и базовые вопросы

[E.K.]

О как! А мне пока не рассказали...

[Игорь Русинов]

Доброе утро. Насколько большое влияние на KasperskyOS оказала архитектура ОС QNX? Скорее Нейтрино наверное. 

[Sergey V. Rogachev]

Игорь, сейчас очень трудно что-либо достоверно утверждать про влияние других ОС, т.к. проект существует довольно давно, с 2002 года, и за время его существования многое поменялось: ядро переписывалось, значительно переделывалось, сменялись ведущие концепции и лидеры в команде разработки.

Я, как внутренний наблюдатель за 11.11, могу лишь постараться обратить внимание на какие-то черты, присущие другим микроядерным проектам, и находящие отклик в ядре нашей системы.

 

По моим наблюдениям, микроядро QNX Neutrino не так сильно похоже на ядро KasperskyOS. Явные отличия можно заметить даже по документации о внутреннем устройстве и программных интерфейсах этих систем, не погружаясь в чтение исходного кода (Neutrino: http://www.qnx.net/developers/docs/6.4.0/neutrino/sys_arch/kernel.html, KasperskyOS: https://support.kaspersky.ru/help/KCE/1.1/ru-RU/KasperskyOS-CE.pdf). Важно сказать, что QNX - изначально POSIX-совместимая система реального времени. KasperskyOS поддерживает POSIX в виде прослойки, в то же время под ней у системы есть свой собственный родной API, совсем непохожий на UNIX. Гарантии реального времени наша система пока не представляет и мы только работаем над отдельными аспектами RT.

 

Современное микроядро KasperskyOS стоит сравнивать скорее с микроядром Zircon от Google, или с современными ответвлениями традиции микроядер L4, например L4Re.

 

В нашем микроядре используется механизм object capabilities, через который происходит управление жизненным циклом системных объектов, а также распространение в системе прав доступа к этим объектам. Это черта почти всех современных проектов по разработке микроядер.

 

В отличии от совсем миниатюрных seL4, NOVA, CompositeOS Kernel, ядро KasperskyOS не выносит управление памятью в пространство пользователя, имеет продвинутый планировщик потоков, исполняемый в привилегированном режиме, полноценно поддерживает мультипроцессорность, включая балансировку нагрузки между ядрами. Эти небольшие системы, в попытке оптимизировать скорость передачи сообщений, идут на ухищрения, передавая их в регистрах процессора, или через специальную закрепленную для каждого потока страницу памяти. В KasperskyOS такие подходы оказываются неуместными, т.к. сообщения должны проходить через монитор обращений, реализующий общесистемную политику безопасности. Это означает, что в KasperskyOS нужно сохранять в ядре отдельную копию сообщения перед проверкой в мониторе, дабы избежать атак типа TOCTOU.

 

Кстати, о мониторе безопасности. Я не знаю ни одного микроядра кроме оригинального Flux, которое бы использовало общий монитор обращений для контроля доступа к системным и пользовательским объектам. Сейчас это скорее прерогатива монолитных систем: SELinux, AppArmor, TrustedBSD. А это уже Linux и BSD!

 

Разработчики не раз замечали, что некоторые API, особенно внутри ядра, порой отдаленно напоминают Windows NT. Неудивительно, первые разработчики ядра пришли из других направлений ЛК, где на них повлиял общий архитектурный стиль этой системы, а тянется он еще от того самого DEC, откуда когда-то в Microsoft перешел Дейв Катлер.

 

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

 

Я очень рад, что наша система получается достаточно самобытной. Работая в команде KasperskyOS, чувствуешь себя причастным к созданию чего-то необычного и нового.

Изменено 16 декабря, 2023 пользователем Sergey V. Rogachev

[Игорь Русинов]

Спасибо! 

[Игорь Русинов]

Здравствуйте! Какой язык программирования используется в написании Kaspersky OS? Раньше основные ЯП были C/C++, сейчас продвинулся Rust.

Изменено 22 декабря, 2023 пользователем Игорь Русинов

[4spirit]

если вопрос про язык на котором ядро, то основной = С. Платформо-зависимые части содержат ASM. С++ тоже в ходу.

Для политик безопасности используется Haskell, который потом компилируется в С. В частности для того, что бы оставалась возможность формальной верификации.

 

Сейчас активно обсуждаем возможность перепилить ключевые компоненты ядра на Rust, т.к. (с одной стороны) он позволяет значительно повысить доверие к коду, что для нас критически важно. А с другой стороны = работа серьезная, предварительно оценивается в 1 год работы. Т.е. это должно быть взвешенное решение.