Комментарии 23
Ryzen 3000 были выпущены примерно 5 лет назад и для них уже окончен срок программной поддержки? причем это брешь в безопасности. Выглядит как то жадно со стороны AMD. Процессор покупатель не меняет так часто как те же смартфоны.
Надеюсь, в Америке их засудят.
А толку?
С другой стороны, а сколько лет производитель должен поддерживать? Как определить эту цифру?
Хорошо, 5 лет. А почему не 6? А если 6, то почему не 7? В какой момент нужно остановиться и почему именно на этой ццфре?
Выпустят исправление для всех Ryzen - так вылезут деды с фуфыксами (FX) и тоже затребуют. А чем они хуже? Так мы до мышей дотрахаемся (с), в смысле, до каких-нибудь древних Phenom, прости господи.
Интересно, как будет выглядеть это обновление с точки зрения конечного домашнего пользователя? В виде обновления прошивки для UEFI матплаты? Если так - то и производители мат.плат могут привнести свои соображения на предмет - кого обновлять, а кого - уже и нет...
Или существует отдельный механизм обновления микрокода CPU ?
На винде не знаю как, а на Линуксе есть прям два отдельных пакета в системе - микрокоды на Интел и АМД. Они вроде как подгружаются ядром при каждом запуске.
Соответственно, если в какой-то момент загрузил что-нибудь с флешки - то обновления в тот момент в системе не будет...
AGESA это не совсем микрокод, обновить её из ОС не получится.
AGESA включается в прошивку, которая спокойно обновляется из-под работающей системы
Тут вся ветка идёт в контексте "можно ли обновить, если на выпуск прошивки вендор забил".
И в случае с агесой ответ - нет, нельзя, это не микрокод, который может обновить поставщик ОС или даже сам пользователь.
Началась-то ветка с обновления микрокода, это вы, зачем-то, приплели agesa )
Вот тут явно указаны митигации как прошивкой так и микрокодом.
Для потребительских процессоров ни про какой микрокод не говорится.
Зато, упоминается, что именно в указанной версии AGESA будет реализовано исправление. Самое главное в поисках того, кто приплёл агесу, не выйти на самих себя :)
Окей, я согласен, что конечный домашний пользователь, обладающий серверным процессором EPYC, сможет устранить уязвиимость обновлением микрокода.
Что-то заставляет вас думать, будто одно и то же ядро вдруг не может быть пропатчено одним и тем же микрокодом?
Этот, пока-что, видит лишь странную неточность в документации, явно связанную с консьмерским/просьюмерским позиционированием, в стиле мы не отключали ECC, но ее поддержка зависит от производителя матплаты, только без зависимости от производителя.
Делать какие-либо экстраполяции далее — wishful thinking, строить на этом аргументацию — и вовсе bullshit.
Самое главное в поисках того, кто приплёл агесу, не выйти на самих себя :)
Два ваших коммента от корня на втором и третьем уровнях недвусмысленно говорят о том, что выйти на себя у каджита не получится физически
Или существует отдельный механизм обновления микрокода CPU ?
Существует, но AGESA это не микрокод.
Если так - то и производители мат.плат могут привнести свои соображения на предмет - кого обновлять, а кого - уже и нет
Выбирайте производителей с длительной поддержкой а-ля HP/Dell.
внедрить вредоносное ПО в загрузчик UEFI
А если паяльником заюзать у биоса ножку "write protect"?
В том то и дело, что корректно работать такая система не будет — упадет на первом же SetVariable, т.к. запись в NVRAM происходит при каждой загрузке (сохраняется последняя загруженная конфигурация, обновляется список загрузочных устройств, обновляется значение MonitonicCounter и т.п.). Чтобы справиться с этой проблемой, нужно либо заменять оригинальный драйвер NVRAM на такой, который на флеш вообще не пишет, либо сразу же загружать вышеупомянутый эмулятор CrEmuVariable, который подменит оригинальные сервисы GetVariable/SetVarible/GetNextVariableName/QueryVariableInfo собственными, и система будет работать. В таком режиме, понятно, тоже есть свои минусы, настройки из BIOS Setup не сохраняются, к примеру, но если все уже настроено — это работает.
https://habr.com/articles/281412/comments/#comment_8849394
А делать штатное решение (в виде отдельной микросхемы для хранения переменных) производителям невыгодно:
расходы (умножаем на число выпускаемых плат)
невостребованность (это нужно двум с половиной пользователям, заботящимся о безопасности и осознающим проблему, в то время как подавляющее большинство ничего не знает про существование каких-то биосов и не хочет знать)
В итоге, пока вы тратите ресурсы на реализацию фич, которые почти невостребованы пользователями, конкуренты этого не делают → вы проигрываете.
Тут случай, когда заразился вирусом и вынужден покупать новую материнскую плату, чтобы от него избавиться...
Есть где почитать про эту уязвимость? Нужно ли для работы эксплоита в биосе включать этот SMM или оно необходимая часть системы?
AMD не будет закрывать уязвимость Sinkclose в старых Ryzen и Threadripper 1-го и 2-го поколения