Как узнать микрокод процессора
Обновлено: 06.07.2024
Вначале немного истории, теории и зачем вообще это нужно.
Являясь владельцем двух ноутбуков ASUS U6V (рабочий) и Acer 6935G (домашний) периодически сталкиваюсь с проблемой повышенного нагрева ASUS, из турбины выдувается воздух по температуре как из фена, даже в ненагруженном режиме. Это обусловлено конструкцией данного ноутбука ввиду его малых габаритов и достаточно "горячего" процессора P8600. Имея некоторый опыт по оптимизации производительности и тепловыделения для микросерверов основанных на процессорах Xeon серии L, решил посмотреть какая версия микрокодов для моего процессора загружается в ноутбуке. На ноутбуке стоит предпоследний BIOS версии 213, последний 214 версии не поддерживает WakeOnLan, а он мне важен для работы. Версия микрокодов для моего процессора датирована 2008 годом, поискав обновления нашел последнюю версию от 2010 года, очевидно в это время закончилась поддержка Интелом данного процессора. Путем несложных манипуляций по замене микрокода в BIOS и перепрошивке, я получил ноутбук с процессором на последней версии микрокодов. На какое-то время я забыл об этом и обнаружил что мой ноутбук стал меньше греться, турбина в обычном ненагруженном режиме не поднимается выше 4200 оборотов и из неё дует теплый воздух, а не горячий как ранее.
Итак немного теории. Микрокоды были внедрены в процессоры для возможности программного исправления ошибок преобразования и выполнения команд x86 системы в RISC uops. Воизбежание отзыва процессоров с обнаруженной проблемой прозводители стали применять загружаемые микрокоды. При каждой загрузке вашего ноутбука или ПК, BIOS материской платы по определенному протоколу пересылает в процессор обновленные микрокоды. По мере обнаружения ошибок производители обновляют и оптимизируют версии микрокодов. Это одна из причин почему вам настоятельно рекомендуют прошивать последнюю версию BIOS, которая в теории должна содержать последние микрокоды. Но на практике это не всегда так. Обновления микрокодов выпущены производителем процессоров, а производители, в данном случае, ноутбуков не спешат с обновлениям BIOS.
Я не могу напрямую доказать влияние микрокодов на тепловой режим работы процессора, но факты на лицо. Мои размышления остановились на том, что микрокоды кроме основного своего назначения - исправлять ERRATA ошибок команд, влияют на EIST (Enhanced Intel Speed Step Technology) и позволяют более оптимально переводить процессор в состояния пониженного энергопотребления, что влечет за собой облегчение теплового режима.
Перейдем окончательно к вопросу зачем это нам нужно:
- исправим ошибки, обнаруженные производителем процессоров;
- улучшим тепловой режим в моем случае (я не могу гарантировать что на ваших ноутбуках будет также, но могу предположить что будет аналогично).
Если у вас нет уверенности, что вам это нужно, далее можете не читать.
Итак, какого же было мое очередное разочарование в разработчиках ACER, точнее компании-подрядчике производящей для Acer ноутбуки. Ранее я уже писал про невозможность включения VT (Virtual Technology) посредством BIOS в нотбуке Acer 6935G. Теперь насколько просто замена микрокодов реализована в AMI BIOS с помощью утилиты MMTOOL. И насколько непрозрачен механизм обновления микрокодов на Insyde H2O BIOS. Хотя утилита обновления FlashIt и имеет специальный ключ /FM для обновления микрокодов. Отдельно обновлять биос файлами микрокодов она отказалась, только из файла образа биоса для вашей модели. И тут производитель о нас покупателях не позаботился. Прийдется самим исправлять эту ситуацию.
Нам понадобится:
- AIDA (она же Everest в прошлом), для примера взял версию 4.5 Portable Edition;
- обновления микрокодов для процессоров Intel с сайта Intel, последнее датировано 30 апреля 2014;
- любой Hex редактор, для примера взял WinHex 16.9;
- BIOS для вашей модели с сайта Acer, для меня версия 1.20 модель 6935G;
1) Запускаем AIDA и в секции CPUID смотрим какой у нас процессор и версия микрокодов загружена в него.
в моем варианте это CPUID 10676 (Core 2 Duo Penryn) степпинг С0, версия микрокодов 60С;
2) Берем обновления микрокодов для процессоров Intel, для вашего удобства я их уже распаковал из DAT файла.
Сверяем по версии CPUID и платформы находим соответствующий файл микрокодов. Находим файл содержащий микрокоды версии 60F, которые новее имеющихся у меня в BIOS версии 1.20; Внимание . Обязательно берите обновления только для вашего CPUID и идентификатора платформы .
3) Открываем файл нашего BIOS в WinHex. Поскольку BIOS грузит микрокоды непосредственно из памяти в процессор они всегда находятся в файле биоса в несжатом виде. Ищем HEX строку (Ctrl+Alt+X) согласно номера CPUID нашего процессора, младшим байтом вперед для 10676 это будет 760601;
У меня совпадение находит в строке по адресу 00187000. Убеждаемся что это не случайное совпадение. По смещению 4 должна быть версия наших текущих микрокодов 060С (байты в обратном порядке), а по смещению 18 идентификатор нашей платформы 80. Значит мы нашли правильное место.
4) Открываем в WinHex выбранный нами файл микрокодов. Выделяем блок содержащий весь файл микрокодов (Ctrl+A).
5) Копируем блок (Ctrl+C) и переходим на вкладку с нашим биосом.
6) Ставим курсор в позицию 00187000.
Выполняем запись блока как на картинке (Ctrl+B).
Должны получить следующее предупреждение о записи блока:
Нажимаем Ok и получаем следующий вид:
Сохраняем получившийся BIOS в новый файл для примера 140613_UPD.FD.
Записываем его на флешку с которой собираемся обновлять наш BIOS вместе с утилитой FlashIt.
7) Грузимся с флешки и запускаем Flashit <имя_нашего_сохраненного_файла> /FM
Наблюдаем процесс обновления в BIOS области микрокодов, который завершается перезагрузкой системы.
Загружаемся в Windows, запускаем AIDA и проверяем номер обновленных микрокодов для нашего процессора.
Распространено мнение, что эта технология присутствует только в некоторых современных чипсетах Intel, и для ухода от проблем безопасности достаточно выбирать чипсеты без поддержки АМТ. На данном этапе это уже не верно, последний чипсет 7 серии во всех модификациях поддерживает данную технологию.
И еще, к сожалению, проблема безопасности АМТ у нас абсолютно не обсуждается в силу безграмотности специалистов ИБ, но на западе полно публикаций на эту тему, с очень жесткими выводами. Наберите в поисковике: «Intel AMT backdoor» и убедитесь сами.
Командные подставы
Начну эту часть издалека. Был (дай бог пускай и сейчас здравствует) такой известный в компьютерных кругах человек Крис Касперски (Николай Лихачёв). Не путать, пожалуйста, с другим Касперским, хоть сферы деятельности этих людей раньше тесно пересекалась, совпадение фамилии одного и псевдонима другого чистая случайность. Крис Касперский был известным специалистом в области «белого» взлома, у него много публикаций на эту тему. Последняя публикация датируется серединой 2008 года и касается обнаруженных им уязвимостей в процессорах фирмы Интел.
Собственно как таковой публикации не было кроме безобидной презентации, ее можно посмотреть по ссылке здесь:
Доклад состоялся, но обнаруженная уязвимость и демонстрация ее эксплуатации так и не были представлены…, вместо этого докладчик оказался в Америке на ПМЖ уже осенью того же 2008года.
Что там конкретно нарыл Касперский так и не известно, но общее представление о реальных разборках в этой кремневой сфере можно получить из еще двух событий уже не такого далекого прошлого.
Между давними соперниками процессоростроения произошел крупный конфликт, приведший к «сливу» конфиденциальной информации о бекдорах в процессорах.
Но вскоре «империя» AMD нанесла ответный удар.
Кстати, фирма Intel назвала это недокументированную возможность обтекаемой фразой «специфическая реализация» и не признала эту «особенность» бекдором или ошибкой реализации. Фирма так и поставляет процессора с этой, как она выражается; «специфической реализацией команды SYSRET».
Поэтому всем крупным разработчикам коммерческого софта пришлось пропатчить собственные продукты для обхода этой «специфической особенности выполнения команды». Но эту уязвимость команды SysRet можно эксплуатировать с уровня драйверов и приложений, и их может писать кто не попадя. Так что уязвимость, позволяющая повышать уровень привилегий, присутствует в процессорах Intel до настоящего момента.
Приведенной выше информации думаю достаточно для обоснования утверждения о тайных противостояниях производителей процессоров и аппаратных закладках в их продукции. В силу периферийности нашей страны и убогости профессиональных познаний «генералов» ИБ в этой сфере контролировать и участвовать в этих процессах в настоящий момент мы не в состоянии, хотя могли бы легкостью, будь на то хотя бы малейшее желание.
Как ни странно, у нас, « как в Греции,- все есть…» необходимый научный задел в автоматизированной верификации системы команд в стране имеется. Несомненным лидером в этой области является Институт Системного Программирования Российской Академии Наук (ИСП РАН). К сожалению, наработки в области автоматизированной верификации процессорных структур этого института вместо нашего собственного государства использует Корея, фирма Самсунг в частности.
Вот и получается, что имеем не ценим, а окончательно потеряв, даже не заплачем…
Но у этой темы есть и другая, хоть и легальная, но абсолютно непрозрачная сторона. Речь идет об механизмах обновления микрокода.
Страсти по микрокоду
Немного теории, чтобы ввести в курс дела. Процессора архитектуры х86 имеют смешанное программно-аппаратное управление. Любая команда для процессора х86 это набор микроопераций, простые команды это одна микрооперация, а сложные команды могут состоять из сотен, а для некоторых современных команд из тысяч микроопераций.
Простые команды (типа арифметических, логических) процессор выполняет на комбинаторной логике за одну микрооперацию, фактически это аппаратное выполнение команды.
Более сложные команды состоят из цепочек микроопераций с условными переходами, циклами, прерываниями. Так вот, эти цепочки микроопераций и являются микропрограммами выполнения команд процессора. Это конечно очень поверхностное и упрощенное объяснение механизма выполнения команд на современных процессорах х86, но думаю, суть понятна.
Все микропрограммы выполнения команд хранятся в самом процессоре, в специальной энергонезависимой памяти, и заливаются туда на этапе его изготовления. Но, как известно, у любого программиста на тысячу строк кода всегда найдется хотя бы одна ошибка, так что ошибки в микропрограммах бывают, и для оперативного их исправления используется механизм патчей.
У Intel все написано в документации (Vol. 3A глава 9.11 MICROCODE UPDATE FACILITIES). Механизм обновления микрокода для процессоров AMD можно обнаружить на официальном сайте, в документации он не описан. Алгоритмы обновления микрокода у обоих производителей практически одинаковы, различия только в структуре патча. Так что разберем тему на основе официальной документации Intel, вот выдержка:
9.11 MICROCODE UPDATE FACILITIES
The Pentium 4, Intel Xeon, and P6 family processors have the capability to correct errata by loading an Intel-supplied data block into the processor. The data block is called a microcode update. This section describes the mechanisms the BIOS needs to provide in order to use this feature during system initialization. It also describes a specification that permits the incorporation of future updates into a system BIOS.
Intel considers the release of a microcode update for a silicon revision to be the equivalent of a processor stepping and completes a full-stepping level validation for releases of microcode updates.
A microcode update is used to correct errata in the processor. The BIOS, which has an update loader, is responsible for loading the update on processors during system initialization (Figure 9-7). There are two steps to this process: the first is to incorporate the necessary update data blocks into the BIOS; the second is to load update data blocks into the processor.
Механизм обновления микрокода прост, каждый раз после подачи питания или после выдачи сигнала сброса (Reset) необходимо загрузить патч во все процессорные ядра. Другими словами, текущие патчи не сохраняются в энергонезависимой памяти и их нужно каждый раз перезаписывать.
Структура патча состоит из трех частей, первая часть «Header» и последняя «extended signature» описана в документации полностью, но они не несут существенного значения.
Самая главная часть («Date» - размер не фиксирован), - тело патча, не описана в документации, структура его не известна. Именно эта часть содержит микропрограммы, которые замещают прошитые на этапе производства микропрограммы процессора. Фирмы Intel и AMD не предоставляют никакой информации для того чтобы узнать хотя бы какие команды и режимы работы процессора подвергаются изменению.
Предполагается (так сказано в документации), что процедура обновления микрокода производится из БИОС, но нет никаких ограничений на ее проведение и во время последующей работы процессора. Другими словами, патчить микропрограмму процессора можно до бесконечности и во время работы операционной системы. Блокировок режима обновления микрокода в аппаратуре процессора не предусмотрено, проверки подлинности патча также нет. А вот это уже некорректно, и попахивает бекдором, скрытым под недокументированными возможностями
Производители процессоров регулярно распространяют официальные обновления микрокода, но списка исправленных ошибок, либо добавленных оптимизаций нет. Есть только номер патча, его можно контролировать после заливки в процессор.
Идиотизм ситуации в том, что эти обновления должны попасть в процессор во время загрузки ОС, и, к примеру, Microsoft не сообщает официальной информации про номер патча который она грузит.
Вот пример такого файла обновления микрокода операционной системы Windows.
Другими словами, нет возможности контролировать текущую прошивку микрокода даже на уровне его номера. Также невозможно блокировать функцию обновления микрокода аппаратно, она всегда доступна из нулевого кольца привилегий.
Еще одной проблемой становится БИОС материнских плат, там всегда имеется патч микрокода для процессора, но кто гарантирует, что он корректен? Недобросовестное искажение его содержимого возможно и на этапе его создания в Интел и на этапе заливки в БИОС при производстве материнской платы.
Кроме этого патч может обновляться во время обновления БИОС материнской платы уже в процессе эксплуатации оборудования да и просто заменить его в БИОСе не проблема. Хоть какую то гарантию давала бы цифровая подпись на патче, но ее наличие не предусмотрено в структуре блока обновления микропрограммы, производители БИОС никакой внешней защиты на эти патчи также не накладывают.
Вот мы и подошли к теме современных БИОС, но об этом в следующей части этого печального цикла статей.
Читайте также: