Кстати, а вы вообще давно видели инструкцию bound в ядре,
или в юзерспейсе, пусть даже в 32-битном? Ась?

Поясню эту фразу для непонятливых. Чтобы что-то атаковать, это что-то должно _быть_. Вот вы утверждаете, что инструкция bound, которой даже нет в лонг моде - уязвима. А кто её использует то? Ну, можете, конечно, включить CONFIG_32BIT в ядре, и атаковать собственный тест-кейс, использующий bound. И потом всем говорить, что мельтдаун работает на АМД. Я правильно понял ваш план действий? :)

Вы же не станете утверждать, что Intel не подвержен мельдауну,

Не стану. Однако AMD тоже ему подвержен.

Но ведь AMD не подвержен мельдауну! Или вы что-то путаете, или намеренно пытаетесь вляпать AMD за компанию если вляпался Intel. Ваши мотивы со стороны выглядят как:

«Несправедливо будет если вляпался только Intel, тем более что дома у меня только Intel. Как же так, мои божественные распиаренные процессоры вдруг дырявее чем у этих амдунов? Ну уж нет! Если находят уязвимость в Intel, то значит и AMD априори уязвима к ней, ведь все x86 одинаковы!11адин»

Не более дырявый, чем AMD-шный SMP

Как раз-таки Intel'овский гипертридинг более дырявый, и намного - раз уж его рекомендуют отключать; в то время как отключать SMP ни у кого и в мыслях нету - как впрочем и пруфов у вас.

Я ж на чужие работы ссылаюсь.

Никто из экспертов мирового уровня не заявляет что AMD подвержен мельдауну, хотя уже неоднократно проверяли и перепроверяли. Пока не подтверждено фактами, все ваши заявления относительно одинаковой уязвимости AMD и Intel - выдумки завистливого интелобоя.

Никто из экспертов мирового уровня не заявляет что AMD
подвержен мельдауну, хотя уже неоднократно проверяли и
перепроверяли.

Да он вам сейчас на meltdown-bnd будет ссылку давать, который, яко бы, работает на АМД. Анонимус мало вменяемый, но крайне предсказуемый, и кидает всем одно и то же, не глядя на опровержения. По этому, подготовьтесь заранее ему на meltdown-bnd ответить.

Никто из экспертов мирового уровня не заявляет что AMD подвержен мельдауну, хотя уже неоднократно проверяли и перепроверяли.

Только вот не «никто из экспертов», а «никто из горе-новостеписателей». Или вы хотите сказать, что действительно смотрели доклады на конференциях, читали работы исследователей, а не только жёлтые новости?

Но ведь AMD не подвержен мельдауну! Или вы что-то путаете, или намеренно пытаетесь вляпать AMD за компанию если вляпался Intel.

А, вы, наверное, не читали предыдущий тред. Да, там много лишнего флуда. Но, ничего, я процитирую ещё раз:

We present a consistent and extensible systematization of transient execution attacks, i.e., Spectre, Meltdown, Foreshadow, and related attacks.
We demonstrate all attacks in our classification tree through practical proofs-of-concept with vulnerable code patterns evaluated on CPUs of Intel, ARM, and AMD.

Как раз-таки Intel'овский гипертридинг более дырявый, и намного - раз уж его рекомендуют отключать; в то время как отключать SMP ни у кого и в мыслях нету - как впрочем и пруфов у вас.

Так вы дайте пруфы на дыры в гипертрединге, тогда я дам пруфы на аналогичные дыры в AMD. А то фиг его знает, какие «дыры» вы имели ввиду, у некоторых, вон, инструкция HLT тоже среди дыр числится.

Как и в случае с Meltdown, мы полагаем, что наши процессоры неуязвимы для этих новых гипотетических вариантов атак с целью выполнения определенного кода: L1 Terminal Fault — SGX (также известна как Foreshadow) CVE 2018-3615, L1 Terminal Fault — OS/SMM (также известна как Foreshadow-NG) CVE 2018-3620 и L1 Terminal Fault — VMM (также известна как Foreshadow-NG) CVE 2018-3646, благодаря нашей аппаратной защите архитектуры страничной организации. Мы рекомендуем клиентам, использующим процессоры AMD EPYC™ в своих ЦОД (в том числе в виртуальных средах), не применять программные средства защиты от Foreshadow для своих платформ AMD.

https://www.amd.com/ru/corporate/security-updates

Состояние на 14 августа. В случае со Spectre v1 и v2 АМД признали наличие уязвимости.

Состояние на 14 августа. В случае со Spectre v1 и v2 АМД
признали наличие уязвимости.

Давайте не передёргивать. Они признали наличие уязвимости, но не в проце, а в операционках, которые не используют ASID/PCID, да ещё и пихают bpf jit в ядро. И сделали для таких «тупых» операционок новые барьерные инструкции. То ли дело Интел - у них уязвимость оказалась прямо в проце.

А, вы, наверное, не читали предыдущий тред. Да, там много
лишнего флуда. Но, ничего, я процитирую ещё раз:

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

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

Да.

We demonstrate all attacks all attacks in our classification tree through practical proofs-of-concept with vulnerable code patterns evaluated on CPUs of Intel, ARM, and AMD.

Вы неправильно поняли это предложение и неправильно выделили текст. Здесь не говорится о том что «все разработанные атаки работают для всех рассмотренных процессоров» ! Или у вас туго с техническим английским, или намеренно гнёте в свою пользу - но интелоспецифичные уязвимости от ваших наивных рассуждений никуда не денутся.

Так вы дайте пруфы на дыры в гипертрединге,

Надеюсь, здесь рассказано доступным для вас языком - https://arstechnica.com/information-technology/2018/11/intel-cpus-fall-to-new-hyperthreading-exploit-that-pilfers-crypto-keys/

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

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

Что вы имеете в виду? Meltdown? Спектре? Когда именно не помогли? Когда это всё только началось, или на сегодняшний день? Уточните вопрос, плиз.

он там уже лет 5 висит в этой комплектации если не больше

он там уже лет 5 висит в этой комплектации если не больше

Нафиг Эльбрус, есть Байкал.

я об l1tf всё тот же. Тогда же, когда АМД они помогли. Не?

я об l1tf всё тот же. Тогда же, когда АМД они помогли. Не?

Вы хотите спросить, почему апдейты от Spectre помогли АМД защититься от l1tf, а Интелу - не помогли? Я правильно «декодировал» вопрос? :) Просто по тому, что l1tf - это продолжение мельтдауна, а не спектре, в основном. Да, я уже видел новые классификации, где всё, что афектит кеш, называют спектре, но это глупость.

Так вот, поскольку мельту АМДшные процы не подвержены, они не подвержены так же и l1tf, вне зависимости от фиксов. И по тому:

As in the case with Meltdown, we believe our processors are not
susceptible to these new speculative execution attack variants:
L1 Terminal Fault
<skip>
We are advising customers running AMD EPYC™ processors in their
data centers, including in virtualized environments, to not
implement software mitigations for their AMD platforms.

В общем, если коротко, l1tf - это мельт, а не спектре.

Вы неправильно поняли это предложение и неправильно выделили текст. Здесь не говорится о том что «все разработанные атаки работают для всех рассмотренных процессоров» !

Здесь не говорится. А в работе говорится. Так что всё выделено верно.

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

Да.

Если вы действительно читали подобные работы или смотрели доклады, то соответствующую строку в работе найдёте за несколько секунд.

Надеюсь, здесь рассказано доступным для вас языком - https://arstechnica.com/information-technology/2018/11/intel-cpus-fall-to-new...

Ха! Эта ссылка — прямое подтверждение моих слов. Именно в ней написано:

We strongly suspect AMD Ryzen architectures which feature SMT are vulnerable, but we leave that for future work
(The real reason is we don’t have the [hardware] to test it on at the moment)

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

По ходу, это тоже ложь? Емнип, потеря производительности была из-за попыток заткнуть Spectre, который отлично воспроизводится и на AMD, не?

Это логично, в принципе, вектор Spectre — предсказание ветвлений, и попытка его отключить должна снижать производительность.

В общем, если коротко, l1tf - это мельт, а не спектре.

Ну я вот не знаю, какому из анонимов и хочу донести, что АМД чихали на мельт.

Ну я вот не знаю, какому из анонимов и хочу донести, что АМД
чихали на мельт.

Второй аноним не особо то и разницу между мельтом и спектре понимает. Для него это всё атака на кеш, «а кеш есть на всех процах». :) Что ему можно вообще объяснить...

Это логично, в принципе, вектор Spectre — предсказание
ветвлений, и попытка его отключить должна снижать
производительность.

ASID/PCID никто не отменял.

Да всё он понимает, он тут дурачком прикидывается, вот что печально.

Да всё он понимает, он тут дурачком прикидывается, вот что
печально.

Но всё-таки он нас заставил SPOILER по косточкам разобрать. Без катализатора в виде его троллинга, вероятно, никто бы так и не сподобился глянуть... :)

Евикшн сет связан с тем, что надо физ адреса свои найти. Через 4К алиасинг это не сделать, а через 1м - можно.

Не обязательно. Или как, по вашему, eviction set-ы искали до spoiler-а? Вот так и искали, перебирали адреса 4к-алиасов и проверяли, попадают ли они в сет. А как ищут со spoiler-ом? Точно так же: перебирают spoiler-овые адреса 1м-алиасов, и проверяют, попадают ли они в сет. Со спойлером шанс попадания выше, о чём я и писал «нужно перебирать меньше адресов». Поэтому поиск ускоряется в 2-3 раза (а не на два порядка, потому что к поиску самого сета добавляется медленный поиск 1МБ-алиасов).

Именно по этому, SPOILER - новый сайд ченнел, и новый метод поиска эвикшн сетов.

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

И что от него было толку? Он маппинг физ адресов в той работе не находил,

Не находил. Ну, находил, но только 12 бит. Это никак не противоречит моим словам. Маппинг физ.адресов там всё равно не использовался, просто проверялось, есть задержка или нет, не важно сколько бит совпало.

да и вообще, он там только в начале описан, а потом идёт MULTI-PROCESS4K-ALIASING.

А в этой работе он в конце описан, а потом сразу выводы.

зачем вы это привели - непонятно.

Мне тоже было не понятно, что вы хотите сказать фразой «можно применять и в рамках того же процесса», вот я и привёл пример, как 4к-алиасы применялись в рамках того же процесса.

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

Говорят, они потом изменили точку зрения. Почему в предварительном заявлении они сказали иначе — не знаю. Может решили, что если в работе исследовали интел, то к ним это неприменимо. А может хотели на курсе акций поспекулировать...

А кто сказал, что ошибка должна быть ТУТ? Я вам уже неделю назад объяснял, что проблема лишь в том, что операционки не использовали ASID/PCID.

Э... Что? Во-первых, если ошибка устранится при использовании процессорной фичи (причём, Intel-овой, в AMD её нет же?), то это таки баг процессора, не? Во-вторых, если не трудно, опишите, каким образом конкретно это может помочь в описанном примере?

А теперь ещё появились новые барьерные инструкции, чтобы сбрасывать бранч предиктор, и компиляторы про них знают.

Хотите сказать, это баг компилятора, генерирующего неверный машинный код? Ок, смотрим машинный код:

  ...
  test eax, 0
  je end_condition
  mov ebx, secret[ebx]
  and ebx, 64
  mov eax, a[ebx]
end_condition:
  ...

Вы точно уверены, что мне стоит читать именно это описание Meltdown-а? ;)

Да, так как доку от Прожект Зиро вы точно не станете читать, так хоть уж это.

Просто там в секции «Механизм» описывается почти мой пример для Spectre. То есть выходит, что между Spectre и Meltdown нет разницы согласно ссылке которую вы посоветовали прочитать.

Вы требуете от меня невозможного - у вас мат части нет, чтобы объяснить это короче, чем в доке прожекта зиро.

Ну не для меня так хоть для других. Вы же написали: «Я бы мог объяснить вам технические детали различий». Таки не можете?

Но могу начать с наводящих вопросов и домашних заданий.

Тогда это будет не объяснение, а игра в угадайку.

CONFIG_32BIT ?

Ну! Дошло наконец?

Что дошло? В ядре нет такой опции!

Кстати, а вы вообще давно видели инструкцию bound в ядре, или в юзерспейсе, пусть даже в 32-битном?

Я также никогда не встречал инструкции F0 0F C7 C8. Значит ли это, что в старых пнях не было «F00F»-бага?

PS: эх, похоже, я вас переоценил, жаль... с достойным оппонентом общаться интереснее.

В общем, если коротко, l1tf - это мельт, а не спектре.

Ну я вот не знаю, какому из анонимов и хочу донести, что АМД чихали на мельт.

Странно, но в отличие от Intel-а и ARM-а, AMD ничего не написали про неуязвимость к meltdown-br. И на вопросы журналистов не ответили... Интересно, почему?

Хотя, даже если они признают, что уязвимы к этому виду атаки, то они всегда могут добавить, что «there is a near zero risk». А любители AMD, утверждавшие про неуязвимость, скажут «ну так мы же имели ввиду оригинальный вектор meltdown, а про будущие атаки мы ничего такого не говорили». :)

А на счёт L1TF... Есть шанс, что его можно эксплуатировать и методом Spectre тоже, хоть это и маловероятно. Но если это возможно, то публикации об этом... если я правильно считаю... не будет раньше лета. Уязвимость слишком новая, не прошёл ещё срок раскрытия деталей.

Не обязательно. Или как, по вашему, eviction set-ы искали
до spoiler-а?

Ой, по-разному... Вот сюда загляните, например: http://palms.ee.princeton.edu/system/files/SP_vfinal.pdf

In Section IV, we discuss how we construct the eviction set
using large pages and without reverse-engineering the hash
function.

А иногда и не могли найти один евикшн сет, и мониторили сразу несколько.

Вот так и искали, перебирали адреса 4к-алиасов и проверяли,
попадают ли они в сет.

Гениально, может ещё и алгоритм на пальцах и примерах покажете?

Не находил. Ну, находил, но только 12 бит.

12 бит чего? Физ адреса? И кому это нужно, если они и так известны, они совпадают с 12 битами вирт адреса! И вы это раньше сами говорили, что интересно... Ну и регрессия.

Почему в предварительном заявлении они сказали иначе —
не знаю.

Я пока не видел пруфа на то, что это вообще сказали ОНИ. Вы же уверены, что всё было именно так? Отлично, дайте пруф, поверю и я. Кто именно это сказал?

(причём, Intel-овой, в AMD её нет же?)

Первое что поисковик выдал: https://www.dell.com/downloads/global/products/pedge/en/49741B_New AMD Optero... ASID там легко находится.

Э... Что? Во-первых, если ошибка устранится при
использовании процессорной фичи, то это таки баг процессора,

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

С точки зрения этого кода, если в eax лежит 0, то процессор
должен полностью пропустить весь блок присваиваний. Почему
же он этого не делает?

А вас это колышит? Суть не в том, кто что делает, а в том, что другой процесс может на это: а) повлиять, б) подсмотреть. А за изоляцию процессов отвечает операционка, при условии, конечно, что ей предоставили для этого все необходимые механизмы. Если они есть, а она ими не пользуется... Удивительно, что приходится объяснять такие азы.

Просто там в секции «Механизм» описывается почти мой
пример для Spectre.

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

Тогда это будет не объяснение, а игра в угадайку.

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

Что дошло? В ядре нет такой опции!

Ой, ну ошибся, по памяти, всё-таки, пишу. Сорян. Имел в виду CONFIG_IA32_EMULATION. Ну и помимо него ещё отключают CONFIG_MODIFY_LDT_SYSCALL, чтобы нельзя было всё равно создать 32битный сегмент.

Я также никогда не встречал инструкции F0 0F C7 C8.
Значит ли это, что в старых пнях не было «F00F»-бага?

Опять начинается тупость... Включите, хоть, голову, чтобы понять, что инструкция bound должна быть в самом атакуемом коде, и она там, очевидно, должна контролировать доступ к массиву, чтобы за границы никто не вышел. Вот если она там есть, её можно обмануть, и таки выйти за пределы. FOOF же позволял положить систему из любого контекста. А что, по вашему, должен делать bound в контексте атакующего, где никакого массива и границ нет?

PS: эх, похоже, я вас переоценил, жаль... с достойным
оппонентом общаться интереснее.

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

Странно, но в отличие от Intel-а и ARM-а, AMD ничего не
написали про неуязвимость к meltdown-br

По тому, что они, в отличии от меня, на всякие глупости вам отвечать не нанимались. Если вы решили, что инструкцией bound можно атаковать (а не наоборот, её саму атаковать, когда она контролирует доступ к массиву), то мне вас искренне жаль. Но только она ни где не используется.

Такое ощущение что в пиар отделе Штеуд'а сменили тактику. Вместо отрицания собственных косяков давят на то что у «красных» якобы те же проблемы. Ну что то вроде «выбора нет, поэтому спокойно покупайте наше, оно не хуже».

Такое ощущение что в пиар отделе Штеуд'а сменили тактику.
Вместо отрицания собственных косяков давят на то что у
«красных» якобы те же проблемы.

Сколько жу тут анонимусов, алиас детектор сломать можно! :) Вряд ли тролящий здесь анонимус может иметь хоть какое-то отношение к какому-либо пиар отделу.

Просто там в секции «Механизм» описывается почти мой пример
для Spectre.

А вы вообще хотя бы поняли, чего сравнили? Ваш пример для спектре, то есть уязвимый паттерн на _атакуемой_ стороне, с механизмом реализации мельта, то есть с алгоритмом атакующей стороны! И получили внешнее сходство, да это просто гениально! Ну примерно как и с bound: что-то где-то увидел, ага, баундом можно атаковать. :)

То есть выходит, что между Spectre и Meltdown нет разницы
согласно ссылке которую вы посоветовали прочитать.

Я бы вам сказал, где у вас нет разницы, но надоело. :) Там пункт 4 наводит на мысль о разнице. Уязвимый паттерн, обычно, не «Читает значение V(Ap) из защищённой области памяти по адресу Ap». Но вас, конечно, это не смутило...

Странно, но в отличие от Intel-а и ARM-а, AMD ничего не написали про неуязвимость к meltdown-br. И на вопросы журналистов не ответили... Интересно, почему?

Потому, что meltdown-br это еще один вектор на meltdown, с которым у красных проблемы нет?

Ну если для вас все x86 одинаковы и спроектированы одинаково и уязвимы одинаково, то о чём можно с вами дальше разговаривать? Вопиющая техническая безграмотность. А

strongly suspect

можно засунуть куда подальше - даже в суде «подозрения» в качестве доказательств не принимаются. Может я «strongly suspect» кое-что про тебя - и что, оно так и есть, судя по твоей логике?

На AMD воспроизводятся только определённые варианты Spectre, и то такие которые затыкаются практически без потерь производительности - в отличие от Intel.

Ядро 4.19 : влияние патчей для уязвимостей на производительность процессоров Intel/AMD

В этих тестах на Phoronix поучаствовали серверные процессоры Intel Xeon и AMD EPYC:

https://www.phoronix.com/scan.php?page=article&item=linux-419-mitigations&num=1

Если кратко: при включенных патчах исправляющих известные на тот момент уязвимости для которых были исправления, Intel в среднем замедлялся на около 15%, а AMD на около 5%.

https://www.reddit.com/r/Amd/comments/9bjyyy/amd_5_vs_intel_15_metldown_spectre_and_others/

Но эти «15%» - в среднем; а на некоторых тестах, особенно тех которые Heavy I/O, Intel проседает на 20%+. А если у него ещё и гипертридинг отключить с учётом недавно вскрывшегося, то Intel вообще тыковка-тыковкой!

Сколько жу тут анонимусов, алиас детектор сломать можно! :)

Он тут один. И разговаривает сам с собой.

на дружбу! ;)

Странно, но в отличие от Intel-а и ARM-а, AMD ничего не написали про неуязвимость к meltdown-br. И на вопросы журналистов не ответили... Интересно, почему?

Потому, что meltdown-br это еще один вектор на meltdown, с которым у красных проблемы нет?

Но когда опубликовали работу по Foreshadow для Intel, то они сразу же написали «мы неуязвимы к этому варианту атаки».

Почему же, когда опубликовали работу по Meltdown-BR для Intel и AMD, они ничего не ответили? Ведь они тем более должны были написать «мы неуязвимы, ребята ошиблись», разве нет?

Это ж не анонимус на лоре написал, официальная публикация, другие вендоры ответили, а AMD нет. Почему?

Мне в голову приходят три варианта объяснения.

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

2. Они действительно уязвимы, но если они об этом скажут, то выйдет, что до этого они врали, и нужно к AMD применять все те же меры защиты, что и к Intel-ам. А это потеря производительности, и сильный урон по репутации. Вот они решили отмолчаться и понадеяться, что никто не будет фактически эксплуатировать эту уязвимость. Всё-таки эксплуатация сложная, а AMD встречается не так часто, чтобы ради них стараться.

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

3. И последний вариант. Они уязвимы, но! Но есть какая-то другая, пока неопубликованная уязвимость, о которой им уже сообщили, и для которой всё равно надо выкладывать фикс. А этот фикс автоматически исправит и Meltdown-BR, т.е. можно про него отдельно не писать.

2.a.

ещё поверю. Но эти апдейты выходили с такой присказкой: «мы не уязвимы, но на всякий случай кое-что там попатчим, чтоб в будущем ещё бяки не вылезло». И если это пресловутый meltdown-br - то чего ж таки по производительности АМД это не ударило?

«мы не уязвимы, но на всякий случай кое-что там попатчим, чтоб в будущем ещё бяки не вылезло». И если это пресловутый meltdown-br - то чего ж таки по производительности АМД это не ударило?

Может ударило, просто никто не тестировал разные версии микрокода AMD на производительность. А может они смогли пофиксить микрокод так, что производительность не упала. А может они ещё и не фиксили ничего... фиг его знает.

Микроархитектура процессора AMD отличается от Intel-ов, и многие Intel-овые методы исследования для AMD не работают. (Например, там кеш может быть не inclusive, и многие кеш-атаки под AMD нужно затачивать отдельно.) А из-за того, что AMD реже встречается, по ним и публикаций намного меньше. Детали архитектуры Intel-ов либо документированы, либо давно реверсинженернуты. А для AMD многое ещё предстоит исследовать.

В целом, если не считать дурацких cpu-багов, типа падающей компиляции на ryzen-ах, AMD сейчас действительно безопаснее. Просто потому, что о них меньше известно. Конечно, это security through obscurity, но тем не менее.

В целом, если не считать дурацких cpu-багов, типа падающей компиляции на ryzen-ах

У этого бага, кстати, интересное описание:

в ryzen они под вопли про «элементы исскусственного интеллекта» вхерачили в проц блок для «ускорения» бенчмарков. он как бы узнает код бенчмарков и впихивает «подсказки» чем заменить те или иные инструкции чтоб перло быстрее. но этот блок стал «узнавать» код gcc и всё начало падать.

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

Но, увы, если это правда, то AMD в этом никогда не сознается.

И если это пресловутый meltdown-br - то чего ж таки по
производительности АМД это не ударило?

Я уже объяснил анонимусу (во всех подробностях) про meltdown-br, точнее, про meltdown-bnd, который реально работает только на Intel MPX. Зря вы тратите на него время. Сейчас уже очевидно, что он банально тролит, пользуясь тем, что люди не читают объяснения друг друга, и если всем одну и ту же фигню втирать, то хоть кто-нибудь да запутается. Он вас заставляет обсуждать не применимую к АМД атаку, и фантазировать на тему её фиксов, выпущенных ими тайно, уводя от фактов, изложенных, к тому же, в этом триде, и легко проверяемых. Стоит ли играть по его правилам - это уж каждый сам пускай решает. :)

In Section IV, we discuss how we construct the eviction set

И в секции 4 описан... тот же алгоритм: перебираем адреса, проверяем, если попадают в сет, то добавляем.

может ещё и алгоритм на пальцах и примерах покажете?

На пальцах — уже. Детальнее — сабжевая статья, секция «5.1 Efficient Eviction Set Finding».

Не находил. Ну, находил, но только 12 бит.

12 бит чего? Физ адреса? И кому это нужно, если они и так известны

Никому. Потому я и написал «не находил». Формально как бы находил 12 бит, но это не использовали. Как и совпадение 20 бит. Просто проверяли наличие задержки. Вызвана ли она совпадением 20 бит, или, например, 18, тоже не использовалось.

Я пока не видел пруфа на то, что это вообще сказали ОНИ. Кто именно это сказал?

Фиг его знает, кто именно. «AMD spokesperson said». Тот же текст и по TV говорили.

https://www.dell.com/downloads/global/products/pedge/en/49741B_New AMD Optero... ASID там легко находится.

Если погуглить что такое ASID:

AMD introduced a 1-bit tag extension with the Pacifica virtualization extensions. This 1-bit Address Space ID (ASID) is, in the context of virtualization, used to distinguish the VMM's address space from that of the guest domains.

У нас не виртуалки, нам это не поможет.

бранч предиктор «тренируется» сначала в другом процессе, чтобы в процессе жертвы выполнилась спекулятивно «не та» ветка

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

то для вас пусть будет баг в процессоре.

Даже AMD считает, что это баг процессора («applicable to AMD processors»).

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

Это не механизм изоляции, это мелкая оптимизация. Но, как оказалось, и её у AMD нет.

Ваш пример для спектре, то есть уязвимый паттерн на _атакуемой_ стороне, с механизмом реализации мельта, то есть с алгоритмом атакующей стороны!

Мы обсуждаем ссылку, которую вы предложили прочесть. Где в той ссылке «атакуемая» и «атакующая» стороны? Ну или согласитесь, что вы просили прочесть неверное или неполное описание. И предложите своё взамен.

Там пункт 4 наводит на мысль о разнице. Уязвимый паттерн, обычно, не «Читает значение V(Ap) из защищённой области памяти по адресу Ap».

Не наводит. «Читает значение V(Ap) из защищённой области памяти по адресу Ap» из их текста не отличается от mov ebx, secret[ebx] из моего примера.

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

Просто это выглядит по-дурацки.
Я: Особой разницы нет, это одна уязвимость, но разные вектора атаки, пруф: pdf-ка где все вектора собрали в общей классификации
Вы: Это 2 принципиально разных подхода. Я бы мог объяснить, но не буду. Идите читайте википедию (и википедия ваших слов не подтверждает)
В результате этих виляний мне кажется, что вы и сами не уверены в чём разница.

CONFIG_32BIT - очевидно, что серверные дистры эту опцию всегда отключают
Имел в виду CONFIG_IA32_EMULATION

RHEL/Centos — это серверный дистр? Тогда не отключают:

$ grep CONFIG_IA32_EMULATION /boot/config-3.10.0-957.5.1.el7.x86_64 
CONFIG_IA32_EMULATION=y

инструкция bound должна быть в самом атакуемом коде

Почему в атакуемом? Пруф? Или своими словами объясните наконец что такое, на ваш взгляд, meltdown и spectre.

Анонимус, вас тут уже все по достоинству оценили

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

Но если кому-то интересно, я составлю итоги нашей беседы, когда она подойдёт к концу.

Ну если для вас все x86 одинаковы и спроектированы одинаково и уязвимы одинаково, то о чём можно с вами дальше разговаривать?

А разве кто-то говорил, что они спроектированы одинаково?

А strongly suspect можно засунуть куда подальше - даже в суде «подозрения» в качестве доказательств не принимаются.

Во-первых, мы не в суде. В вопросах безопасности «strongly suspect» ­— это достаточный повод, чтобы выбросить алгоритм шифрования.

Во-вторых, «strongly suspect» от автора статьи по безопасности всё-таки значит больше, чем «я сказал — неуязвимо» от анонимуса на лоре.

Если кратко: при включенных патчах исправляющих известные на тот момент уязвимости для которых были исправления, Intel в среднем замедлялся на около 15%, а AMD на около 5%.

Что-то маловато. Я помню в отдельных тестах была и 30% просадка. А в специально написанном бенчмарке можно и на 80% просесть.

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

Во-вторых, это — ожидаемо. Ядро отключает KPTI на AMD. То есть сравниваются влияние всех фиксов плюс KPTI на Intel, и всех фиксов кроме KPTI на AMD. Логично, что на AMD просадка должна быть меньше на размер KPTI.

И в-третьих, если верить тестам фороникса, дело не только в уязвимостях. Если бы дело было только в них, то при отключении всех фиксов скорость бы сравнялась со старыми ядрами. А по тестам даже ядро с отключенными фиксами местами на 40% не дотягивает до скорости ядра 4.14: https://www.phoronix.com/scan.php?page=article&item=linux-416early-spectr...

На AMD воспроизводятся только определённые варианты Spectre

«только определённые» — это какие?

И в секции 4 описан... тот же алгоритм

То есть, «using large pages» вы, конечно, не увидели?

На пальцах — уже. Детальнее — сабжевая статья, секция «5.1
Efficient Eviction Set Finding».

Не говорите ерунду, на 4К алиасах никто физ адреса не найдёт. Везде используют либо большие страницы, либо другие техники.

Никому. Потому я и написал «не находил». Формально как бы
находил 12 бит, но это не использовали.

Вот именно. Дальше 12 бит на 4К алиасах не подняться никак.

Фиг его знает, кто именно. «AMD spokesperson said».

Вот именно. Кто-то где-то сказал, да ещё и устно, если вообще. Аноним запомнил и всем это тычет.

Тоже нет. Можно «тренировать» и запускать в своём процессе,
например, чтобы читать память браузера из javascript-
сандбокса. Странно, что вы этого не знаете

Так это вы не знаете, что в АМД и это не работает, по крайней мере в последних процах. ZEN использует только полные адреса в BTB, а не их части, как раньше делали. Следовательно, атаке внутри одного процесса он не подвержен в принципе. У АМД _были_ модели процов предыдущих поколений, где этот баг применим и лечится барьерами, но это не последние модели. С ерусами этой проблемы нет. И главное, конечно, что мельт на АМД не работает, а не это.

Даже AMD считает, что это баг процессора («applicable to
AMD processors»).

Эта формулировка ничего не говорит о том, где они видят баг. Они лишь говорят, что с процессорами АМД соответствующие варианты спектре можно, по тем или иным причинам, воспроизвести.

Мы обсуждаем ссылку, которую вы предложили прочесть.
Где в той ссылке «атакуемая» и «атакующая» стороны?

В ней нет, но она есть в спектре, с которым вы сравнивали... Включите голову уже, напрягает.

Ну или согласитесь, что вы просили прочесть неверное или
неполное описание.

Вполне нормальное, вам и это осилить ещё месяц объяснений уйдёт. И не факт, что я стану его на это тратить!

Не наводит. «Читает значение V(Ap) из защищённой области
памяти по адресу Ap» из их текста не отличается от mov ebx,
secret[ebx] из моего примера.

То есть, вы реально не понимаете разницы между тем, что они имеют в виду под «защищённой областью памяти», и тем, что вы читаете из области _своей_ памяти, защищённой обычной проверкой границ массива?

В результате этих виляний мне кажется, что вы и сами не
уверены в чём разница.

Вам давно уже всё «кажется», вы не понимаете и 5% моих слов. Википедии бы тоже хватило, но вы не понимаете и написанное там, а от меня чего-то ждёте.

RHEL/Centos — это серверный дистр? Тогда не отключают:

Но отключить можно? Да или нет? Хотя и не нужно вовсе, но, так как вы не понимаете, почему не нужно - успокойтесь и на том, что отключить _можно_.

Почему в атакуемом? Пруф?

Пруф чего? Вы издеваетесь? У вас проверка границ может делаться как, не знаю, ассертом, так и инструкцией bound. Они нашли способ её обмануть, всё! Что тут непонятно то? Как вы собираетесь ей (а не её саму) _атаковать_? Вы бредите?

For its part, Meltdown-BR provides a way to bypass linked
checks, which generate exceptions when an out-of-bound value
is encountered. It exploits the transient execution after
such an exception to capture information outside of the
limits that would otherwise not be accessible, the experts
in digital forensics report.

Никто нас не оценивал.

Вас лично в каждом отдельном триде оценили, их их оценки мало отличаются от моей. Можете бредить дальше.

инструкция bound должна быть в самом атакуемом коде

Почему в атакуемом? Пруф?

Вы хоть сами понимаете, пруф чего именно вы спрашиваете? Они постоянно находят новые способы обхода проверок границ массивов. Нашли и в случае, когда проверку осуществляет инструкция bound. Назвали это meltdown-bnd... Какой тут нужен пруф, пруф чего? Так как bound в реальном мире не используется, на АМД этой атаки нет (а в случае Intel есть MPX, который можно атаковать этим же meltdown-br). Что тут вообще может быть непонятно?

тролит, пользуясь тем, что люди не читают объяснения друг друга

Я вот, кстати, как раз внимательно читаю.

Я вот, кстати, как раз внимательно читаю.

Тогда снимаю вопрос о том, зачем вы с ним обсуждаете «тайные фиксы meltdown-bnd». Видимо, вы, в отличии от него, понимаете, что АМД действительно могли пофиксить реализацию bound, даже несмотря на отсутствие атаки. Кстати, meltdown-bnd - это, вообще-то, спектре. Мельтом его назвали только из-за того, что там эксепшн кидается. Но это даже не тот эксепшн, который характерен для мельта, и основную мельтовую багу эта техника не эксплуатирует. Да и на выходе лишь обход проверки границ массива - типичный спектре. Жаль, что люди не придерживаются исходных терминологий, а каждый лепит свою. На этой почве такие вот чудики и появляются, как наш гость.

Даже AMD считает, что это баг процессора («applicable to
AMD processors»).

Нашёл ответ одного из сотрудников АМД на эту тему:

Adding a ASID-like tag to the prediction tables would vastly
increase their size.

Address tables (indirect jumping/call/ret) typically do have
some tagging, but they are not the main workhorse predictors.

Разумеется, к обсуждаемому нами мельту это отношения не имеет, равно как и к тем вариациям спектре, которые пользуются алиасингом в BTB (которого в ZEN быть не может, а в интелах - есть).

Но если кому-то интересно, я составлю итоги нашей беседы,
когда она подойдёт к концу.

«Час прошёл, второй - увы! Нет ответа из Москвы...» Будут итоги то хоть?

Пользуясь случаем, приношу извинения Woolf'у за дезу про ASIDы. Оказывается, АМДшники уже прям на форумах анонимусам отвечают, что тегов в BTB не будет, а я... понадеялся... ну вы поняли. :) Сорри!

То есть, «using large pages» вы, конечно, не увидели?

Видел. А что это значит? Huge pages? Так они обычно выключены. Просто большие куски памяти? Так большими кусками и в сабжевой статье выделяли, они так contiguous memory детектили.

Вот именно. Дальше 12 бит на 4К алиасах не подняться никак.

Не спорю. Дальше и не нужно. Там просто меряется задержка. А совпало там 20 бит или 12 — не имеет значения.

Так это вы не знаете, что в АМД и это не работает, по крайней мере в последних процах. ZEN использует только полные адреса в BTB, а не их части, как раньше делали. Следовательно, атаке внутри одного процесса он не подвержен в принципе.

Вы опять написали что-то странное... К тому же, вроде, даже AMD не утверждала, что часть их процессоров неуязвимы к Spectre. А если бы это было так — они бы это точно написали. А Ryzen — это ZEN? Процессоры Ryzen уязвимы к Spectre?

У АМД _были_ модели процов предыдущих поколений, где этот баг применим и лечится барьерами, но это не последние модели. С ерусами этой проблемы нет.

Можно какой-то пруф этому утверждению? А то другие пишут, что с ерусами эти проблемы тоже есть.

Эта формулировка ничего не говорит о том, где они видят баг. Они лишь говорят, что с процессорами АМД соответствующие варианты спектре можно, по тем или иным причинам, воспроизвести.

А что тогда вообще считать багом процессора? Дайте определение, что с вашей точки зрения «баг в процессоре»?

Но отключить можно? Да или нет?

Отключить можно, но не отключают.

Хотя и не нужно вовсе, но, так как вы не понимаете, почему не нужно - успокойтесь и на том, что отключить _можно_.

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

То есть, вы реально не понимаете разницы [...]
Пруф чего? Вы издеваетесь? [...]
Вы хоть сами понимаете, пруф чего именно вы спрашиваете? [...]
Вам давно уже всё «кажется», вы не понимаете и 5% моих слов.[...]
а от меня чего-то ждёте.

Жду, что вы скажете своё мнение, что лично вы называете Meltdown и Spectre. У вас же есть своё мнение? Пусть это мнение не совпадает с моим, но оно же у вас есть? Если да, то сформулируйте его, пожалуйста.

Вы ответите на этот и почти все остальные мои вопросы, если просто своими словами опишете, что такое для вас Meltdown и Spectre, без «почитайте ХХХ» и «всё написано в YYY».

«Час прошёл, второй - увы! Нет ответа из Москвы...» Будут итоги то хоть?

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

Нашёл ответ одного из сотрудников АМД на эту тему

Можно ссылку на источник?

Соответственно, операционке приходится пользоваться инструкциями сброса BTB

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