Комментарии 15
Шёл 2020 год, люди продолжали воевать с SecureBoot — единственной своей защитой от вредоносных ором-ок…
Драйвер файловой системы (не ограничиваться же родным efi-шным FAT?)И быть взломанным через воткнутый накопитель, ФС которого специальным образом испорчена. Нет, чем меньше в прошивке драйверов ФС, тем спокойнее.
Я согласен с общим посылом, на самом деле, хоть и горячо приветствую и получение опыта модификации UEFI, и написание статей вроде этой о том, на какие грабли пришлось наступить.
Опять же как основному автору UEFITool мне приятно видеть, что программа до сих пор активно используется даже несмотря на отсутсвие значимого прогресса в ее разработке после 2015 года.
С другой стороны, настоящую безопасность очень редко получается обеспечить добавлением кода, особенно если этот код в каком-то смысле чужеродный. Microsoft и Apple планомерно гонят всякие антивирусы и прочих любителей воткнуть драйверца из ядра их ОС поганой метлой, и правильно делают.
Здесь же у нас выходит чужой АПМДЗ, для которого нужно прошивку оригинальной платы переделывать и потом запрещать обновления этой самой прошивки на оригинальные. Понятно, что у авторов не было возможности делать собственные платы или разрабатывать решение вместе с ОЕМом, а решать вопрос требовалось в таки или иначе, и они его решили — честь и хвала, но сам подход я порекомендовать все-таки не могу — слишком много любви вприсядку, на мой взгляд.
Опять же как основному автору UEFITool мне приятно видеть, что программа до сих пор активно используется даже несмотря на отсутсвие значимого прогресса в ее разработке после 2015 года.
С другой стороны, настоящую безопасность очень редко получается обеспечить добавлением кода, особенно если этот код в каком-то смысле чужеродный. Microsoft и Apple планомерно гонят всякие антивирусы и прочих любителей воткнуть драйверца из ядра их ОС поганой метлой, и правильно делают.
Здесь же у нас выходит чужой АПМДЗ, для которого нужно прошивку оригинальной платы переделывать и потом запрещать обновления этой самой прошивки на оригинальные. Понятно, что у авторов не было возможности делать собственные платы или разрабатывать решение вместе с ОЕМом, а решать вопрос требовалось в таки или иначе, и они его решили — честь и хвала, но сам подход я порекомендовать все-таки не могу — слишком много любви вприсядку, на мой взгляд.
Тут речь скорее о том, что зачастую в хранилище сертов Secure Boot'а лежат майкрософтовский серт и серт вендора, а душа просится в рай Unix. Есть, конечно, пару изящных решений этого вопроса (как говорится, Shim вам в помощь, да и в само хранилище сертификатов зачастую можно добавить желанный открытый ключ), но вопрос для обывателя ведь еще и в скорости решения.
Отключил Secure Boot -> обрел свободу -> ослабил безопасность системы (а вдруг нет?)
Отключил Secure Boot -> обрел свободу -> ослабил безопасность системы (а вдруг нет?)
Хорошая статья, спасибо.
У меня по результатам работы с большим объемом прошивок примерно те же мысли: на проверку совместимости (и потому и саму совместимость) со стандартом почти все плюют (им нужно платы выпускать в срок, а не прошивку вылизывать до идеального состояния), везде расставлены всякие интересные грабли, причем у разных вендоров расположение граблей отличается, документация если и есть какая-то, то она или утекшая Intel Confidential, или бесполезная, и т.п.
У меня по результатам работы с большим объемом прошивок примерно те же мысли: на проверку совместимости (и потому и саму совместимость) со стандартом почти все плюют (им нужно платы выпускать в срок, а не прошивку вылизывать до идеального состояния), везде расставлены всякие интересные грабли, причем у разных вендоров расположение граблей отличается, документация если и есть какая-то, то она или утекшая Intel Confidential, или бесполезная, и т.п.
Импорт модулей в прошивку выполнялся средствами утилиты UEFITool, и мы наткнулись на интересный баг: если вставить модули ffs в конец тома DXE, после всех freeform, то собранный образ «кирпичил» плату. Выходом было добавлять модули после любого родного DXE драйвера.Интересно было бы разобраться, что именно там не так с томом или с DXE Core.
Позже стало понятно, что без автоматической утилиты импорта модулей не обойтись, и проблема сошла на нет после написания оной.Если в вашей утилите можно провернуть то, что нельзя сделать в UEFITool — это может быть багом, и о нем стоило бы сообщить разработчикам.
Ещё в нашей практике посчастливилось наткнуться на два мини-компьютера с Intel Bay Trail D и 32-разрядной прошивкой на борту. Случай редкий, но в своё время вызвал необходимость экстренно перекомпилировать модули. Собственно, как и вопрос: встретимся ли мы с более современной платформой такой же разрядности в будущем? А если встретимся, то где?Упаси вас рандом, доктор сказал в морг — значит в морг. Зато в недалеком будущем можете встретиться с UEFI для архитектур отличных от x86 (ARM, RISC-V), и там у них тоже весело и задорно.
Работает почти безотказно, за исключением некоторых старых моделей HP, где микруха SOIC-16 с прошивкой находится в такой доступности, что проще исхитриться и припаять к ее ногам переходник, чем протискивать клипсу.И тут Microsoft Surface такой врывается со своими флешами в корпусе TFBGA24! Хорошо хоть к тестовым точкам можно цепляться и там.
Иногда бороться с защитой от записи помогает парсер IFR, приоткрывающий нам завесу над скрытыми настройками и переменными.Наглым образом прорекламирую свой парсер IFR, он в некоторых местах парсит лучше, особенно новые прошивки с UEFI 2.5+
Исследование снятых с двух чипов дампов показало много интересного. В частности – огромное количество «Invalid» записей в NVRAM основной прошивки и несколько подобных в резервной. Ну и не встречавшуюся ранее мешанину данных в томе с DXE драйверами. О точной причине проблемы старта свитча оставалось только гадать.Большое количество записей Invalid — это нормально для железа, которое работало долгое время, и потому уборка NVRAM от мусора делалась в последний раз еще при царе Горохе. Мешаниной в томе DXE может быть недавно исправленный баг, при котором алгоритм сжатия LZMAF86 определялся как просто LZMA.
Про таинства МЕ простых ребят с улицы учит в основном coreboot и реверс-инжениринг. Грустно, но в общем-то неизбежно, пока Intel не видит связи между открытием документацией и увеличением прибыли, ничего не изменится.
А как дела у АМД? Есть там что-то наподобии ME? Простите, если вопрос глупый, но не приходилось ковырять АМДшные биосы, и новее Athlon64 ничего в руках не держал.
Дела у AMD с документацией открытой вроде бы сначала шли относительно неплохо, а потом они решили внедрять свой аналог МЕ — AMD Platform Security Processor (PSP), и все снова оказалось под замком. Вот тут хорошие ребята работают над его реверсом в данный момент.
Были проблемы и с пропуском в Shell’e загрузочного скрипта <startup.nsh> – доли секунды на выбор вместо пяти положенных по умолчанию. Возможно, эти проблемы вызваны модификацией фирменными модулями KSS, возможно, дело в неаккуратно «отвинченном» МЕ.Все гораздо проще — это настраивается, хоть и не по фэн-шуй (правкой исходников, а не PCD). Я вот здесь объяснял, как это сделать, в блоке «Ускоряем отладку дальше»
Отличный день! Вторая статья про важное!
За развитиемГУАШ(Punto что-то подозревает) UEFI настороженно слежу с самого появления, ибо не рад. В очередной раз меня убедили, что хакнуть можно всё. Успехов!
За развитием
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проблематика и особенности реализации UEFI на различных платформах