Здравствуйте, Pzz, Вы писали:
C>>Да, самое простое посчитать число тактов. Но этим оно не ограничивается. Причём даже кэш не нужен, один из способов — использовать инструкции с переменным числом тактов (деление, например) и смотреть сколько тактов оно выполняется в зависимости от данных.
Pzz>А часто вообще попадаются программы, которым на вполне законных основаниях надо слазить в ядерные адреса и обойтись легким SIGSEGV'ом, вместо заслуженной смерти?
Этот вопрос надо было задавать, когда вводили Structure Exception Handling и аналоги
Здравствуйте, Pzz, Вы писали:
Pzz>А часто вообще попадаются программы, которым на вполне законных основаниях надо слазить в ядерные адреса и обойтись легким SIGSEGV'ом, вместо заслуженной смерти?
Cyberax не правильно объяснил. Никакого SEGV не будет.
char *data = 0xFFFFa123123; // В ядреchar myData[1024]; // В userSpace
dumpCaches();
if (someConditionThatWillBeFalse) {
// сюда лезет branchPredictor и меняет только cache!int oneOrZeroInKernel = (*data) & 0x01;
myData[oneOrZeroInKernel*512]
}
checkWhatIsCachedInMyDataViaTiming() // if myData[512] is cached than kernel had 1, else 0
Здравствуйте, novitk, Вы писали:
Pzz>>А часто вообще попадаются программы, которым на вполне законных основаниях надо слазить в ядерные адреса и обойтись легким SIGSEGV'ом, вместо заслуженной смерти?
N>Cyberax не правильно объяснил. Никакого SEGV не будет.
Он объяснил правильно, но у него Meltdown, а у тебя Spectre. Последний сложнее, т.к. там определенным путем надо натренировать этот branch prediction, чтобы он пошел исполняться.
В то время как в прямом чтении у тебя практически гарантия.
Здравствуйте, andrey.desman, Вы писали:
N>>Cyberax не правильно объяснил. Никакого SEGV не будет.
AD>Он объяснил правильно, но у него Meltdown, а у тебя Spectre. Последний сложнее, т.к. там определенным путем надо натренировать этот branch prediction, чтобы он пошел исполняться. AD>В то время как в прямом чтении у тебя практически гарантия.
Я просто смотрел в обратном порядке и думал вопрос Pzz был по JS, где используется Spectre. Впрочем, я не совсем понимаю зачем нужен именно SEGV. Принципиальная сущность Meltdown-a мне кажется в том, что Интел дает доступ к ринг-0 из ринг-3 в спекулятивных вычислениях, а уж ловить там SEGV или просто запутать branch predictor if-om не особо важно. Отличие от Spectre в том что в последнем ссылки между рингами не скачут.
Здравствуйте, MadHuman, Вы писали:
MH>но тогда почему к примеру MS рапортует что выпустила патч?...
А непонятно что они там навыпускали. есть какие то патчи, что конкретно из перечисленного они исправляют — мне лично не понятно. расплав помоему ms еще не исправил, так, для спектра некоторые варианты закрыли. А может наоборот.
Здравствуйте, kov_serg, Вы писали:
V>>А красово, а? _>Не красиво. Есть же виртуальная память и у каждого процесса она своя. Что мешает не иметь охраняемых данных в ввиртуальном адресном пространстве вообще?
Производительность. Переключение таблиц отображения при переходе userspace->kernel и обратно вызывает сброс TLB и заметное замедление.
Здравствуйте, MadHuman, Вы писали:
MH>но тогда же невозможно её исправить за счет патча для ОС, нетакли? MH>но тогда почему к примеру MS рапортует что выпустила патч?...
От Meltdown полностью можно защититься с помощью патча. Для Spectre можно прикрыть только определённые пути её эксплуатации.
Здравствуйте, Pzz, Вы писали:
C>>Да, самое простое посчитать число тактов. Но этим оно не ограничивается. Причём даже кэш не нужен, один из способов — использовать инструкции с переменным числом тактов (деление, например) и смотреть сколько тактов оно выполняется в зависимости от данных. Pzz>А часто вообще попадаются программы, которым на вполне законных основаниях надо слазить в ядерные адреса и обойтись легким SIGSEGV'ом, вместо заслуженной смерти?
Ну обращение по (void*)(unsigned long)(-1) — достаточно частое явление и по POSIX должен быть SIGSEGV или SIGBUS. Оба можно поймать.
Кстати, даже если программа помрёт вместо ловли сигнала — никто не мешает сделать fork() в точности перед пробой.
Здравствуйте, Cyberax, Вы писали:
C>От Meltdown полностью можно защититься с помощью патча. Для Spectre можно прикрыть только определённые пути её эксплуатации.
а каков возможный принцип этого патча (от Spectre)? ведь работает нативный код.. даже системных вызовов нет, кроме тайминга, для которого можно массу вариантов придумать..
Видели какую-то информацию как это возможно?..
Здравствуйте, MadHuman, Вы писали:
MH>а каков возможный принцип этого патча (от Spectre)? ведь работает нативный код.. даже системных вызовов нет, кроме тайминга, для которого можно массу вариантов придумать.. MH>Видели какую-то информацию как это возможно?..
Вроде должна быть защита на уровне конкретных приложений, а не на уровне ос.
Здравствуйте, MadHuman, Вы писали:
MH>судя по описанию, дыра на уровне процессора. MH>но тогда же невозможно её исправить за счет патча для ОС, нетакли? MH>но тогда почему к примеру MS рапортует что выпустила патч?...
Дыра работает в определенном режиме процессора. Можно не использовать этот режим, тогда дыра перестанет работать. Но вызов ядра из пользовательской задачи станет заметно дороже.
Здравствуйте, Cyberax, Вы писали:
C>От Meltdown полностью можно защититься с помощью патча. Для Spectre можно прикрыть только определённые пути её эксплуатации.
Казалось бы, если в адресном пространстве процесса "ненужных" страниц совсем не присутствует, а не как сейчас, они присутствуют, но в запрещенном виде, то с помощью spectre ни до чего лишнего и не дотянешься...
Здравствуйте, Pzz, Вы писали:
Pzz>Казалось бы, если в адресном пространстве процесса "ненужных" страниц совсем не присутствует, а не как сейчас, они присутствуют, но в запрещенном виде, то с помощью spectre ни до чего лишнего и не дотянешься...
Можно вылезти, например, из песочницы javascript и получить доступ к памяти всего процесса.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, Pzz, Вы писали:
Pzz>Казалось бы, если в адресном пространстве процесса "ненужных" страниц совсем не присутствует, а не как сейчас, они присутствуют, но в запрещенном виде, то с помощью spectre ни до чего лишнего и не дотянешься...
Проблема в том, что определённые последовательности кода (в основном, проверки границ) внутри syscall'ов можно эксплуатировать из userspace. Это не требует никаких дыр в безопасности — процессор просто исполняет код внутри ядра, а зловредный шпион наблюдает за кэшем из userspace.
Плюс возможности шпионажа изнутри песочниц в браузере.
