Принцип «безопасность через неясность» не один год критикуется специалистами, но это не мешает крупным производителям электроники под предлогом защиты интеллектуальной собственности требовать подписания соглашений о неразглашении для получения технической документации. Ситуация ухудшается из-за возрастающей сложности микросхем и интеграции в них различных проприетарных прошивок. Это фактически делает невозможным анализ таких платформ для независимых исследователей, что ставит под удар как обычных пользователей, так и производителей оборудования.
Примером может служить технология Intel Management Engine (Intel ME), а также ее версии для серверных (Intel SPS) и мобильных (Intel TXE) платформ (подробнее об этой технологии см. [5], [6]. В этой статье мы расскажем, как используя недокументированные команды (если термин «документированный» вообще применим к Intel ME), можно перезаписать память SPI flash и реализовать самый страшный сценарий — локальную эксплуатацию уязвимости в ME (INTEL-SA-00086). Корнем данной проблемы оказался недокументированный режим работы Intel ME — Manufacturing Mode.
Что такое Manufacturing Mode
Intel ME Manufacturing Mode — сервисный режим работы, предназначенный для конфигурирования, настройки и тестирования конечной платформы на стадии производства; он обязательно должен быть отключен перед поступлением оборудования в продажу и отгрузкой пользователю. Ни этот режим, ни его потенциальные риски не описаны в публичной документации Intel. Обычный пользователь не имеет возможности выключить его самостоятельно, так как утилита для управления им из пакета Intel ME System Tools официально не доступна. Отметим, что никакие программные средства защиты не способны защитить пользователя, в случае если этот режим оказался включенным, или хотя бы оповестить его об этом. Даже утилита Chipsec [2], которая специально предназначена для выявления ошибок конфигурации чипсета и процессора на уровне прошивки UEFI (в частности, неправильного конфигурирования прав доступа к регионам SPI flash), ничего не знает об Intel Manufacturing Mode.
Этот режим позволяет задавать критически важные параметры платформы, хранящиеся в однократно записываемой памяти (FUSES). Примером таких параметров, которые «зашиваются» во FUSES, являются параметры BootGuard (режим, политики, контрольная сумма ключа цифровой подписи для модулей ACM и UEFI). Часть из них называются FPF (Field Programmable Fuses). Список FPF, которые могут быть записаны в FUSES (неполный, на самом деле ряд FPF нельзя задать напрямую), можно получить через утилиту FPT (Flash Programming Tool) из пакета Intel ME System Tools.
Рис 1. Результат работы опции –FPFs утилиты FPT
Следует отметить, что на долю FPFs приходится лишь часть общего массива FUSE, а большая часть этой памяти используется самой Intel для хранения множества параметров платформы. Например, часть пространства этого массива называется IP Fuses и предназначена для хранения конфигурационных параметров отдельных аппаратных модулей (Intelligent Property). Так, специальное устройство DFx Aggregator хранит во FUSE признак того, является ли платформа серийной или тестовой.
Помимо FPF, в Manufacturing Mode производитель оборудования имеет возможность задавать параметры прошивки Intel ME, которые хранятся во внутренней файловой системе прошивки — MFS, на носителе SPI flash. Эти параметры могут быть изменены в случае перепрограммирования SPI flash. Они носят название CVARs (Configurable NVARs, Named Variables).
За установку CVARs отвечает модуль прошивки Intel ME — mca_server. MCA — это аббревиатура Manufacture-Line Configuration Architecture, общего названия процесса конфигурации платформы на этапе производства. CVARs, так же как и FPF, могут быть заданы и прочитаны с использованием FPT.
Рис 2. Список CVARs, выводимых утилитой FPT для платформы Broxton P
Список переменных CVARs зависит от платформы и версии прошивки Intel ME. Для чипсетов, поддерживающих технологию Intel AMT, одной из таких переменных является пароль для входа в MEBx (ME BIOS Extension).
Установка FPFs и практически всех переменных CVARs возможна только в том случае, если прошивка Intel ME функционирует в Manufacturing Mode. Сам процесс установки FPFs разделен на два этапа: задание значений FPFs (которые сохраняются во временную память) и перенос значений FPFs в массив фьюзов. При этом первый этап возможен только в Manufaturing Mode, а реальный «прожиг» происходит автоматически, после выхода из Manufacturing Mode, если во время работы в этом режиме производитель задал значения FPF и при этом соответствующий диапазон в массиве фьюзов еще никогда не записывался. Таким образом, если система функционирует в Manufacturing Mode, переменные FPF, скорее всего, не инициализированы.
Признак отключения Manufacturing Mode хранится в файле /home/mca/eom на MFS, таким образом при перезаписи SPI flash прошивкой c базовой файловой системой (подробнее в [9]) платформа имеет возможность опять функционировать в Manufacturing Mode (но перезаписать FUSES уже не получится).
OEM public key
Таким образом, процедура конфигурации платформ Intel довольно сложна и состоит из нескольких этапов. Если производитель оборудования нарушил или изменил последовательность, то платформа подвергается серьезному риску. Даже если Manufacturing Mode завершен, производитель мог не записать FUSES, что даст возможность злоумышленнику сделать это за него, записав свои значения вместо ключа для подписи стартового кода модулей BootGuard (AСM) и UEFI и таким образом позволив загружаться платформе только с его вредоносным кодом, причем на постоянной основе. Это приведет к безвозвратной потере оборудования, так как мошеннический ключ будет прописан в постоянную память, навсегда (подробности этой атаки можно найти в исследовании Александра Ермолова «Safeguarding rootkits: Intel BootGuard» [8]).
В новых системах (Apollo Lake, Gemini Lake, Cannon Point) в FPF хранится не только ключ для BootGuard, но и открытый ключ OEM (вернее, SHA-256 от RSA OEM public key), на который опираются сразу несколько механизмов защиты ME. Например, в специальном разделе SPI flash, называемом Signed Master Image Profile (SMIP), хранятся заданные производителем PCH Straps (аппаратная конфигурация PCH). Этот раздел подписан на ключе, SHA-256 от которого помещен в специальный файл на SPI flash. Этот файл называет oem.key, находится в разделе FTPR и содержит разные публичные ключи, поставляемые OEM, для подписи самых разных данных. Приведем полный список наборов данных, которые подписываются производителем, каждый на уникальном ключе, для платформы Cannon Point:
Рис 3. Список подписываемых OEM данных платформы CNP
Сам файл oem.key подписан общим корневым ключом OEM, хеш-сумма которого должна быть записана в FPFs.
Рис 4. OEM Signing
Обход блокировки записи в ME-регион
До недавнего времени (до Intel Apollo Lake) прошивка Intel ME находилась в отдельном SPI-регионе, который имел независимые права доступа для CPU, GBE и ME. Таким образом, при правильной конфигурации атрибутов доступа со стороны CPU (основной системы) невозможно было ни прочитать, ни записать прошивку ME. Однако современные SPI-контроллеры чипсетов Intel, имеют специальный механизм Master Grant. Эта технология закрепляет за каждым SPI-мастером строго определенную часть SPI flash, этот мастер является владельцем своего региона, вне зависимости от прав доступа указанных в SPI-дескрипторе. Каждый мастер имеет возможность предоставить доступ (на чтение или на запись) к своему (и только своему) региону другому мастеру, какому пожелает.
Рис 5. Отрывок документации Intel, описывающий SPI Master Grant
Таким образом, даже если в SPI-дескрипторе прописан запрет на доступ к SPI-региону ME со стороны хоста, ME может все равно предоставить доступ к своим данным. На наш взгляд, это сделано для возможности обновления прошивки Intel ME в обход стандартного алгоритма.
Host ME Region Flash Protection Override
В прошивке Intel ME реализована специальная HECI-команда, которая позволяет открыть доступ на запись к ME-региону SPI со стороны CPU. Она называется HMR FPO (Host ME Region Flash Protection Override). В одном из наших предыдущий исследований мы подробно описывали эту команду [5]. У нее есть несколько особенностей.
После получения команды HMR FPO прошивка откроет доступ к своему региону только после перезагрузки. В самом МЕ также предусмотрена защита: команда воспринимается только в период выполнения UEFI BIOS, до так называемого момента End of Post (EOP). EOP — это еще одна HECI-команда, которую посылает UEFI BIOS до передачи управления операционной системе (ExitBootServices). В некоторых BIOS Setup можно найти опцию, которая и обеспечивает отправку команды HMRFPO до EOP.
Рис 6. Открытие ME-региона в BIOS
После получения EOP прошивка ME игнорирует HMR FPO, возвращая соответствующий статус. Но это происходит только после завершения режима Manufacturing Mode. Таким образом, прошивка ME в Manufacturing Mode воспринимает HMR FPO в любое время, вне зависимости от End of Post. Если производитель не закрыл режим Manufacturing Mode, злоумышленник (формально говоря, для этого нужны права администратора, но ведь даже ядро ОС изначально не может перезаписывать прошивку ME) может в любое время изменить прошивку ME. На этом этапе атакующий может перезаписывать образ МЕ, например для эксплуатации уязвимости INTEL-SA-00086. При этом возникает необходимость перезагрузки, но это не является помехой на практически всех платформах, кроме MacBook. Именно на компьютерах Apple существует дополнительная проверка в UEFI, которая осуществляется в момент старта и блокирует запуск системы, если регион ME открыт с помощью HMRFPO. Однако, как мы покажем далее, этот механизм защиты преодолевается, если прошивка ME функционирует в Manufacturing Mode.
Перезагрузка ME без перезагрузки основного CPU
В современных компьютерах существует несколько вариантов перезагрузки платформы. Из них задокументированы: глобальная перезагрузка и перезагрузка только основного CPU (без перезагрузки ME). Однако, если существует способ перезагрузить МЕ без перезагрузки основного CPU (предварительно выполнив также команду HMRFPO), доступ к региону откроется, а основная система продолжит функционировать.
Рис 7. Управление типом перезагрузки
Исследовав внутренние модули прошивки ME, мы обнаружили, что существует HECI-команда («80 06 00 07 00 00 0b 00 00 00 03 00», подробнее об отправке команд см. [5]) для перезагрузки только (!) ядра Intel ME, которая в Manufacturing Mode может быть послана также в любое время, даже после EOP.
Рис 8. Листинг дизассемблера функции, выполняющей обработку HECI-команд перезагрузки ME
Таким образом, злоумышленник, послав эти две HECI-команды, открывает ME-регион и может писать туда любые данные, без перезагрузки платформы. При этом совершенно неважно, чтo содержит SPI-дескриптор, то есть правильные атрибуты защиты SPI-регионов не защищают прошивку ME от изменения, если система функционирует в Manufacturing Mode.
Практический случай: уязвимость CVE-2018-4251
Мы проанализировали несколько платформ разных производителей. Среди них были ноутбуки компании Lenovo и Apple MacBook Prо. В исследованных компьютерах из линейки Yoga и ThinkPad мы не нашли каких-либо проблем, связанных с Manufacturing Mode, зато ноутбуки компании Apple, основанные на чипсетах Intel, функционируют в Manufacturing Mode. После передачи этой информации в компанию Apple данная ошибка (CVE-2018-4251) была исправлена в обновлении ОС macOS High Sierra 10.13.5.
Локальная эксплуатация INTEL-SA-00086
Итак, используя уязвимость CVE-2018-4251, злоумышленник может записывать старые версии прошивки ME, содержащие уязвимость INTEL-SA-00086, и при этом ему не нужен ни SPI-программатор, ни доступ к перемычке HDA_SDO (то есть физический доступ). Таким образом реализуется самый опасный — локальный — вектор этой уязвимости (выполнение произвольного кода в прошивке ME). Примечательно, что в пояснениях к бюллетеню безопасности INTEL-SA-00086 Intel не упоминает открытый Manufacturing Mode как средство для эксплуатации данной уязвимости локально, без физического доступа, а говорит лишь о том, что локальная эксплуатация возможна только при неправильной настройке доступа к SPI-регионам, что не соответствует действительности. Для защиты пользователей мы решили описать, как проверить наличие Manufacturing Mode и как его отключить.
Как защититься
В пакет системных утилит для разработчиков оборудования на основе чипсетов и процессоров Intel (Intel System Tools) входит утилита MEInfo (TXEInfo, SPSInfo для мобильных и серверных платформ соответственно), которая предназначена для того, чтобы получить расширенную диагностическую информацию о текущем состоянии прошивки Management Engine и всей платформы в целом. Мы демонстрировали эту утилиту в одном из наших предыдущих исследований, посвященном отключению ME и недокументированному режиму HAP (High Assurance Platform) [6]. Эта утилита, вызванная с флагом –FWSTS, выдает подробное описание статусных HECI-регистров и сообщает статус Manufacturing Mode (установленный 4-й бит статусного регистра FWSTS сигнализирует о том, что Manufacturing Mode активен).
Рис 9. Пример вывода утилиты MEInfo
Мы также разработали программу [7], с помощью которого можно проверить статус Manufacturing Mode, если у пользователя по какой-либо причине нет доступа к Intel ME System Tools.
Рис 10. Пример работы скрипта mmdetect
Возникает вопрос, как самостоятельно завершить Manufacturing Mode, если оказалось так, что производитель не сделал этого. Для завершения Manufacturing Mode утилита FPT имеет специальную опцию, –CLOSEMNF, которая, кроме своего основного назначения, также позволяет установить рекомендуемые права доступа к регионам SPI flash в дескрипторе.
Рис 11. Результат работы утилиты FTP с опцией –CLOSEMNF
В данном примере мы использовали параметр NO опции –CLOSEMNF для того, чтобы не выполнять перезагрузку платформы, которая производится по умолчанию сразу после завершения Manufacturing Mode.
Заключение
Наше исследование показывает, что проблема Manufacturing Mode прошивки Intel ME существует и даже такие крупные производители, как Apple, способны ошибаться при конфигурации платформ Intel. Хуже всего, что нет никакой публичной информации на эту тему и конечные пользователи даже не догадываются о такой серьезной проблеме, способной привести к потере конфиденциальной информации, появлению неудаляемых руткитов и безвозвратному выводу оборудования из строя.
Кроме того, у нас есть подозрения, что возможность перезагружать ME без перезагрузки основного CPU может повлечь за собой и другие проблемы в безопасности из-за рассинхронизации состояний BIOS/UEFI и ME.
Авторы: Марк Ермолов и Максим Горячий
[1] Intel Management Engine Critical Firmware Update, Intel-SA-00086
[2] GitHub — chipsec/chipsec: Platform Security Assessment Framework
[4] Fast, secure and flexible OpenSource firmware, Coreboot
[5] Mark Ermolov, Maxim Goryachy, How to Become the Sole Owner of Your PC, PHDays VI, 2016
[6] Mark Ermolov, Maxim Goryachy, Disabling Intel ME 11 via undocumented mode, Positive Technologies’ blog
[7] Intel ME Manufacturing Mode Detection Tools
[8] Alexander Ermolov, Safeguarding rootkits: Intel BootGuard
[9] Dmitry Sklyarov, Intel ME: Flash File System. Explained
Комментарии (41)
bird0001
02.10.2018 17:02Здравствуйте.
1. Как быть, если у пользователей не получается установить даже драйвер intel MEI? (часто встречаю)
2. Все же отключать или не отключать intel ME? Просто: да/нет?
P.S. С удовольствием читаю Ваши статьи по поводу ME :) Спасибо.h0t_max Автор
02.10.2018 17:21Добрый день, спасибо.
1. Скорее всего не та версия драйверов.
2. По желанию)
CodeRush
02.10.2018 17:22+11. Если у вас все нужное вам работает без драйвера (например, используется внешняя видеокарта и изображение выводится именно ей) — ничего страшного от его недоступности не будет, перестанут работать пару утилит вроде XTU или Clock Commander, но если ими не пользоваться, то драйвер можно не ставить.
2. Обычному пользователю лучше не отключать, потому что вы переводите систему из категории «тестировалась в таком виде производителем» в категорию «не тестировалась никем и никогда», и во второй могут случаться всякие сюрпризы вроде загрузки по 30 секунд и зависаний при попытке обновления прошивки. Если вы энтузиаст и прошивку умеете патчить и обновлять в ручную (а еще вам не нужна встроенная видеокарта или вывод HDCP через нее, и вы не пользуетесь SGX) — можете смело отключать.
Tufed
03.10.2018 16:34Злобный вирус/хакер не сможет использовать уязвимость intel ME, если драйвер на неё не установлен в системе.
CodeRush
02.10.2018 17:13+1Два чая этим авторам, наконец-то описали уязвимость в деталях.
Вообще говоря, проблема не столько в Manufacturing Mode, сколько в возможности отката на уязвимую версию ME v11 несмотря на все попытки со стороны прошивки эту возможность закрыть (если они были вообще, таковые попытки), и если благодаря Максу и Марку Apple удалось убрать возможность локальной эксплуатации, то от физической атаки на МЕ-регион в SPI flash защиты на большинстве систем нет (для машин с ME v11, для которой имеется заведомо уязвимая версия прошивки, от такой атаки защищен только на iMac Pro).
Intel решили проблему с откатом до уязвимых версий в ME v12, добавив Security Version Number в FPF'ы, т.е. после обновления на версию с SVN=X, никакие версии с SVN < X на этой машине больше загрузиться не смогут, т.е. без обхода FPF'ов (а это гораздо более серьезная уязвимость) основную проблему таки получилось решить.h0t_max Автор
02.10.2018 17:18Спасибо)
Intel решили проблему с откатом до уязвимых версий в ME v12, добавив Security Version Number в FPF'ы, т.е. после обновления на версию с SVN=X, никакие версии с SVN < X на этой машине больше загрузиться не смогут, т.е. без обхода FPF'ов (а это гораздо более серьезная уязвимость) основную проблему таки получилось решить.
… если производитель не забыл закрыть Manufacturing Mode)))CodeRush
02.10.2018 17:32Таки да? Вот этого я уже не застал, потому что теперь со включенным Manufacturing Mode платформа больше не стартует.
Опять же напомню еще раз, чтобы народ меньше пугался, что ME manufacturing mode умеет выключаться сам, если flash descriptor настроен правильно. К сожалению, это «правильно» по Intel'овски запрещает из региона МЕ чтение, а это портит жизнь довольно сильно, плюс дает Intel ложную уверенность в том, что на MFS можно хранить ключи и их оттуда никто не считает.
В итоге Apple пришлось выключать его вручную только потому, что «правильную» в смысле Intel конфигурацию они не используют, и МЕ у них открыт на чтение.h0t_max Автор
02.10.2018 17:35Интел то решил, но все равно пока он не бъет производителей «по рукам» за открытые регионы и криво сконфигурированный BIOS, ни BootGuard, ни защита от даунгрейда не сработает, на мой взгляд.
CodeRush
02.10.2018 17:39Вот поэтому надо все проверять через MeInfo -verbose, FPT и остальное, а еще лучше эти проверки встроить прямо в прошивку, чтобы она колом вставала при неправильных значениях, либо сама пыталась их исправить, насколько это возможно.
По рукам они бить не могут — руки не настолько длинные, и потому идут по правильному пути, снижая сложность настройки этих технологий, которая до этого была запредельной, а теперь стала просто высокой. Если они этот тренд продолжат, то где-нибудь к МЕv15 вендоры таки смогут (и потому начнут) включать все эти вещи «одной кнопкой», а пока там просто лес стал чуть менее темным.h0t_max Автор
02.10.2018 17:46На самом деле мне нравится идея стопорить загрузку если конфигурация кривая, но пока это не мейнстрим. Ждем очередного инцидента, чтобы остальные об этом задумались… Хотя для некоторых производителей годы идут и ничего не меняется(
Если они этот тренд продолжат, то где-нибудь к МЕv15 вендоры таки смогут (и потому начнут) включать все эти вещи «одной кнопкой», а пока там просто лес стал чуть менее темным.
Они усложняют с каждой версией и конфигурацию, и кажется сами в ней уже путаются. Хочется верить, что когда они сделают «одной кнопкой» это будет работать действительно хорошо.CodeRush
02.10.2018 18:01+1Конфигурацию усложняют, а вот интерфейс к ней — упрощают, и на разнице между v11 и v12 это хорошо видно. Я очень надеюсь, что к них кто-то там понял, что нынешние их технологии просто невозможно настроить так, чтобы в них не зияло дыр, и стал чинить вот это, потому что иначе всем этим технологиям — грош цена.
Мне самому, в принципе, пофигу уже, потому что Т2 закрывает эти вопросы раз и насовсем, но у остальной индустрии Т2 нет, да и у Apple пока что машин с Т2 — три штуки ровно, и они все дорогие.
Am0ralist
02.10.2018 22:09Хотя для некоторых производителей годы идут и ничего не меняется(
а у каких хоть что-то меняется, если не секрет?h0t_max Автор
03.10.2018 09:22У dell, apple, lenovo с безопасностью прошивок хорошо. Этот вопрос поднимался, CodeRush подправит, если я кого-то забыл.
Am0ralist
03.10.2018 12:51Гм, как раз про Lenovo он вроде как не очень отзывался (особенно, если помнить, что есть ширпотреб и есть тинкпады отдельно)…
У асусов все совсем не так? (((h0t_max Автор
03.10.2018 13:12Возможно мне повезло, у тех которые я видел все было хорошо. Хотя историю с модулем UEFI, который устанавливал свой софт в винду я помню.
SergeyMax
02.10.2018 17:48Да, с правами администратора уязвимостей становится гораздо больше.
CodeRush
02.10.2018 17:54+1С такой «успешной» security history всех популярных ОС, можно смело считать, что у локального атакующего эти права уже есть. В конце концов, SecureBoot никто так и не включает, а без него тот же локальный атакующий может загрузить на вашей системе хоть EFI Shell, хоть Linux, и иметь там любые права.
defecator
03.10.2018 09:47Вроде процессор и есть процессор, чипсет и есть чипсет.
А кто мне расскажет, для чего производители настолько всё усложняют?
Для чего нужен ещё один компьютер внутри компьютера?
Daysleeper
03.10.2018 14:43что-бы большой брат, смог следить за тобой, не взирая на то, какую ос, браузер или vpn ты используешь. давно ходят слухи, что баги в безопасности Intel ME, это не баги а фичи (встроенные бэкдоры для спецслужб).
oteuqpegop
04.10.2018 09:48Если погрузиться в конспирологию, то вряд ли ME является наиболее привлекательной целью для намеренного размещения бэкдоров. Код полноценно не зашифрован, универсален, а его объем сравнительно небольшой, так что если разместить там что-то очевидно вредоносное, то кто-нибудь в итоге это отреверсит, и будет большой конфуз, разбирательства, финансовые потери. Для Intel это такой гигантский риск, что просто настойчивого пожелания спецслужб будет недостаточно, думаю. Если же разместить просто уязвимость, которую потом если что можно позиционировать как непреднамеренную ошибку, то система не будет из коробки готова к служению большому брату, а типичная эксплуатация таких уязвимостей подразумевает, что для этого сперва нужно получить как минимум локальный доступ. То есть последующая персистентность остается практически единственным профитом, а геморроя довольно много (у ME физически не хватит ресурсов на полноценный шпионаж за основной системой в реальном времени, придется сопрягать их, да еще и беспалевно...). Если градус предполагаемой слежки оправдывает такие сложности, то логичнее предположить что-то эдакое в действительно зашифрованном микрокоде или вообще на железе, особенно с учетом последних исследований @xoreaxeaxeax.
CodeRush
03.10.2018 16:04+4Это как сказать, что самолет и есть самолет, чего производители настолько их усложняют? Летали бы дальше на этажерках, которые можно обслуживать одним человеком, и которым не нужно аэропорта, но нет, понавыдумывали Боингов и Аэробусов, в которых черт ногу сломит…
Если серьезно, то современный процессор общего назначения — одна из самых сложны вещей, созданных человеком, на мой взгляд. Там под капотом скрыто управление питанием, управление частотами, управление встроенной периферией, криптография, ускорение специализированных вычислений, куча всего еще, и все это само по себе настолько сложное, что делать это все «на железе», т.е. написанным на Verilog и синтезированным до уровня транзисторных блоков — космически дорого, т.к. любая серьезная ошибка приводила бы к необходимости уничтожения всей партии процессоров и чипсетов с ней.
В итоге вместо этого синтезируется процессор «общего назначения», но попроще, и задача выполняется уже программой для него. Программу можно улучшить без замены самого процессора, программу намного легче отлаживать, программисты дешевле в конце концов. При этом процесс синтеза таких процессорных ядер уже отработан, а свободного места под очередной на кристалле море. Так появился микрокод (там еще не совсем общее назначение, но уже близко), когда декодер операций стало невыносимо писать, потом SMU/PMC (когда невыносимо стало управлять питанием), потом ICC (частотами), потом ME (собрали почти весь разрозненный управляющий софт под одной крышей и запустили в РТОС).
Есть и другая сторона этой медали «переходи на софт или умри» — такой переход резко упрощает реализацию новых идей, и потому вместе с хорошими идеями реализуются и не очень хорошие. Эй пацаны, хотите DRM прямо в чипсете — нате, хотите удаленное управление прямо там же, бесплатно — держите, хотите Java-машину и запуск апплетов прямо там же — пожалуйте, только денег заплатите, чтобы мы вам апплет подписали. А когда ядер много стало свободных, их стали двигать как бесплатный микроконтролер общего назначения, который уже ко всей чипсетной периферии подключен, и который можно программировать, заменив им отдельно стоящий EC/BMC.
Короче, миром опять правит не тайная ложа, а явная лажа. Я не могу отрицать заговора спецслужб или происки марсиан, но я легко могу для себя объяснить нынешнюю ситуацию и без них.
Konachan700
03.10.2018 16:04+1Железо сложное, сценарий его запуска очень сложный, многое железо еще и требует дергать его в реалтайме. Драйверами уже не обойтись. Плюс пользователь хочет красивый биос с тридэ и мышкой, хочет удаленный доступ без ОС, хочет минимум драйверов, энергоэффективность, защиты от дурака, безопасность… Производитель делает то, что требуют массы. А закрыто это дело потому что в исходниках наверняка черт ногу сломит, как в плане качества, так и в плане лицензирования.
h0t_max Автор
03.10.2018 17:35+1На самом деле, на мой взгляд, если интел откроет МЕ дело это не исправит, так как всякую прошивку ключей root of trust для МЕ придется «зашивать» уже вендорам, а они более простые вещи делать еще не научились (в большинстве своем). А исходники без описания железа тоже не сильно спасут (на мой взгляд). Что касается МЕ, у меня скорее претензия к инженерному решению скорее а не к тому, что это появилось…
MK_Ultra
мой нерасторопный APU AMD A9 становится все лучше и лучше!
EmmGold
Как неуловимый Джо
MK_Ultra
да, как неуловимый Джо, но не все ли равно?
EmmGold
Дык про это и топик, буквально первый абзац:
marat_zh
AMD в этом плане ничем не лучше Intel, у них есть аналогичная и так же секретная технология — AMD PSP.
По крайней мере для Intel можно купить материнскую платы, разработчики которой использовали биос с открытым исходным кодом и нашли способ отключить Intel ME, а для AMD такого нет.
h0t_max Автор
У AMD PSP, насколько я знаю, появился относительно недавно. На счет «отключения», после статей про HAP AMD опубликовало BIOS в котором есть опция отключения, но на самом деле это невозможно.
CodeRush
Эта опция (BIOS PSP Support) — такое же отключение PSP, как незапуск HeciDxe — отключение ME. Нормально PSP на процессорах с ним отключить нельзя — он память тренирует и S3 bootscript хранит, так что Intel и в этом плане лучше.
BiosUefi
Почему все упоминают про PSP, но никто про SMU(MP)0/1/2....5?
А ведь PSP крутится только на одном из них. Вроде?
CodeRush
Не, для PSP выделили отдельное ядро Cortex-M, а SMU как исполнялось на LM32, так и продолжает (могло измениться в новых процессорах, я после FP4 с AMD не работал).
Про почему — а к чему там иметь доступ из SMU? К профилям питания, или к шине SMBUS? Таким же образом можно EC в обычном ПК сломать — это довольно просто, прошивки к ним до сих пор мало кто подписывает, только толку не очень много, мне в голову приходит только кейлоггер, и то если клавиатура по PS/2 к EC подключена.
BiosUefi
>> PSP выделили отдельное ядро Cortex-M
а ABL крутится на соседнем ядре, раздавая команды для PSP?
CodeRush
Не знаю точно, выполняет ли PMU свой кусок AGESA Boot Loader на том же ядре, или на соседнем (скорее все же на соседнем), но со стороны прошивки это выглядит как «подготовил таблицы, отправил их в PSP mailbox, дождался ответа, вуаля — память готова», со слотовой DIMM такая магия даже удобнее, но как только начинает хотеться странного, памяти там себе на обе стороны платы напаять, вот это все, как магия дает сбой и начинаются танцы с бубном.
CodeRush
Поправлю сам себя, там Cortex-A, в первом поколении были А5, что сейчас у Rysen/EPYC — не знаю, но скорее всего что-то боее мощное.