LINUX.ORG.RU

По поводу избирательного применения kpti для разных процессов

 , , ,


0

3

Планируется ли впиливать такие костыли в ядро Linux, чтобы некоторые процессы можно было б запускать с запатченным от meltdown механизмом системных вызовов, а некоторые можно было б и с незапатченным?

Обычно память ядра замаплена в адресное пространство процесса, и суть этого meltdown в том, что можно спекулятивно эту память читать, а потом по времени доступа к какой-то другой памяти (из-за кэширования) косвенно определять, что именно прочиталось. И, если я все правильно понял, патч, закрывающий данную дыру, просто отключает маппинг памяти ядра в адресное пространство процесса, оставляя лишь некий минимальный функционал, которого достаточно чтобы опять замапить-размапить ядро в адресное пространство на время исполнения системного вызова. Так почему не сделать так, чтобы запускаемые от имени определенного пользователя процессы работали без этих защитных механизмов? Например, пускать postgresql без kpti, а всякие там браузеры уже с kpti т.к. они выполняют недоверенный код. Опция nopti умеет только глобально эту защиту отключать для всех процессов.

Кроме того, некоторые сервера работают в пространстве ядра, nfs-kernel-server например. Если б можно было легко перенести postgresql в кернелспейс, там будет еще меньше накладных расходов т.к. не надо будет ring0<->ring3 переходов делать, как это происходит с обычными процессами.

Перемещено tailgunner из development

★★★★★

И вообще, каким способом это было б легче всего делать? Типа чтобы запущенные каким-то конкретным пользователем процессы были с kpti, а каким-то другим пользователем - без kpti? Или тут через cgroups можно что-нибудь придумать?

SZT ★★★★★
() автор топика

Аппаратно пофиксят же, большинство хомячков что-то там попроцессно переключать не будут всё равно.

anonymous
()
Ответ на: комментарий от anonymous

Аппаратно пофиксят то само собой, но на данный момент нужно ж как-то жить с этими дырявыми процессами

SZT ★★★★★
() автор топика

Такая возможность теоретически вообще возможна? Ты не видишь препятствий для предложенной тобой модели? Я ни на что не намекаю, просто любопытно.

I-Love-Microsoft ★★★★★
()

Такой патч делают, будет ли он в ядре - даже Линус пока не знает.

Если б можно было легко перенести postgresql в кернелспейс, там будет еще меньше накладных расходов

epic_facepalm.bmp

tailgunner ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Не вижу причин, по которым это должно быть невозможным. Тем более даже какой-то экспериментальный патч есть, но Торвальдсу он не нравится

https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1583009.html

I know Andy asked for it, and I know he's usually right, but he's on drugs on this one.

Per-thread PTI does not make sense, and it is WRONG. It means, for example, that you can't just say «we always just use one page table for this mm», and not even populate the other one.

So per-thread PTI is garbage and must die. Either the VM is protected or it is not. It's about the mm, not about the thread. Andy didn't give any sane reasons why it should be per-thread.

Думаю что правильнее отключать этот pti не для отдельных доверенных процессов, а например для вообще всех процессов, запущеных от имени какого-то пользователя. Например если кто-то смог поломать браузер, и оказалось так, что браузер работает с этим pti, то можно браузером переписать ~/.bashrc чтобы запускался через него некий процесс, который бы уже был без pti и им уже можно свободно читать память ядра

SZT ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

Если б можно было легко перенести postgresql в кернелспейс, там будет еще меньше накладных расходов

epic_facepalm.bmp

А в чем тут заключается фейспалм?

SZT ★★★★★
() автор топика
Ответ на: комментарий от SZT

А в чем тут заключается фейспалм?

В том, что ты хочешь исполнять в ядре большой кусок кода, который работает по сети и умеет расширять свой функционал через динамические библиотеки и скриптовые языки.

tailgunner ★★★★★
()
Ответ на: комментарий от SZT

Думаю что правильнее отключать этот pti не для отдельных доверенных процессов, а например для вообще всех процессов, запущеных от имени какого-то пользователя

Точнее, лучше для целой ветки процессов (а не всего пользователя). Вот тот же зловред от браузера, так он будет оставаться в одной ветке без прав вредить. Примерно как переменная окружения спускается на нижележащие уровни скриптов, только тут это нельзя отключить.

Хорошая у тебя мысль, светлая голова, но об этом стоит написать куда-нибудь, и это прочитает аж сам Линус.

I-Love-Microsoft ★★★★★
()
Последнее исправление: I-Love-Microsoft (всего исправлений: 1)

Если будет возможность для части процессов выключить KPTI, а для другой части - включить, то вирусы будут отключать себе KPTI.

ZenitharChampion ★★★★★
()

Напомню собравшимся, что KPTI сейчас нужна для защиты от уязвимостей, которые позволяют только читать приватные данные, а не писать .bashrc и исполнять вредоносный код.

roof ★★
()
Ответ на: комментарий от anonymous

Это же вирусы. Им на всё прав хватает. Черви проникнут через дырку. Трояны установятся под видом чего-то полезного. Поэтому я считаю, что KPTI должен быть включен глобально, и без перезагрузки не отключаемым.

ZenitharChampion ★★★★★
()
Последнее исправление: ZenitharChampion (всего исправлений: 3)
Ответ на: комментарий от anonymous

Не совсем. За перделы изолированного контейнера такой вирус не выйдет. А если есть включение/выключение KPTI «per-process», то нет проблем считать данные из чужого контейнера.

ZenitharChampion ★★★★★
()
Последнее исправление: ZenitharChampion (всего исправлений: 1)
Ответ на: комментарий от ZenitharChampion

Есть права - загружаем модуль ядра и кладём бот на контейнер. Нет прав - не можем переключать что попало.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.