Защита выполнения данных с аппаратной поддержкой в bios
В ранее опубликованной статье "Вирус
в Shadow RAM" были рассмотрены уязвимости, позволяющие программно
модифицировать выполняемый блок BIOS, находящийся в оперативной памяти.
Очевидно, это дает вредоносным программам широкие возможности, но не вызывает
повреждения оборудования, поскольку искажается не содержимое микросхемы BIOS, а
его копия, находящаяся в ОЗУ и обновляемая при каждом перезапуске компьютера.
Продолжая начатую тему, рассмотрим и более тяжелый случай – искажение
содержимого микросхемы BIOS. После такой атаки, материнская плата требует
ремонта, а точнее – восстановления содержимого микросхемы BIOS.
Как известно, авторы вирусов начали использовать эту уязвимость еще около 10
лет назад, практически сразу после того, как в качестве носителя BIOS стали
применяться микросхемы электрически перепрограммируемых ПЗУ (Flash ROM). В
сложившейся ситуации, минимизация угрозы стала заботой не только авторов
антивирусных программ, но и разработчиков аппаратного обеспечения, в частности,
материнских плат. Отметим, что полностью исключить опасность несанкционированной
модификации BIOS невозможно, так как для этого пришлось бы отказаться от
"законной" возможности его обновления.
В предлагаемом материале, на уровне ассемблера и программирования
конфигурационных регистров, рассматривается процесс программного доступа к
функциям микросхемы Flash ROM, а также системные ресурсы, управляющие таким
доступом и защищающие BIOS от несанкционированного искажения.
При таком глубоком исследовании, нам потребуется работать с регистрами,
которые в каждом чипсете реализованы по-разному. Разумеется, в одной статье
невозможно описать архитектуру всех чипсетов. Поэтому, для того, чтобы разговор
был предметным, остановимся на одном из вариантов: в качестве примера рассмотрим
платформу на чипсете Intel 815, детально описанном в 3, использующую
микросхему BIOS SST 49LF004A, детально описанную в [18]. Перечислим все действия
программы, выполняемые при стирании сектора и записи данных в микросхему Flash
ROM для такой платформы. Протокол доступа к микросхеме Flash ROM, описанный
ниже, используется как программами обновления BIOS, так и вредоносными
программами, цель которых – искажение или стирание содержимого микросхемы BIOS.
В приложении к статье содержатся исходные тексты программы, осуществляющей
доступ к функциям микросхемы Flash ROM.
Как это делается
1) Микросхема BIOS подключена к "южному мосту" чипсета посредством
интерфейса LPC (Low Pin Count), детально описанного в [1]. Для доступа к
содержимому BIOS на предмет чтения и записи, а также передачи управляющих команд
и контроля текущего состояния микросхемы Flash ROM, используется 16-мегабайтный
диапазон FF000000h-FFFFFFFFh в адресном пространстве памяти. Чтобы программные
обращения к указанному диапазону транслировались в физические циклы чтения и
записи на интерфейсе LPC, конфигурационные регистры "южного моста" чипсета
должны быть установлены следующим образом.
В 16-битном регистре BIOS_CNTL (его координаты в конфигурационном
пространстве Bus=0, Device=1Fh, Function=0, Register=4Eh-4Fh) бит 0 нужно
установить в "1". Это снимает блокировку циклов записи и разрешает их трансляцию
на интерфейс LPC.
2) Микросхема SST 49LF004A, используемая в качестве носителя BIOS,
имеет объем 512 Кбайт и разделена на 8 блоков по 64 Кбайт. Каждый блок имеет
свой регистр защиты записи (Block Locking Register). Например, для блока 0,
расположенного по адресам FFF80000h-FFF8FFFFh, адрес регистра Block Locking
Register равен FFB80002h. Для разрешения стирания и записи блока, бит 0 этого
регистра должен быть установлен в "0". Адреса регистров защиты записи для
каждого блока и другие подробности содержаться в [18]. Манипуляции с регистрами
микросхемы Flash ROM, расположенными в пространстве памяти, выполняются с
помощью стандартных инструкций архитектуры x86, обеспечивающих чтение и запись
ячеек памяти, например MOV. Вопросы организации регистров, отображенных на
память (Memory-mapped I/O) детально рассмотрены в ранее опубликованной статье
"Устройства системной поддержки. Исследовательская работа №
7,
8 и
9".
3) Для запуска операции стирания блока или сектора требуется выполнить
последовательность из шести циклов записи заданных байтов по заданным адресам.
Последовательности приведены в [18] а также в исходном тексте программы,
прилагаемом к статье. Использование многоцикловых последовательностей для
запуска операций стирания и записи, снижает вероятность случайного искажения
содержимого Flash в результате программного сбоя.
4) Для запуска операции записи байта требуется выполнить
последовательность из четырех циклов записи заданных байтов по заданным адресам.
Отметим, что перед выполнением записи, для сектора, в который выполняется
запись, необходимо выполнить стирание.
Об аппаратной защите BIOS и ее эффективности
Как было показано выше, для перезаписи содержимого Flash ROM, программа
должна выполнить три действия: перенастроить чипсет для обеспечения доступа к
микросхеме BIOS, перенастроить регистры блокировки записи, входящие в состав
самой микросхемы BIOS и, наконец, передать приказ записи или стирания. На каждом
из этих трех этапов действуют механизмы защиты BIOS от несанкционированной
модификации. Рассмотрим подробнее эти механизмы, а также причины, по которым они
в ряде случаев оказываются неэффективными. Приведенная информация поможет
выработать методику, позволяющую исследовать заданную материнскую плату на
предмет наличия рассматриваемой уязвимости.
1) Регистр BIOS_CNTL, рассмотренный выше входит в состав "южного
моста" чипсета, его бит 0 управляет блокировкой циклов записи, адресованных
микросхеме BIOS. Бит 1 того же регистра (это бит BLE, BIOS Lock Enable)
позволяет установить режим, при котором попытка снять защиту записи будет
перехватываться BIOS, а точнее, при попытке установить бит 0 в "1" будет
генерироваться прерывание SMI (System Management Interrupt) с передачей
управления специальной процедуре, входящей в состав BIOS. Причем, если BIOS при
старте установит такой режим перехвата, программно выключить его чипсет не
позволяет, этот режим будет выключен только после аппаратного сброса (по сигналу
RESET). Подробности в [3].
К сожалению, разработчики BIOS обычно не используют этот механизм,
предоставляемый чипсетом. Во всех материнских платах, исследованных автором, бит
BLE (бит 1 регистра BIOS_CNTL) установлен в "0", поэтому, попытки снятия защиты
записи не перехватываются.
Вместе с тем, работа "вирусописателей" несколько осложнена тем, что
архитектура регистров управления доступом к BIOS в каждом чипсете различна,
поэтому для снятия защиты, вирус должен распознавать чипсет и иметь модули
поддержки под каждый чипсет.
2) Регистры защиты записи Block Locking Register, также рассмотренные
выше, входят в состав микросхемы Flash ROM SST 49LF004A. Здесь также
предусмотрен бит защиты записи (бит 0) и бит, установка которого в "1" позволяет
запретить снятие защиты записи (бит 1). Если биты 0 и 1 установлены в "1",
микросхему BIOS программно вывести из состояния защиты записи невозможно, это
произойдет только при аппаратном сбросе (по сигналу RESET). Подробности в [18].
К сожалению, и этот механизм обычно не используется разработчиками BIOS, а
ведь его применение могло бы существенно улучшить защищенность. Во всех платах,
исследованных автором, бит 1 в регистрах защиты блоков микросхем Flash ROM
установлен в "0", то есть снятие защиты записи разрешено.
3) Третий уровень защиты, состоит в том, что для запуска операций
стирания и перезаписи микросхемы BIOS, требуется своеобразный пароль, а именно,
передача многоцикловых "ключевых" последовательностей со строго определенными
адресами и данными. Так как у всех микросхем одного типа пароль одинаковый и его
можно узнать из документации на микросхему, например 4, 17, такая мера
может защитить только от случайного искажения содержимого BIOS при программном
сбое и записи беспорядочных данных. Вредоносная программа, прочитав
идентификаторы ROM Vendor ID и ROM Device ID, может распознать тип микросхемы
BIOS и сформировать требуемые ключевые последовательности в соответствии с
документацией на данную микросхему.
С точки зрения использования этих сигналов, материнские платы бывают трех
видов:
Третий вариант - сигналы защиты записи формируются с помощью
программно-доступного регистра, состоянием которого управляет BIOS. При этом
пользователю не нужно переключать "перемычки", но защищенность будет хуже, так
как в отличие от второго варианта, здесь есть возможность программного
выключения защиты. Вместе с тем, это неплохой компромисс. Так как указанный
программно-доступный регистр обычно реализуется специфическими ресурсами платы,
"вирусописатель", располагая информацией только на чипсет и микросхему BIOS, но,
не имея принципиальной электрической схемы материнской платы, не узнает о том,
что и в какой регистр надо записать для снятия защиты на данной материнской
плате.
Источники информации
14) PCI BIOS Specification. Revision 2.1.
15) PCI Local Bus Specification. Revision 3.0.
16) PCI-to-PCI Bridge Architecture Specification. Revision 1.1.
17) 2 Megabit (256K x 8) Multi-Purpose Flash SST39SF020 Data Sheet.
18) 2 Mbit / 4 Mbit Firmware Hub SST49LF002A / SST49LF004A Data Sheet.
19) 2 Mbit LPC Flash SST49LF020 Data Sheet.
20) 1 Mbit SPI Serial Flash SST25VF010 Data Sheet.
21) 2 Mbit / 4 Mbit SPI Serial Flash SST25VF020 / SST25VF040 Data Sheet.
22) W49V002FA 256K x 8 CMOS Flash Memory with FWH Interface Data Sheet.
23) W49V002A 256K x 8 CMOS Flash Memory with LPC Interface Data Sheet.
24) MX28F1000P 1M-BIT [128K x 8] CMOS Flash Memory Data Sheet.
25) SPI EEPROM Interface Specification. Part Number 223-0017-004 Revision H.
26) SPI Interface Specification. Technical Note 15.
Книги
27) В.Л. Григорьев. Микропроцессор i486. Архитектура и программирование.
Москва ТОО “ГРАНАЛ” 1993.
28) 2B ProGroup: В.А. Вегнер, А.Ю. Крутяков, В.В. Серегин, В.А. Сидоров, А.В.
Спесивцев. Аппаратура персональных компьютеров и ее программирование. IBM PC/XT/AT
и PS/2. Москва “Радио и связь” 1995.
Установил Hyper-V Server
Дистанционно обращаюсь к нему
вроде все работает машины создаются
но при попытке запустить вирт.машину получаю такую ошибку:
Не удается запустить виртуальную машину, поскольку не выполняется низкоуровневая оболочка. Эту проблему могут помочь устранить следующие действия: 1) Убедитесь, что процессор физического компьютера имеет поддерживаемую версию виртуализации с аппаратной поддержкой. 2) Убедитесь, что виртуализация с аппаратной поддержкой и защита выполнения данных с аппаратной поддержкой включены в BIOS физического компьютера. (Если требуется изменить BIOS, чтобы включить любой из этих параметров, необходимо выключить питание физического компьютера, а затем включить его. Перезагрузки физического компьютера недостаточно.) 3) Если в хранилище данных конфигурации загрузки внесены изменения, проверьте эти изменения и убедитесь, что настроен автоматический запуск низкоуровневой оболочки.Машина если на нее поставить обычные сервер 2008 не CORE работает с виртуальными машинами нормально
но хочется освободить лицензию и использовать ее под другие задачи
Ответы
bcdedit /set hypervisorlaunchtype auto
Все ответы
" Не выполняется низкоуровневая оболочка"
Где мне смотреть то?
PS. Машина аппаратно совместима.
Народ помогите пожалуйста никак не справится с проблемой!
"Hyper-V launch aborted due to auto-launch being disabled in the registry."
Переставлял уже 4 раза. Русский вариант, английский все одно и тоже
Не запустить виртуальную машину.
Сервисы вроде все запущены. В реестре никаких вроде явных ошибок не увидел
Что делаю не так непонятно
bcdedit /set hypervisorlaunchtype auto
мне тоже не помогло. Есть еще какие соображения?
У меня была та же проблема. Для её решения я зашёл в биос своего физического компьютера, там нашёл пунк "Virtualization" и установил значение в "Enabled". а сервер какой?была такаяже проблемма сегодня решилась звонком в сервис службу HP прислали мануал, там оказываеть помимо пунка виртуализация надо ещё некоторые параметры включать в частности ещё No-Execute Memory Protection
Собственно, для работы виртуальных машин в в BIOS должна быть включена поддержка аппаратной виртуализации (AMD-V/Intel VT) и Data Execution Prevention.
Если упростить ответ, то
bcdedit /set hypervisorlaunchtype auto
Попробую Hyper-V как службу на 2008 R2, вроде пару лет назад работало.
Я установил Docker и получаю эту ошибку при запуске графического интерфейса:
В BIOS необходимо включить аппаратную виртуализацию и защиту выполнения данных.
Похоже на ошибку, поскольку Docker работает как шарм из командной строки, но мне интересно, знает ли кто-нибудь, почему это происходит?
Прежде чем вы спросите, да, я включил виртуализацию в BIOS, и утилита идентификации процессоров Intel подтверждает, что она активирована. Docker, docker-machine и docker - все работают из командной строки, Virtualbox работает, запуск Docker из Debian или Ubuntu VM работает.
Есть одна странная проблема с графическим интерфейсом.
- Юбилейная версия Windows 10 Pro x64
- Intel core i5-6300HQ @ 2,30 ГГц
Если описанные функции включены, проблема связана с отключенным Hyper-V или не запущенным агентом гипервизора.
РЕШЕНИЕ A (если Hyper-V полностью отключен или не установлен)
Откройте PowerShell от имени администратора и
Включить Hyper-V с
РЕШЕНИЕ Б (если функция Hyper-V уже включена, но не работает)
Включить гипервизор с
Теперь перезапустите систему и попробуйте еще раз.
РЕШЕНИЕ C
Если проблема не устранена, возможно, Hyper-V в вашей системе поврежден, поэтому
Зайдите в Панель управления -> [Программы] -> [Компоненты Windows] и полностью снимите флажки со всех компонентов, связанных с Hyper-V. Перезагрузите систему.
Снова включите Hyper-V. Начать сначала.
ПРИМЕЧАНИЕ 1 :
Hyper-V требует аппаратной виртуализации в качестве предварительного условия. Убедитесь, что ваш компьютер поддерживает эту функцию. Если да, и по-прежнему не работает, возможно, ваш BIOS неправильно настроен и эта функция отключена. В этом случае отметьте, включите и попробуйте еще раз. Функции виртуализации могут быть представлены под разными именами в зависимости от используемой платформы (например, если вы не видите какой-либо опции, которая явно использует метку виртуализации, на AMD вам необходимо проверить состояние функции SVM , на Intel - на VT-x состояние функции).
ПРИМЕЧАНИЕ 2 .
Hyper-V можно установить только с некоторой версией, например:
Windows 10 Корпоративная; Windows 10 Профессиональная; Windows 10 для образовательных учреждений.
Hyper-V нельзя установить на более дешевые или мобильные версии Windows, например:
Windows 10 Домашняя; Windows 10 Mobile; Windows 10 Mobile Корпоративная.
Ниже приведено рабочее решение для меня. Выполните следующие действия.
Откройте PowerShell от имени администратора или запрос CMD от имени администратора.
Запустите эту команду в PowerShell-> bcdedit /set hypervisorlaunchtype auto
Теперь перезапустите систему и попробуйте еще раз.
Я удалил Intel HAXM и VirtualBox, теперь Docker работает
Для меня все, что мне нужно было сделать, это удалить VMware.
Докер сейчас работает
Можете ли вы попробовать включить Hyper-V вручную и потенциально создать и запустить виртуальную машину Hyper-V вручную? Детали:
Попробуйте это в PowerShell (администратор включен):
Это установит HyperVisor без инструментов управления, и после этого вы сможете запустить Docker.
Я пробовал много предложений выше, но докер продолжает жаловаться на аппаратную ошибку виртуализации. Виртуализация включена в BIOS, а также установлен и включен Hyper-V. После нескольких попыток и ошибок я в конце концов загрузил инструмент coreinfo и обнаружил, что гипервизор на самом деле не включен. Использование ISE (64-разрядная версия) в качестве администратора и выполнение команды из приведенного выше решения B, которое успешно включает гипервизор (снова проверяется с помощью coreinfo -v). После перезапуска докер теперь успешно работает.
Проблема для меня была решена, когда я удалил Cygwin.
Еще пользуюсь бродягой. Похоже, я могу использовать только одну вещь за раз. Удаление vagrant / virtualBox позволило мне запустить докер и наоборот
У меня был установлен Hyperv и включена виртуализация в моем BIOS.
Но РЕШЕНИЕ А у меня не сработало.
Однако РЕШЕНИЕ B сработало как шарм.
РЕШЕНИЕ B (если функция Hyper-V уже включена, но не работает)
Включить гипервизор с
Bcdedit / set hypervisorlaunchtype auto Теперь перезапустите систему и попробуйте еще раз.
Если с опцией BIOS все в порядке, я просто принудительно отключил и включил все функции HyperV, и это решило мою проблему --cmd Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All --restart Enable-WindowsOptionalFeature -Online -FeatureName Microsoft- Hyper-V –Все
В моем случае, хотя я использовал все упомянутые выше решения, у меня ничего не работало. Поэтому я решил удалить докер и установить его снова.
Теперь, в процессе, я заметил, что не проверял Use Windows containers instead of Linux containers (this can be changed after installation) в своей предыдущей установке, и именно поэтому у меня возникла проблема, указанная выше, и решения все еще не устранили ее. Поэтому убедитесь, что вы проверили его, прежде чем запускать докер для рабочего стола или удалить его и установить снова, отметив эту опцию.
В моем случае мне пришлось удалить Hyper-v, перезагрузить компьютер и снова запустить докер.
Hyper-V , родная для систем Windows – в её серверных выпусках, а также в некоторых десктопных версиях и редакциях – среда для работы с виртуальными машинами и их гостевыми ОС не всегда работает без проблем. Одной из таких проблем может быть выскакивающее при запуске виртуальной машины уведомление, что, мол, Hyper-V не удаётся её запустить, поскольку не выполняется некая низкоуровневая оболочка.
Окно с такой ошибкой является универсальной трактовкой, причина может крыться в нескольких вещах.
Системные требования
Если сама Windows не соответствует требованиям для работы с Hyper-V, а десктопные выпуски не все позволяют работать с этим компонентом, он попросту не активируется в системе. Но есть ещё аппаратные требования. Их несоответствие может не влиять на активацию гипервизора, но в дальнейшем стать причиной появления такой ошибки.
Для работы Hyper-V необходимо:
• Не менее 4 Гб RAM;
• 64-битный процессор с поддержкой SLAT и технологии виртуализации.
Хранилище BCD
Рассматриваемая ошибка может говорить о неверной конфигурации данных хранилища BCD . Компонент Hyper-V глубоко интегрирован в Windows и стартует до запуска ядра системы. Если в хранилище BCD вносились изменения для модификации запуска гипервизора, они могут быть неверными. Либо же запуск Hyper-V и вовсе был ранее намеренно отключён с целью временной оптимизации использования ресурсов компьютера. В таком случае конфигурацию BCD в части запуска гипервизора необходимо либо подкорректировать, либо вернуть дефолтное значение путём установки автозапуска Hyper-V. Для установки автозапуска открываем CMD от имени администратора (обязательно) , вводим:
bcdedit /set hypervisorlaunchtype auto
После этого осуществляем перезагрузку.
AMD Bulldozer
Hyper-V не работает с процессорами компании AMD с архитектурой Bulldozer.
Технологии виртуализации
Для обеспечения жизнедеятельности среды виртуализации посредством любого гипервизора процессор должен быть обустроен технологией, обеспечивающей виртуализацию – Intel Virtualization, либо же AMD-V. О поддержке этих технологий можно узнать на страничке спецификаций процессора на сайтах, соответственно, Intel и AMD . И технология виртуализация, естественно, должна быть включена в BIOS .
Ещё один важный нюанс: для процессоров Intel в BIOS должны быть отключены специфические технологии Intel VT-d и Trusted Execution. С ними встроенный в Windows гипервизор не дружит. Вот примерно так должны выглядеть настройки BIOS для работы с Hyper-V: технология виртуализации включена, а специфические технологии – выключены.
Читайте также: