Карантин для динамической памяти ядра Linux

[moncruist]

Интересная статья, хоть я с самого начала статьи подозревал, что такой подход не выстрелит. Но если вы вдруг сумеете преодолеть все вышеописанные проблемы в вашем патче, пожалуйста не забудьте также отправить патчик сюда make-linux-fast-again.com. Всё-таки, даже 1% просадки производительности — это очень больно.

[a13xp0p0v]

На странице make-linux-fast-again перечислены только параметры командной строки ядра, которые относятся к transient execution CPU vulnerabilities.

Этот сайт шуточный. Если падение производительности на 1% — это очень больно для вас в ваших условиях, то стоит заняться профилировкой ядра и юзерспейса под ваш тип рабочей нагрузки.

Кстати, копировать все параметры со странички make-linux-fast-again бессмысленно. Все защиты от уязвимостей CPU и так будут отключены, если просто написать "mitigations=off" :)

[screwer]

Следил за сюжетом ещё в твиттере :)

[Mingun]

Для завершенности не хватает перевода стишка:

Карантин. Попытка №3.
Не появилась. Нет нужды.
Давай, юзай use-after-free,
Как делал всегда ты ;)

[dmitryrf]

Чем такой карантин отличается от постановки возвращенного слаба в конец списка?

[a13xp0p0v]

Отличий много.

SLAB_QUARANTINE рандомизирован. Он намного больше, под него отводится 1/32 часть всей динамической памяти ядра. Поэтому для того, чтобы вытолкнуть из карантина объект, нужен спрей существенно большего объема.

При этом freelist в slab-кэше, мне кажется, может быть совсем коротким. Поэтому изменение положения объекта в нем не сильно повлияет на работу эксплойта.

[dmitryrf]

Понятно, спасибо!