Pull to refresh
313
0
Николай Шлей@CodeRush

Firmware Security Engineer

Send message
Падает потому, что драйвер SPI возвращает ошибку при верификации, и ошибка эта затем доходит до драйвера NVRAM, который из SetVariable возвращает либо EFI_DEVICE_ERROR, либо EFI_WRITE_PROTECTED. Оно не то, чтобы «должно падать», но опыт показывает, что падает. Понятно, что можно сделать написать NVRAM таким образом, чтобы он уживался с RO-флешем, и у AMI есть даже build token для такого режима, но если брать неадаптированную прошивку, она неизбежно упадет где-нибудь посреди фазы DXE, т.к. первая же SetVariable вместо ожидаемого EFI_SUCCESS вернет что-нибудь из вышеперечисленного.
В том то и дело, что корректно работать такая система не будет — упадет на первом же SetVariable, т.к. запись в NVRAM происходит при каждой загрузке (сохраняется последняя загруженная конфигурация, обновляется список загрузочных устройств, обновляется значение MonitonicCounter и т.п.). Чтобы справиться с этой проблемой, нужно либо заменять оригинальный драйвер NVRAM на такой, который на флеш вообще не пишет, либо сразу же загружать вышеупомянутый эмулятор CrEmuVariable, который подменит оригинальные сервисы GetVariable/SetVarible/GetNextVariableName/QueryVariableInfo собственными, и система будет работать. В таком режиме, понятно, тоже есть свои минусы, настройки из BIOS Setup не сохраняются, к примеру, но если все уже настроено — это работает.
Я тоже интересовался этой темой и у меня получилось защитить микросхему SPI от записи, но для этого нужно либо выносить NVRAM на отдельную микросхему, либо заниматься его эмуляцией. Режим QuadSPI можно отключить, но на работающей системе это будет сделать довольно непросто — придется патчить сразу в нескольких местах.
Всегда пожалуйста.
У меня тоже мое увлечение (переросшее потом в работу) началось со сломанной материнской платы, прошивка которой просто перестала стартовать после очередного обновления. Пришлось покупать прошитый чип на Ебее, но оказалось, что в этом чипе нет данных SMBIOS, и некоторый достаточно дорогой софт после замены отказался признать систему своей. Пришлось разбираться с восстановлением данных, по результату была написана утилита FD44Editor, потом пришлось соорудить комплект для прошивания (FTK), т.к. стандартные утилиты ASUS меня не устраивали, потом я устал от сложностей с PhoenixToot и сел писать собственный велосипед, и все заверте…
Софт этот называется HxD, это один из самых простых и маленьких хекс-редакторов для Windows с GUI. Есть гораздо более продвинутые редакторы вроде 010 Editor или WinHex, но мне хватало и этого всегда.
Основной подводный камень — цена такой системы будет заведомо выше, чем монолитной, плюс затраты на стандартизацию будут весьма ощутимыми, а нести их никто не захочет. Уже сейчас можно делать ноутбуки из модулей COM-Express/QSeven/SMARC/etc, и разрабатывать только носители, но такие системы толще и дороже одноплатных, плюс «свобода творчества» для производителя носителя там весьма ограничена, да любой коннектор — это дополнительный источник проблем с механикой при «боевой» эксплуатации.
У нас разное понимание «сделать», «будет работать» и «можно продавать», в таком случае.
Для меня «сделать плату» — это разработать для нее сначала схему, а затем разводку, выпустить прототипы, с их помощью портировать с CRB прошивку, добиться работы всех устройств, отладить крэши и несовместимости одних настроек с другими, провести EVT, выпустить прошивку, готовую к массовому производству, подготовить BSP и пакеты драйверов, выпустить pre-MP прототипы, провести их DVT и сертификацию, и наладить массовое производство.
«Будет работать» — все вышеперечисленное протестированно и выпущено отделом QA, тестировалось не менее 8 недель к ряду, все замеченные ошибки в железе, прошивке и BSP были справлены по ходу тестирования.
«Можно продавать» — сделано все вышеперечисленное, плюс готовы документация, сертификаты, складская и логистическая инфраструктура, финансы и все остальное.
51nb — пример прототипа, выброшеного на Ebay, больше ничего.
Для каждой страны — свои. В случае США это вышеупомянутая FCC, в случае UK — OFCom и Trading Standards Institute, и так далее. Если продажу несертифицированного товара обнаружат, сам товар будет конфискован, а причастные к его продаже оштрафованы. Если продавать десяток плат в месяц — можно не переживать, только тогда проект снова оказывается «голым энтузиазмом».
Я не хочу продолжать этот бессмысленный спор, если вам интересны проекты из подвала дядюшки Ляо, и вы их согласны покупать с Ебея без сертификатов и документации — ваше право, мне же такие платы даром не нужны, я от prototype-quality железа уже на работе успел устать.
Потому, что они собираются продукт продавать, а без сертификации сделать это легально невозможно — регуляторы не выпустят несертифицированную плату на рынок. Если же все делается «для себя, на коленке» — слишком много денег и усилий придется потратить, проект не окупится никогда.
Не хотите верить — не надо, но я цену тоже взял не с потолка. То, что китайцы готовы сделать EDMS-дизайн чуть ли не за миску риса, судя по рекламе — это все прекрасно, только вот и качество будет соответствующее. Плюс потом надо будет продать не менее 10к плат, чтобы НИОКР и производство окупить в ноль. Могу сказать, что только DVT и сертификация у FCC, EC и РосТеста будет стоит тысяч примерно 20 при наличии необходимого оборудования и специалистов, а без нее конечному потребителю платы продавать не позволят.
Видимо, Motherboard Design Guide, BIOS Writer Guide и остальные вещи с IBP, PlatformSW и ARC-CARE. Только вот не имея опыта, нормальную плату все равно не развести, там миллион подводных граблей, а за 5к китайцы вам разведут такое, что лучше даже не пробовать — напрасно деньги потратите.
Хорошая плата и прошивка меньше чем 200к долларов стоить просто не могут, ибо в их производстве задействованы несколько высокооплачиваемых специалистов, плюс доступ к документации и технической поддержке тоже далеко не самый дешевый.
Это такой каламбур неудачный про то, что там были части первая, полуторная, и вторая. Я согласен с тем, что «три — это куча, а два — это не куча», но оставлю так.
Совершенно реальные, а по суффиксам в именах даже можно догадаться, с каких систем взяты.
Про выравнивание переменных я упоминал, там его нет во всех случаях, кроме гипотетического IA64, но я реальных образов с таких машине не видел, только сборки QEMU + TianoCore, там выравнивание есть и оно по восьмибайтовой границе. По упаковке — все пакуется наиболее плотно.
Разбор происходит следующим образом: если есть доступ к машине, то можно получить имена, GUIDы, аттрибуты и данные переменных, просто читая их последовательным вызовом UEFI runtime — функций GetNextVariableName и GetVariable. В итоге половина данных уже есть и их можно затем найти в дампе, остается угадать формат заголовков и значения некоторых аттрибутов, тут помогает открытый код проектов TianoCore, CHIPSEC, плюс некоторые добрый люди в сообществе, вроде тов. xvilka, иногда делятся своими соображениями или даже кодом.
Если же доступа нет, то либо стоит им разжиться, либо просишь дампы прошивки и вывод команды dmpstore и играешь в угадайку по ним.
Зато так можно отладить эту самую подстветку без танцев с программатором, а потом уже можно исправить оригинальную DSDT, когда уже будет понятно, что новый код работает правильно.
Lenovo большие молодцы в этом смысле, они портируют исправления новых проблем на старые системы, но даже в последней версии для X220 виден PEI-модуль PchS3Peim внутри сжатой секции, и если этот драйвер используется так, как я думаю (даю 95% шанс, что это именно так), то одна из уязвимостей в S3 BootScript в этой прошивке по прежнему не исправлена.
В общем, они хорошо умеют исправлять то, на что им указывают, но сделать сами шаг или два вперед — пока не могут. Толи специалистов не хватает, толи желания. А у Dell получается.
Да там из костылей только код ACPI для подсветки поправить немного, а сделать это можно либо любым нормальным UEFI-загрузчиком (тем же Clover), либо ядром Linux 4.4+, которое научили грузить SSDT, ЕМНИП, т.е. BIOS править не обязательно.
Добавлю со своей UEFI-колокольни об упомянутых современных машинах для плодотворной работы с кодом: с точки зрения прошивки лучшие машины сейчас делают Dell и HP, на второе место я бы поставил Lenovo, которые тоже относительно неплохи, но не без греха, да еще и с SuperFish и WPBT оскандалится умудрились. У Apple сейчас пока еще все очень грустно, но уже в следующем поколении MBP они обещают решить проблемы с защитой от вредоносных OptionROMов, с защитой от подмены загрузчика, с защитой от DMA-атак и с отсутствием HW root-of-trust или хотя бы чипа TPM 2.0 для measured boot.
В общем, если покупать прямо завтра, я бы купил систему у Dell. Они уже и ESRT внедрить успели, и обновления прошивки через репозитории fwupdate распрострают, и BootGuard на них включен и протестирован.
Давненько я не брал в руки шашек не писал длинных русских текстов, если найдете очепятку — пишите в Л/С, постараюсь исправить.
А если модуля нет, его можно добавить. Понятно, что legacy-загрузку таким способом не обеспечить, но она сейчас все-таки мало кому нужна.
Я вам про ветряную мельницу уже ниже ответил. Никто утверждение "для описания реальности нужны НЕ ТОЛЬКО формулы" не оспаривает, вот с высказыванием вроде "формулы — ну нужны" спорили, спорят, и спорить будут. И эти два высказывания — совсем не одно и то же.

Information

Rating
Does not participate
Date of birth
Registered
Activity

Specialization

Инженер встраиваемых систем, Системный инженер
Ведущий