Закладка в чипсетах Intel

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

Еще до официального анонса новых процессоров Intel с поддержкой аппаратной виртуализации (в начале 2007 года) я задумал использовать эти чипы для создания единой вычислительной системы на базе нескольких серверов, которая стала бы для ОС и прикладных программ единой вычислительной установкой с SMP-архитектурой. Для этого требовалось написать компактный гипервизор с нестандартным функционалом, главной особенностью которого было бы не разделение ресурсов единой вычислительной установки между разными ОС, а наоборот, объединение ресурсов нескольких вычислительных машин в единый комплекс, которым бы управляла одна ОС. При этом ОС не должна была даже догадываться, что имеет дело не с единой системой, а с несколькими серверами. Аппаратура виртуализации предоставляла такую возможность, хотя изначально не предназначалась для решения подобных задач. Собственно, система, в которой аппаратура виртуализации применялась бы длявысокопроизводительных вычислений, не создана до сих пор, а уж в то время я вообще был первопроходцем в этой области.
Гипервизор для этой задачи, конечно, писался с нуля. Принципиально важно было запускать ОС уже на виртуализированной платформе, чтобы с первых команд загрузчика ОС все работало в виртуальной среде. Для этого пришлось виртуализировать реальную модель и все режимы работы процессора и запускать виртуализацию сразу после инициализации платформы до загрузки ОС.

Поскольку система виртуализации для этой цели получилась нестандартной и выглядела как полностью автономный компактный программный модуль (объем кода не более 40–60 Кб), язык как-то не поворачивался называть ее гипервизором, и я стал использовать термин "гипердрайвер", поскольку он более точно передавал суть функционального предназначения системы. Серийного оборудования с аппаратурой виртуализации в то время еще не было, однако благодаря сотрудничеству с фирмой "Крафтвей" я имел доступ к предсерийным образцам процессоров и материнских плат с поддержкой виртуализации, которые еще не выпускались официально (так называемым сэмплам, которые фирма Intel любезно предоставляет своим партнерам по бизнесу). Поэтому работа закипела на этом "сэмпловом" оборудовании.

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

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

Я начал разбираться и понял, что моя система виснет при выполнении команд аппаратной виртуализации. Создавалось такое впечатление, что они или совсем не работают, или работают как-то нестандартно. Зависание происходило только во время работы аппаратуры виртуализации в реальном режиме, если же моя система запускалась из защищенного режима, после загрузки ОС, то все было нормально.

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

Первым делом заменил процессоры, но это не помогло. На материнских платах в то время аппаратура виртуализации была только в биосе, где она инициализировалась во время включения сервера, поэтому я начал сравнивать биосы на материнских платах (однотипных платах с сэмплами) — все совпадало до байта и номера самого биоса. Я впал в ступор и, уже не зная, что делать, применил последнее средство — "метод тыка". Чего я только не делал, уже не думая, а просто комбинируя, и в конце концов тупо скачал биосы с официального сайта Intel и переписал их заново в материнские платы, после чего все заработало…

Моему удивлению не было предела: номер биоса был тем же самым, образы биоса совпадали побайтно, но по какой-то причине серийные материнские платы заработали только тогда, когда я залил в них такой же биос, взятый сайта Intel. Значит, причина все-таки в материнских платах? Но единственное их отличие было в маркировке: на сэмплах было написано Assembled Canada, а на серийных платах — Assembled China. Стало ясно, что платы из Китая содержат дополнительные программные модули, прошитые в биосе, а стандартные программы анализа эти модули не увидели. Они, видимо, тоже работали с аппаратурой виртуализации и, соответственно, имели возможность скрыть истинное содержимое биоса. Стала понятна и причина зависаний моего гипердрайвера на этих китайских платах: две программные системы одновременно работали с одной и той же аппаратурой виртуализации, которая не позволяла разделять свои ресурсы. Мне захотелось разобраться с этим зловредным биосом, причем без всякой задней мысли о "закладках", "бэкдорах", "недокументированных возможностях", был просто академический интерес, и не более того.

Нужно сказать, что параллельно с внедрением аппаратуры виртуализации Intel радикально обновила чипсет. Этот чипсет, получивший номер 5000х, выпускается в нескольких модификациях до сих пор. Южный мост этого чипсета, 631xESB/632xESB I/O Controller Hub, к которому подключены флеш-микросхемы с биосом, практически в неизменном виде выпускается с 2007 года и используется в качестве базового чипа почти для всех серверов в двухсокетном исполнении. Я скачал даташит на южный мост, прочел описание и просто обалдел. Оказывается, к этому новому южному мосту подключаются три микросхемы флеш-памяти: первая представляет собой стандартный биос, вторая выделена под программы процессора сетевого контроллера, а третья предназначена для интегрированного в южный мост блока ВМС.

Блок менеджмента системы (ВМС) — это средство удаленного управления вычислительной установкой и ее мониторинга. Он незаменим для больших серверных комнат, где из-за шума, температуры и сквозняков просто невозможно долго находиться.

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

Чтобы не быть голословным, привожу выдержку из документации на этот южный мост:
ARC4 processor working at 62.5 MHz speed.
Interface to both LAN ports of Intel 631xESB/632xESB I/O Controller Hub allowing direct connection to the net and access to all LAN registers.
Cryptographic module, supporting AES and RC4 encryption algorithms and SHA1 and MD5 authentication algorithms.
Secured mechanism for loadable Regulated FW.

Применение иностранных криптографических средств с длиной ключа более 40 бит запрещено на территории России законодательно, а тут — пожалуйста! — в каждом сервере Intel криптомодуль с неизвестными ключами длиной 256 бит. Более того, эти ключи использовались для шифрования программ, зашитых в микросхемы материнской платы на этапе производства.

Выходит, что блоки ВМС в России на серверах Intel, которые имеют в своем составе чипсет 5000х, должны быть отключены. Однако эти блоки, напротив, всегда находятся в рабочем состоянии, даже если сама вычислительная установка отключена (для функционирования ВМС достаточно дежурного напряжения, то есть вставленного в розетку кабеля питания сервера). Все это казалось мне на тот момент второстепенным, поскольку для начала нужно было выяснить, в какой из флеш-микросхем находился программный модуль, работающий с аппаратурой виртуализации и мешающий моему гипердрайверу, и я начал экспериментировать с прошивками.

После ознакомления с документацией я насторожился, а когда обнаружил, что работоспособность гипердрайвера восстанавливается как раз после перепрошивки флеш-микросхемы блока ВМС, даже не удивился. Разбираться дальше без специальных стендов было невозможно, так как криптография полностью перекрывала возможности реверса кода для ВМС. Документации на внутреннюю архитектуру этого интегрированного ВМС я не нашел, в даташите на южный мост Intel описала только интерфейсные регистры для управления этим блоком по стандартным методам доступа, в результате чего получился классический "черный ящик".

Совокупность фактов настораживала и наводила на параноидальные мысли в стиле шпионских детективов. Эти факты однозначно говорили о следующем:
В новых серийных серверных платах Intel на базе чипсета 5000 имеются программы, прошитые в флеш-памяти блока ВМС и исполняемые на центральном процессоре, причем эти программы работают с использованием аппаратуры виртуализации центрального процессора.
Образы флеш-памяти с официального сайта Intel не содержат таких программных модулей, следовательно, мешающие мне программные модули были нелегально прошиты в материнские платы на этапе производства.
Флеш-память блока ВМС содержит зашифрованные программные модули, которые невозможно собрать и залить в флеш-память без знания ключей шифрования, следовательно, тот, кто вставил эти нелегальные программные модули, знал ключи шифрования, то есть имел доступ фактически к секретной информации.

Я сообщил руководству "Крафтвей" о проблеме с прошивкой флеш-памяти блока ВМС и сомнительной с точки зрения законодательства ситуации с новыми чипсетами Intel, на что получил вполне ожидаемый ответ в стиле "не мути, мешаешь бизнесу". Пришлось угомониться, поскольку против работодателей особо не попрешь.

Руки были связаны, но "мои мысли, мои скакуны" не давали мне покоя, было непонятно, зачем эти сложности и как все это сделано. Если у тебя есть возможность разместить собственное ПО в памяти блока ВМС, зачем тебе вся эта морока с центральным процессором? Разумной причиной могло быть только то, что решаемая задача требовала контролировать текущий вычислительный контекст на центральном процессоре. Очевидно, что уследить за обрабатываемой информацией на основной вычислительной системе, используя только периферийный низкоскоростной процессор с частотой 60 МГц, невозможно. Таким образом, похоже, задача этой нелегальной системы состояла в съеме информации, обрабатываемой на основной вычислительной установке, с помощью средств аппаратуры виртуализации. Дистанционно управлять всей нелегальной системой, конечно, удобнее с процессора блока ВМС, поскольку он имеет собственный независимый доступ к сетевым адаптерам на материнской плате и собственные МАС- и IP-адреса. Вопрос "как это сделано?" имел более академический характер, поскольку кто-то умудрился создать гипервизор, умеющий разделять ресурсы аппаратуры виртуализации с другим гипервизором и делающий это корректно для всех режимов, кроме реального режима работы ЦП. Сейчас такими системами уже никого не удивишь, но тогда, пять лет назад, они воспринимались как чудо, кроме того, скорость эмуляции поражала — программно эмулировать хост без значительных потерь в быстродействии было невозможно.

Для пояснения придется немного углубиться в теорию. Архитектура систем виртуализации Intel и AMD не предполагает наличия на платформе сразу нескольких гипервизоров, однако запущенный первым гипервизор может эмулировать для гипервизоров, которые запускаются после, работу на реальном оборудовании виртуализации. В этом случае все гипервизоры, запущенные вслед за первым, работают в эмулируемой среде хоста. Этот принцип я называю "правом первой ночи". Его можно легко реализовать с помощью специальных обработчиков в корневом хосте, при этом режим задачи существенно не изменится, а хосты вторичных гипервизоров будут выполняться в режиме задачи для корневого хоста. Режим эмуляции организовать не сложно, однако с быстродействием возникают проблемы. Аппаратура виртуализации работает в основном с блоком VMCB (VMCS), программы хоста постоянно обращаются к этому блоку, а на каждое такое обращение требуется 0,4–0,7 мкс. Скрыть такую программную эмуляцию хоста для системы виртуализации Intel практически невозможно, слишком много команд виртуализации придется эмулировать программно через выходы в корневой хост, вместо того чтобы выполнять их на реальном оборудовании.

Расскажу немного о различиях между архитектурами виртуализации. Системы аппаратной виртуализации от Intel и AMD совершенно не похожи друг на друга. Главное архитектурное отличие этих систем состоит в режиме работы хоста. В системе AMD хост работает с отключенной аппаратурой виртуализации, то есть его программы выполняются на реальном процессоре. Виртуализация вторичного хоста в системах от AMD требует виртуализации только команды VMRUN (можно считать, что других команд нет). Работа с управляющим VMCB-блоком в архитектуре AMD происходит через обычные команды обращения к оперативной памяти, что позволяет контролировать с помощью вторичного хоста только выполнение команд VMRUN и подправлять при необходимости VMCB-блок перед реальным входом в режим задачи. Удлинить цикл обработки события в два раза еще можно, и на платформе AMD такая эмуляция жизнеспособна. В системе виртуализации Intel все гораздо сложнее. Для доступа к VMCB-блоку используются специальные команды VMREAD и VMLOAD, которые нужно обязательно виртуализировать. Обычно обработчики хоста десятки, если не сотни раз обращаются к полям VMCB-блока, и каждую такую операцию нужно эмулировать. При этом заметно, что скорость падает на порядок, это очень неэффективно.

Стало ясно, что для эмуляции неизвестные коллеги использовали другой, более эффективный механизм. И подсказки насчет того, какой именно, я нашел в документации. Хост у Intel сам является виртуальной средой, то есть ничем, по сути, в этом плане не отличается от среды выполнения задачи и просто управляется другим VMCB (см. схему).