Новые аргументы в битве с настройками Insyde UEFI BIOS

Не так давно на Хабре была опубликована подробная статья о изменении скрытых настроек Insyde BIOS ^[1]. Не претендуя на лавры её автора и всех остальных людей работавших над темой (модифицировавших grub UEFI shell ^[2] и первопроходцев парсинга меню ^[3]), хочу описать несколько проблем (и способов их решения) которые могут возникнуть у желающих применить эту информацию на практике:

1. Невозможность получить расшифрованный дамп биоса
2. Некорректная работа grub-шелла (зависание после выполнения setup_var)
3. Невозможность изменить некоторые настройки

Стоит заметить всеми этими проблемами я лично столкнулся (и потратил на них немало усилий) в попытках активировать для SATA контроллера RAID режим вместо AHCI (для последующего включения Intel SRT ^[4]) на довольно свежем DTR ноутбуке HP Envy 17-j005tx (i7-4700MQ, 16gb, GT740M 2gb, 2x1000gb).

Проблема 1: Невозможность получить расшифрованный дамп биоса

И в статье на хабре ^[1] и в другим местах интернета единственным упоминаемым способом получения дампа расшифрованного (если он не зашифрован на сайте производителя то и проблемы нет) биоса для последующей распаковки и парсинга меню является модификация файла platform.ini ^[5] в папке прошивальшика.

К сожалению на моем ноутбуке (и практически уверен что и на всех остальных новых моделях от HP) этот способ уже не работает — подозреваю что биос закрыли для чтения даже для собственного прошивальшика во избежание проблем в будущем. Все попытки изменения .ini файла и запуска прошивальника приводят к одному результату (что на оригинальной x64 Win 8, что из под PE x32/x64 дистрибутивов, т.е. проблема не в системе) — ошибке «IHSI: flash read error in SMI!» (для гугла). Кстати не пугайтесь, увидев такое перезагрузить ноутбук вы сможете только отключив питание и достав батарейку:

^[6]

Но, что важно, сама прошивка BIOS-а происходит (обычно) при этом не напрямую, а с использованием UEFI — т.е. прошивальшик передает образ BIOS UEFI утилите (как оказалось уже расшифрованный), и нам осталось лишь найти где он хранится. Возможно вы уже обращали внимание на несколько небольших дополнительных скрытых разделов на основном HDD/SSD (и это помимо довольно крупного (24 GB, с исходником win8) видимого Recovery раздела), в моем случае они типа Recovery Partition (400mb) и EFI System Partition (260mb, он то нам и нужен). Вот только беда — стандартным Disk Management вы этим разделам буквы не назначите — на то они и системные, впрочем гугл и командная строка нас как обычно спасают (выполнять обязательно из под аккаунта администратора, и лучше сразу из файлового менеджера, например незабвенного FAR ^[7]):

mountvol X: /S

После этого открываем диск X:, и ищем что-нибудь похожее на BIOS. В моем случае все оказалось довольно прозаично и в папке X:EFIHPBIOS нашлось три под-папки Current, New и Previous с искомым содержимым (01966.bin магический образованный прошивальшиком из 01966.fd). Дальше — все как в статье, распаковываем, парсим, и т.д.

Напоследок замечу что в отличии от чтения прошивальшик не потерял возможность писать BIOS и напрямую даже из под Win8 x64. Узнал я об этом правда печальным способом, пытаясь прошить файлик из оригинального комплекта, но под другую платформу. Надо отдать должное HP — восстановление правильного биоса произошло в течении минуты (мне хватило поседеть ещё +1%) в полностью автоматическом режиме, правда одно последствие осталось — Win8 перестала загружаться в Secure Boot режиме.

Проблема 2: Некорректная работа grub-шелла (зависание после выполнения setup_var)

Узнав заветные адреса переменных которые вам нужно поменять, скопировав grub-шелл на флешку и удачно запустив его (все описано в статье ^[1]) вы можете столкнутся с ещё одной проблемой — каждое выполнение setup_var (неважно на чтение или запись) будет приводить к зависанию ноутбука (в моем случае лечилось только извлечением батарейки). Причина была найдена только путем анализа исходника патча ^[8] для добавления комманды setup_var в grub — банальный buffer oveflow. Автор писал утилиту ^[2] под себя (свой лэптоп), и не рассчитывал что переменная Setup может иметь размер больше чем 0x2bc (а она читается целиком в память, и в моем случае составляла например 0x4ae байт). Можно сказать что всем удачно использовавшим утилиту на протяжении 4 лет довольно сильно повезло — с таким багом можно было получить намного больше проблем (например запись мусора в CMOS) чем просто зависание ноутбука.

Для тех кому «ехать» (т.е. справится с проблемой): качаем пересобранную BootX64.EFI ^[9], кладем как обычно в EFIboot, используем команду setup_var как и в оригинальной версии. Для упорных бонус-трэк: дополнительная команда setup_var2 (меняет значение не только в переменной Setup, но и в переменной Custom, зачем чуть ниже) и lsefivar (выводит список всех доступных переменных, приостанавливать вывод можно break-ом).

Наличие этих двух дополнительных команд объясняется просто: сражаясь с непокорным биосом я обнаружил наличие дополнительной переменной Custom с таким-же GUID и размером как и переменная Setup. Т.к. в тот момент мне не удавалось изменить значение одной опции (подробнее в третей части) — то была надежда чего-то достичь поменяв его в переменной Custom. Успехом эти усилия не увенчались, а команды пусть будут, на память.

Не пугайтесь размеру .EFI образа (2.5mb) — мне было лениво выбирать необходимые модули grub, поэтому они там все — отсюда и размер.

Для недоверчивых и просто любопытных инструкция как повторить мой путь, ну или собрать свой grub:

1. Качаем исходники свежего grub2 (trunk ^[10] на тот момент не собирался, я использовал grub-2.00+20130519 ^[11]).
2. Применяем мой патч ^[12] или фиксим и адаптируем авторский ^[8] (смешно, но лично я около часа времени убил на проблему с grub: incompatible license, и даже гугл не помог — решается добавлением GRUB_MOD_LICENSE(«GPLv3+»); в исходник).
3. Собираем EFI образ grub. Подробно описано здесь ^[13]. Единственное замечание по grub-mkimage, правильная строчка (если включать все модули):

   ../grub-mkimage -d . -o bootx64.efi -O x86_64-efi -p /efi/boot `find *.mod | xargs | sed -e 's/.mod//g'`
   

Упомяну ещё UEFI shell из проекта Tianocore ^[14] (качать EFI 1.0 Shell Full ^[15] или EDKII UEFI Shell 2.0 ^[16], но первая версия у меня работала стабильнее) — весьма удобная штука, имеет доступ и к EFI и к файловой системе (необходимый диск находим проверяя с помощью ls по очереди fs0:, fs1:, и т.д.), может выполнять другие EFI приложения, а так же сохранять значения EFI переменных (самое для нас важное) с помощью команды dmpstore. Про её команды можно для завтравки почитать тут ^[17] или тут ^[18], пример использования в наших целях (сохраняет целиком значение переменной Setup в fs1:setup_dumpsdump1.bin):

fs1:
cd setup_dumps
dmpstore Setup -s dump1.bin

Только учитываете что в дамп переменной добавляется заголовок переменной длины, для Setup смещение относительно индексов из меню и команды setup_var составляет 0x28).

Хочется добавить что BIOS на моем ноутбуке позволяет загружать не только файл BootX64.EFI из папки EFIboot, но и любой .EFI файл из любой папки почти любого носителя (опция Boot from EFI file, спасибо HP). В принципе ту же функциональность можно получить использованием UEFI шелла и загрузкой остальных EFI приложений из него, но тем не менее.

Проблема 3: Невозможность изменить некоторые настройки

В процессе ваших попыток изменения скрытых настроек BIOS вы можете столкнутся с тем что самые необходимые вам настройки не будут менятся, возвращаясь в исходное состояние после перезагрузки (переинициализации BIOS). К сожалению вендоры могут добавлять в биос свой код, который будет проверять наличие оборудования, серийный номер, или ещё какие-либо параметры и в зависимости от этого автоматически восстанавливать настройки на исходные значения. Причем сделано это будет не назло нам (спрятаных из BIOS меню хватает для защиты от дурака), а просто для того чтобы использовать одну и ту же платформу и один и тот же BIOS для разных конфигураций ноутбуков. И если вы пытаетесь поменять эти настройки только для того чтобы выяснить сможет лишь ваш ноутбук работать с новым железом (скажем mSATA модуль) — то тогда возможно стоит рискнуть, купить и установить его. Возможно вам повезет и магические настройки сами появятся или изменятся, как по щучьему велению.

Чтобы не быть голословным приведу свою историю: в моем случае такой злаполучной опцией стало 0x39 — HDC Configure As IDE / AHCI / RAID, которую никакими усилиями не удавалось поменять на значение 0x2 (RAID). Нужно мне это было только по одной причине — чтобы добавив в ноутбук mSATA SSD модуль подключить его в качестве кэша в виде Intel SRT ^[4]. При этом наличие mSATA разъема ни в спецификациях ни в сервисном мануале вообще не описано, лишь на одной сильно размытой картинке из манула есть что-то похожее, но чтобы к нему добраться нужно наполовину разобрать шасси (а не просто снять заднею крышку). Теперь вы наверное понимаете мои сомнения — нужно покупать не копеечный SSD (был выбран кстати Toshiba 128GB — THNSNH128GMCT, радующий тестами ^[19], и в последствии разбитый как 1/2 iSRT, 1/4 over provisioning, 1/6 volume), разбирать наполовину ноутбук (купленный фирмой неделю назад, т.е. почти наверняка теряя гарантию), и даже если повезет с разъемом, то не факт что когда-нибудь удастся включить опцию RAID в BIOS. Надежду давало лишь то, что в США HP позволяет выбирать конфигурацию таких ноутбуков (при этом все они используют один и тот же биос), в том числе и добавляя 24gb или 32gb SSD Cache, правда при этом ограничивая максимальный обьем памяти 8gb (зачем?). Результат сомнений ниже (разъем в зеленой рамке):

^[20]

Производитель (HP) не подвел, первое включение и магическая опция сразу обнаруживается на месте, там где её ещё несколько минут назад не было (т.е. несколько дней неторопливой возни c setup_var на смарку):

Напоследок хочу ещё заметить радостное — в отличии от всех описаний в интернете, Windows 8 вообще не заметила изменение AHCI режима на RAID, лишь в Device manager контроллер поменял название с SATA AHCI Controller на SATA RAID Controller. Заслуга это GPT, самой Windows 8, или Intel — не знаю, и не очень задаюсь этим вопросом — просто наслаждаюсь преобразившейся (без какого либо геморроя) скоростью работы системы.

Disclaimer. Всю информацию из статьи вы используете на свой страх и риск. Проверьте, пожалуйста, что у вас есть средства восстановления BIOS и его настроек до того как будете проводить какие либо эксперименты.

Автор: brainsucker

Источник ^[21]