Кроссплатформенная библиотека EOOS Safe для KasperskyOS

[Sergey Baigudin]

Здравствуйте, коллеги!

Прочитал в Telegram-канале "KasperskyOS. Разработка" запись с предложением делиться успехами в разработке на KasperskyOS и подумал: а почему бы и нет?

Я уже очень давно занимаюсь разработкой безопасного программного обеспечения, и в частности разработкой собственной кроссплатформенной библиотеки EOOS Safe на языке С++. Когда-то очень давно начал её развивать ещё для POSIX и WIN32 совместимых операционных систем, затем адаптировал эту библиотеку для FreeRTOS, а когда появилась KasperskyOS CE 1.1, то я задался вопросом как собственно изучения самой операционной системы, так и адаптации EOOS Safe для неё. Изучил. Адаптировал.

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

Готов к любым каверзным вопросам и дискуссиям 🙂

[Yura Beznos]

Приветствую, Сергей!

Выглядит интересно.

У меня сходу ряд вопросов появился.

1. Как сложно было портировать на KasperskyOS ? Какие трудности возникли на уровне ОС, на уровне инструментария, удобно ли использовать плагин для VSCode, чего не хватает и т.п.?

2. Вот есть стандартная библиотека в C++ с большим многообразием возможностей, привычная, знакомая, множество примеров в интернет можно найти, а тут новая библиотека, какие вы видите доводы взять разработчику вашу библиотеку?

[Sergey Baigudin]

Здравствуйте, Юрий!

Извините, пожалуйста, за задержку с ответом. Спасибо вам за оценку и за проявленный интерес. Я старался 🙂 

On 3/10/2025 at 10:13 AM, Yura Beznos said:

1. Как сложно было портировать на KasperskyOS ? Какие трудности возникли на уровне ОС, на уровне инструментария, удобно ли использовать плагин для VSCode, чего не хватает и т.п.?

 

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

Моя библиотека на 99% покрыта юнит-тестами, написанными с использованием библиотеки gtest. И моей целью было как раз запустить мои юнит-тесты, чтобы убедится, что весь функционал под KasperskyOS работает так-же, как под Linux и под Windows. И я не знаю почему, но я пытался собрать gtest из исходников под KasperskyOS, и это у меня никак не получалось. И только потом, где-то случайно я нашёл, что gtest уже включена в KOS SDK. После этого всё пошло гораздо проще.

Потом, я помню, мне очень хотелось выводить не только в stderr, но и в stdout. Точнее, я изначально выводил в stdout, но ничего в терминале не видел. А проблема, как оказалась, была в том, что в stdout выводить без подключённой клиентской библиотеки VFS не возможно. Пришлось разбираться с не очень очевидной вещью - какие пакеты надо подключить в CMake для VFS, какую клиентскую библиотеку VFS слинковать к моему исполняемому файлу, как описать IPC между моим процессом и процессом VfsRamFs, какие сущности добавить в CMake для Einit. В итоге я это сделал, но это было действительно не очевидно.

Ещё, как известно, KasperskyOS поддерживает POSIX, но мне очень хотелось изучить нативный KOS API и соответственно его использовать. Но если Mutex и Semaphore мне удалось использовать с нативным KOS API, то вот работу с Thread - нет, и мне соответственно пришлось использовать pthread.

Плагин для VSCode я не использовал. В общем и целом какой-то глубокой отладки я не проводил, всё можно было отладить условно в блокноте. Но надо отметить, что у меня уже все тесты были написаны до этого, а значит их нужно было только лишь запустить.

Чего не хватает? Знаете, я думаю, что исчерпывающей документации, ибо много вещей приходилось решать на уровне догадки. Хотя я понимаю, что KasperskyOS Community Edition это всё таки ознакомительная сборка и наверняка для боевых решений есть и более полная документация, и техническая поддержка самой Лаборатории.

On 3/10/2025 at 10:13 AM, Yura Beznos said:

2. Вот есть стандартная библиотека в C++ с большим многообразием возможностей, привычная, знакомая, множество примеров в интернет можно найти, а тут новая библиотека, какие вы видите доводы взять разработчику вашу библиотеку?

Вы знаете, Юрий, я думаю что стандартная библиотеке она на то и стандартная, чтобы решать стандартные задачи. Я же в своём решении целюсь на разработку программных продуктов с точки зрения функциональной безопасности. У меня есть определённый опыт в этом. В частности, я стараюсь полагаться на стандарт функциональной безопасности дорожных транспортных средств ISO-26262, я полностью квалифицировал свой код на правила кодирования MISRA-C++:2008. В том числе, я постарался изящно решить вопрос с выделением динамической памяти, как того требует ISO - т.е. вы можете конфигурировать библиотеку EOOS так, чтобы она выделяла ресурсы ОС из пула каждого менеджера ресурсов, или из динамической кучи. И всё это прозрачно для пользователя. Таким образом мне, например, удалось портировать EOOS в том числе и под FreeRTOS, и собрать FreeRTOS со статическим управлением ресурсами. Т.е. моя цель в том числе и переносимость кода - не только между различными ОС, но и между аппаратными платформами, включая выстаиваемые системы. Я думаю вряд-ли у вас получится что-то написать с использованием стандартной С++ библиотеки под Windows или KasperskyOS, а потом это всё перенести на некий микроконтроллер под управлением FreeRTOS, например. Ну или, как минимум, у вас на микроконтроллере на хватит памяти, или вы не сможете пройти сертификацию. Я же пишу EOOS так, что бы вам по сути не надо было бы ничего другого, только компилятор. Даже стандартная библиотека не нужна, ни Сишная, ни Плюсовая. Так что мои доводы вот примерно такие 🙂

Edited March 13 by Sergey Baigudin

[Yura Beznos]

Сергей, приветствую вновь.

В 13.03.2025 в 13:39, Sergey Baigudin сказал:

Извините, пожалуйста, за задержку с ответом.

Не стоит извиняться, я тут тоже не быстр с ответами, старый добрый формат форума предполагает вдумчивую и содержательную беседу 😀.

Стало только интереснее.

Выходит, если перед проектом среди задач есть:

• функциональная безопасность;
• соответствие ISO-26262;
• портируемость на поддерживаемые библиотекой платформы,

то библиотека будет очень удобна для такого проекта, верно? Может что-то я пропустил? (это мне интересно т.к. разные прототипы когда делаем на KOS, то выбираем возможный инструментарий и с т.з. конструктивной безопасности). Похоже, что данная библиотека подходит для более широкого применения в робототехнике и IoT, помимо automotive. 

А с точки зрения формальной верификации думали применять? Или она будет иметь смысл только уже для конечного кода?

В 13.03.2025 в 13:39, Sergey Baigudin сказал:

Ещё, как известно, KasperskyOS поддерживает POSIX, но мне очень хотелось изучить нативный KOS API и соответственно его использовать. Но если Mutex и Semaphore мне удалось использовать с нативным KOS API, то вот работу с Thread - нет, и мне соответственно пришлось использовать pthread.

Если желание не пропало, то можем тему с использованием своих нитей на KOS развить. Я бы постарался найти или написать примеры демонстрирующие работу.