Ещё в нашей практике посчастливилось наткнуться на два мини-компьютера с 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, и вот в этот самый момент (если его получится отловить) можно перехватить управление через ДМА-атаку прямо с хоста.
Если делать полный ресет — будет, а если нет? Там сейчас всяких ресетов разных видимо-невидимо, а на PCH есть такое отличное устройство Integrated Sensor Hub, к которому пользователь может написать свою прошивку собственную.
Понятно, что это все — страшно дорогая целевая атака, которую нет смысла даже пытаться применять по площадям против условного слесаря Васи (фишинг и рассылка вирусов отлично работают там уже, сложнее ничего не нужно), и статья больше про «это потенциально возможно сделать при условии что А, Б, Ц и звезды верно сошлись», чем про «любое повышение прав до рута позволяет взломать МЕ полностью и любить в нем гусей до старости лет». Тем не менее, баг отличный, и статья отличная, и пацаны — вообще ребята, пусть ищут и пишут еще.
Там сейчас к шине столько всякого хлама подключено, что задирать шину выше +5-10% чревато очень неприятными глюками в самых неожиданных местах вроде контролеров дисков или даже питания. Запрещают этот разгон нынче больше по старой памяти, чем по объективным маркетинговым причинам, на мой взгляд.
Далеко не все защищенные дисковым шифрованием машины имеют физические устройства ввода, и далеко не все таковые устройства имеют программируемые контролеры, пригодные для перехвата секрета из них. При этом интерпозер для SPI/LPC может быть сделал в виде платы размером с ноготь и установлен незаметно в корпус вашего выделенного сервера злонамеренным администратором дата-центра. Короче, если у вас физическая атака вне модели угроз — то внешний TPM может быть лучше внутреннего (он проще, интерфейс к нему стандартизирован, выпускают их разные производители, и потому при потере доверия к одному из них можно перейти на другого), а там, где таковая атака вероятна, внутренний TPM может быть лучшим выбором, плюс он еще и бесплатный зачастую.
В этом сегменте AMD очень долгое время был аутсайдером, и потому у многих вендоров просто нет своих специалистов по работе с их APU, а без таковых платы получаются или жручие, или падучие, или греющиеся как печка.
Те, кто в свое время не перестал выпускать продукцию на AMD (даже если она получалась не очень прибыльной, HP, например) теперь могут быстро наладить выпуск, а не кто залез в Intel с головой теперь думают, где бы им людей нанять срочно вчера, найти нужные (или восстановить утерянные) контакты с AMD, и проверить свои контракты с Intel на предмет подводных камней и троянских коней, чтобы потом не отдать им всю прибыль от продажи чужих процессоров в суде.
Зато значительно проще физически, потому что шина, к которой подключен отдельный TPM — либо LPC, либо SPI, и обе они и низкоскоростные, и старые достаточно, чтобы интерпозер для них имелся у любого минимально подготовленного атакующего.
Хороший встроенный TPM нужно было делать на отдельном кристалле внутри SoC, а не запускать его в виде процесса вместе с еще 2 мегабайтами всякого хлама, и его бы не сломали вместе с этим хламом. К сожалению, делать так получается дорого и долго, и поддержка получается дорогая, а с точки зрения прибыли нет никакой разницы между настоящей безопасностью и почти настоящей, и тем 0.0001% пользователей, которым эта разница действительно жизненно важна, обычно советуют делать свои собственные процессоры из своего собственного кремния на своих собственных заводах.
Статистики у меня нет, только ощущения, и по ним разницы какой-то особой на своих задачах я не заметил ни от программных патчей, ни от обновлений на более новые «исправленные» процессоры, потому что прогресс процессоров Intel после SkyLake практически остановился и идет исключительно за счет увеличения количества ядер на одном кристалле. Выход годных 10нм кристаллов IceLake до сих пор настолько кошмарно низкий, что выпустить их получилось только в виде мобильных огрызков с 9 Вт теплопакета и базовыми частотами в ~1 Ггц. Все остальное как было 14нм (Broadwell, 2014 год), так и остается в нынешнем 2020, и ожидаемые в этом году CometLake (т.е. 10 серия для десктопов и ее друзья — чипсеты 400 серии) — тот же самый SkyLake пятилетней давности, только только с большим количеством ядер за те же деньги.
В общем, если вам ядер не хватало — теперь их больше кладут, но AMD теперь их отгружает значительно бодрее за те же деньги. Если же не хватало чего-то еще, объема памяти, скорости дисковой подсистемы, и т.п. — устранять нужно именно это, и замена процессора на «новый-безопасный» сильно не поможет.
Там еще одна проблема, и за которой обновление отложили: ребята из MS не стали проверять, что оно вообще может быть установлено (т.е. что ключ МС присутствует в KEK), и пытаются писать в dbx даже тогда, когда права на это не имеют, и при этом воспринимают EFI_SECURITY_VIOLATION как критическую ошибку, и пугают пользователей сообщениями о ней. Надеюсь, в следующей итерации это исправят.
По поводу проблем с ноутбуками HP — там сработала система защиты переменных SecureBoot от несанкционированной записи, включенная по умолчанию. Система эта почему-то не удаляет ключ МС из КЕК при работе (это баг, потому что как еще сообщить коду ОС, что писать в db* нельзя?).
В общем, все как всегда: люди придумывают механизм обновления, которым никто никогда не пользовался, и потому он вообще не тестировался, а когда наконец им решили воспользоваться, оказалось, что детали работы этого механизма неизвестны ни тем, кто им решил воспользоваться, ни тем, кто его реализовывал. Бизнес как обычно.
Отнюдь, потому что это не те PRR'ы, а чипсетные, и подавай там напряжение на #WP или нет, на запись со стороны чипсета (а flashrom пишет именно чипсетным контролером) это не повлияет.
Не думаю, что там что-то сильно поменялось с 2015 года, когда я писал про Lenovo в ключе «стараются вроде, но недостаточно, и регулярно оскандаливаются то с одним, то с другим». HP и Dell по прежнему немного лучше в смысле безопасности, но разница не принципиальная, и против некоторых широко известных типов атак (DMA-атаки, например) они все одинаково не защищены.
В данном случае из шелла уже не выйдет, потому что SMM Dispatching к тому моменту давно уже закончился, и новые SMM-драйверы оттуда уже не запустить, так что придется нужный драйвер все равно в прошивку добавлять. Раньше там был баг с тем, что ОРОМы могли запускаться раньше, чем SMM-фаза заканчивалась, но его исправили довольно давно, и сейчас на него надеяться мало смысла.
Лучшим вариантом было бы добавить в прошивку свой SMM модуль, который UEFI бы легально разместил в SMRAM, чтобы не беспокоиться, что нашим кодом будет перезаписано что-то важное.
Вот тут можно сделать еще один шаг — если возможность внедрения собственного кода уже имеется, то можно предоставить собственный обработчик на незадействованный номер SMI, в котором будет не только необходимый шелл-код, но и патчер для всех остальных обработчиков, к которым несложно получить доступ (они связаны в глобальный список mSmiEntryList, и можно итерироваться по нему):
HM77 — это чипсет без поддержки AMT вообще, о чем первая строка и сообщает. Все остальное — это сами настройки уже, т.е. если чипсет сменить, а настройки — нет, то AMT заработает.
Если в вашей утилите можно провернуть то, что нельзя сделать в UEFITool — это может быть багом, и о нем стоило бы сообщить разработчикам.
У меня по результатам работы с большим объемом прошивок примерно те же мысли: на проверку совместимости (и потому и саму совместимость) со стандартом почти все плюют (им нужно платы выпускать в срок, а не прошивку вылизывать до идеального состояния), везде расставлены всякие интересные грабли, причем у разных вендоров расположение граблей отличается, документация если и есть какая-то, то она или утекшая Intel Confidential, или бесполезная, и т.п.
Отнюдь. LGPL позволяет и статическую линковку, но при условии, что пользователь может заменить слинкованную библиотеку на свою. Т.е. если вы распространяете вместе со своим приложением его объектные файлы и инструкцию по линковке, LGPLv2 вы не нарушаете.
МЕ конкретно основной системе вообще не должен ничего, кроме как по HECI отвечать и в том самом конфигурационном пространстве светиться, так что он вполне может уйти в глубокий сон, последующее пробуждение из которого снова пройдет через уязвимый ROM, и вот в этот самый момент (если его получится отловить) можно перехватить управление через ДМА-атаку прямо с хоста.
Понятно, что это все — страшно дорогая целевая атака, которую нет смысла даже пытаться применять по площадям против условного слесаря Васи (фишинг и рассылка вирусов отлично работают там уже, сложнее ничего не нужно), и статья больше про «это потенциально возможно сделать при условии что А, Б, Ц и звезды верно сошлись», чем про «любое повышение прав до рута позволяет взломать МЕ полностью и любить в нем гусей до старости лет». Тем не менее, баг отличный, и статья отличная, и пацаны — вообще ребята, пусть ищут и пишут еще.
Те, кто в свое время не перестал выпускать продукцию на AMD (даже если она получалась не очень прибыльной, HP, например) теперь могут быстро наладить выпуск, а не кто залез в Intel с головой теперь думают, где бы им людей нанять срочно вчера, найти нужные (или восстановить утерянные) контакты с AMD, и проверить свои контракты с Intel на предмет подводных камней и троянских коней, чтобы потом не отдать им всю прибыль от продажи чужих процессоров в суде.
Хороший встроенный TPM нужно было делать на отдельном кристалле внутри SoC, а не запускать его в виде процесса вместе с еще 2 мегабайтами всякого хлама, и его бы не сломали вместе с этим хламом. К сожалению, делать так получается дорого и долго, и поддержка получается дорогая, а с точки зрения прибыли нет никакой разницы между настоящей безопасностью и почти настоящей, и тем 0.0001% пользователей, которым эта разница действительно жизненно важна, обычно советуют делать свои собственные процессоры из своего собственного кремния на своих собственных заводах.
В общем, если вам ядер не хватало — теперь их больше кладут, но AMD теперь их отгружает значительно бодрее за те же деньги. Если же не хватало чего-то еще, объема памяти, скорости дисковой подсистемы, и т.п. — устранять нужно именно это, и замена процессора на «новый-безопасный» сильно не поможет.
По поводу проблем с ноутбуками HP — там сработала система защиты переменных SecureBoot от несанкционированной записи, включенная по умолчанию. Система эта почему-то не удаляет ключ МС из КЕК при работе (это баг, потому что как еще сообщить коду ОС, что писать в db* нельзя?).
В общем, все как всегда: люди придумывают механизм обновления, которым никто никогда не пользовался, и потому он вообще не тестировался, а когда наконец им решили воспользоваться, оказалось, что детали работы этого механизма неизвестны ни тем, кто им решил воспользоваться, ни тем, кто его реализовывал. Бизнес как обычно.
Вот тут можно сделать еще один шаг — если возможность внедрения собственного кода уже имеется, то можно предоставить собственный обработчик на незадействованный номер SMI, в котором будет не только необходимый шелл-код, но и патчер для всех остальных обработчиков, к которым несложно получить доступ (они связаны в глобальный список mSmiEntryList, и можно итерироваться по нему):