Боремся с дистанционным контролем: как отключить Intel ME

Логично, поскольку AMT это такой «приятный бонус» от наличия ME. Если пользователь не хочет сам удалённо управлять своим железом — он волен отключить, но, увы, Intel не намерена лишать такой возможности себя.

А зачем оно там есть? И можно ли до него как-то достучаться?

В «живой природе» выловить такое не удалось, видимо это вопрос времени,
но патент и настройки для этой функции в Flash Image Tool для PCH есть
уже сейчас.

Я так и подумал (в презентации на слайде 5, приведен рисунок из патента). Однако в патентах, имеющих отношение к ME, много чего написано, не имеющего отношение к действительности.

Тут имелось ввиду, что UMA используется как swap бортовой SRAM. Кеш для
ME — это сам SRAM.

А это из какого патента?

Кэш кода/данных это кэш ME-контроллера. ME SRAM — отдельное внутреннее ЗУ, ME ROM (со стартовым кодом, тоже, кстати, кэшируется) — отдельное внутреннее ЗУ, ME UMA – область в оперативной памяти компьютерной системы.

Содержимое этих областей спроецировано в адресное пространство ME-контроллера.

1. В прошивках, которые были исследованы, SPI активно используется в процессе работы. При обновлении ME вынужден блокировать доступ к Flash, что приводит к отключению критических для ME функций.

Критических это каких?

Допустим, после получения сообщения HMR FPO (о нём упоминается на слайде 20 в презентации) в HECI, ME не трогает флеш-память, а значит, прошивку. Но до этого момента он уже успел загрузить весь (или почти весь) свой код в ME UMA (это показывает, как минимум тот факт, что HECI работает, через который ME получает сообщение). Следовательно, до этого момента ME-контроллер успеет выполнить определённое количество кода и нет доказательств того, что он не будет исполнять загруженный код и дальше, пусть и деактивировав некоторые внешние интерфейсы.

2. Сбой Dram Init Done на самом деле не является запросом к ME на отключение, а просто имитирует аппаратный сбой, что заставляет ME
переходить в режим бездействия.

А в чём заключается режим бездействия? В презентации на слайде 14 упомянута «ошибка», что под этим подразумевается? Генерация исключения? Это приведёт к ресету компьютерной системы.

Не оповещение ME-контролеру о DRAM Init Done приведёт к тому, что он не будет использовать ME UMA, но остаётся ещё ME SRAM, и доступ к SPI флеш-памяти (т.е. к своей прошивке) никуда не делся.

3. Режим Manufacture Mode — специальный режим, который предназначен для отладки оборудования при производстве, опять таки те прошивки, которые попадались действительно выключали ME, не только KVM, но и устройство перестает отвечать на любые запросы и еще много косвенных доказательств.

Если верить документации (например, из System Tools Kit), ME выключен на платформе в режиме Manufacture Mode (в следствие HDA_SDO или настроек в flash descriptors). Но как вы в этом убедились?

На мой взгляд «косвенных доказательств» (наблюдение ограничения функциональности Intel ME т.е. отключения внешних интерфейсов, в т.ч. HECI) недостаточно, чтобы однозначно утверждать, что подсистема Intel ME не функционирует вообще, никакого кода не исполняется, и она не «проснётся» при возникновении какого-либо события извне.

К тому же, в презентации на слайд номер 26 приводится список компьютерных систем, где, если я правильно Manufacture Mode включен out-of-the-box? Вы хотите сказать, что у счастливых обладателей этих систем, ME уже выключен? :)

4. Возвращаясь к UMA и выключению канала. Как сказано в презентации, сам по себе этот способ убивает машину через не более чем 40 секунд,
но его можно использовать как косвенный показатель того, что ME действительно не функционирует

Имхо, это больше сбой в работе контроллера памяти. В любом случае, это DoS платформы, а не способ отключения Intel ME.

«выдираем» у ME процессора данные и код, объем ядра и базовой обвязки у МЕ больше чем SRAM, функционировать без UMA в «полную силу» ОС МЕ контроллера не может.

А какого размера SRAM у ME? Какие кодовые модули в прошивке вы считаете базовой обвязкой? Спрашиваю конкретные цифры, чтобы убедиться в нехватке места.
Без ME UMA «в полную силу» подсистема не функционирует, но ограничение функциональности не означает отключение.

5. В какой то степени мы доверяем, что ME выключает сам себя (можно взять модуль, найти обработчик указаной команды и удостовериться в
этом). Но исследователи представили метод для косвенного доказательства отключения МЕ.

А вы анализировали этот обработчик? Т.е. всю цепочку исполнения кода от начала принятия команды на выключение до окончания её обработки и перехода в «режим бездействия»? Если да, то не могли бы подробнее описать, что там происходит? И для какой версии Intel ME firmware?

Подается, он висит в бесконечном цикле.

Почему он оказывается в бесконечном цикле? Как вы в этом убедились?
В демке, насколько я понял, была отправлена команда на отключение ME в HECI, значит, в результате принятия этой команды? Опять же, возникает вопрос про обработчик, который я задал выше.


В заключение скажу, что способов, описанных в открытых (патенты, спецификации на чипсет и процессор, форумы, книги по ME) и полуоткрытых (System Tools Kit) источниках явно недостаточно, для того, чтобы выключить подсистему Intel ME. Исследователи и разработчики, которые занимаются/интересуются этим вопросом довольно продолжительное время в один голос твердят об этом (пруф, пруф, пруф, пруф, ещё можно спросить «как дела с отключением ME?» у разработчиков проектов на основе свободного ПО, например Purism).
Неужели всё так просто?

Повторюсь, все эти способы:

• либо приводят к DoS (почти сразу или через несколько десятков минут);
• либо не гарантируют того, что подсистема Intel ME действительно выключена.

Либо и то и другое :)

Соглашусь с комментариями выше в этой ветке: чтобы гарантировать неисполнение кода ME-контроллером следует отнять у него этот код, удалив прошивку из ME-региона и добиться полной работоспособности платформы. И даже в этом случае, останется код в ME ROM, содержимое которого, в production-версиях компьютерных систем неизвестно.

Вы хотели сказать наоборот — не старше 2009 года для интел и 2013 для АМД.