Pei intel mrc execution что это

Обновлено: 06.07.2024

Каждый, кто работал с эмулятором для разработки Android -приложений, знает, что даже на современных компьютерах эмулятор загружается и работает очень медленно. Intel Hardware Accelerated Execution Manager ( Intel HAXM) – это решение данной проблемы, использующее аппаратные возможности виртуализации и позволяющее значительно ускорить работу эмулятора Android .

Intel HAXM работает в паре с эмулятором для х86 устройств. При этом, виртуальное устройство будет работать со скоростью, приближенной к скорости работы реального устройства, что поможет сократить время на запуск и отладку приложения.

Прежде, чем установить Intel HAXM, необходимо убедиться, что компьютер удовлетворяет системным требованиям:

В процессе установки будет предложено определить объем выделяемой оперативной памяти. Можно оставить значение , предложенное по умолчанию. Если в процессе работы потребуется изменить это значение , нужно просто запустить установку еще раз.

Также во время установки может возникнуть предупреждение о том, что виртуализация не включена. В этом случае нужно проверить настройки в BIOS , возможно, виртуализация поддерживается системой, но по умолчанию отключена.

Для того, чтобы проверить, что все установлено верно и работает, необходимо в командной строке выполнить: sc query intelhaxm. После выполнения данной команды будет показан текущий статус службы (Рис. 3.1).

Рис. 3.1. В командной строке показан статус службы Intel HAXM

Теперь необходимо создать новое виртуальное устройство с помощью AVD Manager . В окне свойств следует добавить обязательный параметр в раздел Hardware – GPU Emulation (Рис. 3.2).

Рис. 3.2. Окно свойств при создании нового эмулятора

Осталось запустить и проверить, все ли настроено верно. Для этого нужно выбрать созданный эмулятор, запустить его и в настройках посмотреть название устройства. Если все было сделано правильно, то в поле Model number будет написано " Android SDK Build for x86 " (Рис. 3.3).

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

3.2. Intel Energy Checker SDK

Программы, особенно для мобильных устройств, могут и должны быть энергоэффективными, однако разработчики зачастую не уделяют этому показателю должного внимания. Для мобильных устройств большое значение имеет экономный расход электроэнергии, благодаря которому продлевается срок работы от аккумулятора. Поэтому пользователю предпочтительно использовать более энергоэффективные приложения. Зачастую разработчики приложений создают свои программы на настольных ПК, где показатели потребления электроэнергии намного менее существенны, чем производительность . Тем не менее, если не обращать внимания на вопросы потребления энергии, запуск программы на мобильном устройстве может обернуться для пользователя неприятной неожиданностью. Intel Energy Checker SDK измеряет количество работы, производимой системой, и соответствующее потребление энергии и позволяет тем самым определить, насколько эффективна система в части энергопотребления, и помочь в оптимизации приложения.

Уровень потребления, безусловно, является важным показателем энергоэффективности, но сам по себе он не дает полного представления о работе приложения. Малопотребляющие системы, выполняющие при этом малый объем полезной работы, могут быть менее эффективными, чем более мощные системы, способные осуществлять более значительные вычисления. Более того, даже в рамках одной системы не существует единой метрики – в зависимости от приложения ключевые показатели могут разниться. Intel Energy Checker SDK является гибким инструментом, позволяющим разработчикам проводить измерения и контроль энергоэффективности системы.

В Intel Energy Checker SDK широко используется понятие "энергоэффективность". Повсеместно принятого определения энергоэффективности не существует, но в Intel Energy Checker SDK используется следующее:

Энергоэффективность = Работа / Энергия

Под термином "работа" понимается объем полезной работы, выполненной приложением. Простого, четкого и однозначного определения термина "полезная работа" также не существует; то, что считается полезной работой в одной программе, может не считаться таковой в другом приложении. Например, количество полезной работы, проделываемое платежным приложением, отличается от количества полезной работы, выполняемой приложением-видеосервером, программой доступа к базе данных или почтовым сервером.

Intel Energy Checker SDK API предоставляет доступ к показателям проделанной приложением полезной работы с помощью простой программной оснастки. Решение остается за разработчиком. Например, можно считать работу определенных компонентов программного видеопроигрывателя, выполняющих какую-либо работу для пользователя (например, декодирование видео), полезной работой, а действия других компонентов (получающих доступ к ресурсам, ожидающих ввода, выполняющих синхронизацию) не будут считаться полезными. Intel Energy Checker SDK позволяет разработчикам определять, какие замеры "полезной работы" важны для конкретного приложения, и предоставляет доступ к ним с помощью простого API .

Intel Energy Checker SDK API предоставляет функции экспорта и импорта счетчиков в приложения. Счетчики хранят информацию о количестве событий или процессов, другие приложения могут считывать показания этих счетчиков и осуществлять действия на основе их текущих значений. Ядро Intel Energy Checker API состоит из пяти функций, которые позволяют открывать, повторно открывать, читать, записывать и закрывать счетчики.

Вторым этапом расчета энергоэффективности приложения является измерение объема энергии, израсходованной при работе программы. Для этого в Intel Energy Checker SDK применяются два средства, входящие в пакет SDK : Energy Server (ESRV) и Temperature Server (TSRV). ESRV используется для отслеживания потребления электроэнергии по данным внешних измерительных устройств, а TSRV отслеживает показатели температуры по данным термодатчиков.

В состав Intel Energy Checker SDK , помимо уже упомянутых средств, входят еще две вспомогательные программы:

PL GUI Monitor – это пользовательский интерфейс (Рис. 3.4), отображающий счетчики PL в запущенной программе, совместимой с Intel Energy Checker API.
PL CSV Logger3 – это приложение, собирающее и записывающее показатели счетчиков PL в CSV-файл для дальнейшего анализа в программах обработки электронных таблиц.

После оснастки кода программы необходимыми счетчиками разработчик может собирать информацию о том, как приложение расходует электроэнергию, и применять необходимые меры для оптимизации. Разработчики приложений для мобильных устройств могут работать над оптимизацией потребления электроэнергии в различных областях:

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

Хотя изначально Intel Energy Checker SDK создавался для работы в дата-центрах, его можно использовать на клиентских или мобильных платформах. Он может работать в операционных системах Windows , Linux, Solaris и MacOS.

Несмотря на то, что изначально Intel Energy Checker SDK был призван облегчить анализ энергоэффективности и оптимизацию приложений, его можно использовать для доступа ко всем счетчикам, необходимым разработчикам или пользователям. Например, разработчики по своему усмотрению могут использовать механизм счетчиков для наблюдения за метриками качества обслуживания или счетчиками производительности.

Что происходит при запуске сервера, порой неизвестно даже опытным системным администраторам и разработчикам. Во второй части материала тестировщик Selectel, Владимир Туров, подробно рассказывает о процессе на примере UEFI.

Первая версия того, что сейчас известно как Unified Extensive Firmware Interface (UEFI), разрабатывалась в 90-е годы прошлого тысячелетия специально под системы на Intel® Itanium® и называлась Intel Boot Initiative, а позже — EFI.

Желание «обновить» процесс загрузки было ожидаемо. PC-BIOS, именуемый ныне Legacy, предлагает работать в 16-битном real mode, адресует всего 1 МБ оперативной памяти, а загрузчик вместе с таблицей разделов должен размещаться в первых 512 байтах накопителя. Более того, PC-BIOS передает управление первому найденному загрузчику без возможности возврата назад. При этом обработку случаев с несколькими операционными системами возлагают на плечи загрузчика.

Ограничение на размер загрузчика диктует использование разметки Master Boot Record (MBR), появившийся в 1983 году. MBR не стандартизирован, однако множество производителей придерживаются «сложившихся традиций». У MBR есть серьезные ограничения: по умолчанию поддерживается только 4 раздела и объем накопителя не более 2.2 ТБ.

В декабре 2000 года была выпущена первая широко распространенная спецификация EFI под версией 1.02. Спустя пять лет Intel передали EFI в UEFI Forum, добавив Unified в название, чтобы подчеркнуть изменения. Спецификация UEFI лежит в открытом доступе и состоит из нескольких документов:

ACPI Specification;
UEFI Specification;
UEFI Shell Specification;
UEFI Platform Initialization Specification;
UEFI Platform Initialization Distribution Packaging Specification.

Самое интересное начинается в UEFI Platform Initialization Specification, где описываются все фазы загрузки платформы.

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

Последовательность фаз загрузки UEFI Источник: UEFI Platform Initialization Specification

После инициации включения платформы блок питания ждет, пока не завершатся переходные процессы, и после устанавливает сигнал на линию Power_Good. И первым начинает работу не центральный процессор, а автономная подсистема Intel® Management Engine (ME) или аналогичная ей AMD Secure Technology (ST). Эта подсистема проводит собственные операции, а затем подготавливает и запускает первое ядро одного процессора, именуемое Bootstrap Processor (BSP).

В соответствии с принятой терминологией ядро/поток процессора здесь и далее будет называться процессором: начальным (bootstrap processor) или прикладным (application processor).

Как и в Legacy, процессор начинает выполнять первую инструкцию в конце адресного пространства по адресу 0xfffffff0. Эта инструкция — прыжок на первую фазу инициализации платформы — SEC.

обработка события включения;
инициализация достаточного количества памяти для следующей фазы;
становление корня доверия системы;
передача необходимой информации и управления на следующую фазу.

Процессоры x86_64 запускаются в 16-битном реальном режиме, и в процессе первичной инициализации BSP переводится в 32-битный защищенный режим. Затем происходит обновление микрокода всех доступных процессоров.

Следом происходит обработка события включения. Под этим подразумевается агрегация информации о состояниях оборудования, чтобы на следующей фазе некоторые модули могли сделать выводы о «здоровье» и общем состоянии платформы.

Во время фазы SEC не происходит инициализация оперативной памяти. Вместо этого свободный кэш процессора помечается как несбрасываемый, и он превращается во временную оперативную память. Такой режим называется no-eviction mode (NEM). В выделенной памяти создается стек, что позволит модулям из следующих фаз использовать стековые языки программирования до инициализации основной оперативной памяти.

Далее происходит инициализация всех прикладных процессоров (Application Processor, AP) с отправкой им специальной последовательности межпроцессорных прерываний (Inter-Processor Interrupt, IPI). Последовательность Init IPI — Start-up IPI — пробуждает прикладной процессор и запускает на нем самотестирование — Built-In Self-Test (BIST). Результаты тестирования записываются и передаются далее для анализа.

В конце фазы Security необходимо найти раздел Boot Firmware Volume (BFV), на котором располагается исполняемый код следующей фазы, а также по возможности найти другие, неосновные, разделы с кодом (Firmware Volume, FV).

Чтобы оправдать название фазы Security и стать корнем доверия, во время выполнения этой фазы код, которому мы планируем передать управление, может быть проверен на отсутствие несанкционированных изменений и вредоносных частей программы.

В первой части этой статьи мы познакомились с форматом UEFI Capsule и Intel Flash Image. Осталось рассмотреть структуру и содержимое EFI Firmware Volume, но для понимания различий между модулями PEI и драйверами DXE начнем с процесса загрузки UEFI, а структуру EFI Firmware Volume отставим на вторую часть.

UEFI Platform Initialization

С высоты птичьего полета процесс загрузки UEFI выглядит так:

Вообще говоря, нас интересует не весь это процесс, а его часть — Platform Initialization (PI), которая делится на 3 фазы: SEC , PEI и DXE .
Всю документацию по PI можно свободно загрузить с сайта UEFI Forum. Фазы SEC и PEI описаны в Volume 1, фаза DXE — в Volume 2, общие архитектурные элементы, в том числе интересующие нас форматы файлов и заголовков EFI FFS — в Volume 3, субфаза SMM (стартует в середине DXE и идет параллельно) — в Volume 4, стандарты на совместимое с PI оборудование и ПО — в Volume 5. Про оборудование и ПО здесь я писать не стану, а вот остальные фазы нужно упомянуть, т.к. не зная их, сложно понять, зачем в файле BIOS'а столько всего и чем это всё отличается друг от друга.

Фаза SEC

Обработать все виды platform restart'ов: включение питания после неактивного состояния, перезагрузка из активного состояния, выход из режима глубокого сна, различного рода исключительные ситуации
Подготовить временную память
Стать Root of Trust системы: или доверять остальным частям PI, или проверить их валидность каким-либо способом
Подготовить необходимые структуры данных и передать их и управление в фазу PEI. Как минимум, передаются состояние платформы, адрес и размер BFV , адрес и размер временной RAM, адрес и размер стека

Reset Vector: сброс кэша и переход на главную процедуру иницилизации в ROM
Switch to protected mode: переключение в защищенный режим процессора с плоской памятью без подкачки
Initialize MTRRs for BSP: запись в кэш известных значений для различных областей памяти
Microcode Patch Update: обновление микрокода всех доступных процессоров
Initialize NEM : свободный кэш помечается как несбрасываемый, после чего его можно использовать как временную RAM до инициализации основной, а также позволяет написать эту самую инициализацию на обычных ЯП со стеком, в данном случае на C
Early BSP /AP interactions: отправка всем AP прерывания INIT IPI , затем Start-up IPI, получение данных BIST со всех AP
Hand-off to PEI entry point: передача управления и данных в фазу PEI

Фаза PEI

Establish use of «memory»: перенос данных из ROM в раннюю RAM (т.е. в кэш)
PEI Dispatcher: запуск модулей PEIM в порядке от не имеющих зависимостей до имеющих сложные зависимости. Это цикл, который заканчивается в момент, когда не запущенных модулей не остается
CPI PEIM: инициализация CPU, настройка MSR и т.п. (Мы вернемся к этому модулю при обсуждении патча CPU PM)
Platform PEIM: ранняя инициализация MCH , ICH , встроенных интерфейсов платформы (SMBus , Reset, и т.п.). Определение режима загрузки (обычный, Recovery, S3 Resume), используя данные, полученные в фазе SEC.
Memory Initialization PEIM: инициализация основной RAM и перенос в нее данных из кэша, которым теперь можно пользоваться нормально. процесс зависит от определенного на предыдущем шаге состояния системы, например, при S3 Resume тестирование памяти не выполняется, что сокращает время загрузки
Если система не находится в S3 Resume, то происходит передача HOB'ов и управления в фазу DXE, а фаза PEI на этом завершается
Если все же находится — выполняется CPU PEIM for S3 Boot Script, выполняющий возврат всех процессоров в их сохраненное состояние
S3 Boot Script Executor: восстановление состояния других устройств
OS Resume Vector: переход к ОС

Фаза DXE

Cубфаза SMM

Заключение

Теперь вы знаете, как происходит загрузка UEFI и какие модули необходимы для нее.
Я принял решение разделить планируемую вторую часть еще на две, чтобы уменьшить размер поста и снизить когнитивную нагрузку на читателя.
Во второй части статьи мы наконец рассмотрим структуру файла EFI FV, и сведения из этой вам там очень пригодятся.
Спасибо за внимание.

10 ноября 2020 г. корпорация Intel выпустила рекомендации по безопасности Intel-SA-00391. Эта информация была опубликована в рамках регулярного процесса обновления продукции Intel.

В рекомендациях по безопасности говорится о том, что потенциальные уязвимости безопасности в Intel® Converged Security and Manageability Engine (Intel® CSME), Intel® Server Platform Services (Intel® SPS), Intel® Trusted Execution Engine (Intel® TXE), Intel® Active Management Technology (Intel® AMT), Intel® Standard Manageability, и динамический загрузчик приложений Intel® (Intel® DAL) может привести к эскалации привилегий, отказу в обслуживании или раскрытию информации.

Корпорация Intel выпускает обновления микропрограммного обеспечения и программного обеспечения для снижения этих потенциальных уязвимостей с помощью:

Intel® CSME
Intel SPS
Intel TXE
Intel® AMT
Intel® Standard Manageability

Корпорация Intel не выпускает обновлений для снижения этих потенциальных уязвимостей, и Intel выпустила уведомление о прекращении выпуска продукции для SDK intel® DAL.

См. подробную информацию о оценках общей уязвимости и уязвимостей (CVES) и общей системе начисления баллов за уязвимость INTEL-SA-00391.

Затрагиваемая продукция

Intel® Converged Security and Management Engine (Intel® CSME), технология Intel® Active Management (Intel® AMT), Intel® Standard Manageability:

Обновленная версия	Заменяет версию	Компонент
11.8.82	с 11.0 по 11.8.80	Intel® Converged Security and Management Engine (Intel® CSME), Intel® AMT, Intel® Standard Manageability
11.11.82	с 11.10 до 11.11.80	Intel® CSME, Intel® AMT, Intel® Standard Manageability
11.22.82	с 11.20 до 11.22.80	Intel® CSME, Intel® AMT, Intel® Standard Manageability
12.0.70	с 12.0 по 12.0.69	Intel® CSME, Intel® AMT, Intel® Standard Manageability
14.0.45	с 14,0,0 до 14,0,44	Intel® CSME, Intel® AMT, Intel® Standard Manageability
14.5.25	с 14,5,0 по 14,5,24	Intel® CSME, Intel® AMT, Intel® Standard Manageability
SPS_E5_04 04.04.400	Все предыдущие SPS_E5_04 версии	Сервисы серверных платформ Intel® (Intel® SPS)
SPS_SoC-X_04 00.04.200	Все предыдущие SPS_SoC-X_04 версии	Intel® SPS
SPS_SoC-A_04 00.04.300	Все предыдущие SPS_SoC-A_04 версии	Intel® SPS
SPS_E3_04:01.04.200	Все предыдущие SPS_E3_04 версии	Intel® SPS
SPS_E3_05.04.200	Все предыдущие SPS_E3_05 версии	Intel® SPS
3.1.80	с 3.1.0 по 3.1.79	Механизм доверенного исполнения Intel® (Intel® TXE)
4.0.30	с 4,0,0 до 4,0,29	Intel® TXE

Версии микропрограммного обеспечения Intel® Manageability Engine (Intel® ME) от 3.x до 10.x более не поддерживаются. Выпуск новых версий для этих версий не планируется.

Дополнительная информация о CVE-2020-8705 системах под управлением системы Intel® Converged Security and Management Engine (Intel® CSME) версии 11.8.x. 11.12.x или 11.22.x

CVE-2020-8705 относится только к системам с технологией Intel® Boot Guard, включенной производителем системы.

Если в вашей системе включена технология Intel Boot Guard, для ее снижения потребуется intel® CSME версии 11.8.82.0, 11.12.82.0 или 11.22.82.0 (или более поздней).

Если ваша система не имеет включенной технологии Intel Boot Guard, достаточно intel CSME версии 11.8.80, 11.12.80 или 11.22.80 (или более поздней) для снижения других уязвимостей SA-00391.

Обратитесь к производителю своей системы, чтобы проверить, включена ли технология Intel Boot Guard в вашей системе.

Используйте инструмент Intel® Converged Security and Management Engine Version Detection Tool (Intel® CSMEVDT) для определения версии CSME, установленной в вашей системе.

Рекомендации

Обратитесь к производителю своей системы или системной платы для получения обновления микропрограммного обеспечения или BIOS для устранения этой уязвимости. Корпорация Intel не может предоставить обновления систем или системных систем других производителей.

Часто задамые вопросы

Нажмите или выберите тему для получения информации:

Как устранить эти уязвимости? Обратитесь к производителю своей системы или системной платы для получения обновления микропрограммного обеспечения или BIOS для устранения этих уязвимостей. Корпорация Intel не может предоставить обновления систем или системных систем других производителей. Каковы описания уязвимостей, общие уязвимости и номера CVE (Common Vulnerability Scoring System, CVSS) и общая информация об уязвимостях, связанных с Intel® AMT и ISM? Смотреть рекомендации по безопасности, Intel-SA-00391 для получения полной информации о резюме, связанных с этим объявлением. Как определить, влияет ли на меня эта уязвимость? Средство обнаружения Intel CSME Detection Tool может быть запущено на любой платформе для оценки работы платформы с последней версией микропрограммного обеспечения. Для использования инструмента У меня есть система или системная плата, изготовленные корпорацией Intel (Intel® NUC, Мини-ПК Intel®), которые демонстрируют свою уязвимость. Чем я занимаюсь? Перейти к Поддержка Intel перейдите на страницу поддержки вашего продукта. Вы сможете проверить обновления BIOS или микропрограммного обеспечения для вашей системы. Я создал свой компьютер из компонентов, поэтому не могу связаться с производителем системы. Чем я занимаюсь? Обратитесь к производителю системной платы, приобретенной для сборки вашей системы. Они несут ответственность за распространение корректного обновления BIOS или микропрограммного обеспечения для материнской платы.

Если у вас возникли дополнительные вопросы по этой проблеме, обратитесь в службу поддержки Intel.

Читайте также: