Почему uefi в низком разрешении
сем привет. У меня вопрос, на который я нигде не могу найти ответа. У меня возникла следующая проблема. Я собрал новый компьютер, Ryzen 2700X, Nvidia GTX1660, 16 Gb DDR4, SSD 2.5 512 gb, Aorus B450 Pro, Win 10 OS x64 (1909). Система очень хорошо работает. Но есть одно но. Когда я нажимаю на кнопку включения, меня встречает логотиа БИОСА, дальше идет нормальный загрузочный экран Windows 10, и после нескольких секунд экран становится кратковременно темным и на экране появляется круг из вращающихся точек, но он низкого разрешения. После этого появляется экран входа пользователей но уже нормального разрешения (1920 x 1080). Повторюсь, система работает прекрасно, но очень раздражает этот дополнительный загрузончный экран с низким разрешением.
Что делал: переустанавливал Windows, ставил другой SSD, переустанавливал драйвера для всего, включая видеокарту - все не привело к успеху.
Прощу помощи!
Конфигурация компьютера | |
Процессор: Intel Core i7-970 (3,2Ghz) | |
Материнская плата: ASUS Rampage III Extreme (BIOS version: 1601) | |
Память: Corsair CMT6GX3M3A1866C9 (6 x 2Gb) | |
HDD: OCZ RevoDrive 3 (240Gb) | |
Видеокарта: NVIDIA GeForce GTX 650 | |
Звук: Realtek High Definition Audio (ALC889) | |
Блок питания: Corsair CMPSU-850HX (850Вт), ~2009 г. | |
CD/DVD: LG GH22NS50 | |
Монитор: ASUS VK278Q (27") | |
Ноутбук/нетбук: ASUS EEE PC Lamborghini VX6S: Atom D2700 (2,1Ghz) | 4Gb RAM | Radeon HD 6470M (1366x768; 12,1") | Corsair "Force 3" SSD (90Gb) | |
ОС: Windows 7 "Ultimate" (64-bit) | |
Прочее: Клавиатура: Logitech G19 | Мышь: ASUS GX850 | Акустика: SVEN-Audio HA-385 |
Когда UEFI передает управление видеодрайверу из состава Windows - это и есть тот кратковременный момент, когда разрешение экрана становится низким, поскольку запуск и инициализация драйвера с последующей передачей ему управления происходят не мгновенно. Проще говоря, ничего вы с этим не поделаете. Самого раздражает этот момент, но увы.
Роясь в закромах Родины, обнаружил некогда топового двухголового монстра AMD Radeon R9 295 X2. Поскольку времена сейчас понятно какие в плане доступности новых видеокарт, сразу же возник интерес посмотреть – а на что способен дорогущий старичок. О чем позднее будет подробный отчет (сразу скажу, что картина сложилась интересная), а вот в начале возникли проблемы с эксплуатацией. Ну, во-первых, карты того времени очень сложно заставить работать на современных платформах. Дело не в железе – а в поголовном отсутствии UEFI BIOS для карт 2014 (и частично 2015) года. Поэтому на последних платформах AMD (AM4 с чипсетами 500-й серии) и Intel (LGA1200 во всех видах) зачастую требуется большой бубен – причем с переменным успехом. К сожалению – так бы многие старые карты еще пожили. С другой стороны, не факт, что их владельцы так уж гоняются за самыми свежими платами и процессорами. А на LGA1151 Second Edition, например, таких проблем еще нет.
Но в моем случае первым подводным камнем оказалось вовсе не это, а очень смешная проблема – обычно на тестовом стенде используется HDMI, но у 295 Х2 нет ни одного такого разъема. Хотя карта и поддерживает до шести FHD-мониторов, но непосредственно на ней расположены четыре разъема Mini-DisplayPort 1.2 и один DVI-D. В доме ничего подходящего из кабелей и переходников не нашлось, в офисе вроде что-то было, но ехать туда не планировалось – да и уверенности в наличии нужного тоже не было. Поэтому решено было поступить простым и гарантированным образом: заказал на WildBerries за 290 рублей переходничок DVI-HDMI с доставкой в соседний дом на следующий день. Впопыхах даже не посмотрев – какой он там.
За что на следующий день и поплатился: не лезет. Не лезет потому, что на карте DVI-D, а на переходнике – DVI-I. Разницу разъемов DVI все помнят с детства, поскольку это программа начальной школы. Кто забыл – напомню:
Вариантов у меня было два – добыть-таки подходящий переходник/кабель или доработать имеющийся. Признаюсь честно – если бы я точно знал, что второе возможно и проверено, скорее всего пошел бы по первому пути из-за лени. Но, поскольку отчетов о проведении таких «мероприятий» мне не попадалось, стало тупо любопытно. Тем более, что сгореть ничего не должно, а копеечного адаптера в общем-то и не жалко.
Первая часть марлезонского балета понятна – надо удалить четыре контакта, которые в принципе используются только в аналоговом режиме. Оказалось, что в современных недорогих разъемах их не паяют, так что… 30 секунд работы узкогубцами и все. Но не помогло – поскольку все равно не лезет. Проблема в широком контакте «С5» — обычно он действительно широкий в A/I, но поуже в D. Хотя большинство производителей на это плюет – и делает одинаково. Или и вовсе для универсальности повсюду DVI-I – даже там, где он в принципе не нужен. Как, кстати, и в переходнике от GreenConnect. При этом если посмотреть спецификации, то в цифровом режиме «С5» вообще не нужен: это земля для «С1»-«С4». Но в миллионах разъемов и кабелей он есть, что наводит на мысли – зачем-то это нужно.
Поэтому сначала решил его вытащить и обрезать. Потом… просто вытащить – и попробовать так. Попробовал – заработало. Правда нашелся один подводный камень – на плате Asus ROG Maximus X Hero (LGA1151-2 Z370) изображение на мониторе появлялось только после загрузки Windows, т.е. в BIOS зайти не выходило. Также понадобилось загрузиться с флэшки с Acronis – тоже полюбовался на черный экран. А вот на свежих ROG Maximus XII Extreme и ROG Maximus XIII Hero (обе LGA1200 на Z490 и Z590) в BIOS зайти можно – но и только-то. Дальше продвинуться сложно. Впрочем, не слишком старался – возможно, что проблема решаема.
Первыми, кстати, на нее напоролись покупатели плат на AMD X570. Люди, понятно, не бедные – но некоторые попробовали сохранить старые «затычки» и обломались. Откуда взялось поверие, что старые видеокарты не совместимы с PCIe 4.0. Выход в прошлом году LGA1200 показал, что и с PCIe 3.0 они также «не совместимы». Ибо проблема вовсе не в PCIe, а в прошивках. Так что если хочется проапгрейдить древнюю систему, но замену видеокарты оставить «на потом» (в настоящее время – ничего удивительного в таком желании нет), поскольку в игры не играю, играю только в старые игры, мне достаточно FHD и т.п., то стоит заранее проверить совместимость. Иначе может оказаться, что никакой «затычки на первое время» вовсе нет, так что проблему придется решать сразу же.
Благо и проверить несложно – нужную информацию дает GPU-Z. Конкретно нас интересует строчка с «BIOS Version», а еще конкретнее – галочка справа. Скриншоты сняты на R9 295 X2 и RX 480 – у второй проблем совместимости с современными системами нет, у первой – есть. Водораздел проходит где-то посередине «десятых», т.е. производители видеокарт на деле подготовились заранее, причем это не такая уж и массовая проблема (новые видеокарты в старые системы устанавливают намного чаще, чем старые в новые), но когда на рынке творится такая фигня, как сейчас – всякое может быть. А отзывов, соответственно, слишком мало, чтобы, например, создать список конфигураций, где такие проблемы не возникают или легко решаются. Очень может быть, что они существуют. И однозначно есть варианты, где и «решить» в принципе ничего невозможно – например, с APU Ryzen Pro серии 4х50G (может и не только с ними) Compatibility Support Module загрузить попросту невозможно. Какие уж там древние карты расширения, когда даже с диска с MBR-разметкой не загрузишься-то. Меняем процессор – и теплае ламповая легаси возвращается.
В общем, смешение технологий разных временных периодов в одной системе – не лучшая затея. Производители компьютерного железа, конечно, священную корову совместимости очень ценят и уважают. Но ее период полураспада составляет порядка пяти лет – а при превышении этого срока могут всплывать самые забавные и неожиданные (и не всегда решаемые) проблемы. А вот с ощипыванием DVI – все просто. Дурь там ровно одна – сам по себе DVI-D придумывали зря. Впрочем, ограничься производители одним DVI-I – тоже пришлось бы потом отвечать на недоуменные вопросы пользователей: я кабель воткнул, а он не работает. Вот и придумали специальный цифровой вариант. В который неизвестно зачем воткнули и один из контактов чисто аналогового режима. Но такие проблемы отлично решают узкогубцы :)
Как устроена загрузка современных ОС? Как при установке системы настроить загрузку посредством UEFI, не утонув в руководствах и ничего не сломав?
Я обещал "самое краткое руководство". Вот оно:
- Создаём на диске таблицу разделов GPT
- Создаём FAT32-раздел на пару сотен мегабайт
- Скачиваем из интернета любой UEFI-загрузчик
(нам нужен сам загрузчик, это один бинарный файл!) - Переименовываем и кладем этот файл на созданный раздел по адресу /EFI/Boot/bootx64.efi
- Создаём текстовый конфиг, кладем его там, где загрузчик ожидает его увидеть
(настройка и местоположение конфига зависят от конкретной реализации загрузчика, эта информация доступна в интернете) - После перезагрузки видим меню загрузчика
(Если на диске установлена Windows 8 или 10 — с большой вероятностью это руководство сокращается до пунктов 3 — 5.)
TL;DR не надо прописывать путь к загрузчику в новых загрузочных записях UEFI — надо файл загрузчика расположить по стандартному "пути по-умолчанию", где UEFI его найдет, и вместо загрузочного меню UEFI пользоваться меню загрузчика, которое гораздо проще и безопаснее настраивается
Выводы
CSM – это конфигурация UEFI, которая обеспечивает совместимость с устаревшей версией BIOS за счет эмуляции среды BIOS.
Через CSM вы можете использовать устаревшие операционные системы и дополнительные ПЗУ, которые не поддерживают UEFI.
Я рекомендую использовать CSM для загрузки через устаревший BIOS, только если вы:
- Настраиваете виртуальную машину – UEFI на гипервизорах виртуальных машин обычно ограниченный и экспериментальный; Загрузка BIOS поддерживается намного лучше
- Необходимо загрузить 32-битную операционную систему на 64-битной машине
- Используемая прошивка глючная
- Часто меняете жёсткие диски между машинами
- Хотите установить более старую ОС
Помимо этих сценариев, лучше использовать UEFI. UEFI быстрее, безопаснее и обладает превосходной функциональностью.
Если вы включите CSM для установки более старой операционной системы, ваше устройство автоматически загрузится в том же режиме, в котором оно было установлено.
Преимущества БИОС
Что такое BIOS и UEFI
Прежде чем мы углубимся в CSM, вам нужно знать, что CSM является компонентом прошивки UEFI.
BIOS и UEFI – это низкоуровневое программное обеспечение, которое проверяет ваше оборудование, а затем передаёт процесс загрузки вашей операционной системе при включении компьютера.
BIOS расшифровывается как Basic Input/Output System. Это первое, что появляется при включении компьютера, когда он прокручивает несколько строк или экранов текста. Когда вы включаете компьютер, BIOS позволяет ему работать.
BIOS – это то, что облегчает связь между всеми микросхемами и компонентами вашего компьютера. Он проверяет, что все аппаратные устройства работают.
Как только он закончит проверку всего, он даёт разрешение операционной системе загрузиться.
UEFI (Unified Extensible Firmware Interface) начал заменять BIOS в качестве загрузочной прошивки в 2007 году из-за жёстких ограничений BIOS.
Система, которую обычная BIOS использует для доступа к вашему жесткому диску или твердотельному накопителю, называемая главной загрузочной записью (MBR), может обрабатывать только разделы размером менее 2 ТБ. Это стало серьёзной проблемой для BIOS, когда накопители начали превышать этот предел емкости.
Подавляющее большинство современных компьютеров используют UEFI, а не традиционный BIOS, хотя в большинстве случаев он по-прежнему называется BIOS.
Возвращаясь к исходному вопросу этой статьи: при переходе от традиционного BIOS к UEFI был введен новый параметр под названием CSM.
CSM отображается как компонент в меню настройки UEFI.
Но, что такое CSM и для чего он используется?
Более простой процесс загрузки
BIOS предлагает более простой процесс загрузки. С UEFI можно последовательно загружать только несъёмные носители.
Это связано с тем, что записи загрузчика для операционных систем на внутренних дисках хранятся на материнской плате.
Другие загрузчики
systemd-boot очень простой и предоставляет спартанского вида чёрно-белое меню. Есть варианты красивей, если душа просит красоты.
Clover. Позволяет выставлять нативное разрешение экрана, имеет поддержку мыши на экране загрузки, разные темы оформления. Дефолтная тема ужасна, конфиг в виде xml нечитаем, настроить не смог.
Более гибкие варианты ОС
Большинство систем UEFI являются 64-разрядными, а это означает, что 32-разрядные системы должны будут прибегать к CSM для загрузки. Версии Windows старше Vista SP1 не могут загружаться с UEFI.
Вариант безопасной загрузки
Безопасная загрузка может быть скорее проблемой, чем преимуществом, в зависимости от ваших потребностей.
Вот почему большинство аппаратных средств позволяет вам отключить её. Однако наличие дополнительной проверки подписи на уровне прошивки является дополнительной функцией защиты от руткитов.
Как включить CSM
Включение CSM отличается для каждой марки материнской платы. Это включает в себя вход в BIOS при запуске компьютера и поиск вкладки Загрузка или Безопасность.
Найдите меню с надписью «Безопасная загрузка», и там должна быть опция «Запуск CSM».
После того, как вы включите «CMS», выберите «Сохранить изменения», и ваш компьютер будет готов к запуску с CSM.
Меньше ошибок
Реализации UEFI могут иметь незаметные, но фатальные ошибки и недостатки. Это может привести к поломке материнской платы из-за загрузки неправильного драйвера или удаления конфигурации прошивки.
BIOS существует с 1981 года, и способ его взаимодействия с ОС за это время не сильно изменился.
В настоящее время это очень тонкий слой, который используется только во время загрузки.
ОС почти не имеет доступа к тому, что остается внутри BIOS, поэтому фатально сломать что-либо гораздо сложнее.
Более быстрая загрузка и лучшее управление питанием
UEFI с быстрой загрузкой может быть в два раза быстрее, чем устаревшая загрузка на компьютерах с Windows.
Такие функции, как сон, гибернация, перезагрузка и т.д., могут частично или полностью обходить POST (самотестирование при включении). Это означает, что ваш компьютер почти мгновенно готов к работе после таких энергосберегающих режимов.
Улучшенная поддержка больших дисков
Разделы MBR из BIOS поддерживают только до 2 ТБ. UEFI достигает теоретических ~9 зетабайт.
Вы по-прежнему можете загружать большие диски в BIOS, используя гибридные таблицы разделов и дополнительный раздел загрузчика. Тем не менее, он лучше поддерживается в UEFI без необходимости дополнительных патчей.
"Самое краткое руководство" — чуть более подробно
Загрузочная запись нам не нужна — дело в том, что при выставлении в настройках BIOS загрузки с диска прошивка UEFI сначала ищет на нём EFI-раздел, а затем пытается исполнить файл по строго фиксированному адресу на этом разделе: /EFI/Boot/BOOTX64.EFI
Что такое "EFI-раздел"? В теории, он должен иметь особый тип "EFI System" (ef00). На практике, годится первый раздел на GPT-диске, отформатированный в FAT32 и имеющий достаточно места, чтобы разместить загрузчик и вспомогательные файлы (если есть).
Пункт 3: "Скачиваем из интернета любой UEFI-загрузчик". Что это значит? Загрузчик — это просто исполняемый файл определенного формата, к которому в комплекте идет конфиг. К примеру, если у вас есть под рукой установленный пакет с systemd — файл загрузчика можно найти по адресу /usr/lib/systemd/boot/efi/systemd-bootx64.efi, переименовать его в bootx64.efi и скопировать в /EFI/Boot/ на EFI-разделе. Нет под рукой systemd? Скачайте архив с сайта Archlinux. Или с репозитария Ubuntu. Или Debian. Есть под рукой система с Windows? Возьмите виндовый загрузчик оттуда, тоже сгодится )) Если сумеете настроить, я честно говоря не пробовал.
Пункт 4: "Настроить конфиг". Как и обычная программа, когда загрузчик запускается — он ожидает найти по определенным путям файлы конфигурации. Обычно эту информацию легко найти в интернете. Для загрузчика systemd-boot нам необходимо в корне EFI-раздела создать каталог "loader", а в нём файл "loader.conf" с тремя строчками (привожу свои):
Параметр editor отвечает за возможность отредактировать пункт загрузочного меню перед запуском.
Рядом с loader.conf необходимо создать каталог entries — один файл в нём будет отвечать за одну загрузочную запись в boot-меню. У меня там один файл arch.conf с таким содержанием:
Я не упомянул, но довольно очевидно — ядро и initramfs должны лежать в одной файловой системе с загрузчиком, то есть на EFI-разделе. Пути к ним в конфигах отсчитываются от корня этой ФС.
Как узнать, какую схему загрузки использует компьютер
Вот как проверить, загружается ли ваша операционная система Windows через BIOS или UEFI.
Теперь найдите «Режим BIOS», и рядом с ним будет написано UEFI или Legacy .
- Если UEFI, ваш BIOS на самом деле является UEFI, а параметр CSM в вашем BIOS отключен (в противном случае вы не могли бы загрузить ОС в режиме UEFI)
- Если Legacy, ваш BIOS либо несколько устарел, либо у вас используется UEFI BIOS с параметром CSM.
Для чего используется CSM
Два распространенных сценария, требующих CSM.
Первая ситуация – если вы устанавливаете старую операционную систему, которая не поддерживает загрузку UEFI. Это будет Windows Vista до SP1 или более ранняя.
Ещё одна причина использовать CSM – если вам нужно установить операционную систему с другой «разрядностью», чем у прошивки. Например, если вы хотите установить 32-разрядную ОС на машину с 64-разрядным UEFI, вам потребуется использовать CSM.
Также важно отметить, что загрузка BIOS обычно требует создания разделов MBR. Однако, некоторые загрузчики поддерживают схемы разбиения, например GPT.
Загрузка UEFI обычно требует, чтобы разрядность ОС соответствовала разрядности прошивки, и большинство машин на основе UEFI имеют 64-разрядную прошивку.
Преимущества UEFI
Что такое CSM в прошивке UEFI
CSM означает модуль поддержки совместимости. Это дополнительный инструмент, включенный в прошивку UEFI, который обеспечивает совместимость с устаревшей версией BIOS.
CSM предлагает обратную совместимость, загружая машину, как если бы вы использовали устаревшую систему BIOS.
Это также позволяет вам использовать более старые операционные системы, которые не поддерживают UEFI. Вы создаёте устаревшую совместимость с BIOS, эмулируя среду BIOS, совместимую с вашей текущей операционной системой.
Если ваш компьютер относительно новый и поставляется с предустановленной Windows, CSM, скорее всего, будет отключен по умолчанию.
Вам не нужно включать его, если вы не хотите установить более старую операционную систему, которая не поддерживает UEFI, или если вы пытаетесь загрузиться со старого накопителя, который вы недавно подключили, на котором уже установлена ОС.
Родной мультизагрузчик
UEFI позволяет заявить, что на одном жестком диске установлено более одной ОС.
Затем вы можете выбирать между ними в пользовательском интерфейсе прошивки. Это означает, что вам не нужен дополнительный загрузчик.
Как делать не надо
Есть, на самом-то деле, несколько способов настроить UEFI-загрузку. Я начну с описания других вариантов — чтобы было понятно, как (и почему) делать не надо. Если вы пришли за руководством — мотайте в самый низ.
Не надо лезть в NVRAM и трогать efivars
Наиболее "популярная" процедура установки загрузчика в систему такова: установщик ОС создаёт специальный раздел, на нём — структуру каталогов и размещает файлы загрузчика. После этого он с помощью особой утилиты (efibootmgr в linux, bcdedit в windows) взаимодействует с прошивкой UEFI-чипа, добавляя в неё загрузочную запись. В этой записи указывается путь к файлу загрузчика (начиная от корня файловой системы) и при необходимости — параметры. После этого в загрузочном меню компьютера появляется опция загрузки ОС. Для linux существует возможность вообще обойтись без загрузчика. В загрузочной записи указывается путь сразу к ядру вместе со всеми параметрами. Ядро должно быть скомпилировано с опцией EFISTUB (что давно является стандартом для большинства дистрибутивов), в этом случае оно содержит в себе заголовок "исполняемого файла EFI", позволяющий прошивке его запускать без внешнего загрузчика.
При старте системы, когда пользователь выбирает нужную ему загрузочную запись, прошивка UEFI сперва ищет на прописанном в этой записи диске особый EFI-раздел, обращается к файловой системе на этом разделе (обязательно FAT или FAT32), и запускает загрузчик. Загрузчик считывает из файла настроек свой конфиг, и либо грузит ОС, либо предоставляет загрузочное меню. Ничего не замечаете? Да, у нас два загрузочных меню — одно на уровне прошивки чипа UEFI, другое — на уровне загрузчика. В реальности о существовании второго пользователи могут даже не догадываться — если в меню всего один пункт, загрузчик Windows начинает его грузить без лишних вопросов. Увидеть экран с этим меню можно, если поставить вторую копию Windows или просто криво её переустановить.
Обычно для управления загрузочными записями руководства в интернете предлагают взаимодействовать с прошивкой UEFI. Есть аж пять основных вариантов, как это можно сделать: efibootmgr под linux, bcdedit в windows, какая-то софтина на "Маках", команда bcfg утилиты uefi shell (запускается из-под UEFI, "на голом железе" и без ОС, поскольку скомпилирована в том самом особом формате) и для особо качественных прошивок — графическими средствами UEFI (говоря популярным языком, "в настройках BIOS").
За всеми вышенаписанными "многобуков" вы могли легко упустить такую мысль: пользователь, чтобы изменить настройки программной части (например, добавить параметр запуска ОС), вынужден перезаписывать flash-память микросхемы на плате. Есть ли тут подводные камни? О да! Windows иногда способна сделать из ноутбука кирпич, linux тоже, причём разными способами. Качество прошивок часто оставляет желать лучшего — стандарты UEFI либо реализованы криво, либо не реализованы вообще. По логике, прошивка обязана переживать полное удаление всех переменных efivars без последствий, не хранить в них критичных для себя данных и самостоятельно восстанавливать значения по-умолчанию — просто потому что пользователь имеет к ним доступ, и вероятность их полного удаления далека от нуля. Я лично в процессе экспериментов неоднократно (к счастью, обратимо) "кирпичил" свой Lenovo — из загрузочного меню исчезали все пункты, включая опцию "зайти в настройки".
Работа с загрузочными записями UEFI — тоже не сахар. К примеру, утилита efibootmgr не имеет опции "редактировать существующую запись". Если ты хочешь немного изменить параметр ядра — ты удаляешь запись целиком и добавляешь её снова, уже измененную. При этом строка содержит в себе двойные и одинарные кавычки, а также прямые и обратные слеши в не особо очевидном порядке. Когда я наконец заставил эту магию работать — я сохранил её в виде bash-скриптов, которые до сих пор валяются у меня в корневой ФС:
Не надо использовать GRUB
Это чёртов мастодонт, 90% функциональности которого предназначено для дисков с MBR. Для настройки необходимо отредактировать ряд файлов, после чего выполнить команду генерации конфига. На выходе получается огромная малопонятная нормальному человеку простыня. В составе — гора исполняемых файлов. Ставится командой, которую просто так из головы не возьмешь — надо обязательно лезть в документацию
Для сравнения — самый простенький UEFI-bootloader, который есть в составе пакета systemd, ставится командой
Эта команда делает ровно две вещи: копирует исполняемый файл загрузчика на EFI-раздел и добавляет свою загрузочную запись в прошивку. А конфиг для неё занимает ровно СЕМЬ строчек.
Различные неочевидные последствия
Вы можете легко попробовать эту схему в работе. Берёте USB-флешку, форматируете в таблицу разделов GPT, создаете FAT-раздел и копируете туда загрузчик. Комп сможет с неё стартовать.
Если просто скопировать на такую флешку boot-раздел установленного linux — система будет спокойно загружаться с флешки, не видя разницы.
С момента выпуска первой спецификации EFI в двухтысячном году прошло около девятнадцати лет. Десять лет понадобилось интерфейсу, чтобы выйти на пользовательский рынок и закрепиться на нем. На текущий момент редко где можно увидеть современный компьютер без UEFI в прошивке материнской платы. Стандарт интерфейса нарастил «мясо» и несколько тысяч страниц в официальной документации. Для обычного пользователя ничего не поменялось, кроме эпизодических столкновений с включённым Secure Boot. Но если плоскость работы смещается в разработку, всё становится интереснее.
Сама концепция модульной архитектуры UEFI подразумевает, что эти модули можно не только использовать в стандартной конфигурации, но и загрузить что-то своё. Драйвер файловой системы (не ограничиваться же родным efi-шным FAT?), драйвера периферии, приложения, загрузчики – всё можно подгрузить руками, было бы что грузить и немного Shell’а. Можно сделать шаг «вглубь» и обратиться к содержимому прошивки, избавляя себя от танцев с SecureBoot и необходимости писать прослойку из скриптов (на страницах хабра достаточно статей, посвящённых этому).
На этой почве родилась идея создания функциональных модулей, выполняющих разнообразные функции безопасности до загрузки ОС способных в дальнейшем объединиться и стать чем-то вроде интегрированной среды доверенной загрузки, затрагивающей оба сервиса интерфейса boot и runtime таким образом, чтобы между модулями в прошивке и модулями на диске ничего нельзя было «просунуть» без низкоуровневого вмешательства, а после них – только с разрешения администратора безопасности.
Реализация этой идеи познакомила нас с огромным количеством нюансов и тонкостей UEFI – начиная со множества недокументированных или слабодокументированных возможностей, багов, и заканчивая так любимым всеми разработчиками неопределенным поведением. Начнем по порядку.
Платформозависимость
Первое, что необходимо выяснить при интеграции в платформу – сможем ли мы с ней работать? Версия спецификации UEFI важна, и на большинстве устройств она представлена в диапазоне между 2.1 и 2.7. Более новое пока не попадало на исследовательский стенд. Более старое встречается, и его работоспособность может быть ограничена из-за отсутствия нужных протоколов или криво написанных для их реализации драйверов. Например, часто не хватает UnicodeCollation, при обращении к smbios возникают недокументированные ошибки, не работают функции смены языка через SetVariable(). Бывает всякое, в зависимости от вендора и свежести, ведь иногда приходится ставить свои протоколы даже на относительно новые платы.
Ещё в нашей практике посчастливилось наткнуться на два мини-компьютера с Intel Bay Trail D и 32-разрядной прошивкой на борту. Случай редкий, но в своё время вызвал необходимость экстренно перекомпилировать модули. Собственно, как и вопрос: встретимся ли мы с более современной платформой такой же разрядности в будущем? А если встретимся, то где?
Следующий шаг – определение способа интеграции. Модули встраиваются в прошивку, прошивка находится в SPI-микросхеме на плате, там же неподалёку располагается PCH с Intel ME. И тут возникает самый интересный вопрос – а как туда достучаться? Старый добрый программатор с «крокодилом» — это хорошо, это надёжно. Даже если не зацепится до конца, всегда можно посмотреть на горящие светодиоды на плате, питания с программатора для них вполне хватает. Работает почти безотказно, за исключением некоторых старых моделей HP, где микруха SOIC-16 с прошивкой находится в такой доступности, что проще исхитриться и припаять к ее ногам переходник, чем протискивать клипсу.
Знаю, что на Хабре есть люди, сделавшие вклад в написание flashrom’а, им отдельное спасибо.
Но, несмотря на надёжность и достоверность снятия дампа программатором, этот способ плохо подходит, если требуется что-нибудь установить в UEFI на несколько машин, или если целевая платформа для установки не у вас на столе. К счастью для нас, производители оставили нативные утилиты для работы с прошивкой: FPT (Flash programming tool) из комплекта Intel (CS)ME System Tools, и AFU (AMI Firmware Update) для Aptio от American Megatrends. Эти утилиты запускаются как из среды EFI, так из операционных систем Windows, Linux, DOS. Утилиты в чём-то взаимозаменяемые, обе позволяют считать образ если не целиком, то определенные регионы уж точно. И иногда даже позволяют записать обратно.
Пишет и не пишет
Тут и появляется первый серьёзный камень преткновения на пути интеграции. Далеко не все материнские платы позволяют считать прошивку целиком, запрещая доступ к региону ME (ME – почти святое, Интел его читать по-хорошему не разрешит, а по-плохому мы не всегда хотим). Ещё меньше – залить что-то даже в регион BIOS, если только это не подписанная капсула. Вероятность успеха сильно разнится в зависимости от производителя и свежести чипсета. На некоторых моделях материнских плат можно пронаблюдать забавную картину: то, что не записывалось на старых платах вендора, на новых влетает враз.
Иногда бороться с защитой от записи помогает парсер IFR, приоткрывающий нам завесу над скрытыми настройками и переменными. А иногда помогает только хардкор – джампер, открывающий доступ на запись или «выключающий» ME (если таковой предусмотрен, конечно).
Сложный характер систем
Платы Acer, Asus, AsRock и Gigabyte в большинстве случаев пишутся без лишних сложностей. Особняком стоят Intel, HP и серверное железо. HP мало того, что не даёт записать в себя программно, ещё и ругается на любую попытку модификации прошивки (у CodeRush есть статьи по поиску и отключению проверки целостности). Intel более-менее записывался до 87-го чипсета, потом стал глух к просьбам открыть врата региона BIOS.
С Intel’ом первое время было забавно. Импорт модулей в прошивку выполнялся средствами утилиты UEFITool, и мы наткнулись на интересный баг: если вставить модули ffs в конец тома DXE, после всех freeform, то собранный образ «кирпичил» плату. Выходом было добавлять модули после любого родного DXE драйвера. До этого не сразу дошли, и по началу это выглядело, будто Intel контролирует целостность прошивки, как HP. Позже стало понятно, что без автоматической утилиты импорта модулей не обойтись, и проблема сошла на нет после написания оной.
С серверным железом проще и сложнее одновременно. С одной стороны, на серверах всегда существуют дополнительные способы обновлять и модифицировать BIOS’ы, с другой – объем кастомизации в этих самых BIOS’ах зашкаливает, благо на сервера не скупятся и ставят достаточно вместительные микросхемы flash-памяти, зачастую еще и резервируя их.
При установке на сервера всегда неплохо иметь возможность удаленного обновления BIOS через IPMI. Правда, для этого по-хорошему нужна лицензия, само собой платная. Если её не оказывается в нужный момент, вполне возможно угодить в забавную ситуацию, подобную той, которую мы получили, внедряя модули в BIOS сервера Supermicro.
После внедрения модулей загрузка зависала намертво из-за блокирования одним из модулей безопасности (не учли своенравность серверных BIOS’ов, с кем не бывает!). При отсутствии возможности принудительно откатить BIOS через IPMI, рука сама потянулась к программатору, но вот незадача – стандартная SOIC-8 клипса оказалась маловатой для SOIC-16 микросхемы! Ну и ладно, ведь в теории серверная плата имеет возможность резервного восстановления с подключенного носителя, подхватывая SUPER.ROM образ в корне. Но этот механизм не запускается, так как по мнению системы все ОК, все работает, следовательно, и откат BIOS’а не нужен! Что делать. История закончилась беготней по городу в поисках нужной клипсы, экстренной перепайкой проводов, наляпанных китайцами в непонятном для нас порядке, и наконец – перепрошивкой.
С Lenovo вышло ещё интереснее. На полученных от вендора свитчах, под крышкой корпуса была найдена управляющая плата с двумя «микрухами» под прошивку, с SSD под операционку и с жестко зафиксированной батарейкой. BIOS оказался крепким орешком, ни в какую не хотел кушать модифицированный образ, поддаваясь только программатору. В одной из попыток что-то записать, в свитч вставили флешку с консольной убунтой (графику терминал не выдавал) и вполне благополучно загрузились. Сделав то, что требовалось, по старой памяти «выключили» систему командой halt -p. Свитч, по своей природе не приспособленный ни к какому выключению, кроме как по отсутствию питания, оказался не готов к такому и не хотел больше запускаться. Линк на морде горел через раз, вентиляторы тихо шелестели, а все порты выдавали ничего. Перепрошивка не помогала, батарейка сидела как влитая – мы опасались сломать крепление. В итоге, силой упорства и словесного воодушевления под контакты пролезла тонкая пластинка диэлектрика, энергозависимая память сбросилась, свитч ожил.
Исследование снятых с двух чипов дампов показало много интересного. В частности – огромное количество «Invalid» записей в NVRAM основной прошивки и несколько подобных в резервной. Ну и не встречавшуюся ранее мешанину данных в томе с DXE драйверами. О точной причине проблемы старта свитча оставалось только гадать.
Вообще, программная часть редко бывает лишена своих неожиданных нюансов. Многие попавшиеся нам платы до 87-го чипсета (разных производителей) имеют неприятную особенность выдавать бесконечный поток ошибок при вводе команды «dh -v» в консоли shell'a. При ручном вводе это не критично, но при сборе данных в файл это оканчивается досадным зависанием. В обоих случаях приходится перезагружать машину. Радует, что при этом файл с данными не распухает до необъятных размеров.
Очень своенравным показал себя BIOS ПК Kraftway с платой ASRock H81M-DGS. Так, на Ctrl Alt Del он реагирует зависанием, из которого его может вывести только Reset. Были проблемы и с пропуском в Shell’e загрузочного скрипта – доли секунды на выбор вместо пяти положенных по умолчанию. Возможно, эти проблемы вызваны модификацией фирменными модулями KSS, возможно, дело в неаккуратно «отвинченном» МЕ.
На плате Asus H97-PLUS в прошивке имеется следующая особенность – со временем переполняется BootOrder. Скорее всего, причина кроется в ошибках в коде. Хотя, может быть, производитель хотел сохранять все загрузочные устройства, когда-либо подключавшиеся в плате, но не рассчитал, что их может быть больше десятка за один день. Так вот, когда BootOrder переполняется, происходит зависание системы в процессе загрузки. Для его очистки необходимо отключить все загрузочные устройства и включить систему. Прошивка очищает себя, и система загружается напрямую в оболочку BIOS Setup. Работоспособность сохраняется до следующего переполнения.
Обобщая опыт работы с платами различных вендоров, приходишь к выводу, что практически невозможно узнать, с какими неожиданностями на уровне EFI будешь иметь дело на следующей плате, даже если у неё уже известная модель. Это своего рода лотерея, ведь иногда и на этапе сбора информации о системе могут возникнуть трудности. Возможно, в этом есть доля неугасающего исследовательского идеализма и веры в производителя, ведь как иначе могут вызывать удивление случаи зависания некоторых наисвежайших плат с ME v11 и v12 при запуске на них FPT или MEInfo старших версий?
Проблематика работы с аппаратными протоколами
Отдельные проблемы всплывают, когда начинаем работать с USB-устройствами – накопителями и токенами. Происходит это зачастую потому, что код BIOS для работы с периферией – это опасный коктейль из драйверов и приложений от Independent Hardware Vendor (IHV) под конкретную периферию, кода от производителя чипсета (в нашем случае – от Intel), кода от производителя BIOS и кода от производителя материнской платы.
Возникали следующие «интересные» ситуации:
Токен «не обнаружен». При этом на нём горит LED. Вероятно, не проходит процедура начального сброса USB-устройства хост-контроллером, то есть питание подано, но сброс через изменение линий D+ и D- не отрабатывает правильно, а без него любые дальнейшие манипуляции с токеном бессмысленны.
Компьютер зависает до загрузки shell (опять же при подключенном токене). При этом без токена ПК нормально стартует. Вживую это выглядит следующим образом: компьютер кажется зависшим сразу после старта, пока токен торчит в разъёме. Вынимаешь его – загрузка внезапно продолжается. Подключаешь – снова висит. Явная проблема в UEFI, и о причинах можно только гадать.
Ситуация, когда невозможно открыть интерфейс USB_IO. Возможно, связана только с интерфейсом для работы со смарт-картами – USB CCID. Некий драйвер AMI уже открыл USB_IO c параметром EFI_OPEN_PROTOCOL_BY_DRIVER. Драйвер имеет протокол с GUID:
Однако при этом не будет вызван BindingStop(), т.е. событие извлечения устройства не отслеживается, и драйвер будет пытаться пользоваться invalid handle. Такое наблюдалось с ПК HP Compaq Elite 8300 SFF и с некоторыми другими. Это или своеобразная защита вендора от нежелательных драйверов, или обычный баг разработки. Возможно, в AMI постоянно что-то делают в направлении USB CCID, но мешающий драйвер не выгрузить, так как он находится в одном модуле «AMI UHCI» вместе с USB HID, USB MassStorage. С UninstallInterface() дела обстоят похожим образом.
Или другая интересная особенность. В одном из UEFI BIOS, где токен не обнаруживался, USB_IO позволял зачитать дескрипторы устройства, но на следующий UsbBulkTransfer() возвращалось EFI_INVALID_PARAMETER. Причем, такое происходило только с некоторыми типами токенов, с абсолютно теми же параметрами другие работали отлично.
Вообще, в протоколе EFI_USB_IO_PROTOCOL интересно реализован метод UsbBulkTransfer(). Он предназначен для гарантированной доставки пакета за неограниченное время, или за время, указанное в параметре Timeout. Но был проведен эксперимент с MassStorage устройством: при копировании большого файла на флешку она извлекалась. ПК зависал намертво. При подключении флешки ПК отвисал и продолжал писать файл как ни в чем не бывало. Та же ситуация была и с токенами, но со своей спецификой. Это проблема архитектурная, в EFI нет прерываний кроме таймера, а устройства работают по опросу. То есть система зависла где-то в опросе USB, но до выхода по таймауту не дошла, при повторном появлении устройства просто продолжила и завершила операцию.
Виртуализация
Ещё один небольшой камень в огород VMware – встроенный в нее драйвер FAT32 поддерживает создание и редактирование файлов только в нотации 8.3. Непонятно, зачем это было сделано, но это ограничение, явно требующее внимания. Вполне вероятно, схожую реализацию драйвера можно пронаблюдать и на реальных платформах, но пока таковые нам не попадались.
С другой стороны, в виртуалках никаких танцев с утилитами прошивки, программаторами, джамперами, неудобными чипами. Отдельный ROM-файл, UEFITool и строчка в конфиг-файле. Почти идиллия.
Напоследок
Кусочек запроса из CHIPSEC. Где учат таким таинствам?
Как уже было сказано, разработка и внедрение в оболочке UEFI – процесс увлекательный и креативный. Всегда можно столкнуться с чем-то новым даже на известном поле. С одной стороны, радует, что стандарт развивается, с другой – огорчает, что конкретные его реализации производителями получаются слишком «творческими».
Основными проблемами были и остаются:
- Отход вендоров от спецификации UEFI при разработке прошивки.
- Ошибки в коде при реализации.
- НДВ в коде, всплывающие при интеграции.
Следует отметить, что ситуация медленно, но верно исправляется, и хочется верить, что не за горами тот момент, когда разработка под стандарт станет достаточно прогнозируемым и весьма приятным процессом.
Владимир Онипчук,
Руководитель группы программно-аппаратных средств защиты
ООО «Газинформсервис»
Что такое CSM и как вы можете использовать его, чтобы получить максимальную отдачу от вашего компьютера? Я рассмотрю этот вопрос и всё остальное, что вам нужно знать о CSM, в этой статье.
Лучшее управление программным обеспечением
Некоторые настройки UEFI, такие как порядок загрузки, могут быть изменены операционной системой напрямую.
Это позволяет вам реализовать такие вещи, как «выключение и перезагрузка с компакт-диска» из операционной системы, без необходимости входа в пользовательский интерфейс прошивки.
Что делать, если я устанавливаю первую ОС на новую машину
Вы можете задаться вопросом, какой режим загрузки лучше подходит для установки вашей операционной системы.
Во-первых, вы должны проверить, есть ли у вас возможность установки как с UEFI, так и с BIOS.
Это включает в себя перезагрузку компьютера и нажатие необходимой клавиши для входа в режим настройки BIOS или UEFI (обычно клавиша DEL или F2)
После входа в настройки BIOS/UEFI найдите параметры «Режим загрузки», которые можно переключать между «UEFI», «Legacy» или «UEFI + Legacy».
Она также может называться Включить загрузку UEFI или Включить устаревшую загрузку. Может даже упоминаться термин CSM или модуль поддержки совместимости.
Если в вашем BIOS/UEFI нет таких опций, ваша материнская плата не поддерживает CSM.
При установке новой операционной системы можно придерживаться любого режима загрузки прошивки. Если у вас действительно есть доступные варианты CSM, я рекомендую сначала попробовать UEFI, и если это не сработает, вы можете использовать CSM для установки своей ОС.
Читайте также:
- Вероятность правильного измерения с помощью компьютерного теста уровня усвоения учебного материала
- Нужен ли бортовой компьютер на шевроле ниву
- Перед включением компьютера и другой техники необходимо проверить исправность шнуров электророзеток
- Wordpress не видит загруженные файлы
- Не удалось переименовать файл asterios msxml4 dll