The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Уязвимость Reptar, затрагивающая процессоры Intel, opennews (?), 15-Ноя-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


133. "Уязвимость Reptar, затрагивающая процессоры Intel"  +1 +/
Сообщение от ckotinko (ok), 16-Ноя-23, 00:44 
в общем, на входе стоит "декодер длины команд". из него получаются макро-операции, которые идут в очередь макроопераций.

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

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

также не наш случай - кэш микроопераций. там 18 команд на 32байта, то есть описание причин сбоя неверное.

сложные команды которые являются номером в таблице + набором полей imm32,reg1,reg2,reg3,размер. в таблице лежит адрес кода в прошивке который будет выполнен. в микрокоде наверняка есть специальные псевдорегистры для указания временных регистров, или подстановки reg1,reg2,...imm. почему таблица? потому что прошивка может меняться и адреса в ней плавают. префиксы также влияют на адрес в таблице, например выставляют какой-то бит в опкоде. rex префикс ну просто явно выставляет какие-то биты и ничего больше не делает. ну в общем так бы я делал.

дальше начинает работать код из MS-ROM, который смотрит на то какой был опкод, какие были регистры и т.д. и тут интересный момент: rex.w + movsb = movsq, допустимая команда. а вот rex.r нет. пропуски ветвлений и ветвления мимо кассы могут указывать что команды после сбойной movsb просто не выполняются. походу добавленный код FSRM улетает куда-то по левому указателю или может быть даже делает это намеренно.

кто нибудь проверьте в коде теста на багу следующие варианты правок в однопоточном варианте. в icebreak.asm вот этот код:

rep
rex
rex     r
movsb

на такие варианты:

rep + rex r + movsb
rep + rex b + movsb
rep + rex x + movsb
rep + rex + rex w + movsb
rep + rex + rex b + movsb
rep + rex + rex x + movsb

и еще те же варианты + в начале mov rdx, rsp, заполнить [rsp-64, rsp-8] нулями + сразу после багокоманды команда call $0 (0xe0 0 0 0 0 20 раз) и сохранить данные из стека [rdx-64, rdx-8]. и потом mov rsp, rdx. тогда можно будет точнее сказать что там происходит

алсо оказывается с множественными rex-префиксами кто-то уже натыкался на крахи еще в 2016м году
https://keyboardsmoke.wordpress.com/2016/09/26/multiple-rex-.../
I have run into crashes in some circumstances with certain (unknown) combinations of REX bytes, but the examples here seem to work, and I can’t see any clear difference in the state of the program.

Ответить | Правка | Наверх | Cообщить модератору

136. "вообще, поясню что именно вызывает такое поведение"  +1 +/
Сообщение от ckotinko (ok), 16-Ноя-23, 08:17 
>There are more complex instructions that are not trivial to be decoded even by complex decoder. For instructions that transform into more than four µOPs, the instruction detours through the microcode sequencer (MS) ROM. When that happens, up to 4 µOPs/cycle are emitted until the microcode sequencer is done. During that time, the decoders are disabled.

код который находится в MS-ROM может выполнять ряд операций, вообще не возможных из обычного х86. в том числе и проверять наличие строк в кэше, и получать доступ к шине непосредственно, в отличие от обычных команд. именно на это намекали разрабы интел когда говорили что rep movsb может работать параллельно с кодом находящимся после него и при этом его записи в память неупорядочены.

теперь смотрите: многопоточный сбой в rep movsb приводит к ошибкам MCE. это напрямую связано с ручным рулением шиной. то есть там есть команды которые шатают шину напрямую и при сбое это шатание приводит к  machine check exception. То есть на интеле можно шатать шину из микрокода например.

Ответить | Правка | Наверх | Cообщить модератору

161. "вообще, поясню что именно вызывает такое поведение"  +/
Сообщение от Tron is Whistling (?), 17-Ноя-23, 23:07 
MCE - это не обязательно шатание шины
Это может быть ошибка вторичного декодирования или что-то ещё
Ответить | Правка | Наверх | Cообщить модератору

165. "вообще, поясню что именно вызывает такое поведение"  +/
Сообщение от ckotinko (ok), 18-Ноя-23, 04:40 
> MCE - это не обязательно шатание шины
> Это может быть ошибка вторичного декодирования или что-то ещё

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

Ответить | Правка | Наверх | Cообщить модератору

168. "вообще, поясню что именно вызывает такое поведение"  +/
Сообщение от Tron is Whistling (?), 18-Ноя-23, 11:10 
Вполне возможно, что это просто вторичный результат шатания кривым микрокодом всего, что под руку подвернётся. Ошибка декодирования на блоках исполнения - тоже себе MCE.
Ответить | Правка | Наверх | Cообщить модератору

151. "Уязвимость Reptar, затрагивающая процессоры Intel"  +/
Сообщение от Tron is Whistling (?), 16-Ноя-23, 22:33 
Есть мнение, что интереснее будет поиграться с прочими регистрами перед забаговкой, и посмотреть - меняется ли что-либо. Но разные регистры надо показывать на начало страниц памяти, заполненных разными паттернами.
Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

152. "Уязвимость Reptar, затрагивающая процессоры Intel"  +/
Сообщение от Tron is Whistling (?), 16-Ноя-23, 22:34 
Если оно действительно врезает в очередь микрокоманд данные из заданного источника - то при перетасовке паттернов будут заметно разные но повторяющиеся фичи.
Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру