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

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

Опять интел?

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

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

https://www.anekdot.ru/i/caricatures/normal/19/8/7/granica-na-zamke.jpg

Какой смысл бороться с этими уязвимостями, когда можно просто сделать аппаратный аналог CUBES:

http://dev1galaxy.org/viewtopic.php?pid=17074#p17074

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

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

Вытащить штекер из розетки

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

Ну и хорошо

Горшочек, не вари!

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

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

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

Опять интел?

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

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

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

Купить Intel D2700

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

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

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

Купить atom n570.

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

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

Бенчмарки подвезли, как всегда просели сисколы (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).

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

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

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

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

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

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

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

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

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

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

определение верха в студию

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

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

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

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

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

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

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

Да

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

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

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

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

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

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

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

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

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

{ // ШК 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 валиден, то да, данные попадут в кэш даже если они потом не будут использоваться. Руками можно было бы сделать так чтобы не попадали, но мало кто будет с этим заморачиваться. Побочные эффекты? Ну будет лишняя запись в кэше, с кем не бывает.

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

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

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

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

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

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

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

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