LINUX.ORG.RU
ФорумTalks

SWAPGS - новая уязвимость в механизме спекулятивного выполнения CPU

 , , , ,


0

2

Процессоропроблемы опять перешли в наступление: http://www.opennet.ru/opennews/art.shtml?num=51234

Исследователи из компании Bitdefender выявили новую уязвимость (CVE-2019-1125) в механизме спекулятивного выполнения инструкций современных CPU, которая получила имя SWAPGS, соответствующее названию процессорной инструкции, вызывающей проблему. Уязвимость позволяет непривилегированному атакующему определить содержимое памяти ядра, других процессов или виртуальных машин в системе. Проблема подтверждена в процессорах Intel (x86_64) и частично затрагивает процессоры AMD, для которых не проявляется основной вектор атаки. Ранее реализованные методы противодействия уязвимостям Spectre и Meltdown не защищают от атаки SWAPGS при использовании процессоров Intel, но для Linux, ChromeOS, Android и Windows уже предложены исправления.

Deleted

Тааак, а на чем крутится ЛОР, его уже перевели на «наш» камушек с сертификатом ФСТЭК?

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

Тааак, а на чем крутится ЛОР, его уже перевели на «наш» камушек с сертификатом ФСТЭК?

Кстати, они защищены от Spectre отсутствием спекулятивного выполнения.

Meyer ★★★★ ()

Как отключить спекулятивное выполнение полностью?

ZenitharChampion ★★★★★ ()

Старые процессоры Intel, до Ivy Bridge, атаковать значительно труднее из-за отсутствия поддержки инструкции WRGSBASE, использованной в эксплоите

Ну и хорошо

alexferman ★★ ()

частично затрагивает процессоры AMD, для которых не проявляется основной вектор атаки.

вот и славно, продолжу сидеть на амудях

upcFrost ★★★★★ ()

Никогда такого не было и вот опять. Походу, мой Фуфыкс будет вечен.

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

Опять интел?

Они заколебали.

С ноутами пока деваться некуда, но как понадобится десктоп, занесу денег AMD.

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

Как отключить спекулятивное выполнение полностью?

Купить Intel D2700

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

Кстати, они защищены от Spectre отсутствием спекулятивного выполнения.

О каких камушках речь? В Эльбрусах спекулятивное исполнение очень даже есть. http://elbrus.ru/elbrus_arch

Возможности архитектуры Эльбрус:
Поддержка спекулятивных вычислений и однобитовых предикатов. Позволяет уменьшить число переходов и параллельно исполнять несколько ветвей программы.

SZT ★★★★ ()

Ох уж этот интел. Решето на шерете. Только русский эльбрус спасёт мир.

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

Фига себе. Когда завезли и как это возможно на VLIW архитектуре без кучи костылей?

Meyer ★★★★ ()

Бенчмарки подвезли, как всегда просели сисколы (Thread create, malloc, etc), особенно пострадал Socket Throughput.

И похоже для amd пока по дефолту выключено:

Contrary to Red Hat's report initially saying AMD CPUs are affected, the Linux kernel is not applying this SWAPGS mitigation to AMD hardware (AMD has also issued a statement that they believe they are unaffected by this new Spectre V1 variant).

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

Только русский эльбрус спасёт мир.

Может титаниум таки откопают? Кстати патенты почти уже истекли (в 21 году будет 20 лет с момента выпуска первой модели), так что вендр лок уже не так страшен. На самом деле было бы просто интересно глянуть на такую поделку с открытой isa.

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

Когда завезли и как это возможно на VLIW архитектуре без кучи костылей?

ХЗ, это лучше спрашивать у сотрудников МЦСТ, например alexanius.

SZT ★★★★ ()

Получается, AMD компетентнее в дизайне х86 оказалась? Шо ж так? Доколе!?

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

Аккуратно выкусить через одну ножки на процессоре в третьем ряду сверху...

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

Когда завезли и как это возможно на VLIW архитектуре без кучи костылей?

Я чёт не понял. Весь влив на спекулятивном исполнении основан. А в Эльбрусах спектра нет, у нас проверка прав доступа реализована перед фактическим обращением

alexanius ()

прям мода пошла. хоть кто-нибудь читал об использовании in the wild этого класса уязвимостей?

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

Во, видишь, тебе уже и пофиг, и дочитывать лень. Еще пара-тройка этих однотипных уязвимостей для закрепления реакции публики, и можно выкатывать настоящую, сквозную дырень. =)

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

Весь влив на спекулятивном исполнении основан.

А спекулятивное вычисление там работает только в рамках одной ШК, или процессор может несколько ШК загрузить и как-нибудь спекулятивно считать? Есть ли конвейер над самими ШК?

А в Эльбрусах спектра нет, у нас проверка прав доступа реализована перед фактическим обращением

Т.е. читать данные в кеш процессора он будет только когда будет точно понятно, что эти данные действительно нужны? Это работает в пределах одной ШК, или может если есть несколько ШК и процессор видит что где-то там дальше есть ШК в которой происходит чтение из оперативки, то вот это можно записать в кеш проца?

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

А спекулятивное вычисление там работает только в рамках одной ШК, или процессор может несколько ШК загрузить и как-нибудь спекулятивно считать?

В рамках отдельных инструкций внутри ШК

Есть ли конвейер над самими ШК?

Да

Т.е. читать данные в кеш процессора он будет только когда будет точно понятно, что эти данные действительно нужны?

Да. Если точнее, то в случае ошибки прав доступа будет записано диагностическое значение.

Это работает в пределах одной ШК, или может если есть несколько ШК и процессор видит что где-то там дальше есть ШК в которой происходит чтение из оперативки, то вот это можно записать в кеш проца?

Всё работает по конкретным инструкциям внутри ШК. Для каждого чтения проверяется допустимость, и либо читается реальное значение, либо записывается диагностика

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

Всё работает по конкретным инструкциям внутри ШК. Для каждого чтения проверяется допустимость, и либо читается реальное значение, либо записывается диагностика

А по времени это работает так же? Ну вот допустим есть у нас условный код вида

bool x;
...
char a;
if (x)
{
  a = *(char *)0x24ff1455; // читаем что-то по какому-то адресу
}
else
{
  a = 10;
}
...

Предположим, внеочередное исполнение посчитало и ветку когда x == true и ветку когда x == false и при этом на адрес 0x24ff1455 в виртуальном адресном пространстве процесса может быть что-то отображено, или не отображено (т.е. адрес может быть невалидным и его разыменование приведет к ошибке сегментации, или может быть валидным и ошибки не будет, я знаю про наличие в Эльбрусах особых указателей с тегами, но предположим что это отключено). Если 0x24ff1455 при фактическом (не внеочередном) чтении окажется валидным, в кэш процессора попадут какие-то данные по тому адресу? А если чтение будет только при внеочередном (т.е. x окажется false и ветка с a = *(char *)0x24ff1455; по настоящему выполнена не будет, но указатель будет валидным), тогда в кэш процессора не попадут данные по тому адресу? А если попадут, будет ли время исполнения отличаться в варианте когда указатель (адрес) 0x24ff1455 валиден в сравнении с ситуацией когда указатель невалиден? Ну в любом случае если в кеш что-то попадает, это дает какие-то измеримые сайд-эффекты

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

Мне кажется, тут не стоит употреблять термин «очередное-внеочередное», т.к. все инструкции и ШК в Эльбрусе всегда очередные. Код будет оттранслирован примерно следующим образом (далее псевдоассемблер):

{ // ШК 1
LD .s 0x24ff1455, 0 -> %r1 // Спекулятивно читаем в регистр r1
CMP x, 0 -> p1             // Записываем в предикатный регистр
}
{ // ШК 2
MOV %r1 -> a | p1          // Если p1 == true то записываем в a значение из r1
MOV  10 -> a | ~p1         // Если p1 == false то записываем в a значение 10
}

Понятное дело что потом оптимизации все MOVы уберут, тут они просто для наглядности. Соответственно, если 0x24ff1455 валиден, то да, данные попадут в кэш даже если они потом не будут использоваться. Руками можно было бы сделать так чтобы не попадали, но мало кто будет с этим заморачиваться. Побочные эффекты? Ну будет лишняя запись в кэше, с кем не бывает.

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

Соответственно, если 0x24ff1455 валиден, то да, данные попадут в кэш даже если они потом не будут использоваться. Руками можно было бы сделать так чтобы не попадали, но мало кто будет с этим заморачиваться. Побочные эффекты? Ну будет лишняя запись в кэше, с кем не бывает.

Ну с точки зрения безопасности это не есть хорошо, т.к. таким образом можно из какого-нибудь жаваскрипта замерами времени определить, какие адреса являются валидными, а какие нет (ASLR обходится). И это поможет сделать эксплоит

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

Осталось только научиться записывать в аппаратный стек вызовов :)

Но да, наверняка есть какие-то атаки, которые и тут сработают (по крайней мере в незащищёном режиме)

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

Осталось только научиться записывать в аппаратный стек вызовов :)

Отдельный стек с адресами возврата это конечно похвально, но помимо этого стека есть еще указатели на функции, всякие таблицы виртуальных методов в C++, и в незащищенном режиме их как раз можно будет переписать. Есть еще довольно «полезные» функции setjmp и longjmp, которые по своей природе обязаны что-то с этим стеком вызовов делать, так что можно их каким-нибудь нестандартным способом использовать. Ну и вот интересная статья по теме: Return-oriented Programming without Returns https://cseweb.ucsd.edu/~hovav/dist/noret.pdf

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

Получается, AMD компетентнее в дизайне х86 оказалась? Шо ж так? Доколе!?

Да, это давно известно. Сколько лет Intel безрезультатно мучила x64, пока АМД не сделало AMD64 , который был принят как стандарт (Intel купила лицензию).

BlackJack ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)