Conversation

Несерьёзный Выдумщик

Зачем нам свои процессоры
Show content

У тех же VLIW-процессоров типа «Эльбрус» нет загружаемого микрокода, а потому и неожиданностей гораздо меньше (для эксплуатирующих организаций).

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


Исследователи безопасности из компании Google опубликовали информацию об уязвимости (CVE-2024-56161) в процессорах AMD, затрагивающей загрузчик микрокода и позволяющей обойти механизм проверки цифровой подписи при обновлении микрокода. Загрузка модифицированного микрокода позволяет скомпрометировать механизм AMD #SEV (Secure Encrypted Virtualization), применяемый в системах виртуализации для защиты виртуальных машин от вмешательства со стороны гипервизора или администратора хост-системы.

Уязвимость вызвана использованием небезопасной хэш-функции в коде, выполняющем проверку цифровой подписи после загрузки микрокода в CPU. Для совершения атаки необходимо наличие прав администратора в локальной системе (возможности выполнить код на уровне нулевого кольца защиты #ring0, находясь не в виртуальной машине).

В ходе атаки можно вклиниться в работу гостевых систем, защищённых при помощи расширений AMD SEV (Secure Encrypted Virtualization) и SEV-SNP (Secure Nested Paging), предоставляющих гарантии целостности памяти виртуальных машин, изолирующих процессорные регистры и обеспечивающих безопасную работу со вложенными таблицами страниц памяти. Механизм AMD SEV создавался для того, чтобы персонал датацентров и облачных провайдеров не мог изменить или проанализировать содержимое памяти защищённых гостевых систем, а также исказить вычисления.

Исследователями подготовлен прототип эксплоита, позволяющий загрузить в CPU произвольный микрокод, не заверенный цифровой подписью. Для демонстрации опасности уязвимости предложено обновление микрокода, меняющее логику работы инструкции #RDRAND, применяемой в качестве одного из источников энтропии в генераторах псевдослучайных чисел, используемых в процессе формирования ключей, при выполнении криптографических операций и для генерации случайных идентификаторов.

Изменение приводит к возвращению инструкцией RDRAND только числа 4, вместо случайной последовательности. Для предотвращения совершения реальных атак на системы конфиденциальных вычислений изменённый микрокод обнуляет флаг CF (carry flag), т.е. помечает выдаваемое значение ошибочным. Дополнительные детали и инструменты для генерации изменённого микрокода планируют опубликовать 5 марта, чтобы дать пользователям время на установку исправления на своих системах. Успешный пример атаки продемонстрирован для серверов с процессорами AMD #EPYC 7B13 #Milan и AMD Ryzen 9 7940HS #Phoenix.

В отчёте компании AMD указано, что уязвимость проявляется в процессорах AMD на базе 1-4 поколений микроархитектуры Zen. Обновление микрокода с устранением уязвимости было выпущено 13 декабря 2024 года для процессоров серий AMD EPYC 7001, 7002 и 7003 (#Naples, #Rome, #Milan и #Milan-X), а 16 декабря для процессоров серии AMD EPYC 9004 (#Genoa, #Genoa-X и #Bergamo/#Siena). Для устранения уязвимости на системах, в которых используется аттестация #SEV-SNP, дополнительно требуется обновление прошивки AMD SEV (поставляется вместе с обновлениями BIOS от производителей оборудования).


Дополнительно сообщается об ещё одной уязвимости в процессорах AMD, допускающей проведение атаки по сторонним каналам для извлечения информации о вычислениях в гостевых системах, защищённых с использованием механизма AMD SEV. Проблема затрагивает 1-4 поколения процессов AMD EPYC и связана с возможностью извлечения из процессорного кэша данных, оседающих в процессе работы защищённых гостевых систем. Для анализа содержимого кэша может использоваться метод Prime+Probe, подразумевающий заполнение кэша эталонным набором значений и определение изменений через измерение времени доступа к ним при повторном заполнении.


В #Linux обнаружен механизм обхода защиты от уязвимости #Spectre на процессорах #Intel и #AMD

Новой уязвимости подвержены потребительские процессоры Intel Core 12, 13 и 14 поколений, серверные #Xeon 5 и 6 поколений, а также чипы AMD #Zen 1, Zen 1+ и Zen 2

Обнаруженная исследователями Швейцарской высшей технической школы Цюриха (ETH Zurich) схема атаки позволяют обойти защитный механизм #IBPB (Indirect Branch Predictor Barrier), не позволяющий злоупотреблять спекулятивным выполнением

Швейцарские учёные подтвердили возможность перехватывать результаты спекулятивного выполнения даже после срабатывания механизма IBPB, то есть с обходом существующих средств защиты и с утечкой конфиденциальной информации — в частности, это может быть извлечённый из процесса suid хэш пароля root

В случае процессоров Intel механизм IBPB не в полной мере устраняет результат выполнения недействительной функции после смены контекста

У процессоров AMD метод IBPB-on-entry в ядре #Linux срабатывает неправильно, из-за чего результаты работы устаревших функций не удаляются после #IBPB

О своём открытии исследователи сообщили #Intel и #AMD в июне 2024 года

В Intel ответили, что к тому моменту проблема уже была обнаружена силами самой компании — соответствующей уязвимости присвоили номер #CVE-2023-38575

Ещё в марте Intel выпустила обновление микрокода, но, как установили исследователи, это не помогло исправить ошибку во всех операционных системах, включая Ubuntu

В AMD также подтвердили факт наличия уязвимости и заявили, что она уже была задокументирована и зарегистрирована под номером CVE-2022-23824

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

В AMD ошибку охарактеризовали как программную, а не аппаратную; учитывая, что производитель знает о ней давно, и она затрагивает только старые микроархитектуры, в компании приняли решение не выпускать закрывающее уязвимость обновление микрокода

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

Швейцарские учёные, однако, продемонстрировали, что атака срабатывает на Linux 6.5 с защитой IBPB-on-entry, которая считается наиболее эффективной против эксплойтов типа #Spectre

И поскольку AMD отказалась закрывать её, исследователи связались с разработчиками ядра Linux с намерением самостоятельно разработать патч для «красных» процессоров


Процессоры компании AMD на архитектурах Zen 2 и Zen 3 оказались уязвимы к атаке #faulTPM, позволяющей взломать их через модуль #TPM, пишут порталы Tom’s Hardware и TechSpot. Ирония здесь в том, что #TPM сам по себе отвечает за безопасность – это доверенный платформенный модуль.

Уязвимость процессоров AMD на перечисленных архитектурах нельзя устранить – можно лишь отказаться от их переключиться на решения Intel – ее #CPU в неспособности противостоять атаке #faulTPM пока не уличили.

Проблему в чипах AMD выявили специалисты по кибербезопасности из Берлинского технического университета. В их отчете говорится о результатах тестирования процессоров #Ryzen на Zen 2 и Zen 3 – очень востребованных в России и мире. Первое поколение Ryzen с первой же версией архитектуры Zen в документе не упоминается – видимо, эти CPU в тестах не участвовали, так как к маю 2023 г. они давно морально устарели. С момента их выхода прошло шесть лет.

Вломиться в чип AMD они смогли через встроенный в него сопроцессор безопасности #PSP. Эксперты выудили из него данные, позволяющие расшифровать информацию в модуле ТРМ, а это – прямой путь ко всей информации на компьютере и полным над ним контролем даже при наличии в нем аппаратного модуля безопасности. По сути, из-за уязвимости процессоров AMD к атаке faulTPM хакеры могут скомпрометировать любую программу или шифрование, включая базовое шифрование в Windows – #BitLocker.


Линус #Торвальдс заявил, что в сбоящих операционных системах виноваты разработчики «железа», в особенности Intel

Он считает, что из-за кишащих уязвимостями процессоров Intel разработчикам Linux приходится вносить слишком много правок в ядро, и что именно из-за процессоров в современных ОС так много «дыр»

Первопричиной всего этого стал негатив Торвальдса в сторону технологии линейной адресной маскировки (Linear Address Masking, #LAM) в процессорах Arrow Lake и Lunar Lake

За счет нее в CPU могут использоваться нетранслированные биты адреса для хранения метаданных

Нововведение впервые появилось в процессорах Intel Core 12 поколения, вышедших в конце 2021 г. – оно нужно для повышения безопасности памяти, но при этом, как оказалось, оно мешает быстрой и стабильной работе ядра Linux

Информация о гневе Торвальдса дошла до Intel, и ее инженер Кирилл Шутемов (Kirill Shitemov) прокомментировал высказывание создателя Linux

Он сообщил, что технология #LAM действительно имеет свои недочеты, и что они будут устранены с релизом новой технологии – #LASS или Linear Space Separation Support

Это новая функция безопасности для защиты адресного пространства

К слову, у AMD есть похожая на LAM технология – Upper Address Ignore #UAI

Она появилась с переходом AMD на процессорную архитектуру Zen 4 и впервые была внедрена в чипы #Ryzen 7000

#Эльбрус #VLIW #cybersec #infosec #ИБ #microcode

1
1
2
Зачем нам свои процессоры
Show content

@grumb@idealists.su Поменять вдоль и поперёк изученную архитектуру на напрочь закрытую, без софта, которую невозможно произвести — так держать, продолжайте.

1
0
0
re: Зачем нам свои процессоры
Show content

@vovanium

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

И софт давно весь в исходниках, пересобрать не проблема. gentoo & archlinux не дадут соврать.

А x86 давно не архитектура, а лишь ISA — набор команд. Под капотом у x86 Intel & AMD прячутся давно уже не CISC процессоры. И каждое поколение с новыми архитектурами :)

1
0
0
re: Зачем нам свои процессоры
Show content

@grumb

Ничего в ней закрытого нет, поставляется с полной документацией.
Включая топологию кристалла?
И софт давно весь в исходниках, пересобрать не проблема.
Это ты щас гентушнику рассказываешь?blobcatlaugh
не CISC процессоры.
CISC или не CISC определеяет ISA. Противоречишь себе.
Не нравится х86, бери RISC-V. ISA — открыта, core открытых навалом, реализации в железе на рынке доступны любому желающему, никакого микрокода, бери — не хочу.
Но зачем-то понадобилось что-то на не оправдавшей себя никак архитектуре за космические деньги, с единственным закрытым компилятором, недоступное почти никак. Штош — флаг в руки.

0
0
0