No Image

Что такое микрокод процессора

0 просмотров
11 марта 2020

Assembler
Язык Ассемблера
Статьи
Низкоуровневое программирование для дZенствующих
Уроки
Крэкинг
DirectX/OpenGL
&nbsp Оптимизация
&nbsp Компиляторы
&nbsp Вирусология
&nbsp Сеть
&nbsp Процессоры
&nbsp Исследование программ
Инструментарий Исходники

Эта статья предназначается только для образовательных целях. Использование микрокода подпадает под копирайт Интела, и его незаконные модификации не приветствуются. Я не модифицировал микрокод и никоим образом не нарушал копирайт.

Несмотря на то, что моей специализацей является вордрайвинг (поиск незащищенных беспроводных сетей), моя первая статья будет посвящена использованию микрокода в процессорах Интел (обновление интеловского микрокода). И вы, мои дорогие друзья, наверное спросите, что это даст вам в плане компьютерной безопасности и как с помощью этого взломать аккаунт вашей подруги на hotmail.com.

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

Для чего? С какой целью? В большинстве случаев для обычной диверсии. если только Интел не скрывает от нас что-нибудь. Тогда могут появиться и другие мотивы. Если Интел хочет что-то скрыть. то что? Может возникнуть возражение, что парни из Интела просто беспокоились или сделали это для собственного развлечения, чтобы занять нейроны, однако сомнительно, что это так. Должна существовать действительно веская причина. Как вы можете видеть, это типичная провокаторская статья, подобные которой с определенной периодичностью публикуются в SET (испанский хакерский журнал, в котором была опубликована оригинальная статья).

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

1.1 Что такое микрокод?

Микрокод используется для реализации некоторых инструкций процессора. Я объясню. Архитектуры компьютеров делятся на две большие категории: RISC и CISC.

Архитектура RISC предусматривает простые инструкции, в то время как CISC – более сложные. В CISC’е компьютеру говорят: "Взломай аккаунт моей бабушки и тети". В RISC’е: "Взломай. Счет. Моей бабушки. Взлома. Счет. Моей тети.".

RISC’овыми являются такие архитектуры как ARM и Sparc. x86 (PC у вас на столе) – CISC’овая архитектура. Что лучше. ладно, это другая история. В x86 есть "большие инструкции", которые разлагаются на более мелкие, выполняемые затем процессором. Конкретные реализации микрокода могут менять то, на какие инструкции разлагаются "большие инструкции". Таким образом Интел сделал возможным появление багов, которые согласно интеловской номенклатуре называются "Errata". Багов много. Просто сделайте поиск по словам "processor Specification Update" на странице Интела.

Классический пример подобного бага – ошибка плавающей запятой в первом Пентиуме, которая была результатом некорректного микрокода.

Понятие микрокода и все, что с ним связано объясняется в главе 8, секции 11 "IA-32 Intel Architecture Software developers manual Volume 3: Systems programming guide", который можно скачать со страницы Intel. Микрокод – это 2048 байтов данных, 48 из которых являются заголовочными. Остальные 2000 – это и есть собственно микрокод. Он зашифрован. Если вы измените микрокод и попробуете его залить в процессор, это не получится, так же как и в том случае, если заливаемый микрокод предназначается для другого процессора.

2. Каким образом можно залить новый микрокод в мой процессор?

Обычно этим занимается BIOS. Также есть одна утилита, которая может установить микрокод из-под Windows, используя специальные файлы, предоставляемые Интелом.

Но мне, например, Windows не нравится. Мне нравится Линукс, и под ним мы можем использовать микрокод легко и просто. Как? Если есть ядро 2.4.X, то при его установки можно выбрать опцию использования микрокода. Я думаю, что в RedHat этот выбок недостаточен. В вашем дистрибутиве Линукса выполните команду

и выберите все, что видите в /dev/cpu.

Вы можете скачать ASCII-файл со всеми микрокодами с http://www.urbanmyth.org/microcode/.

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

3 – Как работает драйвер

Это очень просто.

Регистры MSP (Model Specific registers) предназначаются для внутреннего использования процессором при выполнении различных функций. Эти регистры практически недокументированны, хотя есть некоторые документы, дающие определенную информацию по этому поводу, которую я не буду излагаться здесь. Эти документы можно найти в Сети (google: MSR and appendix H). Возможно, в конце концов Интел будет вынужден документировать эти регистры.

Запись и чтение из регистров MSR производится с помощью инструкций RDMSR и WRMSR. Полный список MSR-регистров можно найти здесь:

Мы записываем в MSR под номером 79h, так как хотим модифицировать микрокод.

Затем используем другой регистр (8bh) и вызываем CPUID. Это инструкция поможет нам узнать различную информацию информацию о процессоре. Вы можете узнать больше об этой инструкции здесь:

Если все идет нормально, в 8bh находится находится специальный код.

Если код в 8bh совпадатет с тем, что находится в 79h, поздравления! у нас новый микрокод. В /var/log/messages (или используя инструкцию dmesg|tail 10)

появится новый микрокод.

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

  1. Микрокод предназначается не для данного типа процессора
  2. Микрокод бы модифицирован

Другими словами, внутри процессора есть сперциальная система безопасности.

Я проанализировал микрокода и установил, что:

  • В Celeron’ах 2000 байтов различаются у всех микрокодов.
  • В Pentium Pro 1136 представляют собой мусор, который можно модифицировать и который не оказывает никакого влияния на конечный результат
  • В Pentium II и III 1056 байтов – это также мусор, модификация которого не оказывает влияния на конечный результат.

Новые драйвера и инструкции можно найти здесь: http://microcodes.sourceforge.net

5 – Что нужно сделать

Криптографический анализ микрокодов, атака с помощью "грубого подбора".

Продолжим нашу печальную историю…

Первую часть цикла можно посмотреть здесь.

Продолжим нашу печальную историю…

Но сначала еще раз о АМТ.

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

И еще, к сожалению, проблема безопасности АМТ у нас абсолютно не обсуждается в силу безграмотности специалистов ИБ, но на западе полно публикаций на эту тему, с очень жесткими выводами. Наберите в поисковике: «Intel AMT backdoor» и убедитесь сами.

Начну эту часть издалека. Был (дай бог пускай и сейчас здравствует) такой известный в компьютерных кругах человек Крис Касперски (Николай Лихачёв). Не путать, пожалуйста, с другим Касперским, хоть сферы деятельности этих людей раньше тесно пересекалась, совпадение фамилии одного и псевдонима другого чистая случайность. Крис Касперский был известным специалистом в области «белого» взлома, у него много публикаций на эту тему. Последняя публикация датируется серединой 2008 года и касается обнаруженных им уязвимостей в процессорах фирмы Интел.

Собственно как таковой публикации не было кроме безобидной презентации, ее можно посмотреть по ссылке здесь:

Но автор собирался сделать полный доклад и демонстрацию конкретного сплойта для обнаруженной им уязвимости в процессорах Intel на конференции Hack In The Box (HITB). Вот новость того времени: http://www.xakep.ru/post/44450/.

Доклад состоялся, но обнаруженная уязвимость и демонстрация ее эксплуатации так и не были представлены…, вместо этого докладчик оказался в Америке на ПМЖ уже осенью того же 2008года.

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

Между давними соперниками процессоростроения произошел крупный конфликт, приведший к «сливу» конфиденциальной информации о бекдорах в процессорах.

Читайте также:  Dark souls 3 все костры

Сначала некий «независимый» специалист обнаружил недокументированные возможности в аппаратуре процессоров AMD вот ссылка на первоисточник: http://www.theregister.co.uk/2010/11/15/amd_secret_debugger/ . Речь конкретно шла об доступе к расширенным режимам контроля при вводе секретного ключа в один из РОН (EDI). Получить такую информацию исследовательским путем конечно невозможно, это явный «слив» направленный на дискредитацию производителя.

Но вскоре «империя» AMD нанесла ответный удар.

В середине прошлого года стала публичной информация о недокументированной возможности в аппаратуре процессоров Intel, только на этот раз бекдор сидел в процессорной команде и был гораздо серьезнее, почитать подробнее можно здесь: http://blog.xen.org/index.php/2012/06/13/the-intel-sysret-privilege-escalation/

Кстати, фирма Intel назвала это недокументированную возможность обтекаемой фразой «специфическая реализация» и не признала эту «особенность» бекдором или ошибкой реализации. Фирма так и поставляет процессора с этой, как она выражается; «специфической реализацией команды SYSRET».

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

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

Как ни странно, у нас, « как в Греции,- все есть…» необходимый научный задел в автоматизированной верификации системы команд в стране имеется. Несомненным лидером в этой области является Институт Системного Программирования Российской Академии Наук (ИСП РАН). К сожалению, наработки в области автоматизированной верификации процессорных структур этого института вместо нашего собственного государства использует Корея, фирма Самсунг в частности.

Вот и получается, что имеем не ценим, а окончательно потеряв, даже не заплачем…

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

Страсти по микрокоду

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

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

Более сложные команды состоят из цепочек микроопераций с условными переходами, циклами, прерываниями. Так вот, эти цепочки микроопераций и являются микропрограммами выполнения команд процессора. Это конечно очень поверхностное и упрощенное объяснение механизма выполнения команд на современных процессорах х86, но думаю, суть понятна.

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

Другими словами, содержимое памяти микропрограмм можно подправить уже на действующем оборудовании, для этого используются специальные информационные блоки (microcode update).

У 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.

Другими словами, нет возможности контролировать текущую прошивку микрокода даже на уровне его номера. Также невозможно блокировать функцию обновления микрокода аппаратно, она всегда доступна из нулевого кольца привилегий.

Еще одной проблемой становится БИОС материнских плат, там всегда имеется патч микрокода для процессора, но кто гарантирует, что он корректен? Недобросовестное искажение его содержимого возможно и на этапе его создания в Интел и на этапе заливки в БИОС при производстве материнской платы.

Кроме этого патч может обновляться во время обновления БИОС материнской платы уже в процессе эксплуатации оборудования да и просто заменить его в БИОСе не проблема. Хоть какую то гарантию давала бы цифровая подпись на патче, но ее наличие не предусмотрено в структуре блока обновления микропрограммы, производители БИОС никакой внешней защиты на эти патчи также не накладывают.

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

Подписывайтесь на каналы "SecurityLab" в Telegram и Яндекс.Дзен, чтобы первыми узнавать о новостях и эксклюзивных материалах по информационной безопасности.

Читайте также:  Форматировать pdf в doc

МИКРОКОД В ПРОЦЕССОРАХ И ТЕОРИЯ ЗАГОВОРА Современные программисты, даже самого высокого уровня, плохо представляют реальную работу вычислительной системы. Да, где-то там бегают битики, байтики, какие-то триггеры и прочая «муть» переключается, но все это от них далеко. Нынче программируют информационные объекты, а не конкретные кусочки кремния.

Программирование на ассемблере стало редкостью, кто-то даже считает, что это умерший язык, и смотрит на него снисходительно. Зря: настоящие программисты, которые программируют, а не пишут некий абстра
ктный текст, всегда знают, что стоит за каждой строчкой исходника и как это будет работать в кремнии.
Для подавляющего большинства людей, считающих себя программистами, процессор — это некий фантомный объект с условными характеристиками и свойствами, среди которых главными являются абстрактные Гигагерцы и Ядра — чем их больше, тем лучше. Этим знания и ограничиваются. Хотя нет, многие еще знают, что Intel лучше AMD.
Собственно, такое вступление было сделано только для одного — чтобы объяснить, почему техническая документация по архитектуре вычислительных систем неинтересна основной массе программистов. Каков интерес, таков и уровень изложения материала. В последнее время техническая документация на процессоры, чипсеты, периферийные контроллеры стала фрагментарна, во многих случаях она превратилась в отписки, а иногда уже встречается и прямая фальсификация (как в случае с vPro/ АМТ, например).
С другой стороны, реальная техническая информация перешла в разряд конфиденциальной, а кое-где и секретной информации. Доступ к ней открыт только избранным и доверенным партнерам, а для прочих за процедурой получения доступа зачастую стоит вопрос: для чего тебе это нужно? И как только на него дается ответ, все контакты обрываются. По крайней мере, такая практика действует в отношении России.
Если сомневаешься, предлагаю зайти на официальный сайт компании Intel для разработчиков. Там есть списки документов, доступных для скачивания, возле многих из них изображен маленький замочек. Для доступа к этим документам нужно пройти регистрацию. Попытайся зарегистрироваться, и тогда все тебе станет ясно.
В России эту процедуру не смог пройти даже уважаемый академический Институт системного программирования РАН (ИСП РАН). А это только уровень так называемых желтых страниц, есть еще уровень красных страниц, есть и более конфиденциальные уровни.
Сразу после такого вступления появляется соблазн начать говорить о недокументированных возможностях, бэкдорах, но статья не об этом. Даже в доступной документации есть информация, которая непостижимым образом проходит мимо людей, профессионально занимающихся информационной безопасностью.
Начну издалека. У многих серьезных программистов случалосьтак, что внешне абсолютно корректно написанный код по непонятной причине не хочет работать. Начинают разбираться, выходят на конкретные цепочки команд и понимают, что они работают в этой последовательности неправильно. Такое в большинстве случаев (у меня, по крайней мере) происходит на оборудовании Intel.
Несколько раз я сам натыкался на подобные «непрухи», но после переноса «сбойного» процессора на другую материнскую плату либо после обновления BIOS ситуация приходила в норму, все начинало работать корректно.

Многие, наткнувшись на похожие трудности, наверняка на этом успокаивались, в лучшем случае переписывали сбойный участок кода и продолжали работать, более не задумываясь о причинах такого поведения процессора .
Похоже, с подобной проблемой столкнулся и небезызвестный Крис Касперски. В 2008 году он объявил, что обнаружил некорректное выполнение команд на процессорах Intel , которое приводило к появлению бэкдоров в сетевом доступе к вычислительной установке. Вот выдержка из новостной ленты того времени:
18072008
Касперски взломал процессоры Intel «Процессоры содержат недоделки, которые разрешают применять уязвимости как конкретно сидя за компом, так и дистанционно, вне зависимости от установленных обновлений и приложений», – говорит Касперски.
На конференции Hack In The Box в Малайзии он планирует показать техники взлома с помощью кода на JavaScript, также потока TCP/IP-пакетов. Спец по сохранности пообещал открыть написанный им код для всех желающих.
Своего обещания он, к сожалению, не сдержал — ни подробного рассказа, ни демонстрации техники взлома так и не последовало. По неизвестной причине автор горячей новости на конференции не выступил.
Я же, как и всякий русский, наступив на эти «грабли» в третий раз, решил наконец разобраться с этими регулярно возникающими проблемами досконально.
Немного специальной информации. То, чем мне пришлось заняться, называется верификацией. Эта работа требует инженерных навыков и специальных знаний. Сложность верификации в том, что современные процессоры — это конвейерные устройства, обрабатывающие несколько команд одновременно. Как правило, ошибки выполнения команд возникают именно в конвейерном режиме. В режиме выполнения единственной команды (шаговый режим в отладчике, к примеру) их обычно нет, поскольку такие очевидные ошибки вылавливаются на этапе тестирования чипов.
Для верификации используются специальные средства, из доступных и бесплатных есть только официальный эмулятор AMD «SimNow», правда, он предназначен исключительно для продукции AMD и верификатором его можно назвать только условно. Для процессоров Intel даже таких ручных средств нет, их приходится каждый раз писать самому под конкретную задачу. Вообще, лучше использовать аппаратный отладчик, но в Россию они не поставляются.
В результате титанических усилий я уперся в конкретный MSR с номером 8Bh, именно содержимое этого регистра в моем конкретном случае определяло неправильное выполнение цепочки команд.
MSR — это моделезависимые системные регистры, их в процессорах множество — никак не менее двух-трех сотен. Из названия ясно, что их функции зависят от конкретной модели процессора . Многие из них со временем превратились в моделенезависимые регистры, и они присутствуют во всех процессорах и выполняют одну и ту же функцию.
Именно к этой категории относился MSR под номером 8Bh. Он присутствует во всех без исключения процессорах фирмы Intel и называется «IA32_BIOS_SIGN_ID» или, более понятно, «BIOS Update Signature», а по-русски «Регистр обновленной сигнатуры Биос». Собственно к Биосу этот регистр имеет косвенное отношение, название только запутывает.

Оказалось, что значение в этом регистре определяло корректность выполнения машинных команд процессора . Полез в документацию почитать про этот MSR и долго матерился — классический пример «силы заднего ума». Вместо того чтобы тратить время на эти исследования, можно было просто внимательно прочитать документацию: несмотря на ее объем, это было бы быстрее и, главное, полезнее. Все написано в документации (Vol. ЗА, глава 9.11 «Microcode update facilities»), и все предельно логично.
В этой главе речь идет об официальном механизме обновления микрокода в центральных процессорах Intel. В официальной документации AMD на современные процессоры упоминаний о такой возможности нет, но это не значит, что и самого механизма обновления микрокода нет. Такой механизм описан на официальном сайте AMD, там же имеются сами патчи микрокода. Механизмы обновления микрокода у обоих производителей практически одинаковы, различия только в номерах используемых для этой процедуры MSR и структуре патча.
Но вернемся к продукции Intel. Вот как она описывает этот механизм:
911 обновление микрокода УСЛУГИ Pentium 4, Intel Xeon, а P6 процессоров семейства имеют возможность исправить опечатки, загрузив Intel поставляемый блок данных в процессор. Блок данных, называется обновление микрокода. В этом разделе описываются механизмы BIOS необходимо предоставить для того, чтобы использовать эту функцию при инициализации системы. Он также описывает спецификацию, которая позволяет включение в будущие обновления системы BIOS.
Intel считает, что выпуск обновления микрокода для кремния пересмотра в сумме, эквивалентной степпинга и завершает полный степпинг Уровень проверки для релизов обновление микрокода.
Обновление микрокода используется для коррекции ошибок в процессоре.BIOS, Mhich имеет загрузчик обновления, отвечает за загрузку обновлений на базе процессоров при инициализации системы (рис. 9-7). Есть два этапа этого процесса: во-первых, включить необходимые блоки данных обновления в BIOS, а вторая заключается в загрузке обновлений блоков данных в процессор.
Немного теории, чтобы ввести в курс дела. Процессоры архитектуры х86-64 имеют смешанное программно-аппаратное управление. Любая команда для процессора — это набор микроопераций, простые команды — это одна микрооперация, сложные команды могут состоять из сотен, а для некоторых современных команд — из тысяч микроопераций.
Это значит, что некоторые простые команды (типа арифметических, логических) процессор выполняет на комбинаторной логике за одну микрооперацию, фактически это аппаратное выполнение команды.
Более сложные команды состоят из цепочек микроопераций с условными переходами, циклами, прерываниями. Так вот, эти цепочки микроопераций и являются микропрограммами выполнения команд процессора . Это, конечно, очень поверхностное и упрощенное объяснение механизма выполнения команд на современных процессорах х86-64, но, думаю, суть понятна.
Все микропрограммы выполнения команд хранятся в самом процессоре, в специальной энергонезависимой памяти, и заливаются туда на этапе его изготовления. Но, как известно, у любого программиста на тысячу строк кода всегда найдется хотя бы одна ошибка, так что ошибки в микропрограммах бывают, и для оперативного их исправления используется механизм патчей.
Другими словами, содержимое памяти микропрограмм можно подправить уже на действующем оборудовании. Для этого используются специальные информационные блоки [microcode update). Intel предоставляет их всем производителям материнских плат, чтобы те включали их в собственные сборки BIOS.
Механизм обновления микрокода прост: каждый раз после подачи питания или после выдачи сигнала сброса (Reset) необходимо загрузить патч во все процессорные ядра. Другими словами, текущие патчи не сохраняются в энергонезависимой памяти, и их нужно каждый раз перезаписывать.
В структуре патча выделяются три части, расположенные последовательно. Первая часть («Header» — размер 48 байт) и последняя (extended signature — размер 20 байт) описана в документации полностью, они представляют из себя набор полей идентификации типов процессора , для которых предназначен данный патч.
Самая главная часть — тело патча («Date» — размер не фиксирован) — не описана в документации, структура ее неизвестна. Именно эта часть содержит микропрограммы, которые замещают прошитые на этапе производства микропрограммы процессора . Intel не предоставляет никакой информации для того, чтобы узнать, хотя бы какие команды и режимы работы процессора подвергаются изменению.
Метод загрузки патча очень прост. Для этого используется единственный MSR 079h (официальное название «BIOS Update Trigger»), его можно только записывать, прочитать из него информацию невозможно.
Как видно из примера [рис. 2), в документации обновление микрокода происходит после записи в MSR 79h стартового адреса памяти, с которого размещен Data-блок патча. Пример реализован для реального режима работы процессора [для BIOS), но эту же операцию можно выполнять и в любом другом режиме работы процессора .

Читайте также:  Просмотрщик 3d max файлов

Единственный способ узнать результат загрузки патча — это прочитать текущую версию патча, для чего используется специальный MSR 8bh. Если патч успешно загрузился, то его новый номер можно прочесть из этого регистра. Если регистр содержит нулевую информацию, то никаких патчей не загружено.
Как видно из примера (рис. 3), для корректного чтения текущей версии патча требуется сначала обнулить MSR 8bh, затем выполнить Команду Cpuld с значением ЕАХ1, и только после этого, прочитав данный MSR, мы найдем в регистре EDX номер текущего патча.
Предполагается (так сказано в документации), что процедура обновления микрокода производится из BIOS, но нет никаких ограничений на ее проведение и во время последующей работы процессора . Другими словами, патчить микропрограмму процессора можно до бесконечности и во время работы операционной системы. Блокировок режима обновления микрокода в аппаратуре процессора не предусмотрено. А вот это уже некорректно и попахивает бэкдором, скрытым под недокументированными возможностями.
Переводя на общепонятный язык: имеется возможность в любой момент подправить алгоритм работы любой команды процессора таким образом, чтобы она выполняла недокументированную функцию. Нужно только знать структуру информационного блока, и тогда из любой процессорной команды можно будет сотворить совершенно иную, собственную, по своему вкусу и разумению.
Посмотрим, как это реализовано «вживую», на конкретной вычислительной системе. Для этого я разработал специальный редактор, выполняющийся до загрузки ОС (рис. 4). MSR 8bh имеет значение 17h.
Если посмотреть на MSR 8bh уже после загрузки ОС, используя стандартный дамп моделенезависимых регистров в Сандре, то получаем другое значение (рис. 5). В регистре содержится 0a3h.
Видно, что значение текущего патча микрокода изменилось. Что это? Ошибка в рассуждениях? Нет, конечно, просто все современные ОС имеют специальный модуль обновления прошивок микрокода центрального процессора , и во время загрузки ОС микрокод обновляется из файла, предоставляемого Intel.
Вот пример такого файла обновления микрокода операционной системы Windows.
Intel регулярно распространяет официальные обновления микрокода (рис. 6), но описания структуры патча в этих бюллетенях нет, это закрытая информация. Нет даже списка исправленных ошибок либо добавленных оптимизаций. С файлом обновления микрокода идет только информация об операционных системах, для которых он предназначен, и типов процессоров, которые поддерживаются этим патчем.
Но информация, тем более конфиденциальная, все равно что вода в решете, она так же может утекать и растекаться, а потом ее уже не собрать. Утечки конфиденциальной информации не редкость, во многих случаях это даже не утечка, а налаженный рабочий процесс. Так что можно с уверенностью говорить о том, что не только специалисты фирмы Intel владеют методами перепрограммирования процессоров. Показывать пальцем на тех, кто кроме них располагает информацией о таких методах, не будем, пальцем показывать некрасиво.
Патчи микрокода — это абсолютно белое пятно. Ни Intel, ни производители материнских плат, ни производители ОС не публикуют данные о номерах патчей и об ошибках, которые они закрывают. Даже Microsoft, от своего имени выпуская патч микрокода, не говорит ничего о том, для чего он нужен, — только обтекаемая фраза о более стабильной работе.
Еще одной проблемой становится BIOS материнских плат; там имеется патч микрокода для процессора , но кто гарантирует, что он корректен? Недобросовестное искажение его содержимого возможно и на этапе его создания в Intel, и на этапе заливки в BIOS при производстве материнской платы.
Кроме этого, патч может обновляться во время обновления BIOS материнской платы уже в процессе эксплуатации оборудования, да и просто заменить его в BIOS не проблема. Хоть какую-то гарантию давала бы цифровая подпись на патче, но ее наличие не предусмотрено в структуре блока обновления микропрограммы. Также невозможно блокировать функцию обновления микрокода аппаратно, она всегда доступна из нулевого кольца привилегий.
Возвращаясь к истории, связанной с обнаружением недокументированного поведения процессоров Intel, выявленного Крисом Касперски, можно предположить, что он столкнулся именно с багами микропрограмм. Были ли они умышленными, либо просто были банальными ошибками, неизвестно, да по большому счету уже и не важно. Сам этот уже подзабытый факт переводит, в общем-то, теоретические рассуждения в практическую сферу — такое возможно.
Вот так и получаются черные дыры ИБ, скрытые под белыми пятнами в технической документации, которую нам скармливают фирмы — производители оборудования.
А всего-то нужно начать грамотно работать с производителями в рамках государственной политики информационной безопасности (если она у нас имеется).
P. S. Материал для статьи готовился на машине производства HP, и, запустив сканер ресурсов системной шины, я обнаружил на ней активный TPM-модуль. Его регистры идентификации смотри на рис. 7. Этим кодам соответствует чип TPM-модуля SLB 96835 производства Infeneon. Насколько мне известно, законодательством запрещено ввозить и тем более использовать криптографические средства западного производства. А эта машинка была произведена на питерском заводе, который является совместным предприятием HP и Foxconn.
P. P. S. Все вышесказанное — лишь мои собственные размышления.

Комментировать
0 просмотров
Комментариев нет, будьте первым кто его оставит

Это интересно
No Image Компьютеры
0 комментариев
No Image Компьютеры
0 комментариев
No Image Компьютеры
0 комментариев
No Image Компьютеры
0 комментариев
Adblock detector