Я не профессионал в области информационной безопасности, моя область интересов — это высокопроизводительные вычислительные комплексы. В тему ИБ я пришел совершенно случайно, и именно об этом дальше пойдет речь. Думаю, эта невыдуманная история гораздо лучше осветит проблемы, связанные с аппаратурой виртуализации, нежели сухое изложение фактов.
Еще до официального анонса новых процессоров Intel с поддержкой аппаратной виртуализации (в начале 2007 года) я задумал использовать эти чипы для создания единой вычислительной системы на базе нескольких серверов, которая стала бы для ОС и прикладных программ единой вычислительной установкой с SMP-архитектурой. Для этого требовалось написать компактный гипервизор с нестандартным функционалом, главной особенностью которого было бы не разделение ресурсов единой вычислительной установки между разными ОС, а наоборот, объединение ресурсов нескольких вычислительных машин в единый комплекс, которым бы управляла одна ОС. При этом ОС не должна была даже догадываться, что имеет дело не с единой системой, а с несколькими серверами. Аппаратура виртуализации предоставляла такую возможность, хотя изначально не предназначалась для решения подобных задач. Собственно, система, в которой аппаратура виртуализации применялась бы длявысокопроизводительных вычислений, не создана до сих пор, а уж в то время я вообще был первопроходцем в этой области.
Гипервизор для этой задачи, конечно, писался с нуля. Принципиально важно было запускать ОС уже на виртуализированной платформе, чтобы с первых команд загрузчика ОС все работало в виртуальной среде. Для этого пришлось виртуализировать реальную модель и все режимы работы процессора и запускать виртуализацию сразу после инициализации платформы до загрузки ОС.
Поскольку система виртуализации для этой цели получилась нестандартной и выглядела как полностью автономный компактный программный модуль (объем кода не более 40–60 Кб), язык как-то не поворачивался называть ее гипервизором, и я стал использовать термин «гипердрайвер», поскольку он более точно передавал суть функционального предназначения системы. Серийного оборудования с аппаратурой виртуализации в то время еще не было, однако благодаря сотрудничеству с фирмой «Крафтвей» я имел доступ к предсерийным образцам процессоров и материнских плат с поддержкой виртуализации, которые еще не выпускались официально (так называемым сэмплам, которые фирма Intel любезно предоставляет своим партнерам по бизнесу). Поэтому работа закипела на этом «сэмпловом» оборудовании.
Макет был собран, гипердрайвер написан, все заработало, как и было задумано. Нужно сказать, что на тот момент аппаратура виртуализации было очень «сырой», из-за чего она не один раз отказывалась работать так, как написано в документации. Приходилось разбираться буквально с каждой ассемблерной командой, а сами команды для аппаратуры виртуализацииписать в машинных кодах, поскольку тогда не существовало компиляторов с поддержкой команд виртуализации.
Я гордился полученными результатами, чувствовал себя чуть ли не властелином виртуальных миров… но моя эйфория продлилась недолго, всего месяц. К тому времени я уже собрал макет на основе серверов с аппаратурой виртуализации, первые серийные образцы которых тогда как раз появились, но макет не работал.
Я начал разбираться и понял, что моя система виснет при выполнении команд аппаратной виртуализации. Создавалось такое впечатление, что они или совсем не работают, или работают как-то нестандартно. Зависание происходило только во время работы аппаратуры виртуализации в реальном режиме, если же моя система запускалась из защищенного режима, после загрузки ОС, то все было нормально.
Профессионалы знают, что в первых ревизиях аппаратура виртуализации Intel не поддерживала работу процессора в реальном режиме. Для этого требовался дополнительный слой достаточно большого объема для эмуляции виртуального х86. Поскольку гипердрайвер запускался до загрузки операционной системы, чтобы она могла полностью поверить в новую виртуальную конфигурацию, то небольшой кусок загрузочного кода ОС выполнялся в реальном режиме работы процессора. Система умирала как раз на обработчиках эмуляции реального режима в гипердрайвере. Сначала я подумал, что где-то ошибся, что-то не понял, о чем-то забыл. Проверил все до последнего бита в своем коде, никаких ошибок не нашел и начал грешить уже не на себя, а на коллег из-за бугра.
Первым делом заменил процессоры, но это не помогло. На материнских платах в то время аппаратура виртуализации была только в биосе, где она инициализировалась во время включения сервера, поэтому я начал сравнивать биосы на материнских платах (однотипных платах с сэмплами) — все совпадало до байта и номера самого биоса. Я впал в ступор и, уже не зная, что делать, применил последнее средство — «метод тыка». Чего я только не делал, уже не думая, а просто комбинируя, и в конце концов тупо скачал биосы с официального сайта Intel и переписал их заново в материнские платы, после чего все заработало…
Моему удивлению не было предела: номер биоса был тем же самым, образы биоса совпадали побайтно, но по какой-то причине серийные материнские платы заработали только тогда, когда я залил в них такой же биос, взятый сайта Intel. Значит, причина все-таки в материнских платах? Но единственное их отличие было в маркировке: на сэмплах было написано Assembled Canada, а на серийных платах — Assembled China. Стало ясно, что платы из Китая содержат дополнительные программные модули, прошитые в биосе, а стандартные программы анализа эти модули не увидели. Они, видимо, тоже работали с аппаратурой виртуализации и, соответственно, имели возможность скрыть истинное содержимое биоса. Стала понятна и причина зависаний моего гипердрайвера на этих китайских платах: две программные системы одновременно работали с одной и той же аппаратурой виртуализации, которая не позволяла разделять свои ресурсы. Мне захотелось разобраться с этим зловредным биосом, причем без всякой задней мысли о «закладках», «бэкдорах», «недокументированных возможностях», был просто академический интерес, и не более того.
Cпасибо за статью, весьма интересно.