Тэвис Орманди (Tavis Ormandy), исследователь безопасности из компании Google, выявил новую уязвимость (CVE-2023-23583) в процессорах Intel, получившую кодовое имя Reptar и в основном представляющую опасность для облачных систем, в которых выполняются виртуальные машины разных пользователей. Уязвимость позволяет вызвать зависание или аварийную остановку работы системы при выполнении в непривилегированных гостевых системах определённых операций. Для тестирования своих систем опубликована утилита, создающая условия для проявления уязвимости...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60116
> процессорах Intelчот дырявые какие камни пошли
это ты еще AMD не видел
AMD не трогай, лучшие процессоры.
Любые процессоры нельзя трогать. Только обезьянки всё равно лапают. Потому б/у-шные процы покупать стрёмно.
Ну, я понимаю, когда не хочешь пользованные, но когда сам пыской по нему елозишь, в чём проблема? Все фанбои этим занимаются, вроде, не жалуются.
Проблема в статическом электричестве (ну и ещё в жире, в особо кривых руках). Потом она перетекает в "а что-то у меня USB перестал работать, а pci-e срывается в 8x". Хуже всего что даже в сервис-центрах порой не знают что такое антистатические браслеты.
не в статике( если не в шерстяной кофте и бьёшь искрами по процу )
а в жирных и потных лапах фанатов. И контакты загаживаются и коррозия может пойтиА статики полупроводники сильно боялись лет 40 назад. Тогда даже полевики до применения или в фольгу заворачивали или все лапы скручивали
Без заземления взял за отдельную ножку, даже искр никаких не было - а детали уже конец, можно выбрасыватьСейчас все выводы обычно являются стойкими к статике от человека
Да-да, конечно! Транзисторов ежегодно добавляют миллионы, но они толще, прочнее и плюют на физику!
Нет. Вот инструкция от.. - батюшки! - самих АМД! https://www.youtube.com/watch?v=qDB5ht47iKg Первые 15 секунд видео. ЧТОБ ВСЕ ВИДЕЛИ!
Вот всегда было интересно
Почему пасту толстым слоем на камень, а не тонким слоем на кулер?
Разве можно работать с продукцией AMD такой отверткой? Винты нужно закручивать динамометрическим ключем с определенный усилием при определенной температуре.
Это и есть динамометрическая отвёртка, он разве об этом не говорит?
это общие рекомендации вроде не ходить летом без шапки а то продует
Там на каждый вход по стандарту добавляют по подобию стабилитрона( это стандарт что для транзюков что для ИМС )
Эта конструкция запросто держит заряд от человека, но сколь-нибудь мощные токи уже не тянет
Не помню точно уже, но, то ли до 800 то ли до 2000 В кратковременно
> Да-да, конечно! Транзисторов ежегодно добавляют миллионы, но они толще, прочнее и плюют на физику!Представляешь, мистер эксперт, транзисторы на I/O можно делать более жирными и прочными чем остальные. Это раз.
Ну а защита от статики по входу стала стандартным атрибутом всех CMOS микросхем. Схемотехнически просто как мычание: 2 диода последовательно в GND и Vcc, сливающие заряд в рельсу питания.
> Нет. Вот инструкция от.. - батюшки! - самих АМД!
А таки современные чипы не идут ни в какое сравнение с древностями которые умирали чуть ли не от дуновения ветра и страшилки требовали аж хранить чипы в фольге, а то и с закороченными лапками. Емкость полевика на входе мизерная, вольтаж от статики легко выбивал оксид входного MOS транзистора после чего тот становится тыквой, навсегда. Сейчас по сравнению с этим просто халява. Потому что чипов без защиты IO от статики уже просто не делается на этой планете много лет. То что если постараться можно и с защитой угробить - другой вопрос.
По-моему, ты сильно переоцениваешь возможность этой "защиты". Спасает она, в основном, не от котиков и мамкиных оверклокеров, жонглирующих камнями на кровати, а от пыли, пролетающей на большой скорости рядом, особенно в 1-2U-корпусках с вентиляторами на 15КОб/мин и при низкой влажности.Не, ты, конечно, надейся, но потом не удивляйся: https://www.youtube.com/watch?v=bZym-6TOGXc
кондёры лопаются
лучшие процессоры еще не придумали
Лучшие процессоры это MOS 6502, ну или Zilog Z80
А все эти ваши интелы и амд, гоуно глюкавое, мусор одним словом.
Вы ещё забыли про более голубое небо, более зелёную траву и баб. Более сочных, более приятных во всех отношениях.Как вы могли это не упомянуть?!
какое ещё небо, какой нафиг баобаб! ты давай с травой то завязывай!на MOS 6502 работает киборг Т-800 и Бендер из Футурамы!
а ваши интелы и амудэ в масленные радиаторы ставят, как нагревательный элемент!
> AMD не трогай, лучшие процессорыТогда новостью выше почитай 🤣
нет, а что там ?как я помню, последних 5-8 лет уязвимости в основном связаны с Штеуд, хоть mentdown какой-нить
это называется "избирательная память"
Это называется фанатизм к Интел иначе интелофилия. Желания защитить Интел в любом явном провале.
Ты неправ и проецируешь. Любителей Интела не существует, существуют только АМДфанбои. Как правило, это родовая травма.
>Любителей Интела не существуетЛукавишь, если не сказать грубее.
> Лукавишь, если не сказать грубее.Ну, может быть, среди таких, кто не понимает, что это вообще за волшебные коробки такие, и как они устроены, они и найдутся. Ты когда-нибудь встречал тех, кто бы был уверен в непогрешимости и неуязвимости продукции Интела?
При этом многие отдают ей предпочтение, зная о недостатках, естественно. Это не совпадение, распространённость выше, меньше проблем с ПО, более предсказуемое железо (например, без проблем с усб или сегфолтами компилятора, вопросов производительности и багов многопотока). Если посмотреть, это всё выглядит как пиар-компания, и вполне успешно поднялся процент облачных внедрений продукции компании-аутсайдера. Непонятно только, зачем "поклонники" так переживают о том, что их едва ли касается.
>как я помню, последних 5-8 лет
Спасибо!
видел, кроме дырени в старых эпиках в PSP, и нескольких проблем со спекулятивным исполнением больше ничего и не вспомнить, все было залатано достаточно безболезненно либо в прошивах либо в ядре (а на новых поколениях начиная с зен3 многое вообще не проявляется), чего не скажешь про интел и по количеству дыр, и по последствиямда AMD тоже подвержен подобным атакам, но интел в плане вообще дуршлаг
> видел, кроме дырени в старых эпиках в PSP, и нескольких проблем со
> спекулятивным исполнением больше ничего и не вспомнить,- Вот те раз подумал Штирлиц.
- Вот те два подумал Борман пуляя второй кирпич.https://www.opennet.dev/openforum/vsluhforumID3/132067.html однако. Не такой позор как у интеля, но тоже фейл.
> это ты еще AMD не виделЗавидуйте молча^W^W им в соседней новости насыпали, наслаждайтесь на пару! Но там все же не так брутально.
AMD в последнее время не лучше:https://en.wikipedia.org/wiki/Transient_execution_CPU_vulner...
Про CacheWarp Максим сейчас пишет новость: https://cachewarpattack.com/
Усложнение логики ведет к увеличению лог. схем в камне, что ведет к большему кол-ву потенциальных дыр.
Все логично.
В "наше всремя" скорее проблема в том что о безопасности не думали в "то время". Ну какие контейнеры в 1980ых? Там даже мультизадачности почти не было.
> Там даже мультизадачности почти не было.В Intel 386 уже была, другой вопрос, что NT 3.1 вышла только в 1993 году.
От 'того времени' в современном железе мало чего осталось, в основном только названия
Всегда покупал AMD.
Тоже уважаю AMD. Но так получилось, что на всех доступных 7 компьютерах установлены Intel. Чисто случайно.
Core2duo топчик за свои деньги
За свои деньги топчик Xeon E5 v4
"Топчик за свои деньги" проигрывает в соотношении цена/качество любому рабочему говну, подобранному на помойке бесплатно.
Кстати, топчик среди ошибкок студентов в ТЭО :)
Спорно, т.к. говно с помойки жрет электричество как не в себя, и очень вскоре е5 окупит себя если учитывать эноргозатраты на полученную вычислительную мощность и сделанную работу. Банальный пример - задача рендеренга видео, компиляция программ.
Vulnerability Lake.
https://en.wikipedia.org/wiki/Lake_of_fire
Lake of Tears
Lake of Tears - Headstones
Интересно как явные бекдоры в перемешку со случайными ошибками вылезают с течением времени. Шило в мешке не утаишь.
Особенно когда надо убедить покупать новую продукцию. Вы заметили, кстати, что в данном случае уже и Альдеры с Сапфирами сливать начали, как "уязвимые"?
Бизнес план такой. Сегодня они делают закладки в процессоры за вознаграждение от госведомств. Выходит новая линейка процессоров, они вскрывают старые карты (иногда - за вознаграждение) подталкивая крупных потребителей к массовому обновлению - прямым покупкам. Массовая слежка + запланированное устаревание = двойной профит.
Было бы славно подкинуть Microsoft идею о том, чтобы Windows 12 не поддерживала эти поколения процессоров из-за их низкого уровня безопасности.
Тут не в процессорах дело. На Гравитоны вообще не удалось Windows поставить.
А linux?
Runtu 22.04 - нет драйвера встроенной сетевой карты, с отдельной картой - нормально. Astra и SE, и CE отлично встает.
А ты не юзай русские дистры.
Сетевка - любимый производителями дешман-Realtek?
Гравитоны - кто/что такие?
Частицы, которые создают эффект гравитации.
Он, похоже, имел ввиду какое-то семейство CPU или платформ.
Отечественный производитель компьютеров
> Он, похоже, имел ввиду какое-то семейство CPU или платформ.Ну так гравитоны - такая частица что хрен ее отловишь и заметишь. Вроде бы теоретически она где-то есть. Практически удачи ее обнаружить, за столько лет пока не получилось.
Ну вот гипотеза о причинах вообще реальной не выглядит.
Длину операции в буфере неправильно посчитали? На фиксированной-то длины префиксе модификации аргумента, не имеющем для этой операции значения, и на фиксированной микрокодовой операции без аргумента?
Больше напоминает заботливо оставленное технологическое отверстие, возможно внутренне документированное, в которое в теории никто потыкаться не должен был по указанным выше причинам.
Вполне возможно, что отверстие таки дебажное, для врезки произвольных микроопераций из заданного источника (и команда таки удобная). Поскольку кодирование таковых не известно - эффекты соответствующие, что оно там при этом начинает исполнять - без внутренних доков никому не известно.
Гражданин, вы совсем отстали от жизни в своём уютном колхозе. Технологическое отверстие давно расширили и теперь оно называется Intel ME и AMD PSP. А это очевидный баг.
Ну то есть получается, что интел сделал баг в двух соснах на ровном месте? С чем и поздравляем.
У repsx/movsx нет флага imm, т.е. префикс размер инструкции поменять не может.
А если бы он вдруг был - декодирование repsx/movsx вообще бы не работало.
Нет, что-то здесь не то (tm)
Пырашу пыращения, rep/movsx, а не repsx/movsx.
> Ну то есть получается, что интел сделал баг в двух соснах на
> ровном месте? С чем и поздравляем.Ты только сейчас заметил реальный уровень инженерии интела и их приоритеты? С чем и поздравляю! Бывало и покруче, типа выгорающих SATA и USB из-за грубых ошибок в дизайне чипов или халтуры/экономии на спичках. И тут кого-то удивляет такая мелочь.
Человек, просто для понимания, драйвер i915 - состоит из воркэраундов глюков чипа чуть менее чем полностью. Как и его ченжлог.
Когда я вижу названия интеловских GPU - у меня на филее волосы шевелятся. В здравом уме это использовать невозможно, разве что по принуждению.
Ну и кстати это ещё не самый страшный драйвер в ядре :)
Мне кажется проще было бы встроить в компиляторы защиту, чтобы такой код не генерился - софт править проще чем процессоры.
Ты ещё предложи за незаконное ручное написание такого кода, а равно за написание программ, его генерирующих, уголовку давать, а тем кто хочет законно предлохить устроиться на работу в соответствующие спецслужбы и/или разработчиков процессоров.
люди в целом хорошие, если им сказать так не делать через компилятор - они не будут, надо верить в людей
А что предлагать? Уже давно есть в УК РФ Статья 273
Да там полный УК статей, при желании их применить и целый ворох статей применимых найдётся, и цешый ворох судей-карьегистов, которые поз козырёк возьмут и скахут "так хочет царь".
Откуда ты заранее знаешь какая инструкция с каким регистром и каким префиксом будет давать UB?
Ок, допустим в компиляторе сделали на конкретно вот этот случай workaround. Дальше что? Пересобирать всю ОС со всеми программами этим новым компилятором вместо того чтобы просто обновить микрокод и устранить причину, а не следствие? Чё, реально проще? Да ты, блин, гений.
Вообще-то проще, если всё opensource и freesoftware. Но не всё.
Ну и есть области, где обновляться нельзя. А старую версию никто уже не собирает или конторы, которая собирала, вообще уже нет. Так что надо бы и там и там править.
Т.е. написание программ на ассемблере полностью утраченный скил ?
ну а зачем тогда еще продвигать всякие хай левел безопасТные ЯП?Чем меньше знаешь как оно там устроено, тем легче "тебя" дурить!
> ну а зачем тогда еще продвигать всякие хай левел безопасТные ЯП?
> Чем меньше знаешь как оно там устроено, тем легче "тебя" дурить!Да вон RowHammer'а даже на JS забацали. Концептуально, чего. Да и спекулятивку шатать - пытаются
Исследователи могут воспринять это как такой себе challenge и достичь своего.
Внезапно, такие опции есть. Даже в MS-компиляторе.
ерунда какая-то в описании уязвимости! я бы понял если бы речь шла про пень4, который внутри итаниум буквально. кэш трасс этот, 3 инструкции в линейке - это итаник с перекодировщиком. отсюда и останов проца был на кэш-промахе.но. Итаники закопаны, и вместо них реанимирован пень-3 на стероидах. Там схема томассуло: используется несколько очередей команд, в пнях-7 их 7, на новых 9, сколько портов указано у агнера фога в доке. Часть очередей ALUшные, одна-две чтение памяти, одна-две "запись адресов" - на самом деле это резервация слотов в очереди записи, и одна-две "запись данных" это запись данных в зарезервированный слот. Вот как-то так. Никаких "смещений" там быть не должно. Это регистровые файлы по сути, где команда хранится блобом.
>Предполагается, что ошибка вызвана неверным вычислением размера инструкции "MOVSB" с избыточным префиксом, что приводит к нарушению адресации инструкций, записанных в буфер ROB после MOVSB, и смещению указателя на инструкции
единственное место где по схемам от самого штеуда могут использоваться адреса - это uop cache. но тогда схема уязвимости неверно описана.
>пень4, который внутри итаниум буквальноitanium - это VLIW-архитектура, требующая сложных компиляторов. Не представляю, как можно вместить такой компилятор в железку, и как сделать, чтобы он мог работать незаметно.
Внезапно так же, как и в эльбрусах. Никаких проблем транслировать/эмулировать x86.x86 тоже RISC внутри. АМД начиная с K5, у интела чуть позже - с pentium pro. Софт под x86 работает как ни в чём ни бывало.
в пне4 официально перекомпиляция х86 в некий "кэш трасс". который выглядит как итаниум по всем параметрам включая ограничения на размер операндов.
> Внезапно так же, как и в эльбрусах. Никаких проблем транслировать/эмулировать x86.С итоговой скоростью работы ~ z80, конечно, проблем нет транслировать
Но почему же тогда все x86_64-процы RISC внутри?
Потому что это удобнее именно для части блоков исполнения.
И то там не вот просто RISC в привычном вам понимании, а по отдельному пайплайну на каждый блок.
Представьте, что у вас замечательная многоядерная конструкция.
Пара ядер умеют складывать и вычитать, битовые сдвиги, ещё что-нибудь.
Пара ядер умеет только умножение.
Одно ядро умеет только в деление.
Еще 3-4 ядра умеют штуки посложнее, типа SIMD и FP, но только их.
Штук 8 ядер умеют только писать в RAM и читать из неё.
И всё это объединено общим быстрым блоком SRAM в пару килобайт, и работает параллельно, не блокируясь.Я бы под такое компилятор общего назначения писать не RISC'нул.
А, да, и всё это ещё и памяти для команд не имеет, и в переходы не умеет.
То есть вам всё это надо непрерывно кормить линейным потоком команд с отдельного управляющего ядра :D
вы описали схему томассуло. процессор очень странный в плане связности по регистрам но ...
Да, её родимую. По сути на ней оно сейчас и строится. Куча внутренних регистров в SRAM и их "переименование" в рабочие от системы команд по мере необходимости. Транзакционность, откаты.
Если проще - там не RISC-проц внутри CISC, а отдельные RISC- и LIW- пайплайны, которые дёргают модули. Модули сами кормиться не умеют, т.е. они не полноценные процы, а просто по факту отдельные контроллеры, работающие с вводом в виде RISC-подобных или LIW команд.
> Но почему же тогда все x86_64-процы RISC внутри?Потому что они при этом и не VLIW внутри? Современные x86 имеют сложные планировщик и конвейеры исполнения, которые превращают CISC в микроинструкции и динамически и асинхронно раскидывают их по разным вычислительным блокам снижая таким образом простой железа.
Эльбрус, как и любой другой VLIW, это просто бревно и оно не умеет динамически ничего планировать, ему сразу нужно подавать всё в разложенном по блокам исполнения виде. Бревно ещё как-то в состоянии просто оттранслировать x86 в свой VLIW, но не в состоянии загрузить x86 инструкциями все свои вычислительные мощности. А если бы оно это умело делать эффективно, то получился бы аналог x86.
Ну толсто же. Первые убогие итаниумы с убогой эмуляцией крутили x86 со скоростью первых pentium, у поздних итаников и эльбрусов с этим намного-намного лучше. Эльбрусы чуть ли не быстрее с этой эмуляцией, чем нативный код, хз как так.
Всем производителям следует добавить поддержку RISC-V в свои процессоры. Чтобы потом просто дропнуть свою legacy-систему команд.
Не то, чтобы поддержку где-то сбоку, а RISC-V использовать в качестве микрокода для кода x86_64. Ну и, конечно же, режим прямого исполнения микрокода RISC-V из ОЗУ сделать. Думается, что в таком случае, затыкание всяких там утечек станет менее болезненным.
Вот это как раз не получится. x86-микрооперации - отдельно для адреса и отдельно для данных.
С точки зрения микропрограммы, и адреса, и данные эмулируемой системы команд, всё есть данные.
Только вот незадача -- RISC-V такое же дырявре УГ как и х86.
Этим достаточно вовремя уже озаботились, пока процессоры ещё в виде описания на HDL, а не в массовом производстве https://www.opennet.dev/opennews/art.shtml?num=59986
> выполнение инструкции "REP MOVSB", закодированной с избыточным префиксом "REX", приводит к неопределённому поведению.хохо, и что на это расскажут защитники UB?
неужели недетерминированность выполнения кода это так круто?
Ну ок, пофикси это на расте.
Ты совсем того?
Причем тут раст?Речь о самой концепции "наш кд работает но 'хз как' в зависимости от внешних условий"
> Причем тут раст?Притом что растаманы - противники UB и гордятся тем, что "у них" в языке его нет.
X86_64 это не CISC, это MegaCISC.
>We believe this bug causes the frontend to miscalculate the size of the movsb instruction, causing subsequent entries in the ROB to be associated with incorrect addresses. When this happens, the CPU enters a confused state that causes the instruction pointer to be miscalculated.Неужели в процессорном внутреннем кодировании микрооперации не имеют одинаковую длину? Такое решение позволяет иметь более простую архитектуру вычисления адреса и анализировать последующие инструкции параллельно. Недостаток - жрёт память для CISC-инструкций, но смысл микроопераций в том, что они простые, для них как раз тащирь с каждой инструкцией её размер должно жрать память.
Неужели деда Мороза не существует ?
А причем тут внутреннее представление, если речь фронтенде, который имеет дело с x86_64 кодом
>We believe this bug causes the frontend to miscalculate the size of the movsb instruction, causing subsequent entries in the ROB to be associated with incorrect addresses. When this happens, the CPU enters a confused state that causes the instruction pointer to be miscalculated.Предположим, что это так. Нельзя ли тогда заставить процессор интерпретировать кодирование микроопераций как аргументы микрооперации и извлечь сами закодированные во внутреннее представление микрооперации? После чего отреверсить сами микрооперации, научиться на них программировать, и благодаря тому же багу затолкнуть в процессор свои последовательности микроопераций. Привилегированных, для взлома SGX.
В SGX уже столько дыр, что оно напоминает дуршлаг. Реверсить микрооперации тут избыточно. Вон судя по соседней новости и в SEV уже дырку проковыряли.
описание бага тут:
https://lock.cmpxchg8b.com/reptar.htmlи тут явно дело не ограничивается movsb. потому что обсираются команды перехода, fxsave и т.д.
>If you guessed that the processor will just silently ignore the rex prefix, you would be correct! Well… except on machines that support a new feature called fast short repeat move! We discovered that a bug with redundant rex prefixes could interact with this feature in an unexpected way and introduce a serious vulnerability, oops
Уже более детально: fast short repeat move. и не любой префикс rex а лишний и с битом R=1. значит интел вставил в микрокод фичу проверки регистра rcx на какой-то размер и упрощенный код для коротких строк.
скорее всего декодер подмешивает биты префиксов в modrm в микрокод если тот разрешает это. багокод выглядит так:
rep
rex
rex r
movsbто есть проверка размера использует неверный регистр? все равно непонятно - ну сработает вместо FSRM упрощенный код или наоборот. а вот если этот бит подействовал на команду ветвления после проверки размера строки.
Скорее всего декодер подмешивает в микрооперации что-то другое, встретив конкретную комбинацию.
О чем я выше и заметил.
Лучше б открыли код микро ос, работающей в проце.
Этого никогда не будет, элита должна держать под контролем стадо.
#радибезопасносте #радистабильносте
> Этого никогда не будет, элита должна держать под контролем стадо.Через процессор? Блин, а как же древние египтяне, персы и римляне с этим справлялись? И хорошо, кстати, справлялись.
Объёмы информации тогда были такие, что для её извлечения хватало банальных пыток..
> Через процессор? Блин, а как же древние египтяне,Тема хорошо раскрыта в Stargate. Правда, вам не понравится такой способ.
Вдруг, и там окажется ОС Танненбаума?
А ты как думаешь, почему он закрыт?! И почему проц вырубается ровно через 30 минут, если вручную подчистить intel me? Уж не для того, чтобы активироваться в предопределённый час "ч" или по контрольному пакетику из интернета?!
Да защищённые компы эйргэпнуты. Не защищённые - обычно за натом сидят.
Кто придумывает эти идиотские названия для уязвимостей и зачем?
Нужно больше хайпа.
А тут ещё смеются над теми кто на кор 2 Дуо сидит.
Смеяться не надо. Сижу на кваде на асусе, и всё прекрасно работает. Почти всё: с августа отваливается сетевой интерфейс. Но никак не отвалится, потому что запилен хитрый скрипт, перегружающий модуль atl1e до тех пор, пока скорость не будет 100Mbps вместо 10-ти (1000 теперь в supported link modes нет вообще).Лень идти в дэнээс, в соседнюю вкладку, открывать его там.
Но, видимо, придётся...
> Лень идти на работу, Но, видимо, придётся...Поправил.
П.с. если совсем всё плохо, можешь попробовать насобирать стеклотару на б\у PCI сетевуху с авито.
тут на сайте уже было обсуждение "прекрасности" core2duo -- приводился список ошибок этого проца. писали что просто чемпион по ошибкам.
Они не смеются, а харрасят. Себе социальный рейтинг повышают. На сколько е-баллов только - большой-большой секрет.
Что зазорного, в том, чтобы в очередной раз пнуть слабого? Ведь если человек в 2023 году сидит на компе 20 летней давности, значит он - несостоятельная личность. Жалость такие социальные инвалиды не вызывают от слова совсем.
Знакомый, года 3 назад, на полном серьёзе бил кулаком себя в грудь, доказывая, что самый безопасный процессор это пентиум 4. Раньше я думал, что у него начались старческие причуды (ему за 40) и он просто жлобится обновлять железо, теперь точно могу сказать, что он прав.
Согласен. Пентиум 4, а лучше бы 3 и настоящий линукс с тайлами и башпортянками на загрузке.
Башпортянки, думаю, лишнее. Выпиливание сустемд не даёт ощутимого высвобождения памяти даже на машинах с 1 гигом и менее.
На 256 даёт. А ещё, говорят, фпс поднимает, но уже на новеньких машинках.
фпс рабочего стола или glxgears?
> На 256 даёт. А ещё, говорят, фпс поднимает, но уже на новеньких машинках.На одноплатниках с 256 мегз системде памяти выше крыши. Зато бутявит минимальную систему за 6 секунд даже без оптимизаций. С скриптотой разумеется дольше - интерпретер звать на каждый скриптк не халявная по ресурсам операция.
> Знакомый, года 3 назад, на полном серьёзе бил кулаком себя в грудь, доказывая, что самый
> безопасный процессор это пентиум 4.Если у него вспухли кондеры или пыхнул питальник - даже не очень врет. В остальных случаях может получиться что он попросту неуловимый Джо.
Надёжность не равно производительность. Вон в Пентагоне до сих пор юзают PDP-11 с 8 дюймовыми дискетами. Неужто у них денег нет на новенький Mac Pro?
не надо выдавать технологическую отсталость в отдельных областях за норму или доблесть. Всё может быть куда банальнее - в отсутствие практики нет необходимости переписывать то, что и так вроде бы работает, но реальные недостатки не проявляются, потому что практики нет. А потом вдруг "что-то случилось" и оказывается, что все это нужно срочно переписать и заменить ещё вчера надо было
Ну да, и memory sinkhole это г*** не подвержено, ага.
Ну нашли и нашли уязвимость... Можно подумать что х86 процессорам есть какая-то альтернатива. Как покупали интел и амд, так и впредь будут покупать какими бы уязвимыми они ни были.
> которые теоретически должны игнорироваться,
> но на практике приводили к странным эффектам,Welcome to Undocumented world.
Гугл не хочет закупить эльбрусов?
> По данным исследователя уязвимость присутствует в семействах процессоров Intel Ice Lake, Rocket Lake, Tiger Lake, Raptor Lake, Alder LakeОзёра уязвимостей
А есть какой открытый x86 процессор? Хотелось бы схемку процессора глянуть. Или это все проприетарщина?
> Хотелось бы схемку процессора глянуть.Это тебе не шарманка на 6п3с.
в общем, на входе стоит "декодер длины команд". из него получаются макро-операции, которые идут в очередь макроопераций.посмотрев какое пенальти за много 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.
>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. То есть на интеле можно шатать шину из микрокода например.
MCE - это не обязательно шатание шины
Это может быть ошибка вторичного декодирования или что-то ещё
> MCE - это не обязательно шатание шины
> Это может быть ошибка вторичного декодирования или что-то ещёпро то, что этот код хитрит с кэшем заявляли сами интеловцы. а MCE триггрерится только на многопотоке и то - надо точно выверять количество нопов перед багокодом. это очень похоже на ручной рулеж шиной и кэшем.
Вполне возможно, что это просто вторичный результат шатания кривым микрокодом всего, что под руку подвернётся. Ошибка декодирования на блоках исполнения - тоже себе MCE.
Есть мнение, что интереснее будет поиграться с прочими регистрами перед забаговкой, и посмотреть - меняется ли что-либо. Но разные регистры надо показывать на начало страниц памяти, заполненных разными паттернами.
Если оно действительно врезает в очередь микрокоманд данные из заданного источника - то при перетасовке паттернов будут заметно разные но повторяющиеся фичи.
Intel: «Для наших замедляющих "обновлений" микропрошивок нашли уязвимости? Как неожиданно и приятно!»