Кроссплатформенная библиотека 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 развить. Я бы постарался найти или написать примеры демонстрирующие работу.

[Sergey Baigudin]

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

On 3/21/2025 at 2:23 PM, Yura Beznos said:

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

Согласен, договорились! 🤝 Тем более я хотел вдумчиво посмотреть на нативные нити КОС. Посмотрел и даже запустил их, но об этом чуть ниже напишу.

On 3/21/2025 at 2:23 PM, Yura Beznos said:

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

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

то библиотека будет очень удобна для такого проекта, верно? Может что-то я пропустил?

Знаете, я бы не говорил слово "удобна", ибо по себе знаю, что для разработчика использовать новые библиотеки никогда не бывает удобно, особенно с первого раза. Но я действительно очень стараюсь, чтобы моя библиотека была таковой - стараюсь максимально документировать как исходный код библиотеки, так и писать документацию на сайте проекта, стараюсь писать подробную документацию, как собрать проект для конкретной ОС и аппаратной платформы, создаю демонстрационные примеры разработки прикладного ПО с использованием библиотеки EOOS и т.д.

А потому - да, верю, что она может быть удобна для разработки новых портируемых приложений нацеленных на функциональную безопасность в том числе и во встраиваемых системах. А так, ISO-26262 это же по сути порождённый стандарт из основного стандарта по функциональной безопасности IEC-61508, так что я думаю, что EOOS вполне можно использовать и в других направлениях. Я в своё время разрабатывал ПО и для медицинского оборудования по стандарту IEC-62304. И все они примерно об одном и том же. Просто я в автомотиве проработал более 6 лет, и много занимался именно разработкой и квалификацией ПО по ISO-26262, потому оно мне просто ближе. Я его в части 4, 6 и даже 5 - перечитал вдоль и поперёк, и работал по ним, как с точки зрения архитектуры ПО, так и разработки.

On 3/21/2025 at 2:23 PM, Yura Beznos said:

Похоже, что данная библиотека подходит для более широкого применения в робототехнике и IoT, помимо automotive.

Да, конечно, как и написал выше, её применение мне видится очень широким. Тут бы только хватило сил всё это довести до необходимого объёма кодовой базы. Ибо, например, в IoT используется большое количество всевозможных протоколов передачи данных, не говоря уже о драйверах устройств, которые пока в моём случаи не разработаны для проекта EOOS. Но и к этому я стремлюсь, опыт и знания есть, и даже определённые наработки есть.

 

On 3/21/2025 at 2:23 PM, Yura Beznos said:

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

Знаете, я пока даже не думал над этим вопросом. Но вот вы спросили, и я обязательно подумаю! Надо подумать...

On 3/21/2025 at 2:23 PM, Yura Beznos said:

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

Спасибо вам большое! Конечно желание не пропало. Я потому и ответил не сразу, ибо хотелось найти время, чтобы вспомнить проблему и попробовать её ещё раз решить. В итоге я её решил. Вчера вечером залил обновление в master, теперь проект EOOS для KasperskyOS целиком и полностью использует исключительно нативный KOS API. Чуть позже я прогоню сборки EOOS для других систем и выкачу новый релиз.

А проблема была в том, что толи я не могу найти, толи её нет, но в KOS API нет функции join(), а её моя реализация в виде заглушки оказалась не очень верной. Но я нашёл ошибку, и всё сделал. Теперь всё работает, все тест проходят на ура.

Но вопрос к разработчика - куда делась функция а-ля KosThreadJoin(), он конечно у меня остался, ибо функция pthread_join существует же.

 P.S. И, кстати, если уж касаться разработчиков, то помню задавался вопросом, почему функции KosMutexLock() и KosMutexUnlock() ничего не возвращают. Ибо функции KosSemaphoreSignal() и KosSemaphoreWait() возвращают коды ошибок, а mutex нет - странно, неужели не может быть ошибки при захвате mutex? В других системах может быть.