Забавная новость про ошибку в интеловских процессорах

Как с таким багом оно работает?

Очевидно данная комбинация инструкций редко используется.

А если вместо rsi rdi другие регистры, или другое смещение вместо единицы, или вместо ch другой регистр из списка ah dh bh - тоже младшие биты запишет?

llvm bruh moment

Как с таким багом оно работает?

Потому что CH и с ним подобные - страшное легаси, которое через mov будет выполняться не одной инструкцией, а тонной микроопераций (µops). Можно предположить, что

mov byte ptr [rsi + rdi + 1], ch

Будет декодирована в что-то типа

uop1: вычислить адрес RSI + RDI + 1
uop2: взять байт из RCX
uop3: положить байт в store buffer
uop4: позже записать store buffer в L1/cache/memory

И где-то в районе uop2 оно конкретно в этом пайпе обосралось, взяло не CH (8..15), а его близнеца с REX префиксом или просто CL (0..7).

Скорее всего даже не сам микрокод кривой, а из-за физических деформаций на производстве конкретно в этом месте в почти 100% вероятности есть деградация (наплыв/пробив/облысение) дорожки, что меняет путь получаемого байта. ЕМНИП это на рапторе были проблемы с перегревами/zlib-rs/deflate. Это ж вообще полуэкспериментальное поколение, что intel вынудили высрать на рынок.

Внесут патчи в LLVM/GCC, чтобы он бил на

mov eax, ecx
shr eax, 8
mov byte ptr [rsi + rdi + 1], al

Как будто первый такой патч в истории, ага. Там код LLVM/GCC на 90% состоит из подобных извратов, потому что железо - говно, архитектура - говно (особенно прикол с встречающимися стеком и кучей), выполнение данных как кода? Легко!

https://github.com/trifectatechfoundation/zlib-rs/pull/520/files

Тут пишут что mov mem,ch превращается в двухбайтовый mov и портит следующий байт.

Могу предположить что оно превращается в mov mem,cx но данных для гадания определённо недостаточно, да и комментарий по ссылке доверия не вызывает.

У кого-то же есть этот проц на лоре наверно? Можно ж проверить самим.

Потому что CH и с ним подобные - страшное легаси

С каких это пор он легаси? Вредители постарались?

А ещё теория заговора.

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

Дак вы почитайте errata к процессорам современным. Полюбуйтесь на wontfix к заметной части багов. А это вполне возможно что микрокодом починят

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

Слишком ненадёжно.

Производственный цикл процессоров долгий. От внедрения бекдора до возможности эксплуатации пройдут годы.

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

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

И тут не производственный цикл проца, а производственный цикл микрокода, это намного короче.

Или нацелено на проприетарщину какую-то. Или на какую-то криптографию на ассемблере.

Может быть.

ужас когда у тебя калькулятор не может 2 однозначных числа сложить.

Напомнило «Машину Трурля» Лема:

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

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

— Да? - сказала машина. - Так сколько будет два плюс два?

— Че… то есть семь… - еще тише проговорил Трурль.

А есть кто шарит в компиляторах? Почему так получилось. В LLVM 23 этот баг исправлен, а проявляется он в версии 22, как я понял из прочитанных постов.

Чот нифига не работает этот ваш баг https://hastebin.com/share/eturuxuyaw.asm Нихрена не могут сделать толком ржависты, даже баг. Зато новость разнести по интернетам это пожалуйста

Это баг процессора, а не компилятора.

У тебя проц «Raptor Lake 13 и 14 поколений» и прога вывела 11AA?

Как с таким багом оно работает?

«Никогда такого не было, и вот опять.» Тебе сколько лет?

А нужные люди в курсе.

В ноутбуке 1370p. То есть да, 13 поколение, raptor lake-p

У меня вывело.

taskset -c 0 ./rpl_bug
11AA
cat /proc/cpuinfo
model name      : 13th Gen Intel(R) Core(TM) i7-13700KF

Не работает.

А этот исходник по ссылке ты сам написал или это пример от исследователей бага?

Может там ещё какие-то условия, например перед buff дописать db 0 чтобы он был не выровнен по 2-байтовой границе. Или записывать значение не mov ecx,11ff а mov rcx,11ff. Или записывать его где-то в другом месте чтобы к моменту записи в память проц уже забыл когда он записывал значение в rcx.

Сам написал. Прочитал пост на лоре. Взял инструкцию, которая указана и использовал её

Дедушка, там по ссылкам пишуть что воспроизводится на E-ядре(Gracemont). А 0 это скорее всего P. Не знаю как у тебя, но у меня нумерация такая - сначала все P ядра идут, потом все E

Все пробовал, 0-23.

Охренеть! Как с таким багом оно работает?

Чем отличатся от: код тесты прошёл, в проде работает год-другой. А тут бац всплывает «Эффект последней строки».

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

фейлилась иногда, а не каждый раз.

Если оно еще и тайминг-зависимое, то вообще удачи.
Это как у AMD во времена Llano целочисленный делитель иногда давал неправильный ответ. Пришлось его полностью отключать на уровне микрокода.

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