Статья про

МИКРОКОД В ПРОЦЕССОРАХ

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

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


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

после переноса «сбойного» процессора на другую материнскую плату либо после обновления 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», а по-русски «Регистр обновленной сигнатуры Биос». Собственно к Биосу этот регистр имеет косвенное отношение, название только запутывает.

В этом разделе описываются механизмы BIOS необходимо предоставить для того, чтобы использовать эту ф


Оказалось, что значение в этом регистре определяло корректность выполнения машинных команд процессора. Полез в документацию почитать про этот 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), но эту же операцию можно выполнять и в любом другом режиме работы процессора.

Пример реализован для реального режима работы процессора [для BIOS), но эту же операцию можно выполн


Единственный способ узнать результат загрузки патча — это прочитать текущую версию патча, для чего используется специальный 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. Все вышесказанное — лишь мои собственные размышления.


Андрей

Спасибо!
Весьма познавательно.

Комментировать