А как у вас единицы юзер-спейса на исполнение запускаются? Неужели без участия ядерного кода? Для этого не нужен интерфейс к ядру?
системные вызовы (send/recv/reply) - это IPC примитивы. Это “глубокое” API, если описывать его более абстрактно. В качестве аргумента в эти IPC примитивы передается идентификатор вызова на системе. Ядро исполняет больше функций, чем просто реализация IPC примитивов. И да, запуск user-space-а происходит при участии ядерного кода - как минимум, процесс должен быть соотнесен с вызовами, которые он будет отрабатывать. А дальше объем ядерного участие в старте процесса рознится. В KasperskyOS, например, создание страничных преобразований делается в ядре, а вот парсинг ELF-а в отдельном процессе на user-space. А в seL4 страничные преобразования, если мне не изменяет память, также готовятся одним из user-space процессов. В HongMeng, например, неясно где происходит парсинг elf-а, но кажется они в ядро и файловую систему втянули. А в seL4 или KasperskyOS файловая система - это не часть ядра.
Если у вас абсолютный приоритет - это какая-то абстрактная безопасность Операционной Системы и ее ядра - это не значит что можно абстрагироваться от смысла существования этой Операционной Системы. Операционная Система, которую никто не использует и которая никому не нужна, будет совершенно безопасна - это и есть вырожденный случай.
Не уверена, что до конца понимаю Ваш аргумент. Кажется, таких тезисов в статье не звучало.
Даже если рассматривать только уязвимости связанные с системными вызовами [исключая динамически линкуемые модули] - это уже какой-то ограниченный взгляд получается, а если их еще и сократить до 3-х вызовов, случай, кажется, совсем вырожденный, не очень понятно что вы хотите получить в этом направлении. Ну в микроядрах, даже коммерчески используемых, не встречала динамически линкуемых модулей. Обычно из-за ограниченной ядерной функциональности, весь сторонний и расширяемый код оказывается на user-space. И да, в микроядрах 3-10 системных вызова (syscall-а), но 30-150 ядерных функции (доступных через системные вызовы). И микроядерная система может предоставлять всю ту же функциональность, что и монолит. Поэтому не понимаю, чем случай является вырожденным. Буду благодарна за пояснение.
Как вы анализируете связанные с таким способом расширения функциональности ядра (добавления драйверов) уязвимости? Загрузка модулей в ран-тайм вызывает несколько интересных историй:
API для загрузки модуля ядра всегда вызывает повышенный интерес злоумышленника
Добавление ядерной функциональности в ран-тайме еще связано с проблемой владения кода. Если исходный код доступен и принадлежит ядру, как в случае Linux, то подгрузка не загруженного ранее модуля, не вызывает серьезные ограничения по статическому анализу, формальной верификации и тестированию функциональности. А если это сторонний модуль, который правит другой разработчик и поставляет в виде blob-ов, то системы нередко возводят объемные конструкции, чтобы создать изоляцию вокруг этого кода (run-time service isolation в os x, например; старый ndis в windows). Ну и проверяют его в своих store-ах насколько возможно
Вроде как ядро которое способно в рантайме принимать новые модули (новые части себя) нельзя назвать монолитом, как вы считаете? В статье не давали определения микроядра и монолита. Иногда из-за загружаемых в ядро модулей говорят не о монолитах, а о гибридных ядрах. Однако, и такая терминология вызывает споры и есть описание, что Windows - это гибрид, а Linux - монолит с загружаемыми модулями. В целом любая работающая система не является в чистом виде реализацией какого-то одного архитектурного паттерна, а представляет собой сложный компромисс во имя достижения каких-то определенных нефункциональных характеристик. В микроядра заталкивают больше функционала чем в классический sel4 во имя производительности. В монолитах из ядер выносят функционал во имя безопасности и гибкости. И чистый монолит и чистое микроядро - сугубо академический продукт. Практически любая операционная система называется монолитом или микросервисом с натяжкой, они все гибриды.
-Wuninitialized, который включен в -Wall, не очень точен по нашим наблюдениям. Коллега предложил пример, где ворнинг не стреляет, а проблема присутствует https://godbolt.org/z/bY898jq98. Более детальные сведения, наверное, только из исходников gcc/clang получится извлечь. По общим соображениям warning-и (wuninitialized) процессят во фронт-енде, а кодогенерация (vars-autoinit) в мидл-енде/бэк-енде.
Переменных на стеке и в heap-е значительно больше, чем из сегмента .data и .bss. Ну и неинициализированные данные из .bss все инициализируются нулями (https://refspecs.linuxfoundation.org/LSB_1.1.0/gLSB/specialsections.html). А у компилятора Си есть опция vars-autoinit, которая зануляет и стековые переменные и данные из кучи, но это снижает производительность (и именно поэтому не включено по умолчанию. и именно поэтому Си в стандарте нет обязательного зануления)
Спасибо за развернутый комментарий. Попробую ответить также развернуто. (1) Статья не про безопасную ОС. Я много работала по процессам безопасной разработки и хотела поделиться опытом, как можно разрабатывать ПО, которое и включает все необходимые харденинги и при этом не будет терять в производительности. Сочувствую, если заголовок ввел вас в заблуждение. (2) Доверять данным можно только после проверки их подлинности и целостности, разделение на процессы не предполагает удаление криптографических проверок. Однако, если у вас есть процесс, которому дали права и на взаимодействие с сетевой картой, и на работу с базой платежей, то взлом такого процесса по сети будет более опасным сценарием, чем взлом процесса, который только принимает данные и парсит их. Да, данные в этот момент будут поддельными. Но arbitrary code execution в процессе с доступом к базе платежей не случится. Чтоб не быть голословной, у Bishop в computer security такой пример рассматривается. А еще это выполнение принципов конструктивной безопасности, которые есть и у нас в ГОСТ (ГОСТ Р 72118-2025), и в академической статье 75ого года (https://www.princeton.edu/~rblee/ELE572Papers/Fall04Readings/ProtectionInfo_Saltzer.pdf). (3) То, что в американских правительственных структурах рекомендуют использовать ПО, написанное на memory-safe языках, не должно означать, что мы сознательно против этого. В CWE-top (https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html) постоянно фигурируют oob, а это как раз spatial memory safety. При этом, безусловно, MSL (memory-safe-languages) не панацея. И Google не спешит свои старые компоненты на Rust переписывать, и мы недавно долго решались как обезопасить парсинг ELF-а и все же оставили его на Си (https://habr.com/ru/companies/kaspersky/articles/906458/). Но MSL для некоторых задач и правда снижает число уязвимостей
Спасибо за правильный вопрос. Почитать про обработку прерываний в КОСи можно в документации - https://support.kaspersky.com/help/KCE/1.3/ru-RU/libkos_irq_api.htm. Вкратце, если сравнивать с Линуксом, то в КОСи вся обработка - это bottom half, но в выделенном real-time-овом потоке. При обработке запрещены все блокирующие вызовы. Доставка прерываний на тот же вектор на время обработки прерывания запрещена на уровне контроллера прерываний. Это конечно медленнее, но MSI уже на подходе.
В тех ИТ компаниях, где работала, тимлид был ближайший менеджер к разработчику. И его должностные обязанности перечисляла. Встречала компании, где в дополнение к тимлиду вводится HR-партнер, который призван вроде как мотивировать и решать конфликты, но даже план развития (на assessment-е), не говоря уж о 1:1, был далеко от HR-партнера. Так что не до конца поняла описанную конструкцию: если тимлид не до конца менеджер, то кто менеджер? unit manager который объединяет тимлидов и является следующим уровнем?
Вот согласна, что в архитекторах и лидах лучше. Тимлидом, по моим наблюдениям, становятся
из-за желания карьерного роста,
из-за отсутствия выделенных экспертных/архитекторских позиции (не все так прекрасны как ЛК),
из-за "кто если не я" (например, тимлид принимает неверные решения, не слушая команду, команда понемногу начинает разбегаться, убегает и тимлид. и вот вы понимаете кто_если_не_я спасет команду; или прекрасный тимлид идет на повышение, никто не хочет из команды быть тимлидом, но вы понимаете что кому-то прийдется стать и кто_если_не_я),
из-за желания попробовать новые управленческие практики (а мне кажется команда может стать бирюзовой; а если сделать прям нормальный scrum; всегда хотел попробовать lean, ...)
"Поэтому чтобы тимлид занимался тем, что может выполнить только он, другие менеджерские задачи, не связанные со спецификой деятельности его команды, должны отойти соответствующим ролям" - с такой конфигурацией я не сталкивалась. Чаще сталкивалась, когда технические решения уходят от тимлида архитектору или эксперту. Ваш вариант тоже прекрасен. Это реальная компания или идеальная?
Про погружение тимлида в архитектуру и дизайн. (1) если у тимлида 5 человек, то он тратит время на этих 5 человек: проревьювить Олю, разобраться с грустью у Пети, отрефлексировать предложение Васи, объяснить основы secure coding Жене, починить пайплайн Тимофею, (2) если у тимлида компонент, то он должен поговорить с суппортом про текущие проблемы, договориться о ресурсах инфраструктуры на тестирование, обсудить интеграционные тесты, сделать статусную презентацию по движению компонента. Это не очень много, но время занимает. И значит меньше времени, чтобы нарисовать flow в деталях, обновить информацию о принятых архитектурных решениях, сравнивать разные варианты реакции на событие по скорости, проверить отказоустойчивость компонента, выбрать из fail-open vs fail-close vs fail-safe vs fail-secure и последовательно продумать внедрение подхода.... и пр и пр. Тимлид чаще всего знает дизайн своего компонента (причем чаще всего потому, что его сам писал), но его не хватает чтобы развивать этот дизайн, потому что у него слишком много задач. Тимлид у нас чаще всего еще и техлид. Именно поэтому у нас столько непродуманностей в дизайне, именно поэтому у нас столько непочиненных процессов.
Мопед не мой. И статистика не моя. Можно зайти на Хабр карьеру, посмотреть их новую стату и задать им вопросы (регистрация бесплатна, но они хотят знать вашу зарплату).
В целом внутри тоже REST. Ибо внутренние разработчики — они тоже разработчики. HTTP проще отлаживать, проще кодить. Синхронное взаимодействие в целом легче понимать. Но, конечно, есть обстоятельства, когда гарантии доставки (от использования очередей) оказываются более значимыми чем удобство использования.
системные вызовы (send/recv/reply) - это IPC примитивы. Это “глубокое” API, если описывать его более абстрактно. В качестве аргумента в эти IPC примитивы передается идентификатор вызова на системе. Ядро исполняет больше функций, чем просто реализация IPC примитивов. И да, запуск user-space-а происходит при участии ядерного кода - как минимум, процесс должен быть соотнесен с вызовами, которые он будет отрабатывать. А дальше объем ядерного участие в старте процесса рознится. В KasperskyOS, например, создание страничных преобразований делается в ядре, а вот парсинг ELF-а в отдельном процессе на user-space. А в seL4 страничные преобразования, если мне не изменяет память, также готовятся одним из user-space процессов. В HongMeng, например, неясно где происходит парсинг elf-а, но кажется они в ядро и файловую систему втянули. А в seL4 или KasperskyOS файловая система - это не часть ядра.
Не уверена, что до конца понимаю Ваш аргумент. Кажется, таких тезисов в статье не звучало.
trade-off гибкость vs простота. глубокие вызовы очень хорошо решают проблему стабильности api
Опиралась на данные в https://github.com/j00ru/windows-syscalls?tab=readme-ov-file.
API для загрузки модуля ядра всегда вызывает повышенный интерес злоумышленника
Добавление ядерной функциональности в ран-тайме еще связано с проблемой владения кода. Если исходный код доступен и принадлежит ядру, как в случае Linux, то подгрузка не загруженного ранее модуля, не вызывает серьезные ограничения по статическому анализу, формальной верификации и тестированию функциональности. А если это сторонний модуль, который правит другой разработчик и поставляет в виде blob-ов, то системы нередко возводят объемные конструкции, чтобы создать изоляцию вокруг этого кода (run-time service isolation в os x, например; старый ndis в windows). Ну и проверяют его в своих store-ах насколько возможно
Совершенно согласна. Еще бы у всех пользователей новые arm-ы были. PAC появился в arm 8.3 :( Но стоило дописать, Вы правы.
-Wuninitialized, который включен в -Wall, не очень точен по нашим наблюдениям. Коллега предложил пример, где ворнинг не стреляет, а проблема присутствует https://godbolt.org/z/bY898jq98. Более детальные сведения, наверное, только из исходников gcc/clang получится извлечь. По общим соображениям warning-и (wuninitialized) процессят во фронт-енде, а кодогенерация (vars-autoinit) в мидл-енде/бэк-енде.
Не занулятся, вы правы. Спасибо за уточнение.
Переменных на стеке и в heap-е значительно больше, чем из сегмента .data и .bss. Ну и неинициализированные данные из .bss все инициализируются нулями (https://refspecs.linuxfoundation.org/LSB_1.1.0/gLSB/specialsections.html). А у компилятора Си есть опция vars-autoinit, которая зануляет и стековые переменные и данные из кучи, но это снижает производительность (и именно поэтому не включено по умолчанию. и именно поэтому Си в стандарте нет обязательного зануления)
Да, вы правы. Хорошая функциональность. Ее добавление будет рассмотрено в будущих релизах
Спасибо за развернутый комментарий. Попробую ответить также развернуто. (1) Статья не про безопасную ОС. Я много работала по процессам безопасной разработки и хотела поделиться опытом, как можно разрабатывать ПО, которое и включает все необходимые харденинги и при этом не будет терять в производительности. Сочувствую, если заголовок ввел вас в заблуждение. (2) Доверять данным можно только после проверки их подлинности и целостности, разделение на процессы не предполагает удаление криптографических проверок. Однако, если у вас есть процесс, которому дали права и на взаимодействие с сетевой картой, и на работу с базой платежей, то взлом такого процесса по сети будет более опасным сценарием, чем взлом процесса, который только принимает данные и парсит их. Да, данные в этот момент будут поддельными. Но arbitrary code execution в процессе с доступом к базе платежей не случится. Чтоб не быть голословной, у Bishop в computer security такой пример рассматривается. А еще это выполнение принципов конструктивной безопасности, которые есть и у нас в ГОСТ (ГОСТ Р 72118-2025), и в академической статье 75ого года (https://www.princeton.edu/~rblee/ELE572Papers/Fall04Readings/ProtectionInfo_Saltzer.pdf). (3) То, что в американских правительственных структурах рекомендуют использовать ПО, написанное на memory-safe языках, не должно означать, что мы сознательно против этого. В CWE-top (https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html) постоянно фигурируют oob, а это как раз spatial memory safety. При этом, безусловно, MSL (memory-safe-languages) не панацея. И Google не спешит свои старые компоненты на Rust переписывать, и мы недавно долго решались как обезопасить парсинг ELF-а и все же оставили его на Си (https://habr.com/ru/companies/kaspersky/articles/906458/). Но MSL для некоторых задач и правда снижает число уязвимостей
Спасибо за правильный вопрос. Почитать про обработку прерываний в КОСи можно в документации - https://support.kaspersky.com/help/KCE/1.3/ru-RU/libkos_irq_api.htm. Вкратце, если сравнивать с Линуксом, то в КОСи вся обработка - это bottom half, но в выделенном real-time-овом потоке. При обработке запрещены все блокирующие вызовы. Доставка прерываний на тот же вектор на время обработки прерывания запрещена на уровне контроллера прерываний. Это конечно медленнее, но MSI уже на подходе.
В тех ИТ компаниях, где работала, тимлид был ближайший менеджер к разработчику. И его должностные обязанности перечисляла. Встречала компании, где в дополнение к тимлиду вводится HR-партнер, который призван вроде как мотивировать и решать конфликты, но даже план развития (на assessment-е), не говоря уж о 1:1, был далеко от HR-партнера. Так что не до конца поняла описанную конструкцию: если тимлид не до конца менеджер, то кто менеджер? unit manager который объединяет тимлидов и является следующим уровнем?
Ну часть историй отваливается все же. Область ответственности у младшего императора меньше чем у старшего. Иначе бы он был старшим.
Вот согласна, что в архитекторах и лидах лучше. Тимлидом, по моим наблюдениям, становятся
из-за желания карьерного роста,
из-за отсутствия выделенных экспертных/архитекторских позиции (не все так прекрасны как ЛК),
из-за "кто если не я" (например, тимлид принимает неверные решения, не слушая команду, команда понемногу начинает разбегаться, убегает и тимлид. и вот вы понимаете кто_если_не_я спасет команду; или прекрасный тимлид идет на повышение, никто не хочет из команды быть тимлидом, но вы понимаете что кому-то прийдется стать и кто_если_не_я),
из-за желания попробовать новые управленческие практики (а мне кажется команда может стать бирюзовой; а если сделать прям нормальный scrum; всегда хотел попробовать lean, ...)
"Поэтому чтобы тимлид занимался тем, что может выполнить только он, другие менеджерские задачи, не связанные со спецификой деятельности его команды, должны отойти соответствующим ролям" - с такой конфигурацией я не сталкивалась. Чаще сталкивалась, когда технические решения уходят от тимлида архитектору или эксперту. Ваш вариант тоже прекрасен. Это реальная компания или идеальная?
Про погружение тимлида в архитектуру и дизайн. (1) если у тимлида 5 человек, то он тратит время на этих 5 человек: проревьювить Олю, разобраться с грустью у Пети, отрефлексировать предложение Васи, объяснить основы secure coding Жене, починить пайплайн Тимофею, (2) если у тимлида компонент, то он должен поговорить с суппортом про текущие проблемы, договориться о ресурсах инфраструктуры на тестирование, обсудить интеграционные тесты, сделать статусную презентацию по движению компонента. Это не очень много, но время занимает. И значит меньше времени, чтобы нарисовать flow в деталях, обновить информацию о принятых архитектурных решениях, сравнивать разные варианты реакции на событие по скорости, проверить отказоустойчивость компонента, выбрать из fail-open vs fail-close vs fail-safe vs fail-secure и последовательно продумать внедрение подхода.... и пр и пр. Тимлид чаще всего знает дизайн своего компонента (причем чаще всего потому, что его сам писал), но его не хватает чтобы развивать этот дизайн, потому что у него слишком много задач. Тимлид у нас чаще всего еще и техлид. Именно поэтому у нас столько непродуманностей в дизайне, именно поэтому у нас столько непочиненных процессов.
Мопед не мой. И статистика не моя. Можно зайти на Хабр карьеру, посмотреть их новую стату и задать им вопросы (регистрация бесплатна, но они хотят знать вашу зарплату).