DOS ядра, возможно ли?

[Konstantin Boyko]

Добрый день!

Начал разбираться с KOS, очень заинтересовала эта тема.
Сразу появились и вопросы:

Кибериммунитет.

Если взять определение иммунитета в медицинском аспекте, то это ответная !защитная! реакция живого организма на некую угрозу.
Причем защитная реакция может концептуально подразумевать не только "запретить", но и при необходимости "уничтожить".

Как обстоит дело в KOS в концепции "уничтожить"? Вы задумывались о такой парадигме?

Возьмем пример с DOS (deny of service) ядра KOS.
Допустим, есть некий вредоносный процесс или группа процессов (сущностей), которые посылают IPC-запросы с высокой скоростью (пусть даже заранее невалидные).
Судя по документации, ядро будет обращаться за разрешением к KSM каждый раз. А раз так, то это типичное "bottleneck".
Что будет, когда таких запросов миллионы? Повышенная нагрузка на CPU с неизбежным DOS.

Есть ли механизмы в ядре (или в KSM), позволяющие обнаружить подобное поведение и произвести уничтожение сущности (процесса)?
Можно ли ограничить количество запросов в единицу времени для каждой сущности и как-то этим управлять?
Т.е. может ли ядро себя защитить?

Где почитать? Есть ли гайды?

Спасибо!

[Александр Лифанов]

Константин, добрый день. Давайте разбираться вместе.
"Я вам не скажу за всю Одессу", поэтому буду отвечать исходя из знаний по KasperskyOS Community Edition.

Сначала про "уничтожить". Для начала надо иметь, что уничтожать. Процессы сами по себе в системе не появляются, их должно запустить что-то существующее. Соответственно, отработка события execute с таким src и dest должна быть явно разрешена. Естественно, разработчик исходного ПО имя вредоносного процесса заранее не знает и разрешить не может (вынесем за скобки обсуждение варианта grant all).

Как подменить исполняемый бинарник соседнего процесса в оперативной памяти - я не знаю. Он находится на другой странице виртуальной памяти, защищен аппаратными механизмами MMU, к тому же оба процесса находятся в user space, не в kernel. Ну, допустим, нашелся какой-то механизм (например, нештатное использование штатного кода, нет контроля подаваемого снаружи параметра частоты события) -> процесс начинает часто дергать KSM запросами (какими, кстати?).

В этом случае следует учесть два фактора. (1) приоритет внутренних процессов ОС (например, отработки таймеров, прерываний) заведомо выше приоритета запросов из user space. Т.е. такой вариант "DOS" съест остатки процессорного времени пользовательских программ, но не системы. Соответственно, ОС работать будет, но, естественно, медленнее. На деле это поведение не отличается от, например, просто программистской ошибки. (2) на деле, сейчас в планах реализации находится квотирование ресурсов, выделяемых процессу системой (втч, процессорного времени). После реализации этой фичи процесс чисто технически не сможет съесть больше выделенного ему, например, 50% процессорного времени.