Работоспособность доверенной среды поддерживается естественно не на всех аппаратных платформах, слишком технически сложное решение и не везде есть необходимое для этого оборудование. Обязательным условием является наличие аппаратуры виртуализации и хотя бы двух процессорных ядер.
Для оборудования AMD этим ограничения и кончаются, с Intel все гораздо сложнее, там как уже говорилось выше стабильные и полнофункциональные версии аппаратуры виртуализации появились только года 3-4 тому назад и соответственно старые процессора поддерживать работу ДВС в полном объеме не будут.
Кроме аппаратных ограничений есть и ограничения на БИОС в части загрузчика UEFI, пока в образ загрузчика ОС не включен активатор ДВС, это дело будущего.
Из ограничений с программными компонентами есть только одно, официальные системы виртуализации совместимы с ГиперДрайвером только если они не используют аппаратною виртуализацию. Дело в том, что архитекторы систем виртуализации Intel и AMD пока нам не разрешают использовать их аппаратуру в мультиплексном режиме, и приходится с ней работать только монопольно.
Гипердрайвер, по праву «первой ночи», захватывает контроль над аппаратурой виртуализации и естественно больше никому ее не отдает, поэтому официальным гипервизорам приходится работать либо в режиме паравиртуализации, либо в режиме эмуляции нулевого уровня привилегий, что даже хорошо с точки зрения безопасности и контроля.
И теперь о главном, надежности функционирования, пока я, как разработчик могу сказать, что получившаяся система не пробиваема только на аппаратуре AMD. Про аппаратуру Intel такое сказать невозможно, в их процессорах много недокументированных возможностей (а по простому бекдоров). Я (и никто в России) не знает как ими воспользоваться, но это не значит что злоумышленники «в серых шляпах» не могут их использовать.
Кроме этого, в архитектуре системы безопасности Intel многое завязано на этап инициализации БИОС, именно на этом этапе система безопасности инициализируется и что самое важно там же блокируется возможность доступа к ней в дальнейшем.
После инициализации БИОС на платформе Intel мы получаем машину с уже настроенными системами безопасности, во многих случаях нет даже возможности посмотреть как они настроены. А если и можем, то ничего изменить уже нельзя, выполнена аппаратная блокировка попыток модификации параметров.
Так что надежность системы на платформе Intel, это вопрос к сборщикам БИОС и архитекторам Intel, я тут как говорится «умываю руки»….
Чтоб не быть голословным приведу пример, но начну издалека.
«День сурка»
Гипердрайверы которыми я занимаюсь пока не применялись в масштабных коммерческих проектах, но это не значит, что они вообще не использовались. Отнюдь, технология отработана, она надежна, но иногда встречаются аномалии. По началу это были мои собственные «косяки» в коде, но к настоящему времени эти «детские болезни» уже в прошлом, все работает безукоризненно.
И все равно «аномалии» бывают даже сейчас, конечно, по каждому случаю нужно разбираться, и разбираемся, как резюме могу сказать, проблем совместимости с софтом и ОС не бывает. Бывает несовместимость с БИОС и аппаратурой материнской платы.
Это не удивительно, Гипердрайвер в первую очередь работает с кремнием, и разные «беспределы» в нем (этому посвящены статьи цикла «Кремневый беспредел») сразу выявляются Гипердрайвером, это можно сказать «лакмусовая бумажка»,- засунул в материнскую плату и сразу видишь, «что такое хорошо, а что такое плохо».
Чтобы не быть голословным приведу конкретный пример, вот снимки того, что называется «хорошо»:
На фотографии экран тестовой программы замера времени выполнения команд и обработки исключений. Время считается в машинных тактах, замер произведен на эталонной машине без Гипердрайвера, реально чистая машина, вопросов к ней нет.
А вот эта же эталонная машина, но с загруженным Гипердрайвером:
Гипердрайвер «честный», он не пытается замаскировать свое присутствие в системе, к слову сказать, таких возможностей у систем виртуализации множество, но здесь все по-честному, на честной машине.
Видно, что время выполнения команд и исключений увеличивается при загрузке Гипердрайвера, и это нормально.
Увеличение времени выполнения бывает двух типов, первый тип, самый очевидный, время увеличивается из-за входа в хост гипервизора, на снимке это команда CPUID, XSETBV и RDMSR с некорректным номером регистра. Циклы выполнения этих команд всегда увеличиваются на 1200-1500 тактов, в зависимости от архитектуры и прошивки микрокода процессора.
Вторым типом увеличения длительности команд является появление дополнительных стадий выполнения команды без выхода в хост гипервизора. Примером может служить левая часть экрана, где выведены значения MSR регистров и время доступа к ним. Время под гипервизором увеличилось в среднем на 30 тактов, эти такты тратятся на проверку соответствия номера текущего регистра со списком номеров регистров требующих выхода в Хост. Тоже самое касается доступа к памяти и обработки исключений, но там естественно увеличение длительности выполнения будет другим, можете посмотреть сами на сколько тактов увеличивается время выполнения этих операций.
Короче говоря, это чистая эталонная машина, вопросов к ней нет.
А теперь посмотрите на снимки экрана той же программы замера времени выполнения на машине в которой все «плохо»:
Даже без Гипердрайвера сразу видны проблемы,- команда XSETBV не выполняется, но это вполне возможно, отрабатывается исключение UD - недействительный код команды. Теперь об однозначных проблемах:
- Команда CPUID с недействительным номером запроса выполняется слишком долго.
- Запредельное время доступа к MSR регистрам с номерами 3F8h-3FEh.
- Не отключилось кеширование ОП, MemAcc показывает время доступа к ОП через Кеш, а не время прямой транзакции в контроллер памяти.
Запускаем на этой плохой машине Гипердрайвер, теперь все стало совсем плохо:
Ну во первых, на этой машине Гипердрайвер установил мировой рекорд, он умудрился зайти и выйти из Хоста при обработке команды CPUID за 750 тактов, я такое вижу впервые, объяснение одно, счетчик тактов работает неправильно, чудес на свете не бывает…
Во вторых, установлен и антирекорд, при выполнении команды RDMSR с недействительным номером регистра вход/выход в Хост занял практически 3000 тактов, диагноз тот же, опять счетчик тактов отработал не правильно…
В третьих, не увеличилось время доступа к MSR регистрам, наблюдается полный хаос, но в среднем оно практически не изменилось...
В четвертых, опять не отработал доступ к оперативной памяти, время увеличилось только на 300 тактов, это время для теневой трансляции, но физический доступ все равно идет в Кеш…
Можно только гадать, что за чудеса творятся на этой машине, вариантов несколько, это может быть особенность реализации режима системного менеджмента, специфика прошивки микрокода, необычная активность сервисного процессора, но может быть и встроенный в БИОС гипервизор, по типу того, что был описан в статье «Китайские закладки».
Естественно на такой «паленой» машине не о какой доверенной среде говорить не приходится, да она и не загружается, виснет в середине загрузки ОС….
Эта «страшилка» озвучивалась исключительно для того, чтобы стало ясно, доверенная среда может быть действительно доверенной только если перед ее загрузкой выполняются проверки на корректность работы аппаратуры. Но и этого мало, нужно контролировать корректность работы аппаратуры на этапе работы ОС, проникнуть в систему можно на любом этапе ее функционирования. Делать это можно сторонними программами, а можно и саму доверенную среду «заточить» под обнаружение вторжений, но это уже совсем другая тема, о ней как ни будь в следующий раз.
«А напоследок я скажу…»
И скажу без лишней скромности, в муках родилась абсолютно новая концепция информационной безопасности.
Она не просто родилась как абстрактный фантом, а реализована в виде программной платформы. На эту платформу можно «навешивать» различные полезные нагрузки, но пока, насколько мне известно, владелец технологии (фирма Код Безопасности) планирует внедрение ее в области ДБО, что дальше будет, посмотрим.
Не думаю что процесс внедрения будет легким, слишком много инновационных решений пришлось применить для превращения этой «сказки» в «быль». Думаю что на этапе массового внедрения у команды разработчиков (и у меня в том числе) будет еще больше проблем, нежели при создании этой платформы.
Мне, честно говоря, страшно…
Но как говорится «глаза боятся, а руки делают», так что продолжение следует.
