Уязвимость в процессорах AMD Zen 1-4 позволяет загружать вредоносные микрокоды

вредоносные микрокоды

Лезут проклятые юзеры своими грязными ручонками в нашу секурную секурность.

РЕ-ШЕ-ТО!

Для эксплуатации этой «уязвимости» нужен root. Расходимся.

Как хорошо, у моих компов на AMD нет доступа злоумышленников с привелегиями локального администратора.

Уязвимость в процессорах AMD Zen 1-4

с привилегиями локального администратора

Уязвимость затрагивает процессоры серий AMD EPYC 7001, 7002, 7003 и 9004

Немножно жёлто :)

Мы обновили вам микрокод, чтобы вам не могли обновить микрокод через дыру в микрокоде.

А минусы в чем?

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

в новых версиях закроют

Какие возможности у микрокода? Можно ли запилить поддержку инструкций motorola 68k?

BigEndian?

википедия:

Motorola 68000 architecture

Designer Motorola

Bits 16/32-bit

Introduced 1979; 46 years ago

Design CISC

Branching Condition code

Endianness Big

Registers

8× 32-bit data registers

7× 32-bit address registers

stack pointer (address register 7)

Новую версию можно не устанавливать. Кстати а обновления микрокода же не прошиваются в проц намертво, их биос шьёт при каждой загрузке (так что откат всегда возможен), или нет?

Вот интересно, а как я, как пользователь виртуалки, могу надежно проверить, что она запущена под sev-cnp?

с привилегиями локального администратора

дело за малым.

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

Да, обновлённый микрокод всегда подгружается на-живую: вначале на одном из этапов прогрузки БИОСа, а потом возможно и со стороны ОС вроде Linux - если в ней реализован такой функционал и ОС сочтёт это целесообразным. Возможность отката на прежние БИОСы, где если и подгружалась то более старая версия микрокода, - по крайней мере программная возможность, без использования программатора! - может быть искусственно ограничена

И не надоело им дыры для ЦРУ пробивать….

Без проблем, дело за малым, разобраться с форматом микрокода

Если у вас есть привилегии локального администратора, зачем связываться с микрокодом? Есть сто тыщ способов нагадить всем и без этого.

В общем, в очередной раз открыли уязвимость ректума к разогретым до 280 градусов металлическим стержням.

Крутяк. Теперь и амудешникам камушки замедлят. А то ишь ты! Сидят по 10 лет на одном процессоре.

Для эксплуатации этой «уязвимости» нужен root.

Который встречается чаще, чем хотелось бы.

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

Насчёт дополнительных инструкций не уверен, но по крайней мере через обновление микрокода можно повлиять на алгоритм выполнения имеющихся инструкций. Правда, возможность экспериментирования ограничена максимальным размером микрокода: для моего старого (зато без «бекдоров» Intel ME / AMD PSP) до-райзеновского амуде архитектур 15h / «early 16h», поддерживающегося опенсорсным БИОСом coreboot, он был равен нескольким килобайтам.

Основная цель механизма запуска обновлённых микрокодов - предоставить возможность производителю процессора программно исправить аппаратный баг выполнения важной функции без перевыпуска; например, в моём случае, без обновлённого микрокода на 15h - глючило IOMMU. Понятное дело, что это добро практически не документировано, но по крайней мере по старому амуде - куда было легче подгружать кастомные микрокоды - были всякие исследования и «proof of concept»

Проц не может ограничить откат биосов

Так я и не утверждал этого - разумеется, искусственное ограничение будет со стороны проприетарного UEFI: просто могут не дать юзерам через утилиту апдейта / встроенное меню обновления - ставить старые версии проприетарного UEFI со старым микрокодом «по соображениям безопасности»

Хоть мне и дела до райзенов особо нет - думаю, эту штуку можно пофиксить без замедления процов

Мамой клянемся, ваша безопасность секурно защищена!

(но если серьезно - то да, любопытно).

Архитектура zero trust священна, и цепочка доверия должна быть неприкосновенна для всех, включая легальных пользователей с правами root’a. Придет время, и пользователи будут благословлять такие дырки, чтобы иметь возможность за’root’овать свой PC с Linux.

Так хостеру-то какая разница что и где запущено? Это ж типа защита содержимого виртуалки от хост системы.

А вот если бы не лезли? Представляешь себе компьютеры и операционки, со всем обвесом, которые занимались бы только правильным использованием памяти, чтобы не текло? Сколько бы одного электричества наэкономили?

Верните Obezyan звезду!

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

Я в курсе, я буквально вчера генерил ассемблерный выхлоп к нему.

Это если обновить биос.

Зачем? Я потратил столько сил чтобы от нее избавиться.

Там по-умолчанию вредоносный микрокод загружен - PSP называется: полный аналог интеловского МЕ.

Никогда мне AMD не нравились!

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