Более удобная разработка 64-битного графического UEFI приложения

[nckma]

Мне почему-то кажется, что уже очень скоро новые материнские платы будут иметь опцию EFI SecureBoot по умолчанию включенной. А может быть ее и выключить будет нельзя.

А значит запустить свое EFI приложение можно будет только подменив в биосе базы PK, KEK, DB. В общем, разрабатываеть свое EFI приложение без цифровой подписи Microsoft будет довольно затруднительно.

[BiosUefi]

Смешнее всего, что с активацией SecureBoot становится невозможно пользоваться и shell, все её встроенные команды ( ls, mem, pci) тоже "не подписаны"((((

[NeonMercury]

Я помню, что на прошлой работе мы дописывали ключи в PK, KEK, DB. И, таким образом грузились как efi, подписанные MS, так и efi, подписанные нашим ключом. Делали это на Lenovo Thinkpad`ах, но прошло уже лет 6 и я не помню деталей реализации. Помню только, что это не было открытым решением из документации, а чем-то вроде "добавить через ";" второй сертификат".

Возможно, что там была какая-то особенность именно на thinkpad`ах. Если кто-то что-то подобное знает, мне будет тоже интересно прочитать - вспомнить, потому что сейчас я не смог найти никакой информации на эту тему.

[CodeRush]

habr.com/ru/post/273497

[nckma]

Сказать по правде, мое мнение, что весь этот SecureBoot в UEFI это просто редкая ерунда. Главная причина такого моего мнения это то, что основной придуманный механизм блокировки скомпрометированных загрузчиков не может использоваться и дальше. После инцидента 2020 года (серия багов BootHole), когда пришлось отозвать более 150 загрузчиков база DBX (UEFI Revocation List) выросла почти до 15 килобайт из 32кб зарезервированных в NVRAM материнки. Скачать Revocation List DBX файл можно на сайте UEFI https://uefi.org/revocationlistfile

Еще такой случай, как BootHole и места для DBX не останется совсем. Поэтому начали придумывать надстройку над всей этой SecureBoot в виде SBAT (SecureBoot Advanced Targeting) типа чтоб одной записью в NVRAM блокировать список однотипных загрузчиков скажем одной версии. Новые загрузчики shim v15.4 уже содержат SBAT таблицы, да и новый grub2.06 должен их иметь.

[CodeRush]

Это все ерунда, конечно, но это наша единственная работающая и относительно универсальная ерунда на ПК. Проблему с разрастанием DBX можно достаточно несложно решить разделением ее на статическую и динамическую части, с добавлением статической (того самого revocation list) в саму прошивку, и модификацией драйвера SecureBoot, чтобы он проверял обе.

У UEFI SecureBoot действительно не очень хороший дизайн, но с практической точки зрения вот такая безопасная загрузка намного лучше, чем никакой, да и у конкурентов не особенно много более качественных альтернативных вариантов. Да, никто не думал в 2011 году, что придется отозвать две сотни подписей одним махом, но эта проблема уже известная, и решаемая, и ее даже решили частично введением в UEFI 2.4 Audit Mode и Deployment Mode с последующим отключением доверия к UEFI CA (которым все эти две сотни загрузчиков все и подписаны). BootHole — это отлично, на самом деле, потому что показывает, что улучшения в системе отзыва и упрощения цепочки доверия надо бы внедрять за 1-2 года, а не за 5-7, как сейчас.

[CodeRush]

Выключить все равно будет можно, это прописано в спецификации, которую настолько сильно никто уже обновлять не станет, переживать не надо. Да и дураков там тоже нет, каждую итерацию в МС подписывать.

[dimka11]

На ARM процессорах вроде не отключаемая, уже кучу лет как

[CodeRush]

Архитектура процессора там не при чем, на ARM есть сейчас стандарт Base Boot Security Requirements, в котором отключаемый SecureBoot прописан явно. Вы говорите про устройства типа смартфонов Nokia с Windows Mobile и прочие планшеты Microsoft Surface, и да, на них в свое время не было возможность отключить SecureBoot без костылей, но они и совместимость со спецификацией UEFI никогда не декларировали, а прошивки для ПК делают именно это вполне явно.