full recovery of the intel management engine firmware failed что делать
Full recovery of the intel management engine firmware failed что делать
Доброго времени суток!
Ноутбук Lenovo Legion Y720-15IKB, типовая модель: 80VR006YLT, Windows 10 (64-bit), версия биоса: 4GCN31WW. Текущая версия Intel Management Engine Interface в диспетчере устройств: 11.7.0.1014
Прошу советов, а также с чем это может быть связано?
220528 Вид страницы
Re: Legion Y720 Не проходит обновление Intel Management Engine 11.8 Firmware
Вы путаете версию драйвера и версию прошивки.
В данном случаи вы обновляли прошивку(Firmware)
Версию прошивки можно узнать с пом. специальной утилиты Intel
Скачать её можно здесь
Вот какую информацию она выдаёт(перевод правда кривоватый)
Вот что в диспетчере устройств
220528 Вид страницы
Re: Legion Y720 Не проходит обновление Intel Management Engine 11.8 Firmware
Прошу советов, а также с чем это может быть связано?
Насколько мне известно такое оповещение не должно выдаваться.
Intel Management Engine Firmware является частью биоса ноутбука.
После обновления Intel Management Engine Firmware ноутбук просто перезагружается.
Re: Legion Y720 Не проходит обновление Intel Management Engine 11.8 Firmware
220528 Вид страницы
Re: Legion Y720 Не проходит обновление Intel Management Engine 11.8 Firmware
Вы путаете версию драйвера и версию прошивки.
В данном случаи вы обновляли прошивку(Firmware)
Версию прошивки можно узнать с пом. специальной утилиты Intel
Скачать её можно здесь
Вот какую информацию она выдаёт(перевод правда кривоватый)
Вот что в диспетчере устройств
0 Это решение оказалось полезным.
Re: Legion Y720 Не проходит обновление Intel Management Engine 11.8 Firmware
Спасибо за Ваш ответ, и извиняюсь за собственную некомпетентность. Действительно, версия прошивки у меня отображается актуальная » Intel(R) Management Engine Версия: 11.8.50.3399″ (прилагаю скрин).
Также согласно выведенной информации утлитой, в моем случае рекомендуется обновить ПО: » Установленное ПО Intel(R) Capability Licensing Service Client устарело. Минимальная требуемая версия 1.47.715.0. Пожалуйста, обновите ПО Intel(R) Capability Licensing Service Client (доступно у вашего производителя системы).»
Могли бы Вы, пожалуйста, порекомендовать где это можно сделать?
220528 Вид страницы
Re: Legion Y720 Не проходит обновление Intel Management Engine 11.8 Firmware
Остаётся ждать когда появится обновлённый драйвер Intel MEI
Re: Legion Y720 Не проходит обновление Intel Management Engine 11.8 Firmware
для чего нужно Intel Management Engine 11.8 Firmware на сайте написано что есть на мой но зачем это так и не понял?
Правила Сообщества
Пожалуйста, ознакомьтесь с правилами сообщества перед публикацией.
Проверьте текущие предложения!
Самые популярные сообщения
Пожалуйста, авторизуйтесь, чтобы поставить Лайк
Welcome to Ideation!
Ideation sections have been created for customers to engage with us by discussing and promoting ideas and improvements relating to Lenovo’s products and services.
As a reminder, your participation in Ideation is governed by Lenovo’s website Terms of Use and by Lenovo’s Forums Community Guidelines. Additional terms governing the Ideation Program are included in the Ideation Terms and may be found here. For your convenience, here’s a
Quick summary of the highlights:
By clicking on “Yes” below you certify that you have read and agree to the Community Guidelines and the Ideation Terms, and acknowledge that by submitting any ideas, material, or information on the Ideation site you grant Lenovo the right to use any such submissions by you in any way without acknowledging, notifying, or compensating you, as described in those documents.
BIOS and Intel Management Engine Firmware update fail on Zbook x360
I have tried installing all version of Intel Management Engine Drivers 1846.12.0.1177 Rev.A/ 1825.12.0.1144 Rev.A/1813.12.0.1124 Rev.A available at https://support.hp.com/us-en/drivers/selfservice/hp-zbook-studio-x360-g5-convertible-workstation/200.
My current BIOS is at Q71 Ver. 01.04.05 and upgrade to Q71 Ver. 01.06.03 A1 avaialble from SSM also fails.
The system is not able to wake from sleep since my last bios update.
Any help is greatly appreciated.
So I fixed the system myself. Posting here for anyone with similar issues.
It was a mix of multiple problems.
— Had to use a Microsoft tool to uninstall all Visual C++ redist packages as these were causing IMEI updates to fail
— The BIOS update fails were caused by insufficient space on EFI partition. So I used diskpart to manually extend the EFI partition.
— Finally, the wake from sleep issue was caused by Samsung NVME drivers when two M.2 SSD are present. Using the new NVME driver from Samsung fixes that.
Thanks for your assistance.
Try using HPIA to install the updates.
One you download and install HPIA it should laucn. Once you are inside HPIA, make sure the Analyze Image tab is selected and then press the Blue Analyze button.
Look at the Summary tab and you will see information about your system.
Click on the Recommendations tab and look for the Intel Management Engine updates. Depending on what has been installed there might be a few items selected as critical. Look at what is selected and you should see that SP93335 as the SoftPaq that needs to be installed. Make sure it is selected (you might see that 1,2 or 3 downloads are listed on the Download button.
Press the Download button.
Select your desired download location or leave as the default. Under Operation, select Download SoftPaqs, extract files and install. Press Start.
Once the installation has completed a summary HTML should appear and tell you if the installation was sucessful.
Reboot the system and repeat the steps above again but this time select the HP Firmware Pack (Q71) v01.06.03. If you have set a BIOS Admin password you will be prompted to supply the password.
Let us know the results of your testing.
I am an HP Employee.
If you like my post, click the thumbs up.
Really appreciate the detailed writeup.
HPIA reveals different issues. After running Analyze, I have the following observations.
— No IMEI related entries under the Recommendations tab
— Under the «Device Drivers» tab IMEI is listed to be the same with the reference image and version is 1815.12.0.2021
— Under the firmware tab IntelME version 12.0.7.1122 is listed under «Target Image only», but there is no corresponding entry for «Reference Image». Note I have all boxes checked so there should be a listing for the reference image state.
My hardware ID from the device manager is PCI\VEN_8086&DEV_A360&SUBSYS_844F103C&REV_10
Since you mentioned I got the softpaq from https://ftp.hp.com/pub/softpaq/sp93001-93500/sp93335.exe and tried installing it. But it fails.
Any help in getting the firmwares updated would be greatly appreciated.
The failure to wake from sleep is a major handicap.
Something is amiss.
Please contact support and provide them with the steps you are have attempted thus far.
Additionally collect the following two things which will greatly assist technical support as they work your issue.
Capture an HPIA configuration file.
Download and run ImageDiags
This location has information on ImageDiags and a nice overview of the utility. The tool is used by all levels of HP Technical Support and will aid them greatly in troubleshooting your issue.
Before you run ImageDiags please read the User Guide which details requirements for the utility (.net 4.5, etc.). Once you ready run ImageDiags by right clicking on the EXE and run as an Administrator.
Be aware that the analysis is very extensive and will take possibly over an hour to complete.
The link to the EXE
Place ImageDiags2.exe into an empty subdirectory on your system so that all of the log files created will be easy to identify.
Let HP Technical Support know that you have run ImageDiags.
I am an HP Employee.
If you like my post, click the thumbs up.
Thanks for the help. I have generated both HPIA logs and ImageDiag logs.
I tried contacting support but they have no idea what to do with these.
They just told me about the disable/enable fast boot options.
Adding the relevant section from the firmware update log.
Hope this helps in identifying the root cause.
2019/02/27 11:40:56.349|000CA3F0|Information|CHPBiosUpdateApp::MergeBinFile|Scan INF folder = [C:\SWsetup\SP92844\]
2019/02/27 11:40:56.349|000CA3F0|Information|CHPBiosUpdateApp::MergeBinFile|Check INF file = C:\SWsetup\SP92844\Q71_010405.inf
2019/02/27 11:40:56.349|000CA3F0|Information|CHPBiosUpdateApp::CheckInfGUID|BinFilePath =»C:\SWsetup\SP92844\Q71_010405.bin»
2019/02/27 11:40:56.380|000CA3F0|Error |HPBiosUpdate::PrivateWmiInfo::GetBinFileName|0x2 command failed, hr = 0x0, return code = 0x3.
2019/02/27 11:40:56.380|000CA3F0|Information|CHPBiosUpdateApp::CheckInfGUID|GUID 4cbcb03a2769a2408bbd2025cdb63a87 Not Found!
2019/02/27 11:40:56.380|000CA3F0|Information|CHPBiosUpdateApp::MergeBinFile|No Validate firmware found!
2019/02/27 11:41:07.929|000CA3F0|Information|CHPBiosUpdateApp::PerformWizard|User canceled wizard.
2019/02/27 11:41:07.933|000CA3F0|Information|CHPBiosUpdateApp::ExitInstance|HpFirmwareUpdRec Return Code = 1602
2019/02/27 11:41:07.945|000CA3F0|Information|CHPBiosUpdateApp::ExitInstance|****************** End of HpFirmwareUpdRec session ******************
2019/02/27 11:41:07.945|000CA3F0|Information|CHPBiosUpdateApp::ExitInstance|
Выключаем Intel ME 11, используя недокументированный режим
В ходе исследования внутренней архитектуры Intel Management Engine (ME) 11-й версии был обнаружен механизм, отключающий эту технологию после инициализации оборудования и запуска основного процессора.
В ходе исследования внутренней архитектуры Intel Management Engine (ME) 11-й версии был обнаружен механизм, отключающий эту технологию после инициализации оборудования и запуска основного процессора. О том, как мы нашли этот недокументированный режим, и о его связи с государственной программой построения доверительной платформы High Assurance Platform (HAP) мы расскажем в этой статье.
Авторы предупреждают, что использование данных знаний на практике может повлечь за собой повреждение вычислительной техники, и не несут за это никакой ответственности, а также не гарантируют работоспособность или неработоспособность чего-либо и не рекомендуют экспериментировать без наличия SPI-программатора.
Введение
Intel Management Engine — это закрытая технология, которая представляет собой интегрированный в микросхему Platform Controller Hub (PCH) микроконтроллер с набором встроенных периферийных устройств. Именно через PCH проходит почти все общение процессора с внешними устройствами, следовательно Intel ME имеет доступ практически ко всем данным на компьютере и возможность исполнения стороннего кода позволяет полностью скомпрометировать платформу. Такие безграничные возможности привлекают исследователей не первый год, но сейчас интерес к технологии Intel ME значительно вырос. Одной из причин этого является переход данной подсистемы на новую аппаратную (x86) и программную (доработанный MINIX в качестве операционной системы) архитектуру. Применение платформы x86 позволяет использовать всю мощь средств анализа бинарного кода, что ранее было затруднительно, так как до 11-й версии использовалось ядро с малораспространенной системой команд — ARC. К сожалению, анализ Intel ME 11-й версии был затруднен тем, что исполняемые модули упакованы кодом Хаффмана с неизвестными таблицами. Но нашей исследовательской группе (Дмитрий Скляров, Марк Ермолов, Максим Горячий) удалось их восстановить (утилиту для распаковки образов можно найти на нашей странице в GitHub).
После распаковки исполняемых модулей мы приступили к изучению программной и аппаратной «начинки» Intel ME. Наша команда занимается этим уже достаточно продолжительное время, и мы накопили большой объем материалов, которые было решено опубликовать. Это первая статья из цикла статей, посвященных внутреннему устройству и особенностям работы Intel ME, и в ней мы расскажем, как отключить основной функционал подсистемы. Этот вопрос терзает специалистов, так как ее отключение позволило бы снизить риски утечки данных, например в случае обнаружения в этой технологии уязвимости нулевого дня.
Как выключить ME
Как выключить ME — этот вопрос часто задают некоторые владельцы компьютеров x86-архитектуры. Тема деактивации неоднократно поднималась, в том числе и исследователями нашей компании.
Актуальности этому вопросу добавляет недавно обнаруженная критическая (9,8 из 10) уязвимость в Intel Active Management Technology (AMT) — технологии, которая базируется на Intel ME.
Сразу огорчим читателя — полностью выключить ME на современных компьютерах невозможно. Это связано прежде всего с тем, что именно эта технология отвечает за инициализацию, управление энергопотреблением и запуск основного процессора. Сложности добавляет и тот факт, что часть кода «жестко прошита» внутри микросхемы PCH, которая выполняет функции южного моста на современных материнских платах. Основным средством энтузиастов, которые «борются» с данной технологией, является удаление всего «лишнего» из образа flash-памяти при сохранении работоспособности компьютера. Но сделать это не так просто, так как, если встроенный в PCH код не найдет во flash-памяти модули ME или определит, что они повреждены, система запущена не будет. Уже несколько лет в сети развивается проект me_cleaner, в рамках которого доступна специальная утилита, позволяющая удалить большую часть образа и оставить только жизненно необходимые для основной системы компоненты. Но даже если система запустилась, радоваться рано — приблизительно через 30 минут может произойти автоматическое отключение, так как при некоторых сбоях ME переходит в Recovery-режим, в котором не функционирует больше некоторого фиксированного времени. В итоге процесс очистки усложняется. Например, до 11-й версии удавалось уменьшить размер образа до 90 KБ, но в 11-й — уже только до 650 КБ.
Секреты в QResource
Intel дает производителям материнских плат возможность задать небольшое количество параметров ME. Для этого компания предоставляет производителям оборудования специальный набор программного обеспечения, в который входят такие утилиты, как Flash Image Tool (FIT) для настройки параметров ME и Flash Programming Tool (FPT), реализующая поддержку программирования flash-памяти напрямую через встроенный SPI-контроллер. Данные программы недоступны конечному пользователю, но их без труда можно найти в интернете. Из этих утилит можно извлечь большое количество файлов формата XML (подробное Intel ME: The Way oftheStatic Analysis), изучение которых позволяет узнать много интересного: структуру прошивки ME и описание PCH strap — специальных конфигурационных битов для различных подсистем, интегрированных в микросхему PCH.
Нас заинтересовало одно из таких полей с именем «reserve_hap», так как напротив него имелся комментарий — High Assurance Platform (HAP) enable.
Поиск в Google не был долгим. Буквально вторая ссылка говорит, что такое название носит программа по созданию доверительных платформ, связанная с Агентством национальной безопасности (АНБ) США. Презентацию с описанием программы можно найти тут. Нашей первой мыслью было поставить этот бит и посмотреть, что будет. Это может сделать любой желающий, если у него есть SPI-программатор или доступ в Flash Descriptor (на многих материнских платах некорректно выставлены права доступа к регионам flash-памяти).
После загрузки платформы утилита meinfo сообщает странный статус — Alt Disable Mode. Беглые проверки показали, что ME не отвечает на команды и никак не реагирует на воздействия из операционной системы. Мы решили разобраться, как система переходит в этот режим и что он означает. К этому времени у нас уже была проанализирована основная часть модуля BUP, который отвечает за начальную инициализацию платформы и, исходя из вывода meinfo, устанавливает этот статус. Для понимания алгоритма работы BUP необходимо более подробно описать программное окружение Intel ME.
Программная часть Intel ME 11
Начиная с PCH 100-й серии компания Intel полностью переработала эту микросхему. Был осуществлен переход на новую архитектуру встроенных микроконтроллеров — с ARCompact компании ARC на x86. За основу был выбран 32-битный микроконтроллер Minute IA (MIA), который используется в микрокомпьютерах Intel Edison и SoC Quark. Он основан на дизайне весьма старого, скалярного микропроцессора Intel 486 с добавлением системы команд (ISA) от процессора Pentium. Однако для PCH компания выпускает данное ядро с применением 22-нм полупроводниковой технологии, получая высокую энергоэффективность микроконтроллера. Таких ядер в новом PCH три: Management Engine (ME), Integrated Sensors Hub (ISH) и Innovation Engine (IE). Последние два могут активироваться и деактивироваться в зависимости от модели PCH и целевой платформы, а ME-ядро работает всегда.
Такие глобальные изменения потребовали изменения и программной составляющей ME. В частности, в качестве основы для операционной системы был выбран MINIX (ранее ThreadX RTOS). Теперь прошивка ME включает полноценную операционную систему со своими процессами, потоками, диспетчером памяти, драйвером аппаратных шин, файловой системой и многим другим. В ME интегрирован аппаратный криптопроцессор, поддерживающий алгоритмы SHA256, AES, RSA, HMAС. Доступ к оборудованию для пользовательских процессов производится посредством локальной таблицы дескрипторов (LDT). Через LDT организовано также и адресное пространство процесса — оно является всего лишь частью глобального адресного пространства ядра, границы которого заданы в локальном дескрипторе. Таким образом, ядру не нужно переключаться на память разных процессов (меняя каталоги страниц), как, например, в Microsoft Windows или Linux.
На этом закончим обзор программного окружения Intel ME и рассмотрим более подробно, как происходит загрузка операционной системы и модулей.
Стадии загрузки Intel ME
Запуск начинается с программы ROM, которая содержится во встроенной в PCH статической памяти. К сожалению, способ прочесть или перезаписать эту память широкой общественности не известен, но в интернете можно найти «предпродажные» версии прошивки ME с разделом ROMB (ROM BYPASS), который, по нашему предположению, дублирует функционал ROМ. Таким образом, исследуя такие прошивки, можно восстановить основной функционал программы первичной инициализации.
Изучение ROMB позволяет понять назначение ROM — выполнение начальной инициализации оборудования, например SPI-контроллера, проверка цифровой подписи заголовка раздела FTPR, загрузка модуля RBE, который расположен уже во flash-памяти. RBE, в свою очередь, проверяет контрольные суммы модулей KERNEL, SYSLIB, BUP и передает управление на точку входа в ядро.
Следует заметить, это эти три сущности — ROM, RBE и KERNEL — выполняются на нулевом уровне привилегий (в ring-0) ядра MIA.
Первый процесс, который создается ядром, — это BUP, который уже выполняется в своем адресном пространстве, в ring-3. Других процессов ядро по своей инициативе не запускает, этим занимается сам BUP, а также отдельный модуль LOADMGR, к нему вернемся позже. Назначение BUP (platform BringUP) — это инициализация всего аппаратного окружения платформы (в том числе процессора), выполнение первичных функций управления энергопитанием (например, запуск системы по нажатию кнопки включения) и запуск все остальных процессов ME. Таким образом, можно с уверенностью говорить, что PCH в 100-й серии и выше просто физически не имеют возможности запуска без корректной прошивки ME. Во-первых, BUP инициализирует контроллер управления энергопитанием (power management controller, PMC) и ICC-контроллер. Во-вторых — запускает целую вереницу процессов; часть из них «жестко прошита» в коде (SYNCMAN, PM, VFS), а другая часть содержится в InitScript (аналог автозапуска), который хранится в заголовке тома FTPR и защищен цифровой подписью.
Таким образом, BUP считывает InitScript и запускает все процессы, которые удовлетворяют типу запуска ME и являются IBL-процессами.
В случае если запуск процесса не удался, BUP не будет запускать систему или переведет ее в Recovery режим, в котором произойдет автоматическое отключение питания после нескольких десятков минут. Как можно видеть на иллюстрации, последним в списке IBL-процессов является LOADMGR. Именно он дает старт оставшимся процессам, но в отличие от BUP, если в процессе запуска модуля происходит ошибка, LOADMGR просто перейдет к следующему.
Таким образом, первый вариант ограничить функционирование Intel ME — удалить все модули, которые не имеют флаг IBL в InitScript, что позволит существенно уменьшить размер прошивки. Но первоначально мы хотели выяснить, что происходит с ME в режиме HAP. Для этого рассмотрим программную модель BUP подробнее.
BringUP
Если присмотреться к алгоритму работы модуля BUP, можно сказать, что внутри него реализован классический конечный автомат. Выполнение функционально разделено на две составляющие: стадии инициализации (представляют собой тот самый конечный автомат) и выполнение сервисных запросов других процессов после инициализации системы. Число стадий инициализации разное, в зависимости от платформы и SKU (TXE, CSME, SPS, consumer, corporate), но основные, общие для всех версий, все же можно выделить.
Первая стадия
На начальной стадии происходит создание внутренней диагностической файловой системы sfs (SUSRAM FS — файловая система, расположенная в энергозависимой памяти), считывание конфигурации, и, самое главное, получение информации от PMC о том, что привело к данному старту — включение питания платформы, глобальный перезапуск всей платформы, перезапуск только ME или же пробуждение из состояния сна. Эта стадия называется boot flow determination. От нее зависят последующие стадии работы конечного автомата инициализации. Кроме того, поддерживаются несколько режимов работы: нормальный и набор сервисных режимов, при которых основной функционал ME не выполняется — HAP, HMRFPO, TEMP_DISABLE, RECOVERY, SAFE_MODE, FW_UPDATE и FD_OVERRIDE.
Вторая стадия
На следующей стадии происходят инициализация ICC-контроллера и загрузка ICC-профиля (отвечает за тактовые частоты основных потребителей), инициализация Boot Guard и начало циклического опроса подтверждения запуска процессора.
Третья стадия
BUP ожидает сообщение от PMC о том, что основной процессор запустился. После этого BUP запускает асинхронный цикл опроса PMC на предмет возникновения событий энергопитания (перезапуск или отключение платформы) и переходит к следующей стадии. Если такое событие произошло, BUP выполнит запрашиваемое действие в момент перехода между стадиями инициализации.
Четвертая стадия
На этой стадии происходит инициализация внутреннего оборудования. Также BUP запускает цикл опроса heci (специального устройства, предназначенного для получения команд от BIOS или операционной системы) на предмет получения DID (DRAM Init Done message) от BIOS. Именно это сообщение позволяет ME понять, что основной BIOS инициализировал оперативную память и зарезервировал для ME специальный регион, UMA, и после этого перейти к следующей стадии.
Пятая стадия
Как только DID получен, BUP, в зависимости от режима работы, который определяется по разным составляющим, либо запускает IBL-процессы из InitScript (при нормальном режиме работы), либо зависает в цикле, выйти из которого он может только при получении сообщения от PMC, например, в результате запроса на перезагрузку или выключение системы.
Именно на этой стадии мы и находим обработку HAP, причем в этом режиме BUP не выполняет InitScript, а зависает. Таким образом, остальная последовательность действий при нормальном режиме работы не имеет отношения к HAP и нами рассматриваться не будет. Главное, что хочется отметить: в режиме HAP BUP выполняет всю инициализацию платформы (ICC, Boot Guard), но не запускает основные процессы ME.
Установка HAP-бита
Исходя из вышесказанного, второй вариант отключения состоит в установке HAP-бита и удалении или повреждении всех модулей, кроме тех, которые необходимы BUP для старта — RBE, KERNEL, SYSLIB, BUP. Сделать это можно просто убрав их из CPD-раздела FTPR и пересчитав контрольную сумму заголовка CPD (подробнее структура прошивки ME описана тут).
Остается еще один вопрос: как установить этот бит? Можно воспользоваться конфигурационными файлами FIT и определить, где он расположен в образе, но есть путь проще. Если открыть FIT, то в секции ME Kernel можно найти некий параметр Reserved. Именно этот бит и отвечает за включение режима HAP.
HAP и Boot Guard
Нами также был найден код в BUP, который при активированном режиме HAP устанавливает дополнительный бит в политиках Boot Guard. К сожалению, выяснить, чем управляет этот бит, нам пока не удалось.
Поддержка ME 11 в me_cleaner
Пока эта статья готовилась к печати, разработчики обновили me_cleaner, в результате чего он стал так же удалять из образов все модули, кроме RBE, KERNEL, SYSLIB и BUP, но без установки HAP-бита, что вводит ME в режим «TemporaryDisable». Нам стало любопытно, что происходит при таком подходе.
Мы выяснили, что удаление разделов с файловой системой ME приводит к ошибке при чтении файла cfg_rules. Данный файл содержит ряд различных настроек системы. Среди них, как мы полагаем, есть флаг, который мы назвали «bup_not_temporary_disable». Если он не установлен, вся подсистема переводится в режим TemporaryDisable, а так как этот флаг – глобальная переменная, по умолчанию инициализированная нулем, то ошибка чтения расценивается как конфигурация, требующая отключения.
Отметим также, что мы проверили также прошивки от серверной и мобильной версии ME (SPS 4.x и TXE 3.x). В серверной версии этот флаг всегда устанавливается в 1, а в мобильно не анализируется. Из вышесказанного следует, что данный способ не сможет работать на серверных и мобильных версиях (Apollo Lake) ME.
Вместо заключения
Таким образом, мы нашли недокументированный PCH strap, который позволяет перевести Intel ME в режим отключения основного функционала на ранней стадии. Хотя физическое удаление модулей из образа с сохранением работоспособности неявно доказывает, что этот режим производит отключение ME, бинарный анализ не оставляет поводов для сомнений. C большой долей уверенности можно сказать, что выйти из этого режима Intel ME уже не в состоянии, так как в модулях RBE, KERNEL и SYSLIB не найдено функционала, который позволял бы это осуществлять. Также мы считаем, что ROM, интегрированный в PCH, практически не отличается от ROMB, в котором тоже не найдено ничего похожего. Таким образом, HAP позволит защититься от уязвимостей, присутствующих во всех модулях, кроме RBE, KERNEL, SYSLIB, ROM и BUP, но, к сожалению, от эксплуатации ошибок на более ранних этапах этот режим не предохранит.
Мы ознакомили представителей Intel с деталями исследования. Их ответ подтвердил нашу догадку о связи недокументированного режима с программой High Assurance Platform. С разрешения компании приведем отрывок из ответа:
In response to requests from customers with specialized requirements we sometimes explore the modification or disabling of certain features. In this case, the modifications were made at the request of equipment manufacturers in support of their customer’s evaluation of the US government’s “High Assurance Platform” program. These modifications underwent a limited validation cycle and are not an officially supported configuration.
Мы полагаем, что данный механизм — удовлетворение обычной просьбы любой правительственной службы, которая хочет уменьшить вероятность утечки по побочным каналам. Но остается главный вопрос: как HAP влияет на функционирование Boot Guard? Из-за закрытости этой технологии ответить на этот вопрос пока не представляется возможным, но мы надеемся, что в скором будущем нам это удастся.
Авторы: Горячий Максим, Ермолов Марк