Относительно кибериммуитета - KasperskyOS CE предоставляет возможность разбивать приложение на сущности, обмениваться между сущностями по IPC и контролировать при помощи psl правил какая сущеность к каким ресурсам имеет доступ (Собственно это и относится к кибериммунитету). Есть возможность писать более сложные правила. Например, в нашей текущей реализации communication, принимающая команды по MQTT не имеет доступа к файловой системе. Если сущность communication будет компрометирована, то это все равно получить доступ к ее конфигурации будет затруднительно. Есть отдельная сущность configuration_server, которая имеет доступ к конфигурации MQTT клиента, но она не имеет доступа к сети и доступна только через IPC. Детально будет в следующей статье.
Мы хотели потрогать KasperskyOS CE вне стен ЛК в задаче, которая чуть сложнее, чем примеры из SDK. На текущий момент впечатления следующие:
Позитивное: 1. KasperskyOS компактная 2. Основная идея, которая заложена в KasperskyOS - что если разбить программу на части и контролировать взаимодействие частей, то при взломе одного компонента не будет компрометирована все система и дальше ломать будет по-прежнему сложно. 3. Есть POSIX и в версии SDK 1.1.1 появился свежий g++ 9.2, который поддерживает C++17/C++20. Это упрощает перенос библиотек.
Сложности: 1. Писать и отлаживать psl правила трудоемко. 2. Из коробки в SDK 1.1.1 нет ничего для фильтрациии сетевых пакетов 3. Поддержки WiFi - в SDK 1.1.1 еще нет.
Относительно real-time - мы еще не мерили параметры, скорее всего достижимо только мягкое реальное время. Планируем померить. Будут результаты - опубликуем.
Более детально про использование камеры, распознавание внутри KasperskyOS и почему мы хотим его использовать, обеспечение приватности камер и противостояние взлому будет в следующей статье.
На роботе нет ни камеры ни лидара. IP камеры на потолке. Программа распознавания и позиционирования на отдельном PC. Она же выдаёт на робот команды управления по MQTT. В следующей версии от PC избавимся и все будет на роботе.
С блоками реконфигурации пришлось разбираться, когда разбирали протокол обмена между IDE и forte. Обработка ошибок в IEC 61499 - есть механизм информирования последующего блока об ошибке в предыдущем, построенный на основе использования входов QI/QO и выхода статуса для детальной информации об ошибке. Многие блоки стандартной библиотеки имеют и обрабатывают QI/QO. В принципе можно расширить булевские QI/QO до целочисленного качества, как в OPC. С экспортом в xml разбирались - писали дополнительные инструменты анализа проекта.
Для оталадки в IDE 4diac есть возможность просматривать значения входов/выходов событий и данных (в меню по правой клавише для входа/выхода есть данных команда Watch). Можно изменять в динамике переменные из IDE. Точек останова в IDE нет, но можно руками инциировать события (в меню по правой клавише для входа событий есть команда TrigerEvent) - работает похоже на пошаговое выполнение. Если заглянуть глубже, то можно подключаться внешнием отладчиком или вставлять отладку к forte т.к. оно на С++.
Да. Одно приложение можно "размазать" на несколько ПЛК и работать, как с единым целым. Функциональные блоки можно назначать на ПЛК входящие в систему.
Нет никакого смысла обсуждать переход на другие платформы. Что мешает учить Copilot на коде выложенном в другом месте? Трафик с других платформ, который генерируется одноразовым скачиванием? Возможным решением могла бы стать модификация открытых лицензий путем добавления явного запрета на использование исходного кода для обучения AI. Возможно токсичных по примеру GPL.
Вопрос в том является ли причиной кипеша нарушение "clean room", "derivative work" и т.д.. или дело в подрыве финансовых основ опенсорс. Успешнвый опенсорс - обычно это не бесплатный, а живущий за сложности использования и счет сервисов по поддержке. Если становится возможно значительно удешевить поддержку/доработку/создание аналога, то возможно это подорвет бизнес модель опенсорc...
Если серьезно подходить, то одним пакетным менеджером даже с собственными пакетами ограничиваться недостаточно. Один пакет тащит другой, а тот следующий. По-хорошему надо SBOM генерировать, а на выявленные компоненты анализатор уязвимостей, а потом смотреть, что с тем ужасом, который получится делать.
Интересно и знакомо. Любопытно насколько часто Вы обновляете материал в курсе? Практику от набора к набору новую или переодические обновления материала после нескольких курсов?
Если упоминается возможность читать текст, как достижение, то похоже технология еще на стадии очень раннего прототипа. Интересно, на какое расстояние и как они объекты проецировать могут?
Информация
В рейтинге
Не участвует
Зарегистрирован
Активность
Специализация
Embedded Software Engineer, System Software Engineer
Относительно кибериммуитета - KasperskyOS CE предоставляет возможность разбивать приложение на сущности, обмениваться между сущностями
по IPC и контролировать при помощи psl правил какая сущеность к каким ресурсам имеет доступ (Собственно это и относится к кибериммунитету). Есть возможность
писать более сложные правила. Например, в нашей текущей реализации communication, принимающая команды по MQTT не имеет доступа к файловой системе. Если сущность communication будет компрометирована, то это все равно получить доступ к ее конфигурации будет затруднительно. Есть отдельная сущность
configuration_server, которая имеет доступ к конфигурации MQTT клиента, но она не имеет доступа к сети и доступна только через IPC. Детально будет в следующей статье.
Мы хотели потрогать KasperskyOS CE вне стен ЛК в задаче, которая чуть сложнее, чем примеры из SDK. На текущий момент впечатления следующие:
Позитивное: 1. KasperskyOS компактная 2. Основная идея, которая заложена в KasperskyOS - что если разбить программу на части и контролировать взаимодействие частей, то при взломе одного компонента не будет компрометирована все система и дальше ломать будет по-прежнему сложно. 3. Есть POSIX и в версии SDK 1.1.1 появился свежий g++ 9.2, который поддерживает C++17/C++20. Это упрощает перенос библиотек.
Сложности: 1. Писать и отлаживать psl правила трудоемко. 2. Из коробки в SDK 1.1.1 нет ничего для фильтрациии сетевых пакетов 3. Поддержки WiFi - в SDK 1.1.1 еще нет.
Относительно real-time - мы еще не мерили параметры, скорее всего достижимо только мягкое реальное время. Планируем померить. Будут результаты - опубликуем.
Более детально про использование камеры, распознавание внутри KasperskyOS и почему мы хотим его использовать, обеспечение приватности камер и противостояние взлому будет в следующей статье.
В версии SDK 1.1.1 только Raspberry PI 4 и возможность запуска в QEMU.
На роботе нет ни камеры ни лидара. IP камеры на потолке. Программа распознавания и позиционирования на отдельном PC. Она же выдаёт на робот команды управления по MQTT. В следующей версии от PC избавимся и все будет на роботе.
С блоками реконфигурации пришлось разбираться, когда разбирали протокол обмена между IDE и forte. Обработка ошибок в IEC 61499 - есть механизм информирования последующего блока об ошибке в предыдущем, построенный на основе использования входов QI/QO и выхода статуса для детальной информации об ошибке. Многие блоки стандартной библиотеки имеют и обрабатывают QI/QO. В принципе можно расширить булевские QI/QO до целочисленного качества, как в OPC. С экспортом в xml разбирались - писали дополнительные инструменты анализа проекта.
Для оталадки в IDE 4diac есть возможность просматривать значения входов/выходов событий и данных (в меню по правой клавише для входа/выхода есть данных команда Watch). Можно изменять в динамике переменные из IDE. Точек останова в IDE нет, но можно руками инциировать события (в меню по правой клавише для входа событий есть команда TrigerEvent) - работает похоже на пошаговое выполнение. Если заглянуть глубже, то можно подключаться внешнием отладчиком или вставлять отладку к forte т.к. оно на С++.
Да. Одно приложение можно "размазать" на несколько ПЛК и работать, как с единым целым. Функциональные блоки можно назначать на ПЛК входящие в систему.
Нет никакого смысла обсуждать переход на другие платформы. Что мешает учить Copilot на коде выложенном в другом месте? Трафик с других платформ, который генерируется одноразовым скачиванием? Возможным решением могла бы стать модификация открытых лицензий путем добавления явного запрета на использование исходного кода для обучения AI. Возможно токсичных по примеру GPL.
Вопрос в том является ли причиной кипеша нарушение "clean room", "derivative work" и т.д.. или дело в подрыве финансовых основ опенсорс. Успешнвый опенсорс - обычно это не бесплатный, а живущий за сложности использования и счет сервисов по поддержке. Если становится возможно значительно удешевить поддержку/доработку/создание аналога, то возможно это подорвет бизнес модель опенсорc...
Интересно насколько это ядро Zircon похоже на минималистичное L4.
Если серьезно подходить, то одним пакетным менеджером даже с собственными пакетами ограничиваться недостаточно. Один пакет тащит другой, а тот следующий. По-хорошему надо SBOM генерировать, а на выявленные компоненты анализатор уязвимостей, а потом смотреть, что с тем ужасом, который получится делать.
Интересно и знакомо. Любопытно насколько часто Вы обновляете материал в курсе? Практику от набора к набору новую или переодические обновления материала после нескольких курсов?
Если упоминается возможность читать текст, как достижение, то похоже технология еще на стадии очень раннего прототипа. Интересно, на какое расстояние и как они объекты проецировать могут?