Заранее отвечу про широко известного в узких кругах слона в комнате с Т2 — checkm8. Проблема известна, решение разрабатывается, о подробностях или сроках говорить не уполномочен, прошу пардону.
Почему загрузчик который показывает меню ввода пароля для FileVault не может загрузить recoveryOS?
Из за гарантий безопасности у пароля на прошивку: «Пароль на прошивку требуется для загрузки любой ОС, кроме основной (в том числе recoveryOS)». Если разрешить загрузку recoveryOS в гостевой режим без пароля, то любой эксплоит (потенциально сильно устаревшего) Safari передаст полный контроль атакующему. Именно поэтому при установке пароля не работает BootPicker, TDM и все остальное, отлично работающее без него.
Нет, все верно. Пароль на прошивку требуется для загрузки любой ОС, кроме основной (в том числе recoveryOS). Более того, утилитой firmwarepasswd можно включить еще более строгий режим, при котором пароль спрашивают при каждой загрузке независимо ни от чего другого.
Также установка пароля на прошивку по умолчанию отключает загрузку OptionROMов с любых устройств (это тоже можно настроить вышеупомянутой утилитой).
Дела у AMD с документацией открытой вроде бы сначала шли относительно неплохо, а потом они решили внедрять свой аналог МЕ — AMD Platform Security Processor (PSP), и все снова оказалось под замком. Вот тут хорошие ребята работают над его реверсом в данный момент.
Я согласен с общим посылом, на самом деле, хоть и горячо приветствую и получение опыта модификации UEFI, и написание статей вроде этой о том, на какие грабли пришлось наступить.
Опять же как основному автору UEFITool мне приятно видеть, что программа до сих пор активно используется даже несмотря на отсутсвие значимого прогресса в ее разработке после 2015 года.
С другой стороны, настоящую безопасность очень редко получается обеспечить добавлением кода, особенно если этот код в каком-то смысле чужеродный. Microsoft и Apple планомерно гонят всякие антивирусы и прочих любителей воткнуть драйверца из ядра их ОС поганой метлой, и правильно делают.
Здесь же у нас выходит чужой АПМДЗ, для которого нужно прошивку оригинальной платы переделывать и потом запрещать обновления этой самой прошивки на оригинальные. Понятно, что у авторов не было возможности делать собственные платы или разрабатывать решение вместе с ОЕМом, а решать вопрос требовалось в таки или иначе, и они его решили — честь и хвала, но сам подход я порекомендовать все-таки не могу — слишком много любви вприсядку, на мой взгляд.
Про таинства МЕ простых ребят с улицы учит в основном coreboot и реверс-инжениринг. Грустно, но в общем-то неизбежно, пока Intel не видит связи между открытием документацией и увеличением прибыли, ничего не изменится.
Исследование снятых с двух чипов дампов показало много интересного. В частности – огромное количество «Invalid» записей в NVRAM основной прошивки и несколько подобных в резервной. Ну и не встречавшуюся ранее мешанину данных в томе с DXE драйверами. О точной причине проблемы старта свитча оставалось только гадать.
Большое количество записей Invalid — это нормально для железа, которое работало долгое время, и потому уборка NVRAM от мусора делалась в последний раз еще при царе Горохе. Мешаниной в томе DXE может быть недавно исправленный баг, при котором алгоритм сжатия LZMAF86 определялся как просто LZMA.
Работает почти безотказно, за исключением некоторых старых моделей HP, где микруха SOIC-16 с прошивкой находится в такой доступности, что проще исхитриться и припаять к ее ногам переходник, чем протискивать клипсу.
И тут Microsoft Surface такой врывается со своими флешами в корпусе TFBGA24! Хорошо хоть к тестовым точкам можно цепляться и там.
Ещё в нашей практике посчастливилось наткнуться на два мини-компьютера с Intel Bay Trail D и 32-разрядной прошивкой на борту. Случай редкий, но в своё время вызвал необходимость экстренно перекомпилировать модули. Собственно, как и вопрос: встретимся ли мы с более современной платформой такой же разрядности в будущем? А если встретимся, то где?
Упаси вас рандом, доктор сказал в морг — значит в морг. Зато в недалеком будущем можете встретиться с UEFI для архитектур отличных от x86 (ARM, RISC-V), и там у них тоже весело и задорно.
Импорт модулей в прошивку выполнялся средствами утилиты UEFITool, и мы наткнулись на интересный баг: если вставить модули ffs в конец тома DXE, после всех freeform, то собранный образ «кирпичил» плату. Выходом было добавлять модули после любого родного DXE драйвера.
Интересно было бы разобраться, что именно там не так с томом или с DXE Core.
Позже стало понятно, что без автоматической утилиты импорта модулей не обойтись, и проблема сошла на нет после написания оной.
Если в вашей утилите можно провернуть то, что нельзя сделать в UEFITool — это может быть багом, и о нем стоило бы сообщить разработчикам.
У меня по результатам работы с большим объемом прошивок примерно те же мысли: на проверку совместимости (и потому и саму совместимость) со стандартом почти все плюют (им нужно платы выпускать в срок, а не прошивку вылизывать до идеального состояния), везде расставлены всякие интересные грабли, причем у разных вендоров расположение граблей отличается, документация если и есть какая-то, то она или утекшая Intel Confidential, или бесполезная, и т.п.
Верно, но можно пока что не использовать QML, и кроме QtWidgets вам ничего не понадобится. У меня там QTreeView в качестве основного элемента интерфейса, а в QML он появился только в Qt 5.5.
Отнюдь. LGPL позволяет и статическую линковку, но при условии, что пользователь может заменить слинкованную библиотеку на свою. Т.е. если вы распространяете вместе со своим приложением его объектные файлы и инструкцию по линковке, LGPLv2 вы не нарушаете.
UEFITool NE (около 50 тыс. строк кода), собранный VS2017 для Windows статически с Qt 5.3.6 (последней версией под LGPLv2, с модулями QtCore, QtGUI и QtWidgets) занимает сейчас порядка 10 Мб. Собранный MinGW — порядка 20 Мб.
Кому именно должны?
МЕ конкретно основной системе вообще не должен ничего, кроме как по HECI отвечать и в том самом конфигурационном пространстве светиться, так что он вполне может уйти в глубокий сон, последующее пробуждение из которого снова пройдет через уязвимый ROM, и вот в этот самый момент (если его получится отловить) можно перехватить управление через ДМА-атаку прямо с хоста.
Также установка пароля на прошивку по умолчанию отключает загрузку OptionROMов с любых устройств (это тоже можно настроить вышеупомянутой утилитой).
Опять же как основному автору UEFITool мне приятно видеть, что программа до сих пор активно используется даже несмотря на отсутсвие значимого прогресса в ее разработке после 2015 года.
С другой стороны, настоящую безопасность очень редко получается обеспечить добавлением кода, особенно если этот код в каком-то смысле чужеродный. Microsoft и Apple планомерно гонят всякие антивирусы и прочих любителей воткнуть драйверца из ядра их ОС поганой метлой, и правильно делают.
Здесь же у нас выходит чужой АПМДЗ, для которого нужно прошивку оригинальной платы переделывать и потом запрещать обновления этой самой прошивки на оригинальные. Понятно, что у авторов не было возможности делать собственные платы или разрабатывать решение вместе с ОЕМом, а решать вопрос требовалось в таки или иначе, и они его решили — честь и хвала, но сам подход я порекомендовать все-таки не могу — слишком много любви вприсядку, на мой взгляд.
Если в вашей утилите можно провернуть то, что нельзя сделать в UEFITool — это может быть багом, и о нем стоило бы сообщить разработчикам.
У меня по результатам работы с большим объемом прошивок примерно те же мысли: на проверку совместимости (и потому и саму совместимость) со стандартом почти все плюют (им нужно платы выпускать в срок, а не прошивку вылизывать до идеального состояния), везде расставлены всякие интересные грабли, причем у разных вендоров расположение граблей отличается, документация если и есть какая-то, то она или утекшая Intel Confidential, или бесполезная, и т.п.
Отнюдь. LGPL позволяет и статическую линковку, но при условии, что пользователь может заменить слинкованную библиотеку на свою. Т.е. если вы распространяете вместе со своим приложением его объектные файлы и инструкцию по линковке, LGPLv2 вы не нарушаете.
МЕ конкретно основной системе вообще не должен ничего, кроме как по HECI отвечать и в том самом конфигурационном пространстве светиться, так что он вполне может уйти в глубокий сон, последующее пробуждение из которого снова пройдет через уязвимый ROM, и вот в этот самый момент (если его получится отловить) можно перехватить управление через ДМА-атаку прямо с хоста.