как узнать микрокод процессора
Как узнать версию микрокода процессора?
Чтобы увидеть микроархитектуру процессора и используемую версию микрокода, запустите команду reg query HKEY_LOCAL_MACHINE HARDWARE DESCRIPTION System CentralProcessor 0 в командной строке Windows. (Вы можете открыть командную строку, нажав Windows + R, набрав cmd и нажав Return.)
Как мне проверить микрокод процессора?
Как найти версию микрокода, которая в настоящее время работает на вашем процессоре. Утилита Intel® Processor Identification Utility сообщает информацию об идентификаторе CPUID для установленного процессора, расположенную на вкладке CPUID DATA инструмента. Версия микрокода указана в разделе CPUID DATA и называется «Версия процессора».
Как обновить микрокод Intel?
intel-microcode — пакет обновления микрокода Debian / Ubuntu и клонов для Intel CPUS.
…
Процедура установки микрокода AMD или Intel в Linux следующая:
Есть ли на CPU прошивка?
Прошивка — это на самом деле просто разновидность программного обеспечения, но она обычно запрограммирована во встроенной в это оборудование памяти и работает на гораздо более низком уровне. В случае ПК ваша материнская плата, ЦП, графический процессор, жесткий диск, мышь и другие устройства имеют собственную прошивку.
Обновления микрокода постоянны?
2 ответа. Само обновление микрокода всегда можно откатить, поскольку оно не является постоянным, хотя, если это обновление выполняется из прошивки (например, UEFI / BIOS), вы можете прошить модифицированную прошивку, чтобы сделать это: … Это зависит от того, как микрокод обновление применено.
Что такое обновления микрокода Intel?
Обновления микрокода Intel — это необязательные обновления, которые устраняют уязвимости и ошибки аппаратной безопасности с помощью программного исправления. Это позволяет Intel исправить или, по крайней мере, смягчить недостатки безопасности, такие как спекулятивные уязвимости выполнения или ошибки, обнаруженные после производства ЦП.
Что такое архитектура компьютера с микрокодом?
Микрокод — это метод проектирования процессора, который устанавливает уровень компьютерной организации между аппаратным обеспечением ЦП и видимой для программиста архитектурой набора команд компьютера. … Он отделяет машинные инструкции от базовой электроники, так что инструкции могут быть разработаны и изменены более свободно.
Microcode_ctl требует перезагрузки?
Обновление микрокода ЦП требует перезагрузки сервера базы данных. Обновленный пакет microcode_ctl может применяться к одному серверу базы данных за один раз в скользящем режиме.
Как обновить прошивку процессора?
Щелкните правой кнопкой мыши процессор и выберите «Обновить программное обеспечение драйвера», чтобы начать процесс обновления. Для завершения обновления вам может потребоваться перезагрузить компьютер.
Какие есть примеры прошивок?
Примеры прошивки включают:
Могу ли я удалить прошивку?
НЕТ, вы не можете его очистить. «Прошивка» и «Программное обеспечение» сравнимы с нашими телами. Прошивка — это автоматическая система, которая управляет нашим сердцем, нашей печенью, нашей ходьбой и т. Д.
Что такое обновления микрокода?
Микрокод процессора сродни прошивке процессора. Ядро может обновлять микропрограмму процессора без необходимости обновлять ее с помощью обновления BIOS. Обновление микрокода хранится в энергозависимой памяти, поэтому BIOS / UEFI или ядро обновляют микрокод при каждой загрузке.
В руке используется микрокод?
Arm Holdings, Ltd. Процессор Arm, напротив, не использует цифровой микрокод в своей оперативной памяти. Текущая реализация альтернативы Arm — это концепция, называемая пользовательскими инструкциями [PDF].
Как я могу обновить BIOS?
Нажмите Window Key + R для доступа к командному окну «RUN». Затем введите «msinfo32», чтобы открыть журнал системной информации вашего компьютера. Текущая версия BIOS будет указана в разделе «Версия / дата BIOS». Теперь вы можете загрузить последнее обновление BIOS материнской платы и утилиту обновления с веб-сайта производителя.
Обновление CPU microcode в AMI BIOS, или пример работы с MMTool
Решил вспомнить былое — модификацию БИОС.
В далёком студенческом прошлом это были подмены модуля raid на линейке мат. плат Epox под сокет A утилиткой cbrom, и кое какие манипуляции утилиткой modbin с пунктами меню.
Ныне появилось желание (плавно перетекающее в необходимость апгрейда) добавить поддержку новых CPU AMD поколения K10.5 (что под сокет AМ2+\AM3) для материнской платы BIOSTAR TA770 A2+ (с сокетом AM2+ и на Award BIOS).
Процесс поиска подходящего БИОСа с необмодимым CPU_list в линейке мат. плат Biostar под сокет AM2+ не дал качественных результатов. Т.к. лишь несколько мат. плат под сокете AM2+ (и лишь на чипсетах NForce) оказались снабжены Award БИОСом. А большинство таких мат.плат Biostar снабжены AMI БИОСом. Как раз последняя условность и позволила мне найти пример для «поиграться» с AMI БИОСами данных мат. плат и поделиться скромным опытом в данной статье прежде, чем разбираться с Award БИОСами (о чем я расскажу уже в отдельной статье).
Представляю донора BioStar A740G M2L+ (AMD 740G / SB710) и реципиента BioStar A740G M2+ (AMD 740G / SB700). Мат.плата, что с литерой «L», более свежая и поддерживает процессоры AM3 официально, в отличие от другой, что ограничена лишь поддержкой процессоров AM2+. Напрашиваются на сравнительный анализ БИОСы их.
С оф. сайта загружаем лишь последнее обновление прошивки БИОСа для каждой их этих мат.плат:
— для A740G M2+ последняя бэта A74GM916.BSS за сентябрь 2009г.
— для A740G M2L+ — файл 74GCU511.BSS — за май 2010г.
Далее вооружаемся утилитой MMTOOL(я использовал версии 3.22, 3.23 и 3.26 — различий в работе не обнаружил). Для работы с MMTOOL расширения файлов прошивок БИОС необходимо переименовывать на *.rom.
Теперь запускаем две MMTOOL и в них подгружаем файлы прошивок от двух мат. плат. Обращаем внимание на разные размеры в столбце «Source size» ( да и в «Size in Rom» тоже разумеется) модуля 11 «P6 Micro Code» в каждой из прошивок.
Переходим в раздел CPU PATCH для детального сравнения:
— файл донора 74GCU511.rom — cpu_list содержит 14 строк с поддержкой CPURev.ID + 1 пустая (рис.1).
— бэта-версия реципиента A74GM916.rom — cpu_list содержит 13 строк с поддержкой CPURev.ID + 1 пустая (рис.2).
После анализа списков этих двух БИОСов становится очевидно, что для более новой мат.платы разработчики использовали более свежие патчи для процессоров AMD, где подправлен микрокод двух строк с CPURev.ID 1043 и 1062 (датируются 2009/07/31) и одна строка с CPURev.ID 10A0 добавлена (датируется 2010/02/17).
Способ №1 — модификация отличительных строк.
Производится извлечение этих трёх отличительных строк из донора 74GCU511.rom — действия «Extract a Patch Data» + «Apply» + 1 последнюю пустую строку и сохранение их в отдельные файлы.
Предварительно в в разделе CPU PATCH файла реципиента A74GM916.rom удаляются две строк с номерами CPURev.ID 1043 и 1062 (чей микрокод более старый чем мы будем далее вставлять) и последняя пустая строка — действия «Delete a Patch Data» + «Apply» (рис.3).
После этого поочерёдно вставляется более новый микрокод из четырёх уже ранее полученных файликов-патчей для CPURev.ID 1043, 1062, 10A0 и пустая строка (рис.4).
Обращаем внимание на размеры («Source size» и «Size in Rom») модуля 11 «P6 Micro Code» до и после применения данных изменений в файле реципиента.
После применения эти размеры у реципиента (рис.6) станут идентичны размерам такого же модуля в файле-доноре 74GCU511.rom (рис.5).
Стоит заметить, что несложно понять, как формируется размер модуля (каждая строка, что в разделе CPU PATCH, занимает по 2048 байт).
Сохранять изменения лучше под новым именем файла.
Далее этот файл проверяется, чтобы по новой без ошибок открывался MMTOOL.
Способ №2 — модификация заменой модуля целиком.
Собственно именно он и описан на просторах интернета (например частично здесь).
В MMTOOL подкружаем файл донора 74GCU511.rom, переходим во вкладку «Extract» и ищем строку «P6 Micro Code». Затем выделяем её, в поле «module file» задаем ему имя ncpucode.bin и выполняем Extract module «in uncompressed form».
Теперь в MMTOOL подгружаем файл реципиента A74GM916.rom, переходим во вкладку «Replace» и снова ищем строку «P6 Micro Code». Выделяем её, ждём Browse и выбираем наш донорский модуль ncpucode.bin. Жмём Replase и далее соглашаемся на замену данного модуля.
Снова обращаем внимание на размеры («Source size» и «Size in Rom») модуля 11 «P6 Micro Code» до и после замены данного модуля в файле реципиента.
После применения эти размеры у реципиента (рис.7) станут идентичны размерам такого же модуля в файле-доноре 74GCU511.rom (рис.5).
Если сравнить результаты обоих способов (рис.6 и рис.7), то заметна разница в 10байт в адресе RomLoc модуля «User Defined or Reserved», следующего за обновляемым модулем «P6 Micro Code» — возможно, это особенности работы MMTOOL.
Как проверить выпустили ли Intel обновления микрокода для вашего процессора
Gibson Research обновили программу InSpectre, о которой я уже рассказывал. Они улучшили функциональность приложения, и в том числе добавили проверку доступности обновления микрокода для вашего процессора. Напомню, что InSpectre проверяет, были ли установлены исправления уязвимостей Meltdown и Spectre на вашем компьютере под управлением Windows и даёт оценку производительности, если патчи не установлены.
Напомню, как просто проверить уязвимость компьютера к Meltdown и Spectre:
1. Скачайте программу InSpectre.
2. Запустите её с правами администратора системы.
3. Программа покажет, есть ли в системе уязвимости, как они влияют на производительность и выпущено ли обновления микрокода.
Читайте анонсы и посты целиком в ЖЖ, Medium, Голосе и Яндекс.Дзен!
Поддержите мой блог финансово. Все донаты пойдут на оплату хостинга и развитие сайта!
партнёры блога
telegram
Реклама
Последние
Рубрики
[…] Проверить, как система защищена от уязвимости Spectre, можно с помощью специальной утилиты InSpectre. […]
СЧЕТЧИКИ
РЕКЛАМА И ДОНАТЫ
Социальные сети
©2016-2021 Блог Евгения Левашова. Самое интересное и полезное из мира ИТ. Windows 10, Linux, Android и iOS. Обзоры программ и веб-сервисов. Статьи о мотивации и продуктивности.
Использование материалов разрешается с активной ссылкой на levashove.ru. 
Данный блог является личным дневником, содержащим частные мнения автора. В соответствии со статьей 29 Конституции РФ, каждый человек может иметь собственную точку зрения относительно его текстового, графического, аудио и видео наполнения, равно как и высказывать ее в любом формате. Блог не имеет лицензии Министерства культуры и массовых коммуникаций РФ и не является СМИ, а, следовательно, автор не гарантирует предоставления достоверной, не предвзятой и осмысленной информации. Сведения, содержащиеся в этом блоге не имеют никакого юридического смысла и не могут быть использованы в процессе судебного разбирательства. Автор блога не несёт ответственности за содержание комментариев к его записям.
Вначале немного истории, теории и зачем вообще это нужно.
Являясь владельцем двух ноутбуков ASUS U6V (рабочий) и Acer 6935G (домашний) периодически сталкиваюсь с проблемой повышенного нагрева ASUS, из турбины выдувается воздух по температуре как из фена, даже в ненагруженном режиме. Это обусловлено конструкцией данного ноутбука ввиду его малых габаритов и достаточно «горячего» процессора P8600. Имея некоторый опыт по оптимизации производительности и тепловыделения для микросерверов основанных на процессорах Xeon серии L, решил посмотреть какая версия микрокодов для моего процессора загружается в ноутбуке. На ноутбуке стоит предпоследний BIOS версии 213, последний 214 версии не поддерживает WakeOnLan, а он мне важен для работы. Версия микрокодов для моего процессора датирована 2008 годом, поискав обновления нашел последнюю версию от 2010 года, очевидно в это время закончилась поддержка Интелом данного процессора. Путем несложных манипуляций по замене микрокода в BIOS и перепрошивке, я получил ноутбук с процессором на последней версии микрокодов. На какое-то время я забыл об этом и обнаружил что мой ноутбук стал меньше греться, турбина в обычном ненагруженном режиме не поднимается выше 4200 оборотов и из неё дует теплый воздух, а не горячий как ранее.
Итак немного теории. Микрокоды были внедрены в процессоры для возможности программного исправления ошибок преобразования и выполнения команд x86 системы в RISC uops. Воизбежание отзыва процессоров с обнаруженной проблемой прозводители стали применять загружаемые микрокоды. При каждой загрузке вашего ноутбука или ПК, BIOS материской платы по определенному протоколу пересылает в процессор обновленные микрокоды. По мере обнаружения ошибок производители обновляют и оптимизируют версии микрокодов. Это одна из причин почему вам настоятельно рекомендуют прошивать последнюю версию BIOS, которая в теории должна содержать последние микрокоды. Но на практике это не всегда так. Обновления микрокодов выпущены производителем процессоров, а производители, в данном случае, ноутбуков не спешат с обновлениям BIOS.
Перейдем окончательно к вопросу зачем это нам нужно:
— исправим ошибки, обнаруженные производителем процессоров;
— улучшим тепловой режим в моем случае (я не могу гарантировать что на ваших ноутбуках будет также, но могу предположить что будет аналогично).
Если у вас нет уверенности, что вам это нужно, далее можете не читать.
Итак, какого же было мое очередное разочарование в разработчиках 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;
7) Грузимся с флешки и запускаем Flashit /FM
Наблюдаем процесс обновления в BIOS области микрокодов, который завершается перезагрузкой системы.
Загружаемся в Windows, запускаем AIDA и проверяем номер обновленных микрокодов для нашего процессора.
Бэкдоры в микрокоде ассемблерных инструкций процессоров x86
Софту мы не доверяем уже давно, и поэтому осуществляем его аудит, проводим обратную инженерию, прогоняем в пошаговом режиме, запускаем в песочнице. Что же насчёт процессора, на котором выполняется наш софт? – Мы слепо и беззаветно доверяем этому маленькому кусочку кремния. Однако современное железо имеет те же самые проблемы, что и софт: секретную недокументированную функциональность, ошибки, уязвимости, малварь, трояны, руткиты, бэкдоры.
ISA (Instruction Set Architecture) x86 – одна из самых долгих непрерывно изменяющихся «архитектур набора команд» в истории. Начиная с дизайна 8086, разработанного в 1976 году, ISA претерпевает постоянные изменения и обновления; сохраняя при этом обратную совместимость и поддержку исходной спецификации. За 40 лет своего взросления, архитектура ISA обросла и продолжает обрастать множеством новых режимов и наборов инструкций, каждый из которых добавляет к предшествующему дизайну, и без того перегруженному, новый слой. Из-за политики полной обратной совместимости, в современных процессорах x86 присутствуют даже те инструкции и режимы, которые на сегодняшний день уже преданы полному забвению. В результате мы имеем архитектуру процессора, которая представляет собой сложно переплетающийся лабиринт новых и антикварных технологий. Такая чрезвычайно сложная среда – порождает множество проблем с кибербезопасностью процессора. Поэтому процессоры x86 не могут претендовать на роль доверенного корня критической киберинфраструктуры.
Вы всё ещё доверяете своему процессору?
Безопасность программ и операционной системы – зиждется на безопасности железа, на котором они развёрнуты. Как правило разработчики софта не учитывают того факта, что железо, на котором разворачивается их софт – может быть недоверенным, вредоносным. Когда железо ведёт себя ошибочно (независимо оттого, преднамеренно или нет), программные механизмы безопасности – полностью обесцениваются. Уже много лет предлагаются различные модели защищённых процессоров: Intel SGX, AMD Pacifica и др. Тем не менее, завидная регулярность, с которой публикуется информация о критических сбоях (из недавних, например Meltdown и Spectre) и обнаруженных недокументированных «отладочных» функциях – наводит на мысль, что наше беззаветное доверие к процессорам беспочвенно.
Современные процессоры x86 представляют собой очень громоздкое и запутанное переплетение новейших и антикварных технологий. У 8086 было 29 тыс. транзисторов, у Pentium – 3 млн., у Broadwell – 3,2 млрд, у Cannonlake – больше 10 млрд.
При таком количестве транзисторов неудивительно, что современные процессоры x86 испещрены недокументированными инструкциями и аппаратными уязвимостями. Среди недокументированных, – обнаруженных почти случайно, – инструкций: ICEBP (0xF1), LOADALL (0x0F07), apicall (0x0FFFF0) [1], которые позволяют разблокировать процессор для несанкционированного доступа к защищённым областям памяти.
Что же касается многочисленных аппаратных уязвимостей процессоров (см. два рисунка ниже), то они позволяют киберзлоумышленнику осуществлять эскалацию привилегий [3], извлекать криптографические ключи [4], создавать новые ассемблерные инструкции [2], менять функциональность уже существующих ассемблерных инструкций [2], устанавливать хуки на ассемблерные инструкции [2], брать под контроль «аппаратно ускоренную виртуализацию» [7], вмешиваться в «атомарные криптографические вычисления» [7] и, – сладкое напоследок, – входить в «режим бога»: подчинять себе легальный аппаратный бэкдор Intel ME (который позволяет получать удалённый доступ даже к выключенному компьютеру) [8]. И всё это – не оставляя каких-либо цифровых следов.
Современные процессоры – это больше софт, чем железо
Строго говоря, современные процессоры даже нельзя назвать «железом» в полном смысле этого слова. Потому что наиболее критичная их функциональность (в том числе, ISA) – обеспечивается перепрошиваемым микрокодом. Изначально микрокод отвечал в основном за то, чтобы управлять декодированием и выполнением сложных ассемблерных инструкций: операции с плавающей точкой, MMX-примитивы, обработчики строк с префиксом REP и т.п. Однако с течением времени на микрокод возлагается всё больше и больше ответственности за обработку операций внутри процессора. Так например, современные расширения процессоров Intel, такие как AVX (Advanced Vector Extensions) и VT-d (аппаратная виртуализация) – реализованы на микрокоде.
Кроме того, сегодня микрокод отвечает, в числе прочего, за сохранение состояния процессора, за управление кэшем и также за управление энергосбережением. Для энергосбережения, на микрокоде реализован механизм прерываний, обрабатывающий состояния электропитания: С-состояния (степень энергосберегающего сна: от активного состояния до глубокого сна) и P-состояния (разные комбинации вольтажа и частоты). Так например, за обнуление L2-кэша при входе в состояние C4, а также при выходе из него – отвечает именно микрокод.
Зачем производители процессоров пользуются микрокодом?
Производители процессоров x86 используют микрокод для разложения сложных ассемблерных инструкций (длина которых может достигать 15 байт) в цепочку простых микроинструкций, – в целях упрощения аппаратной архитектуры и облегчения диагностики. По сути, микрокод это интерпретатор между внешней (видимой для пользователя) CISC-архитектурой и внутренней (аппаратной) RISC-архитектурой.
При обнаружении ошибок в CISC-архитектуре (в ISA, прежде всего), производители публикуют обновление микрокода, которое можно закачать в процессор через BIOS/UEFI материнской платы или через операционную систему (во время процесса загрузки). Благодаря такой системе обновлений, основанной на микрокодах, производители процессоров обеспечивают себе гибкость и снижение затрат – при исправлении ошибок в своём оборудовании. Нашумевшая ошибка с fdiv, которая сильно подкосила процессоры Intel Pentium в 1994 году – сделала ещё более очевидным тот факт, что высокотехнологичное железо подвержено ошибкам точно также, как и софт. Данный инцидент породил у производителей ещё больше интереса к архитектуре процессоров на основе микрокода. Поэтому Intel и AMD стали строить свои процессоры с применением технологии микрокодов. Intel – начиная с Pentium Pro (P6), выпущенного в 1995 году. AMD – начиная с K7, выпущенного в 1999 году.
Всё тайное становится явным
Несмотря на то, что производители процессоров стараются держать архитектуру микрокодов и механизм их обновления в строжайшем секрете, – враг не дремлет. Крупицы разрозненной информации (в основном из патентов, вроде AMD RISC86 [5]) и вдумчивый реверсинг официальных обновлений для BIOS (как это было с K8 [6]), – постепенно проливают свет на тайну микрокода (см. например, на рисунке ниже «механизм обновления микрокода процессоров AMD»). А благодаря постоянной эволюции инструментария для реверсинга (как программного, так и аппаратного) [2], перспективным методикам фаззинга [1] и появлению таких OpenSource-инструментов как Microparse [9] и Sandsifter [10] – киберзлоумышленник может узнать о микрокоде всё необходимое для того, чтобы писать на нём микрокодовую малварь.
Так например, в [2] на правах «Hello world!» (первый шаг к троянизации микрокода) разработан «микрохук» (микрокодовая программа, перехватывающая ассемблерную инструкцию), который подсчитывает, сколько раз процессор обращался к команде div. Этот микрохук представляет собой инъекцию в обработчик ассемблерной инструкции div.
Там же [2] представлен более продвинутый микрохук, – который спокойно себе сидит в ассемблерной инструкции div ebx, ничем не выдавая своего присутствия, и активируется только когда при обращении к div ebx выполняются конкретные условия: в регистре ebx содержится значение B, а в регистре eax содержится значение A. Активируясь, этот микрохук увеличивает значение регистра eip (указатель текущей инструкции) на единицу. В результате выполнение программы (которая имела смелость обратиться к инструкции div ebx) продолжается со смещением: ни с первого байта следующей за div ebx команды, а с её второго байта. Если же в регистрах eax и ebx заданы другие значения, то div ebx работает в обычном режиме. Какая в этом практическая ценность? Например, чтобы незаметно активировать скрытую цепочку ассемблерных инструкций, при использовании обфускационной техники с «перекрываемыми инструкциями» [11].
Эти два примера демонстрируют, как законные ассемблерные инструкции можно использовать для сокрытия в них произвольного троянского кода.
При этом, киберзлоумышленник может активировать свою вредоносную полезную нагрузку – в том числе и удалённо. Например, когда необходимое для активации условие выполняется на веб-странице, контролируемой злоумышленником. Это возможно благодаря компиляторам Just-in-Time (JIT) и Ahead-of-Time (AOT), встроенным в современные веб-браузеры. Эти компиляторы позволяют испускать предопределённый поток ассемблерных инструкций машинного кода – даже если вы пишете программу исключительно на высокоуровневом JavaScript (см. последний листинг – чуть выше).