Vladimir Malygin

Добрый день. Мы постоянно расширяем поддержку аппаратных платформ, в том числе работаем и с отечетсвенными производителями. Проголосуйте за конкретные платформы на нашей продуктовой странице https://kas.pr/kosfeatures , или если у вас есть конкретные предложения в рамках своих проектов напишите нам и мы будем рады обсудить с вами формы сотрудничества и поддержки. А пока предлагаем вам поработать с нашей публичной SDK KasperskyOS Community Edition, которую можете потестировать в QEMU или на Raspberry Pi.

На данный момент драйвер блочного устройства всегда запускается отдельным процессом. Поэтому в прикладную программу предлагается вкомпилировать только библиотеки VFS и реализации требуемых файловых систем. Именно так устроен пример embedded_vfs. Статическая линковка с используемым компонентом удобна для отладки, т.к. всё работает в одном адресном пространстве. Также можно рассчитывать на более быструю обработку вызовов, т.к. нет временных затрат на IPC и работу KSM-модуля. Однако с точки зрения безопасности всегда рекомендуется использовать компонент по IPC, в виде отдельного процесса.

Развертывание KasperskyOS Community Edition в docker не накладывает ограничений на формирование образа файловой системы в KOS CE решении.

Чтобы получить список всех блочных устройств, которые доступны сущности, она должна позвать API BlkDevEnumPorts. API зовется в цикле, пока не будет возвращен код BLKDEV_ENOENT. char portName[256] = { 0 }; do { rc = BlkDevEnumPorts(0, sizeof(portName), portName); if (rc == BLKDEV_EOK) { printf("Found port %s\n", portName); } } while (rc != BLKDEV_ENOENT); Cуществует функция BlkDevLookup, позволяющая найти блочное устройство, соответствующее определенному паттерну (например, по GUID партиции). Что касается паттерна того, как будет называться какое устройство — на текущий момент это зависит от драйвера, при регистрации устройств каждый драйвер сам назначает имя.

Да, есть. Если у вас имеется конкретный проект, то напишите нам о нем и совместно поищем оптимальное решение для вашей задачи, вплоть до повышения приоритета разработки под Risc-V.

Реальный доступ к файлу в этой схеме будет происходить только внутри VFS. То есть, будет 2 связи: A <-> VFS и B <-> VFS . Дальнейшие транзитивные связи VFS к blkdev и pcie тут опускаю — это зависит от архитектуры. Каждый из перечисленных вызовов — отдельное IPC. Возможно сделать так, что в A будет влинкован VFS и, таким образом, A будет полноценным VFS-ом и для своего клиентского кода и для сущности B. Тогда будет только 1 связь A <-> B. В этом случае, все вызовы в А будут локальными вызовами, без IPC, а в B будут уходить через IPC к A.

Если сервер завершил исполнение по любой причине, клиент продолжит исполняться, получив код ошибки rcNotConnected. Таким образом, необходимо обрабатывать ошибки транспортного уровня, которые возвращает системный вызов CallEx. Так как обычно прикладные процессы не обращаются к системным вызовам напрямую, а используют сгенерированные обертки NK, эта ошибка транспортного уровня будет преобразована в соответствующий код возврата NK, а именно NK_ENOTCONN.

В KasperskyOS пока нет четкого соглашения по иерархии каталогов, все сильно зависит от конкретного продукта, разработанного на ее основе. «/c» — произвольная точка монтирования.

В KasperskyOS изначально не предполагалось понятия пользователей и ассоциированных с ними контекстов безопасности. Большинство решений на KasperskyOS используют подход "песочницы". Каждому приложению, условной группе процессов, предоставляется свой ограниченный срез файловой системы или отдельный раздел. Приложение не может получить доступ к другой партиции благодаря политикам KSS.

Примеры использования dhcpcd для настройки сетей есть в нескольких примерах, поставляемых с SDK, например, в multi_vfs_dhcpcd. Параметры сетей указываются в файле /etc/dhcpcd.conf, но путь может быть переопределен с помощью аргументов командной строки для сущности Dhcpcd, устанавливаемых в сущности Env.

Зависит от версии ядра операционной системы. Из узконаправленной системы для запуска приложений KasperskyOS постепенно превращается в полноценную платформу и выход такой возможности не заставит себя долго ждать.

В примерах, включенных в KasperskyOS SDK Community Edition, для настройки сетевых интерфейсов используется сущность dhcpcd, поставляемая в комплекте с SDK. Также есть возможность работать с сетевыми интерфейсами напрямую из кода приложения.

Шифрование IPC сообщений без модификации прикладного кода в KasperskyOS невозможно. Конфиденциальность передаваемых в сообщениях данных обеспечивается аппаратной изоляцией процессов друг от друга. Шифрование сообщений в рамках одной физической системы выглядит непрактичным и несет большие накладные расходы.

С точки зрения прикладных программ – да, регулярно этим занимаемся и POSIX совместимость этому сильно помогает. Что касается драйверов в KasperskyOS нет слоя совместимости с Linuх и при создании драйверов необходимо работать со собственными API.

KasperskyOS Community Edition предоставляет единственный метод отладки, с использованием GDB-stub, встроенного в виртуальную машину QEMU. Этот метод отладки весьма ограничен. Например, QEMU GDB-stub не знает ничего о процессах и потоках гостевой операционной системы. В ядре KasperskyOS уже поддержан полноценный GDB-stub. Включение его в поставку KasperskyOS Community Edition обсуждается. Если вы работаете со своим проектом на KasperskyOS, то опишите проект и вставшие задачи отладки, и мы найдем решение.