Comments 52
Безопасность SecureBoot держится на безопасности NVRAM, т.е. для нее необходимо, чтобы к содержимому NVRAM нельзя было получить доступ каким-то обходным способом, а не стандартными GetVariable/SetVariable, и по умолчанию на обеих ноутбуках это не так (прошивки уязвимы к атакам на S3 BootScript, что позволяет записать свой код в микросхему, что позволяет стартовать раньше SecureBoot, т.е. толку от него без защиты остального — ноль без палочки).
Безопасность любой системы определяется по самому слабому звену, поэтому вместе с SecureBoot нужно использовать и другие способы защиты прошивки, теорию о которых я описывал в вышеупомянутом цикле, а практику показывал на ZeroNights 2015.
Если вы простой пользователь и хотите, чтобы о безопасности вашей прошивки подумал вендор — покупайте системы HP или Dell, несмотря на все их недостатки, конкретно с защитой прошивок там все намного лучше, чем у конкурентов.
Простые пользователи, дошедшие до использования SecureBoot хотят, чтобы безопасность могла обеспечиваться не вендором, а своими руками. Читай
Решать эту проблему нужно с открытия железа и спецификаций к нему, за открытым софтом к таким системам дело не станет.
Добавлю также, эталонная что реализация SecureBoot открыта под лицензией BSD и является частью проекта TianoCore, и мой опыт показывает, что реализации IBV отличаются от нее очень мало, но, конечно, это все равно не тот открытый код, который нам нужен.
Кстати, тут на фоне громкого «выхода» полностью свободных ноутбуков почитал, что якобы в новых платформах невозможно вырезать MEI, так как если автономный котроллер ME не получает за 30 секунд после старта подписанную прошивку, то он ребутит систему. Это реально всё так плохо?
Про «все так плохо» — нет, это зависит от настроек, которые установил производитель ПК. Если он захочет, у вас современная машина с чипсетом/СнК Intel даже до ResetVector'а не дойдет, если хеш прошивки не сойдется с эталонным, но так настраивают систему только полные мудаки, и у таких я советую просто ничего не покупать.
Из топового интелового — сейчас в coreboot человек делает гигабайтовскую плату на G41 чипсете. Про Core iX и открытость — забудьте навсегда. Хотите что-то открытое на AMD с PSP — опять забудьте навсегда.
Переписать GOP-драйвер и SMU firmware для eKabini — и можно жить, все более новое — сразу в лес.
П.С. Если в переписывание видеобиоса я ещё верю, то вот в SMU верится очень слабо, т.к. оный везде (включая BKDG что открытые, что закрытые) описан как черный ящик.
Что касается леса, то в лесу вы долго не проживете. Тупо сломается когда-нибудь (
Этот процессор — последний x86, у которого нет «ядра обеспечения безопасности» с подписанным БЛОБом в качестве прошивки и полным отсутсвием документации на него в открытом доступе.
В особо критичных местах (с потолка — контроль чего-нить не сильно жизненно важного на АЭС (да, я в курсе, что все вендоры железа пишут, что низя АЭС/Медецина + наши компоненты)) — тоже актуально будет. Для справки — АМД до сих пор продаёт Geode LX800 пачками — а это пардон что-то уровня первого-второго пентиума по производительности (и с отсутствием пары ассемблерных команд). И оно широко используется в промавтоматике.
С PSP я воюю прямо сейчас на Merlin Falcon, и он меня уже достал. Не могу ничего рассказать толком, NDA, но по сравнению с eKabini, где никаких танцев вокруг PSP не было — жизнь простого инженера стала с ним значительно сложнее, особенно если в его firmware виден баг, а ты даже сделать с этим ничего не можешь, кроме как репортить в AMD и ждать неизвестно сколько, пока в очередном обновлении AGASE/PI это баг не починят.
Одно замечание. Мне кажется, что упомянутая во врезке (и слайдах ZN) команда:
cat KEK.esl MsKEK.esl > KEK.esl— потенциально очень вредная. Обычно оболочка открывает на запись файл вывода до того как выполнять собственно команду (говорю за B-шеллы, проверил на bash/zsh). В результате выполнения данной команды мы делаем так, что в KEK оказывается только ключ MS, но не наш. Лучше было бы как-то так:
cat KEK.esl MsKEK.esl > newKEK.esl
mv -f newKEK.esl KEK.esl
Или же где лучше поискать подобную информацию?
ESP, на самом деле, не является обязательным, проблема только в отсутсвии драйвера для вашего Software RAID в прошивке. Если его написать и добавить, то можно будет спокойно загружаться с этого самого RAIDа не хуже, чем с ESP.
Пример похожего решения: добавление драйвера NVMe в прошивку старых плат решает проблему UEFI-загрузки с NVMe-устройств.
Я так понимаю, драйвер и не нужен. Сейчас у меня несколько систем с CSM вполне себе загружаются с любого из дисков в массиве, а там уже ядро собирает логический RAID. Т.е. ядро (в данном случае говорю про Linux) само себе «драйвер». Останавливает от перехода на UEFI то, что если откажет диск, на котором лежит ESP — система загрузиться не сможет. Т.е. сделать то ESP на каждом диске несложно, как и нагородить костылей с регулярной синхронизацией «главного» ESP с «подчинёнными», но хочется более прямого решения.
Загрузка без ESP — это интересный вариант. Есть что-то почитать на эту тему?
По поводу загрузки без ESP — почитайте исходники Intel Quark BSP (это открытая прошивка для Intel Galileo, я он ней писал в прошлом году), там система загружается с образа, который прошит непосредственно в микросхему SPI.
Если пилить программный рейд, то достаточно пояснить, как с него считать загрузчик, дальнейшее — дело ядра Linux, которое этим загрузчиком запустится (или является в случае использования EFI_STUB).
PS: С ностальгией вспоминаю OpenFirmware, где прямо в консоли «биоса» можно было наваять дровинку на Fort'е и сохранить её в NVRAM.
Собираются ли внедрить что-то похожее в стандартные реализации UEFI — не знаю, я об этом ничего не слышал, но тенденция, как верно подмечено, совершенно противоположная — «закрыть и не пущать». Меня это не устраивает, и начальника моего тоже, поэтому у congatec весь этот Hardware Verified Boot и прочие схемы защиты платформы от её же покупателя будут включены только для клиентов, которые требуют этого в обязательном порядке.
Жалко, что ваша линейка продуктов такая узкоспециализированная.
Пусть делают что хотят, пока BootGuard не включают. Все остальное при желании может быть (обязательно будет) отломано энтузиастами.
Спасибо! Отличная статья, очень помогла по работе! У меня нужно было протестировать подпись и загрузку модуля ядра нашего на Ubuntu/SecureBoot/Shim, а мой BIOS отказывался восстанавливать хранилище сертификатов по умолчанию — только сброс. Загрузить сертификаты получилось, вот только ничего не заработало после этого… Но, обновление BIOS магическим образом всё вылечило. Так что, если что-то не получается — не факт, что это вы неправы.
Небольшое уточнение, с которым столкнулся, пытаясь включить у себя Secure Boot в 2022. **Очень плохие слова** инсталлятор драйвера NVIDIA для Linux не умеет подписывать свой модуль ключом, защищённым паролем. То есть для него надо обязательно сгенерировать ключевой файл без пароля(опция -nodes в openssl). И об этом вообще нигде не написано, сам допёр методом тыка, ковыряя логи. Плюс, оно там хочет sha512, а не sha256, ключ надо генерить, указывая соответствующую опцию.
Правильно ли я понял, что для dbx можно испльзовать файл отсюда https://uefi.org/revocationlistfile и подписать его ISK? Файл имеет расширение bin, это нормально?
Я dbx обновляю самописным скриптом прямо из ОС (по мере его обновления на сайте). Да, беру этот файл.
#Requires -RunAsAdministrator
$SplitDbxContent= $PSScriptRoot+"\SplitDbxContent.ps1"
Start-Process -FilePath "curl" -ArgumentList "https://uefi.org/sites/default/files/resources/dbxupdate_x64.bin","--output dbxupdate_x64.bin" -NoNewWindow -Wait
&$SplitDbxContent dbxupdate_x64.bin
Set-SecureBootUefi -Name dbx -ContentFilePath .\content.bin -SignedFilePath .\signature.p7 -Time 2010-03-06T19:17:21Z -AppendWrite
Remove-Item signature.p7, content.bin, dbxupdate_x64.bin
SplitDbxContent.ps1 - https://www.powershellgallery.com/packages/SplitDbxContent/
ключ Microsoft Windows Production CA 2011, которым MS подписывает собственные загрузчики
Ключ истекает в 2026 году, поэтому лучше добавлять ещё и Windows UEFI CA 2023 - ключ, которым MS будет подписывать загрузчики в будущем.
Укрощаем UEFI SecureBoot