Spoiler — новая уязвимость в процессорах Intel

Только юрлицам и то не всем подряд.

на 1 уязвимость в AMD приходится целый букет уязвимостей в Intel. Это особенно хорошо видно по недавней истории с meltdown/spectre, когда из 4 уязвимостей Intel, лишь одна оказалась применима к AMD

https://gist.github.com/ford153focus/7994d4dffd7b42f7fa1cdfd9518bfc61

на 1 уязвимость в AMD приходится целый букет уязвимостей в Intel. Это особенно хорошо видно по недавней истории с meltdown/spectre, когда из 4 уязвимостей Intel, лишь одна оказалась применима к AMD

То, что журналисты написали про интел, но не написали про амд, не значит, что у амд нет багов. Их просто проверили не сразу:

We discover 2 new Meltdown attacks, including the first exploitable Meltdown-type effect on AMD, contradicting previous claims by AMD
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.

Эти баги типичны и применимы к любому процессору, в котором есть кеш. В процессорах AMD есть кеш?

https://gist.github.com/ford153focus/7994d4dffd7b42f7fa1cdfd9518bfc61
Spoiler - баг спекулятивного выполнения в цпу Intel раскрывает данные в памяти. Не относится к классу Spectre

А это вообще враньё, как мы уже выяснили. :) Не баг, не совсем спекулятивного выполнения, и не раскрывает данные в памяти. Не уверен, что остальному в этой ссылке стоит доверять...

https://gist.github.com/ford153focus/7994d4dffd7b42f7fa1cdfd9518bfc61
Blue Pill - захват запущенного экземпляра операционной системы «тонким» гипервизором

То есть запуск гипервизора, типа vmware или xen-а, там тоже считается уязвимостью? Серьёзно?

HLT - инструкция , которая прекращала выполнение дальнейших инструкций и переводила процессор в режим остановки

Лол... Для справки — эта инструкция есть во всех процессорах, и она значит «ожидать следующего прерывания». Операционки вызывают её, когда им нечего делать (idle state).

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

This includes 2 new Meltdown variants: Meltdown-PK on Intel, and

Meltdown-BND on Intel and AMD

опять же получается, что процессоры AMD в целом менее проблемны.

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

Эти баги типичны и применимы к любому процессору, в котором есть кеш. В процессорах AMD есть кеш?

причём здесь кэш, если все проблемы - порождение out-of-order execution и smt? или на ARM A53/A55 тоже нашли meltdown и spectre?

То есть запуск гипервизора, типа vmware или xen-а, там тоже считается уязвимостью? Серьёзно?

Концепция vmware или xen-а не заключается в захвате запущенного экземпляра операционной системы

Лол... Для справки — эта инструкция есть во всех процессорах, и она значит «ожидать следующего прерывания». Операционки вызывают её, когда им нечего делать (idle state).

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

опять же получается, что процессоры AMD в целом менее проблемны.

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

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

А что утверждал?

причём здесь кэш, если все проблемы - порождение out-of-order execution и smt?

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

или на ARM A53/A55 тоже нашли meltdown и spectre?

Spectre/meltdown — вряд ли, а всякие memjam или cachebleed — вполне.

Концепция vmware или xen-а не заключается в захвате запущенного экземпляра операционной системы

Интересно, а как гипервизор запустится-то? Кто его запустит, если не операционка? А если ОС его таки запустит, как он вылезет наружу, не виртуализировав ту операционку, которая его запустила?

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

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

Какого сброса? Для выхода из HLT? Да оно само выйдет при очередном прерывании таймера. Это просто ожидание прерывания. Любого прерывания. Нажатия кнопки, прихода пакета в сетевую карту, окончания проигрывания буфера в звуковухе, прерывания таймера в конце концов.

ссылки

Ссылка на рабочий код есть?
Чтобы запустить в qemu винду, в ней открыть браузер и хоп! прочитать файл example.txt в домашней директории хоста.
Или это очередная серия «хакера и солонки»?

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

Их просто проверили не сразу:
We discover 2 new Meltdown attacks, including the first
exploitable Meltdown-type effect on AMD, contradicting
previous claims by AMD

Это фигня, на самом деле. Если речь про Meltdown-BND, так он только с Intel MPX и работает. То, что они смогли с легаси #BR exception поиграться на АМД - этим только детей пугать, так как в x86-64 long mode инструкции bound нет вообще. Даже Интел официально ответил, что в этой статье ничего нового нет. Ответ АМД мне найти не удалось - похоже, им надоело читать подобные статейки. :)

Эти баги типичны и применимы к любому процессору,
в котором есть кеш.

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

и не раскрывает данные в памяти.

Раскрывает данные _о_ памяти. :) О маппингах страниц памяти.

HLT - инструкция , которая прекращала выполнение
дальнейших инструкций и переводила процессор в режим
остановки

Лол... Для справки — эта инструкция есть во всех
процессорах, и она значит «ожидать следующего прерывания».

Сам ты лол.

The HLT instruction is executed by the operating system when
there is no immediate work to be done, and the system enters
its idle state.

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

Я хз, там чувак пишет, что всё так и осталось. Ну тогда Байкал. Ах-ха-ха.

Да оно само выйдет при очередном прерывании таймера

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

по ссылке указана пачка случаев, когда оно не выходит.

По той ссылке много чего указано... Но не это. Про HLT там нет никаких случаев, только ссылка на википедию.

Похоже тебя хватило только на прочтение заголовка

Нет, меня не хватило на то, чтобы найти подтверждение этим словам. Есть только копипаста из linux bootparams, и никаких подтверждений от intel, или кого либо ещё, кроме комментария «problems on some 486Dx4's» в линуксовом ядре.

Сможешь найти, откуда он там взялся, кто его туда вписал? Я даже помогу, это версия linux-1.1.38 от 2 августа 1994-го (в те времена новая версия каждые 2 дня выходила).

Да хватит уже флудить и защищать интел, решето оно и в африке РЕШЕТО. Кто виноват? - ясно: интел конечно же, с его наплевательским отношением безопасности ради читерского прироста к производительности. Что делать? - понятно: бежать на амуде, просто потому что оно не подвержено куче интелоспецифичных уязвимостей, патчи для которых всё больше превращают синих в тыквы. Посему /thread

Да хватит уже флудить и защищать интел

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

Эх... Расслабился народ... Бездумно верят неграмотным журналистам, и потом друг за другом повторяют мифы, вроде:

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

Это ложь. Выше по треду было опровержение. Дважды.

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

Обидно, когда развеивают мифы, да?

Вам - видимо да, раз вы уже перестали отвечать на сообщения, которые ваши мифы развенчивают. :) Я, в общем, не против: развенчивать всё равно буду, отвечаете вы мне, или нет. :) Разве что зарегаетесь - тогда, может, перестану.

Это ложь. Выше по треду было опровержение. Дважды.

Ну и эту фигню я уже опроверг, Spoiler — новая уязвимость в процессорах Intel (комментарий)

Ну и эту фигню я уже опроверг,

Ссылку не ту дал, вот тут опроверг: Spoiler — новая уязвимость в процессорах Intel (комментарий)

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

Если вы так хотите, чтобы я попридирался к вашим словам...

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

Ошибка. Линию позволяет выбрать не «тег», а «индекс».

И использовалось это совсем для других целей. А вот когда они вышли за эти 12 бит, то сразу получили _новый_ сайд ченнел, который вот прям про 8 бит физ адреса инфу выдаёт. Это то понятно? :)

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

Да это они просто сверялись с ним, ну. А я всё вот про это:
SPOILER can track nearby load operationsfrom a more privileged security domain right after acontext switch.

При этом он не подглядывает маппинг ядра. А вы написали «Найдена возможность подглядывания маппинга ядра».

На это вам уже ответили. У АМД в кеш не попадают данные, которые не должны быть доступны данному процессу, и точка.

Ага. И точка. Но как же тогда названные варианты Spectre/Meltdown работают на AMD? Не через кеш?

были времена, когда про безопасность никто не думал, и АМД спокойно копировали у интела [...] Эти времена прошли, они больше так не делают

Патенты мешают.

Раскрывает данные _о_ памяти. :) О маппингах страниц памяти.

А по той ссылке написано другое. Вывод: ссылка врёт, верить ей нельзя. К тому же в такой формулировке это не уязвимость. Ведь любой виртуальный адрес «раскрывает данные о маппингах». И /proc/self/maps тоже.

Сам ты лол. [...] То, что она по прерыванию обратно из сна выходит, не отменяет её назначения входить в idle state и экономить энергию

Это никак не противоречит тому, что я написал: это инструкция, ожидающая прерывание.

Ответ АМД мне найти не удалось - похоже, им надоело читать подобные статейки.

А на другие «статейки» они отвечали?

Я помню, как они отвечали. Что «AMD is not susceptible» к Spectre/Meltdown, что «there is a near zero risk». Пока другие открыто не написали, что таки уязвимы. И ведь некоторые даже после этого продолжают верить в безопасность AMD, вера слепа...

Ну и эту фигню я уже опроверг

Не опровергли, а подтвердили, хоть и неохотно: «То, что они смогли с легаси #BR exception поиграться на АМД - этим только детей пугать». Хотите сказать, что это — случайность? Но почти все баги — случайность. От этого они не перестают быть багами.

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

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

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

Речб не о Spectre в целом, а об intel-специфичных уязвимостях и болезнях. Затыкание уязвимостей для AMD не бьёт по производительности. Вот в чём суть.

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

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

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

Касательно spectre там уязвимость в самой концепции OoO.

Может, это был вброс AMD-шников?

Google никак не тянет на подразделение AMD.

Суть этой ситуацией со spectre в том, что со времён i386 в семействе x86 появилась защита памяти процессов. На эту возможность все полагаются, поэтому при разработки софта не задумываются о безопасности. Внезапно оказалось, что эта защита памяти пробивается, а весь разработанный софт не готов к такому раскладу. И это можно было бы терпеть, как когда-то терпели незащищённость с DOS и windows до NT, если бы всё было локальным. Но с массовым вебом кто угодно может тайком загрузить свой код на компьютер удалённо, и поэтому получается глобальный адок. На защиту процессов есть спрос, поэтому этот спрос так или иначе придётся удовлетворять.

Если вы так хотите, чтобы я попридирался к вашим словам...

Я лишь хочу, чтобы вы перестали народ смущать. Ваши «придирки» к моим словам только лишь показывают ваше незнание всего и вся, увы. :(

Ошибка. Линию позволяет выбрать не «тег», а «индекс».

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

The index describes which cache set that the data has been
put in. The index length is ⌈ log 2 ⁡ ( s ) ⌉ {\displaystyle
\lceil \log _{2}(s)\rceil } {\displaystyle \lceil \log
_{2}(s)\rceil } bits for s cache sets.

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

И где пруф? Использовалось, чтобы посмотреть, что делал _другой_ процесс. А в рамках того же процесса - как использовать 4К алиас?

Во-вторых, оно не выдаёт «про 8 бит физ адреса инфу»,
только про совпадение 20 младших битов физ.адреса у двух
вирт.адресов.

То есть, вы так и не поняли, почему в статье везде фигурировала цифра 8 бит, и почему сайд-ченнел именно новый? Ну, ничего не могу поделать, я объяснял как мог.

Ага. И точка. Но как же тогда названные варианты
Spectre/Meltdown работают на AMD? Не через кеш?

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

Это никак не противоречит тому, что я написал: это
инструкция, ожидающая прерывание.

Только вы написали лол, будто бы вам что-то неверное сказали про idle state. А теперь отмазываетесь.

Я помню, как они отвечали. Что «AMD is not susceptible»
к Spectre/Meltdown

Что за очередная чушь? :( Они про спектре никогда такого не говорили. Говорили лишь, что его сложнее на их процах осуществить. Однако, сразу добавили барьерные инструкции в микрокод, пропатчили винду вместе с микросовтом - сделали всё, что надо. А про мельтдаун - говорили.

Не опровергли, а подтвердили, хоть и неохотно: «То, что
они смогли с легаси #BR exception поиграться на АМД - этим
только детей пугать». Хотите сказать, что это — случайность?

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

Я всего лишь пытаюсь заставить людей думать

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

Блин, вот привыкнешь, когда аноним херню пишет, а потом
приходишь ты и вызываешь когнитивный диссонанс. Спасибо.

Да братан, начинаю понимать, о чём ты меня предупреждал. :) Что тут вообще принято делать с подобными анонимусами то? Ликбезам они не внемлют, читать ничего не хотят, пишут реально херню, игнорируя все попытки навести их на верное русло... Что с ними делать то? :)

ну вот давайте мне пруф, что, в наше время, индекс выбирает не кеш сет, а линию...

Что за приписки «в наше время»? А, что, в ненаше время было иначе?

«Пруф» о том, что такое тэг, есть в той же статье википедии, которую вы цитировали. Но что толку от пруфа, если вы не думаете даже над тем, что сами пишете. Просто включите мозг. Вы писали:

У VIPT кэша могут быть потенциальные алиасы по физ
адресам, когда тэг совпадает, а адреса по факту разные.

Но «PT» в VIPT означает Physically Tagged, то есть тэг берётся из физического адреса. А сабжевая статья замеряет задержку, когда физический адрес недоступен («false dependencies may occur due to the unavailability of physical address»). Внимание, вопрос 1: как «могут быть потенциальные алиасы» при совпадении тэга, если информации о тэге нет?

Можно даже проще. В адресе есть только тэг, индекс и смещение. И вы утверждаете, что тэг совпал. Очевидно, индекс и смещение тоже совпали, раз мы смогли выбрать адрес в кеше. Внимание, вопрос 2: как могут отличаться адреса, но совпадать тэг, индекс и смещение, если кроме них в адресе ничего нет?

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

И где пруф? Использовалось, чтобы посмотреть, что делал _другой_ процесс. А в рамках того же процесса - как использовать 4К алиас?

Я, вроде, уже несколько раз об этом писал. 4к-алиас использовался для «подглядывания» за _другим_ процессом в атаках вроде MemJam. В сабжевой статье для тех же самых целей описали применение 1МБ алиаса, со ссылкой на тот самый MemJam.

То есть, вы так и не поняли, почему в статье везде фигурировала цифра 8 бит, и почему сайд-ченнел именно новый?

Я-то понимаю. Я просто исправляю вашу неверную, неполную, или умышленно искаженную формулировку. Разве моя формулировка неверна?

Никак мельтдаун на АМД не работает

А те исследователи пишут, что работает. Кому верить, им, или вам?

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

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

Как можно их вообще смешивать воедино? Это 2 принципиально разных подхода.

Э... Meltdown и Spectre — это два (точнее, пара десятков) разных векторов атаки на одну и ту же уязвимость: влияние спекулятивных инструкций на кеш. Они даже эксплуатируются одинаково — выбранный спекулятивный код меняет кеш в зависимости от искомой информации. Затем спекуляция откатывается, а изменение в кеше остаётся, и его обнаруживают.

Как можно их смешивать? Так как это сделали в той статье. Именно объединение их в общую классификацию позволило найти 6 новых векторов атаки, в том числе и для AMD.

Что за очередная чушь? :( Они про спектре никогда такого не говорили.

Там была ссылка. Я процитирую, если вам лень кликать. В первых числах 2018-го были опубликованы те самые первые 3 варианта атаки, их назвали: Meltdown, Spectre-V1 и Spectre-V2. AMD заявила: «AMD is not susceptible to all three variants». Чушь? Да, AMD заявила чушь.

Чёрт вас побери, я хотел сказать ровно то, что сказал: что в лонг моде нет инструкции bound!

Тогда как это опровергает мои слова? Вы же писали «эту фигню я уже опроверг». Пусть в 64-битном режиме её нет, а в 32-битном она есть. И 64-битные процессоры могут выполнять 32-битный код. Это позволило эксплуатировать meltdown на 64-битном процессоре AMD.

боюсь, все вас тут игнорить начнут, если ещё не начали.

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

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

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

А, да...

Только вы написали лол, будто бы вам что-то неверное сказали про idle state. А теперь отмазываетесь.

Лол был связан с тем, что инструкцию HLT перечислили в списке cpu «fail»-ов. Ведь ожидание прерывания — это такой фейл... ;)

«Пруф» о том, что такое тэг, есть в той же статье википедии,
которую вы цитировали.

Я просил пруф на ваше определение индекса. Очевидно, что его не будет, после того, как я нормальное вам подсунул.

включите мозг. Вы писали:

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

В сабжевой статье для тех же самых целей описали применение
1МБ алиаса, со ссылкой на тот самый MemJam.

Нет. Основная идея в том, что 1Мб алиас можно применять и в рамках того же процесса, а вот 4К - нельзя. Дополнительный сайд-ченнел для поиска евикшн сетов.

Они обе лечатся в софте, потому что лечение в железе
непонятно как реализовать,

Если вам непонятно, как лечить meltdown в железе, то это проблемы исключительно ваши. Когда вы поймёте, чем он вызван, и чем отличается от спектре, будет полностью понятно, как его лечить в железе. А на счёт сроков - инфа тоже не секретна: https://www.digitaltrends.com/computing/intel-9-series-cpu-spectre/

Э... Meltdown и Spectre — это два (точнее, пара десятков)
разных векторов атаки на одну и ту же уязвимость: влияние
спекулятивных инструкций на кеш.

Твою мать, да почитайте уже хоть что нибудь! https://ru.wikipedia.org/wiki/Meltdown_(уязвимость)

Я бы мог объяснить вам технические детали различий, но просто это бесполезно. Если всё, что вы об этом знаете, лишь что это «влияние спекулятивных инструкций на кеш» (что, безусловно, верно, но это определение из детского сада), то с вами бесполезно что-либо обсуждать. Остаётся уповать лишь на то, что первую строчку (хотя бы именно первую) из википедии вы осилите, а звучит она вот так:

Meltdown — аппаратная уязвимость, обнаруженная в ряде микропроцессоров, в частности, производства Intel и архитектуры ARM. 

Чушь? Да, AMD заявила чушь.

Сложно сказать, что там они заявляли, и откуда вообще была эта фраза взята. Официальные источники их вот тут: https://www.amd.com/en/corporate/speculative-execution-previous-updates#parag... И тут всё понятно. А ваш текст, вероятно, какие-то маркетологи произнесли, имея в виду, что дыры в проце нет, а фиксы в софте - не их проблемы.

Пусть в 64-битном режиме её нет, а в 32-битном она есть.
И 64-битные процессоры могут выполнять 32-битный код.

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

И вы почему-то пытаетесь доказать, что знаете её лучше меня.
Не понимаю, зачем?

Если вы не знаете, что такое тег и индекс, то приходится «доказывать». И именно доказывать, так как просто пойти да почитать вы отказываетесь наотрез.

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

Гениально.

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

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

И ещё я говорил то, что с тегами - это лишь аналогия к той
статье - она не обязана быть точной.

Кстати, как я уже говорил, и VIPT - тоже была лишь упрощённая аналогия. Ведь с VIPT евикшн сеты находить - проблем не составляет. Я сожалею, что использовал VIPT в качестве аналогии, так как, похоже, именно это вас довольно серьёзно сбило с толку (по крайней мере, до этого вы говорили вполне адекватные вещи). Надо всё-таки избавляться от подобных упрощений, и понимать, что LLC, который они атаковали - не VIPT. А тег таки может совпадать, да, но если вы аналогии с ВИПТом доверились, то я извиняюсь, ведь это может в корне исказить понимание (что, в конечном итоге, и произошло).

и бояре на AMD с ехидной улыбкой в сторонке

По той ссылке много чего указано... Но не это. Про HLT там нет никаких случаев, только ссылка на википедию.

т.е. для амбасадоров интуля неочивидно, что файл на gists - лишь собрание ссылок на сторонник ресурсы с описанием в 1-2 предложения?

т.е. ссылка второго уровня для амбасадоров интуля - неподъёмная ноша?

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

А что утверждал?

//_-

процессоры AMD в целом менее проблемны

Spectre/meltdown — вряд ли, а всякие memjam или cachebleed — вполне.

пруфы в студию

не виртуализировав ту операционку, которая его запустила?

подробнее с этого места - как и зачем xen захватывает хостовое ядро

держи, можешь выдрать отсюда по крупицам

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

Это ложь

Почему? Вы же не станете утверждать, что Intel не подвержен мельдауну, что гипертридинг у него не дырявый, и т.д.? А ведь это всё интелоспецифичные уязвимости! И даже если вдруг вам, анону с ЛОРа, вдруг удалось «утереть нос» экспертам мирового уровня насчёт конкретно этой интелоспецифичной уязвимости (в чём, без обид, я очень сильно сомневаюсь) - чаша терпения уже давным давно переполнена. И серьёзным людям, для которых информационная безопасность не пустой звук, давно пора валить с дырявых систем на относительно недырявые: AMD, например; разумеется на тот который без аппаратного бэкдора PSP (аналог Intel ME), и желательно на те материнки которые поддерживаются опенсорсным БИОСом coreboot - потому что бэкдоры могут сидеть и в закрытом UEFI. В-общем, выбрать для себя секурный комп достаточно несложно: заходишь на https://coreboot.org/status/board-status.html и смотришь по AMD: почти всё, кроме поздних плат от PC Engines, - без PSP.

VIPT - тоже была лишь упрощённая аналогия [...] но если вы аналогии с ВИПТом доверились, то я извиняюсь, ведь это может в корне исказить понимание (что, в конечном итоге, и произошло).

Ой, да не проблема. Я с самого начала подумал, что это было упрощение, просто отметил, что в нём есть ошибки, и даже не собирался их обсуждать. Дискуссия завязалась, когда вы написали «почему эта фраза взята в кавычки? Я-то точно такой фигни не писал». Ладно, оставим вопрос тегов, индексов и VIPT-ов, у нас хватает интересных тем для обсуждения.

Основная идея в том, что 1Мб алиас можно применять и в рамках того же процесса, а вот 4К - нельзя. Дополнительный сайд-ченнел для поиска евикшн сетов.

Я не совсем понимаю о чём речь... Евикшн сет не связан с процессами. Да и анализ «4K-Aliasing within a single process» был в работе [46], на которую они ссылаются.

Забавный получился диалог:

— Что за очередная чушь? :( Они про спектре никогда такого не говорили.
— Говорили. (ссылка и цитата)
— Сложно сказать, что там они заявляли ... вероятно, какие-то маркетологи произнесли, имея в виду, что дыры в проце нет, а фиксы в софте - не их проблемы.

Ну по крайней мере разобрались, что всё-таки заявляли. А имели ли они ввиду что это не баг проца... Кстати! А вы, правда, считаете, что Spectre — это баг в софте? Что ж... Давайте рассмотрим его.

Spectre на пальцах. Имеем код вида:

if (function_returning_false()) {
  haha = a[secret[x] & 64];
}

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

Твою мать, да почитайте уже хоть что нибудь! https://ru.wikipedia.org/wiki/Meltdown_(уязвимость)

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

Я бы мог объяснить вам технические детали различий

Кстати... А давайте! Объясните! Если не мне, то, может быть, другим пригодится ваше объяснение.

Покуда CONFIG_32BIT ни отключить

CONFIG_32BIT ?

т.е. ссылка второго уровня для амбасадоров интуля - неподъёмная ноша?

Подъёмная. Только ни по ссылке второго, ни третьего уровней нет подтверждение этим словам. Есть только копипаста из linux bootparams, и никаких подтверждений от intel, или кого либо ещё, кроме комментария «problems on some 486Dx4's» в линуксовом ядре.

Сможешь найти, откуда он там взялся, кто его туда вписал? Я даже помогу, это версия linux-1.1.38 от 2 августа 1994-го (в те времена новая версия каждые 2 дня выходила).

А что утверждал?

процессоры AMD в целом менее проблемны

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

подробнее с этого места - как и зачем xen захватывает хостовое ядро

Ой, не, не в этот раз, это обсуждение очень надолго. Гугли истории по словам BluePill, RedPill, Joanna Rutkowska, и то как с ней спорил Thomas Ptacek, который считал, что сможет отличить BluePill от других софтин аппаратной виртуализации.

Забыл:

пруфы в студию

ARMageddon

Почему?

Потому что эти уязвимости не специфичны для Intel-а. Есть специфические вектора атаки. А специфических уязвимостей очень мало.

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

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

что гипертридинг у него не дырявый, и т.д.?

Стану. Не более дырявый, чем AMD-шный SMP, насколько я знаю.

И даже если вдруг вам, анону с ЛОРа, вдруг удалось «утереть нос» экспертам мирового уровня насчёт конкретно этой интелоспецифичной уязвимости

Да я-то тут причём? Я ж на чужие работы ссылаюсь. «Утереть нос» я могу только неграмотным новостеписателям, которые даже не пытаются разобраться в том, о чём пишут.

чаша терпения уже давным давно переполнена.

Меня беспокоит, что она переполнена ложью.

Я ничего не сделаю, если для вас Intel хуже AMD по религиозным причинам (например, потому что у них в названии 5 букв, а вашей религии это число зла). Но если вы думаете, что Intel хуже, потому что про его баги чаще пишут, то всё ровно наоборот.

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

А ещё Intel просто чаще встречается, и AMD спасает эффект неуловимого джо. Поэтому в некоторых исследованиях можно увидеть что-то вроде:

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)

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

Ну вот приходим опять к тому, что дыра в АМД может и есть, а может и нет. Да-да. «видишь суслика?»

AMD спасает эффект неуловимого джо.

И тем не менее, AMD уже подтвердили свою меньшую проблемность. Я сейчас предлагаю посмотреть, что произошло после патчей l1tf и обновления микрокода как для красных, так и для синих. И, как выяснилось, у красных всё несколько лучше.

как и зачем xen захватывает хостовое ядро

XEN по определению запускается до запуска хостового ядра, и хостовое ядро виртуализировано в нём по умолчанию. Изменить это поведение ЕМНИП нельзя.

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

это нужно адресовать анону, который сравнил blue pill с xen

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

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

спасибо, добавил в список

Я не совсем понимаю о чём речь... Евикшн сет не связан с
процессами.

Евикшн сет связан с тем (в случае, если это не VIPT, my bad), что надо физ адреса свои найти. Через 4К алиасинг это не сделать, а через 1м - можно. Именно по этому, SPOILER - новый сайд ченнел, и новый метод поиска эвикшн сетов.

Да и анализ «4K-Aliasing within a single process»
был в работе [46], на которую они ссылаются.

И что от него было толку? Он маппинг физ адресов в той работе не находил, да и вообще, он там только в начале описан, а потом идёт MULTI-PROCESS4K-ALIASING. Нас не интересует сейчас «we show that 4K-aliasing can also be used to reliably detect multi-tenancy», и зачем вы это привели - непонятно.

Ну по крайней мере разобрались, что всё-таки заявляли.

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

А вы, правда, считаете, что Spectre — это баг в софте?

Да я, вообще-то, это знаю, а не считаю.

Где тут ошибка в коде.

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

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

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

Кстати... А давайте! Объясните! Если не мне, то, может
быть, другим пригодится ваше объяснение.

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

CONFIG_32BIT ?

Ну! Дошло наконец? Или вы не знаете как ядро линукса конфигурировать? Видимо, не знаете, раз упорно продолжаете нести ту же чушь в соседних сообщениях, хотя уже должно быть очевидно, что на АМД мельтдаун не работает, включая и meltdown-bnd, так как CONFIG_32BIT никто на сервере не включит. Что непонятного то?

Пусть в 64-битном режиме её нет, а в 32-битном она есть.
И 64-битные процессоры могут выполнять 32-битный код. Это
позволило эксплуатировать meltdown на 64-битном процессоре
AMD.

Кстати, а вы вообще давно видели инструкцию bound в ядре, или в юзерспейсе, пусть даже в 32-битном? Ась? А вот интеловые bndcl/bndcu могли и видеть. Всё ещё будете утверждать, что мельтдаун работает на АМД? :)