Найдена и исправлена ошибка в ядре Linux, позволявшая эксплуатировать уязвимость Spectre

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

Ещё раз повторяю, в реальном коде, не в связанном с попытками эксплуатации spectre, ситуация когда близкие по времени исполнения команды обращаются к одним и тем же местам в памяти - это типичная ситуация. За счёт этого кэш и эффективен. Так что если какие-то данные были затребованы, но не понадобились сразу, они почти наверняка потребуются снова через десяток тактов. Самый примитивный пример:

if (should_do_something()){
   do_something();
}
process();

В результате тренировки предиктор может считать, что условие вероятно не выполнится, начнет готовиться к process, а потом отменит и выполнит do_something(). Но от необходимости исполнять process никуда не деться всё равно. И это только один простейший случай, в реальности даже разные ветки кода будут обращаться к одним и тем же данным, будь то код метода класса или память по указателю внутри обрабатываемого объекта.

Что до «нужных» вытесняемых данных, тут всё упирается в ассоциативность кэша. В идеальном мире это то что дольше всего не использовалось и потому не нужно. В реале для l1 кэша это 4я по давности использования строка среди других строк с похожими адресами. Делать ассоциативность больше нельзя, так как ассоциативность увеличивает время поиска. Предложенный тобой дополнительный спекулятивный кэш так же усложнит поиск. Соответственно, если разработчик процессора готов жить с увеличенными задержками получения данных из кэша ему разумнее увеличить ассоциативность и тем самым эффективность вытеснения.

То что амд хуже иследован не значит что у них меньше уязвимостей. Они там есть, это уже доказано.

Это точно не про экономию. Это про то, чтобы сделать работу в 2 раза быстрее задействовав в 3-4 раза больше ресурсов. И там ставятся дополнительные и паралельные модули вокруг ядра чтобы это работало.

Что значит хуже? Исследователи не хотят пропиариться на найденных уязвимостях? Не поверю. Скорее они знаю, что интел это полное решето и ищут в нём. А на амд время потратишь и ничего не найдёшь. Рыночек порешал.

Нынешняя версия заголовка божественна.

Я несколько раз перечитал изложение темы ТС, но так и не избавился от своего понимания описанного: исправлена ошибка позволявшая эксплуатировать уязвимость Spectre.

Что я упускаю?

Да, «позволявшая» — хорошее уточнение. Исправил.

Мне на собеседовании они вопрос про фазовый автофокус задавали.

Типа, проверка на гибкость мышления.

Тут ведь какое дело - шила в мешке не утаишь.

Семейству «уязвимостей» - уже пятый год пошел, а ни одного задокументированного использования нет, не говоря про рабочий эксплоит.

Если бы оно действительно работало, уже бы всякая школота на коленке собрала рабочие эксплоиты (за четыре года-то) трахала всех подряд. А этого нет.

хорошо, что у меня все их офигительные патчи отключены

Что за гон на безопасность? Мне крипово. У нас высокотехнологичный мир, бухалтерия, магазины, производство продуктов питания - во всём этом участвуют компуктеры.

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

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

у ИБшнтков работа такая, клиентов запугивать :) Я потому и ушел из иб, потому что как-то стыдно с умным лицом говорить клиентам про ‘сферические уязвимости в вакуме’.

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

Мне кажется, это не показатель, так как:

1. когда взламывают - не всегда понятно, через какую именно уязвимость

2. когда взламывают - об это не всегда сообщают (не считая тем вида «помогите восстановить сервер после взлома» на технических ресурсах)

3. что бы эту информацию найти и систематизировать (привязать взлом к CVE) нужно потратить время.

Я вижу 2 возможных источника информации об эксплуатации уязвимостей:

1. теоретически, системы типа IPS или honeypot могут передавать производителям информацию о попытках эксплуатации уязвимостей, а производители - публиковать статистику.

2. профессионалы, занимающиеся расследованием взломов, может публиковать отчёты в публичном доступе. Если им удастся определить, что использовался спектр/мелтдаун (например, найти скаченный эксплойт и следы его запуска), то они могут опубликовать соответствующее заявление.

Видите ли Вы ещё источники?

Если кто-то обитает на хакерских ресурсах — посмотрите, много ли там жалоб на то, что не удаётся эксплуатировать эти уязвимости.

Видите ли Вы ещё источники?

3. Исследователи безопасности сами могут хвастаться, что им удалось чего-то взломать.

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

Интелов в продаже в 2-3 раза больше, разумнее прилагать усилия в эту сторону. Тем более когда вся эта бодяга всплыла - ризены только становились популярными, а А-серию откровенно закапывали.

Так там и конкуренция среди исследователей выше. Потратишь время, а тебя опередят.

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

Мне кажется, это не показатель

Вполне себе показатель. Ибо

профессионалы, занимающиеся расследованием взломов, может публиковать отчёты в публичном доступе. Если им удастся определить, что использовался спектр/мелтдаун (например, найти скаченный эксплойт и следы его запуска), то они могут опубликовать соответствующее заявление

Так и происходит после того, как все дыры залатаны. Во многих странах это вообще - требование законодательства.

Однако, никаких следов реального использования этого семейства «уязвимостей» за много лет не обнаружено. Никем. Нигде. Ни разу.

И тем не менее, именно интела чесали вдоль и поперёк и нашли мельтдаун, за 1,5-2 года до опубликования кажется. По поводу АМД тогда сказали «мы не знаем, хотя есть вероятность похожих механизмов». Что потом и подтвердилось.

Однако, никаких следов реального использования этого семейства «уязвимостей» за много лет не обнаружено. Никем. Нигде. Ни разу.

Откуда эта информация? Кто-то опросил 100 самых известных исследователей безопасности? Кто-то гуглил 3 дня и 3 ночи? Или откуда ещё?

Я спрашиваю потому, что самый простой способ чего-то не обнаружить — не искать это.

Я уже упоминал, что мы всей командой пытались найти следы этого дела. Это даже не «гуглил три дня и три ночи», это несколько человек исследовали вопрос, гуглили, пытались воспроизвести.

Тогда да, это серьёзный аргумент. Прошу прощения, пропустил.

ты хоть понимаешь вообще что это за уязвимость? которая воспроизводится только в университетских лабораториях в специальных условиях и патч от этого снижает производительность на 25%, заставляя тебя покупать новый проц?

Я периодически еще сам погугливаю, чтобы не пропустить ничего интересного. Но кроме «мы наплодили еще говнопатчей, чтобы вы скорее побежали к нам со своими охулиардами денег, чтобы мы вам их поменяли на железо, где эти патчи неактивны» - ничего не находится пока что.

Рано или поздно выпилят флаг mitigations=off, чтобы побежали безальтернативно.

которая воспроизводится только в университетских лабораториях в специальных условиях?

Меня экхм подташнивает от современных технологий. Ну просто выглядят эмм как говнецо в красивой обёртке. И на высоких мощностях.

Допустим, если раньше кто-то тырил твои данные - это троян, spyware. А сейчас типа-норма, облака. Но выглядит мерзотненько.

У брата новый ноут nvidia 4080 интел 12 ядер, 144 Гц ips. Фирменный софт MSI выглядит «ярко», с перенасыщенными цветами, но он просто дебильный. Очень кривой перевод на русский, какие-то косяки, хлипенький пластик.

Крч технологии даже при росте должны быть безопасными и служить юзеру, а тут превратились в чём-то что-то вроде подсобника «Большого брата» и выгружают данные в облака, но чёт странно крч.

Может они скоро все упадут, если не возьмутся.

В результате тренировки предиктор может считать, что условие вероятно не выполнится, начнет готовиться к process, а потом отменит и выполнит do_something(). Но от необходимости исполнять process никуда не деться всё равно.

Даже в таком коде всё равно никто не гарантирует, что выполнение process() после do_something() обратится по тем же самым адресам, по которым она бы обратилась без do_something(). Поинтеры могли сдвинуться.

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

Предложенный тобой дополнительный спекулятивный кэш так же усложнит поиск.

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

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

Увеличение ассоциативности не означает доп задержки, так как все теги можно просматривать параллельно. Это удорожает кристалл, но производительность от этого не страдает.

Это точно не про экономию. Это про то, чтобы сделать работу в 2 раза быстрее задействовав в 3-4 раза больше ресурсов. И там ставятся дополнительные и паралельные модули вокруг ядра чтобы это работало.

Скорость за счёт безопасности и есть экономия. Доп ядро со всем сопутствующим было бы гораздо дороже. Разве нет?

Даже в таком коде всё равно никто не гарантирует, что выполнение process() после do_something() обратится по тем же самым адресам, по которым она бы обратилась без do_something(). Поинтеры могли сдвинуться.

Могли, а могли и не сдвинуться. Большинство поинтеров никогда никуда не двигается просто потому что появились из-за невозможности предсказания размера, из-за необходимости виртуального вызова или из-за языка в котором «всё есть объект». Но даже если конкретный поинтер в принципе может двигаться, какова вероятность что он будет делать именно внутри do_something()?

Ворк-лоадов много разных, и в общем случае вряд ли кто-то сможет доказать, что вытеснять

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

Однако, если ты уж взялся требовать доказательств, то это тебе, как человеку, предлагающему усложнить систему, нужно доказывать, что, скажем, 4й по давности обращения адрес вероятнее потребуется снова чем тот адрес, который появился в неактивной ветке.

Поиск он усложнит лишь в случае спекулятивного исполнения.

Спасибо что напомнил. Да, ты требуешь усложнения даже тут, т.е. флажок спекулятивности/неспекулятивности потребуется учитывать не только при записи и отставке инструкций, но и вообще везде. Кстати, при OoO исполнении в теории любая инструкция спекулятивна, т.к. может оказаться что безобидная на вид инструкция чтения, идущая логически перед текущей и которую не стали ждать, может вызвать исключение.

Так ядро и есть намного дороже и сложнее. А косяк безопастности возник как побочное явление из за просчёта всех вариантов заранее.

Однако, если ты уж взялся требовать доказательств, то это тебе, как человеку, предлагающему усложнить систему, нужно доказывать, что, скажем, 4й по давности обращения адрес вероятнее потребуется снова чем тот адрес, который появился в неактивной ветке.

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

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

Не совсем. Чтобы такое произошло, нужен тлб мисс, а не кеш мисс. Как я понимаю, через тлб миссы сейчас стараются не спекулировать, так как это мельтом чревато.

Кеши существовали и до суперскалярности. И отлично работали. Это факт. А вот то, что их производительность существенно возросла благодаря спекулятивным вытеснениям - это ваша личная гипотеза

Я ничего не утверждал о улучшении производительности кэшей. Я написал то, что если бы гипотеза о локальности данных была бы неверной, то кэши бы не приносили никакой пользы. А вот то что спекулятивно исполняемая ветка обращается к адресам, никак не связанным с основной - вот это уже ваша гипотеза и она, на мой взляд, абсурдна.

Не совсем. Чтобы такое произошло, нужен тлб мисс, а не кеш мисс

Исключения разные бывают, в том числе и при делении на ноль. И, кстати, я не в курсе как OoO дружит с обычными железными прерываниями, вдруг в случае получения процессор не ждёт завершения цепочки, а просто отменяет все сидящие в буфере на отставку? Ну, в теории можно написать что-то типа a->b->c->d->e.arr[i]++; и каждая операция будет промахом, а окна для OoO сейчас большие, так что вполне реалистична ситуация, когда a->b уже выполнилась и пара следующих за данной строкой инструкций тоже, а дальше IRQ. Будет ли процессор ждать всю остальную цепочку до уже выполненных инструкций, или тупо отменит их?

локальности данных была бы неверной, то кэши бы не приносили никакой пользы.

Кеш инструкций бы всё равно пользу приносил.

А вот то что спекулятивно исполняемая ветка обращается к адресам, никак не связанным с основной - вот это уже ваша гипотеза и она, на мой взляд, абсурдна.

Кешировние чтения, по большому счёту, нужно для префетчинга. Мы взяли какой-то адрес и закешировали. Но фишка не в том, что к нему же обратится и последующий код. А, к примеру, этот же код, на следующей итерации цикла, обратится. Но не к этому же адресу, а к следующему - на то он и цикл. Кеш линии не такие уж и большие, сколько там, 64байта, вроде, каждая? Это слишком мало, чтобы какие-то разрозненные данные префетчить из разных веток. А вот для цикла - самое то. Вот и стараются ассоциативность увеличивать, а не длину. По тому, что локальность данных не такая уж и локальная, но если у вас небольшое число веток в цикле, то как раз несколькими разными линиями можно их все и покрыть. Ветки могут быть горячими и холодными. Кажется очевидным, что холодная ветка не должна вытеснять кеш-линии горячей.

a->b->c->d->e.arr[i]++; и каждая операция будет промахом, а окна для OoO сейчас большие, так что вполне реалистична ситуация, когда a->b уже выполнилась и пара следующих за данной строкой инструкций тоже, а дальше IRQ. Будет ли процессор ждать всю остальную цепочку до уже выполненных инструкций, или тупо отменит их?

Естественно отменит. Мало ли куда он там доспекулировал? Прерывание должно начать обрабатываться непосредственно после завершения текущей инструкции. Если планировщик там на 3 километра вперёд убежал, это никого не волнует, и конвейер флушнется. Другое дело, что есть ещё трейс кеш. Он позволит процу не декодировать заново те же инструкции, после возврата к этому коду.