Комментарии 52
Очень интересная статья, и поучительная. Особенно относительно того, что касается безопасности.
Про безопасность SecureBoot и атаки на него я уже ранее писал, здесь больше про то, как им взять и начать пользоваться.
Безопасность SecureBoot держится на безопасности NVRAM, т.е. для нее необходимо, чтобы к содержимому NVRAM нельзя было получить доступ каким-то обходным способом, а не стандартными GetVariable/SetVariable, и по умолчанию на обеих ноутбуках это не так (прошивки уязвимы к атакам на S3 BootScript, что позволяет записать свой код в микросхему, что позволяет стартовать раньше SecureBoot, т.е. толку от него без защиты остального — ноль без палочки).
Безопасность любой системы определяется по самому слабому звену, поэтому вместе с SecureBoot нужно использовать и другие способы защиты прошивки, теорию о которых я описывал в вышеупомянутом цикле, а практику показывал на ZeroNights 2015.
Если вы простой пользователь и хотите, чтобы о безопасности вашей прошивки подумал вендор — покупайте системы HP или Dell, несмотря на все их недостатки, конкретно с защитой прошивок там все намного лучше, чем у конкурентов.
Безопасность SecureBoot держится на безопасности NVRAM, т.е. для нее необходимо, чтобы к содержимому NVRAM нельзя было получить доступ каким-то обходным способом, а не стандартными GetVariable/SetVariable, и по умолчанию на обеих ноутбуках это не так (прошивки уязвимы к атакам на S3 BootScript, что позволяет записать свой код в микросхему, что позволяет стартовать раньше SecureBoot, т.е. толку от него без защиты остального — ноль без палочки).
Безопасность любой системы определяется по самому слабому звену, поэтому вместе с SecureBoot нужно использовать и другие способы защиты прошивки, теорию о которых я описывал в вышеупомянутом цикле, а практику показывал на ZeroNights 2015.
Если вы простой пользователь и хотите, чтобы о безопасности вашей прошивки подумал вендор — покупайте системы HP или Dell, несмотря на все их недостатки, конкретно с защитой прошивок там все намного лучше, чем у конкурентов.
> Если вы простой пользователь и хотите, чтобы о безопасности вашей прошивки подумал вендор
Простые пользователи, дошедшие до использования SecureBoot хотят, чтобы безопасность могла обеспечиваться не вендором, а своими руками. Читайlegalize weed! open firmware! ))) В сущности вся проприетарщина в этой области ПО выглядит ужасно смешной и при этом жутко бесит.
Простые пользователи, дошедшие до использования SecureBoot хотят, чтобы безопасность могла обеспечиваться не вендором, а своими руками. Читай
Основная проблема открытых прошивок — Intel и AMD не горят желанием открывать MRC для новых систем даже своим же IBV, тем более сообществу. Взамен предлагается использовать Intel FSP / AMD AGESA binary, которые, по факту — мегабайтные BLOBы, реализующие 90% фазы PEI. В итоге что закрытый UEFI, что открытый coreboot + SeaBIOS/TianoCore/Linux — разницы с точки зрения любящего свободу пользователя почти никакой. А реверсить код MRC — дело не на один год, к тому времени целевая платформа уже устаревает до грани полной непривлекательности.
Решать эту проблему нужно с открытия железа и спецификаций к нему, за открытым софтом к таким системам дело не станет.
Добавлю также, эталонная что реализация SecureBoot открыта под лицензией BSD и является частью проекта TianoCore, и мой опыт показывает, что реализации IBV отличаются от нее очень мало, но, конечно, это все равно не тот открытый код, который нам нужен.
Решать эту проблему нужно с открытия железа и спецификаций к нему, за открытым софтом к таким системам дело не станет.
Добавлю также, эталонная что реализация SecureBoot открыта под лицензией BSD и является частью проекта TianoCore, и мой опыт показывает, что реализации IBV отличаются от нее очень мало, но, конечно, это все равно не тот открытый код, который нам нужен.
Я в курсе, что Intel и AMD ломаются как девствиницы. Моя претензия не к вам лично, а по большому счёту просто в эфир )
Кстати, тут на фоне громкого «выхода» полностью свободных ноутбуков почитал, что якобы в новых платформах невозможно вырезать MEI, так как если автономный котроллер ME не получает за 30 секунд после старта подписанную прошивку, то он ребутит систему. Это реально всё так плохо?
Кстати, тут на фоне громкого «выхода» полностью свободных ноутбуков почитал, что якобы в новых платформах невозможно вырезать MEI, так как если автономный котроллер ME не получает за 30 секунд после старта подписанную прошивку, то он ребутит систему. Это реально всё так плохо?
Да я это все слишком близко к сердцу и не принимаю, просто сейчас оно все именно вот так, и каких-то тенденций к изменению ситуации пока не видно. Единственная плата с открытой реализацией UEFI — Intel Galileo, там тоже не обошлось без блобов.
Про «все так плохо» — нет, это зависит от настроек, которые установил производитель ПК. Если он захочет, у вас современная машина с чипсетом/СнК Intel даже до ResetVector'а не дойдет, если хеш прошивки не сойдется с эталонным, но так настраивают систему только полные мудаки, и у таких я советую просто ничего не покупать.
Про «все так плохо» — нет, это зависит от настроек, которые установил производитель ПК. Если он захочет, у вас современная машина с чипсетом/СнК Intel даже до ResetVector'а не дойдет, если хеш прошивки не сойдется с эталонным, но так настраивают систему только полные мудаки, и у таких я советую просто ничего не покупать.
Хотите 100% открытое — Lenovo T500/X200 последнее что вы можете. Хотите чтоб минимум блобов (видеобиос остаётся только) — чтонить на Amd kabini.
Из топового интелового — сейчас в coreboot человек делает гигабайтовскую плату на G41 чипсете. Про Core iX и открытость — забудьте навсегда. Хотите что-то открытое на AMD с PSP — опять забудьте навсегда.
Из топового интелового — сейчас в coreboot человек делает гигабайтовскую плату на G41 чипсете. Про Core iX и открытость — забудьте навсегда. Хотите что-то открытое на AMD с PSP — опять забудьте навсегда.
Вот слова не мальчика, но мужа.
Переписать GOP-драйвер и SMU firmware для eKabini — и можно жить, все более новое — сразу в лес.
Переписать GOP-драйвер и SMU firmware для eKabini — и можно жить, все более новое — сразу в лес.
Вот именно, что более свежее 100% в лес — амд нивкакую не хочет делиться с opensource сообществом данными по PSP, акромя того, что оный есть ARM ядро и что он проверит вашу прошивку перед снятием ресета с x86. Ну а интел сами сказали всё, внеся в железную часть AMT/ME сторожевой таймер, отключающий систему через 30 минут, если код AMT/ME не выполнился. И если с PSP я ещё не слышал громких интриг и скандалов, то про старые реализации ME их уже было достаточно.
П.С. Если в переписывание видеобиоса я ещё верю, то вот в SMU верится очень слабо, т.к. оный везде (включая BKDG что открытые, что закрытые) описан как черный ящик.
П.С. Если в переписывание видеобиоса я ещё верю, то вот в SMU верится очень слабо, т.к. оный везде (включая BKDG что открытые, что закрытые) описан как черный ящик.
Скорее бы с этой проприетарщиной случилась какая-нибудь ерунда, типа всплывшей залепухи от Volkswagen. И тогда была бы надежда, что какая-нибудь еврокомиссия нагнёт их раком, чтобы либо выпилили, либо открыли.
Что касается леса, то в лесу вы долго не проживете. Тупо сломается когда-нибудь (
Что касается леса, то в лесу вы долго не проживете. Тупо сломается когда-нибудь (
Ну когда в лесу умрёт последний кабини (а умрёт он не ранее 2024 года, если верить АМД, если при этом включить режим «как правило ещё пару лет можно купить без проблем», то 2026 год) — тогда и будем думать, может к тому времени будет что-то от других игроков (ну а вдруг VIA оживёт на плацу х86, либо АРМ будет цвести и пахнуть на рынке десктопов (хотя сейчас и с армом на поле opensource не всё радужно))
Мы о чем сейчас говорим? О том, что вы сейчас купите компьютер и он проработает до 2026 года, или о том, что у некоего вендора будет возможность купить комплектуху в 2026 и сделать комп, который он сможет без стыда поставить на витрину и продать в 2026?
О втором. Для вендоров из Embedded и Industrial AMD гарантирует десятилетний срок поддержки и выпуска чипов, пусть и не очень крупными партиями. eKabini вышел в 2014, соответственно EOL он получит в 2024, и еще пару лет можно жить на старых запасах.
Этот процессор — последний x86, у которого нет «ядра обеспечения безопасности» с подписанным БЛОБом в качестве прошивки и полным отсутсвием документации на него в открытом доступе.
Этот процессор — последний x86, у которого нет «ядра обеспечения безопасности» с подписанным БЛОБом в качестве прошивки и полным отсутсвием документации на него в открытом доступе.
Про второе я даже и не спорю, такая возможность у вендора будет. Вот только будет ли актуальна такая железка в 2026 году — вопрос. Но я-то имел ввиду первое: обычного юзера-анонимуса. Ему-то как быть? ) Даже если он сегодня возмет Lenovo T500, то этот лэптом сдохнет гораздо раньше 2026. Не говоря о том, что он устареет морально гораздо раньше.
Обычный юзер-анонимус никому не интересен — денег с него взять не получится, т.к. свобода продается очень плохо, а пока ты занимаешься открытием свой платформы, согласованием открытия документации с производителями процессоров, памяти и контролера клавиатуры, конкуренты успевают выпустить две-три линейки продуктов и оставить тебя наедине с устаревшим уже на старте продаж железом и двумя с половиной потенциальными покупателями из числа фанатов свободы и всего такого. Обычный же пользователь и сам добровольно идет в walled garden, и друзей туда тащит, постоянные рекорды продаж Apple — тому ярчайший пример.
Скажем так. В роли печатной машинки под линуксом, которая может ещё и кино в FullHD показать и музыку послушать даст — оно и в 2026 году будет актуально. Я к примеру условно-терпимо использую hammerhead xrt (P3 900Mhz, 512Mb SDRAM) для просмотра интернета в гараже/на бездорожье. Железке уже более десяти лет, и её условно хватает. Думаю что в 26 году кабини будет примерно такимже
В особо критичных местах (с потолка — контроль чего-нить не сильно жизненно важного на АЭС (да, я в курсе, что все вендоры железа пишут, что низя АЭС/Медецина + наши компоненты)) — тоже актуально будет. Для справки — АМД до сих пор продаёт Geode LX800 пачками — а это пардон что-то уровня первого-второго пентиума по производительности (и с отсутствием пары ассемблерных команд). И оно широко используется в промавтоматике.
В особо критичных местах (с потолка — контроль чего-нить не сильно жизненно важного на АЭС (да, я в курсе, что все вендоры железа пишут, что низя АЭС/Медецина + наши компоненты)) — тоже актуально будет. Для справки — АМД до сих пор продаёт Geode LX800 пачками — а это пардон что-то уровня первого-второго пентиума по производительности (и с отсутствием пары ассемблерных команд). И оно широко используется в промавтоматике.
И не такое переписывали, и если сильно захотеть — можно в космос полететь, так что за SMU я сильно не переживаю, особенно после вот этой презентации (она же на видео).
С PSP я воюю прямо сейчас на Merlin Falcon, и он меня уже достал. Не могу ничего рассказать толком, NDA, но по сравнению с eKabini, где никаких танцев вокруг PSP не было — жизнь простого инженера стала с ним значительно сложнее, особенно если в его firmware виден баг, а ты даже сделать с этим ничего не можешь, кроме как репортить в AMD и ждать неизвестно сколько, пока в очередном обновлении AGASE/PI это баг не починят.
С PSP я воюю прямо сейчас на Merlin Falcon, и он меня уже достал. Не могу ничего рассказать толком, NDA, но по сравнению с eKabini, где никаких танцев вокруг PSP не было — жизнь простого инженера стала с ним значительно сложнее, особенно если в его firmware виден баг, а ты даже сделать с этим ничего не можешь, кроме как репортить в AMD и ждать неизвестно сколько, пока в очередном обновлении AGASE/PI это баг не починят.
а без входа в конфиг сбросить ключи можно? если, не дай Б-же, пароль на вход в конфиг забыли. али только через дырки в «обработчиках» nvram?
тоже интересно. Есть ли какие-то способы обхода? перебор пароля/замена микросхемы?
Стирание NVRAM при помощи программатора, либо подсистемой Crisis Recovery прошивки — два стандартных способа, которые помогают в случае, если PKpriv или пароль утеряны. Если доступ к PKpriv есть, отключить SecureBoot можно удалением переменной PK вызовом SetVariable с нужными параметрами из любой загруженной ОС.
Добавлю еще, что на некоторых системах (на вот этом Acer тестовом, к примеру) есть возможность сброса пароля звонком в Acer Support, где нужно будет доказать, что машина не украдена, а затем назвать набор цыфр, которые отображаются на экране после 3 неудачных попыток ввода пароля. В ответ они пришлют другой набор, и если ответ правильный, то драйвер UnlockPwd этот самый пароль сотрет.
Спасибо, Хабр торт :-)
Одно замечание. Мне кажется, что упомянутая во врезке (и слайдах ZN) команда:
Одно замечание. Мне кажется, что упомянутая во врезке (и слайдах 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 и переписывания загрузчика на нем (обычного LPE до System хватит за глаза). Дальше при отсутвии SecureBoot малварь может подменить загрузчик системы на собственный, и дальше рулить системой как ей заблагорассудится (т.к. она контролирует загрузку ядра и имеет возможность патчить его на лету), а в случае с включенным SecureBoot придется обходить сначала его, иначе вместо перехвата управления получится банальный DoS.
Может быть, не по адресу вопрос, но нет ли какой-то информации, планируется ли в UEFI как-то реализовать избыточность/отказоустойчивость ESP? Сейчас приходится или класть его на аппаратный RAID или работать в CSM, программный RAID в пролёте. Как и SecureBoot.
Или же где лучше поискать подобную информацию?
Или же где лучше поискать подобную информацию?
Не видел таких планов, но это не значит, что их нет.
ESP, на самом деле, не является обязательным, проблема только в отсутсвии драйвера для вашего Software RAID в прошивке. Если его написать и добавить, то можно будет спокойно загружаться с этого самого RAIDа не хуже, чем с ESP.
Пример похожего решения: добавление драйвера NVMe в прошивку старых плат решает проблему UEFI-загрузки с NVMe-устройств.
ESP, на самом деле, не является обязательным, проблема только в отсутсвии драйвера для вашего Software RAID в прошивке. Если его написать и добавить, то можно будет спокойно загружаться с этого самого RAIDа не хуже, чем с ESP.
Пример похожего решения: добавление драйвера NVMe в прошивку старых плат решает проблему UEFI-загрузки с NVMe-устройств.
Признаюсь, я не очень хорошо понимаю, как вообще загружается EUFI-система. Могу пороть чушь.
Я так понимаю, драйвер и не нужен. Сейчас у меня несколько систем с CSM вполне себе загружаются с любого из дисков в массиве, а там уже ядро собирает логический RAID. Т.е. ядро (в данном случае говорю про Linux) само себе «драйвер». Останавливает от перехода на UEFI то, что если откажет диск, на котором лежит ESP — система загрузиться не сможет. Т.е. сделать то ESP на каждом диске несложно, как и нагородить костылей с регулярной синхронизацией «главного» ESP с «подчинёнными», но хочется более прямого решения.
Загрузка без ESP — это интересный вариант. Есть что-то почитать на эту тему?
Я так понимаю, драйвер и не нужен. Сейчас у меня несколько систем с CSM вполне себе загружаются с любого из дисков в массиве, а там уже ядро собирает логический RAID. Т.е. ядро (в данном случае говорю про Linux) само себе «драйвер». Останавливает от перехода на UEFI то, что если откажет диск, на котором лежит ESP — система загрузиться не сможет. Т.е. сделать то ESP на каждом диске несложно, как и нагородить костылей с регулярной синхронизацией «главного» ESP с «подчинёнными», но хочется более прямого решения.
Загрузка без ESP — это интересный вариант. Есть что-то почитать на эту тему?
Загружаются эти системы с CSM исключительно потому, что на каждом диске есть MBR, в которую записан нужный код. Код этот передает управление на PBR раздела /boot или напрямую загрузчику, а он дальше загружает ядро. Если бы MBR была только на одном диске — сисема загружалась бы только с него. Поэтому и ESP нужно на все диски положить. Другой вопрос, что драйверу Software RAID может не понравится ФС FAT на ESP, но она и не обязательна в том случае, если в прошивке имеется драйвер Ext2/3/4.
По поводу загрузки без ESP — почитайте исходники Intel Quark BSP (это открытая прошивка для Intel Galileo, я он ней писал в прошлом году), там система загружается с образа, который прошит непосредственно в микросхему SPI.
По поводу загрузки без ESP — почитайте исходники Intel Quark BSP (это открытая прошивка для Intel Galileo, я он ней писал в прошлом году), там система загружается с образа, который прошит непосредственно в микросхему SPI.
Софтрейду (через mdadm) в принципе без разницы, какая ФС на устройстве. Разве что стоит делать массив с метаданными в конце, а не в начале (-e 0.9 или 1.0), чтоб прошивка, не умеющая md, могла его читать как обычный раздел.
Ну тогда ничего не мешает сделать ESP на каждом диске, и пусть за их дупликацию и целостность отвечает тот же програмный RAID, что и за остальное.
Софтрейду в Linux действительно всё равно на счёт ФС. Потому что в линуксе есть абстракция под названием «блочное устройство», а есть куча файловых систем, которые могут работать поверх любого блочного устройства. Есть ли такое разделение в UEFI я не знаю. Так что очень может статься, что если пилить Softraid для UEFI, то придется его делать filesystem aware.
Есть такая абстракция и в UEFI, и драйверы дисков, к примеру, побликуют их не как ФС или разделы, а как блочные устройства, доступные для чтения и\или записи через протоколы EFI_BLOCK_IO_PROTOCOL и EFI_DISK_IO_PROTOCOL, по штуке на каждое найденное устройство. Обнаружив наличие этих протоколов, драйвер PartitionDxe пытается найти всех дисках разделы, если они нашлись, публикуется EFI_DEVICE_PATH для этих разделов, а его в свою очередь получают драйверы FilesystemDxe, Ntfs, Ext2Dxe, HfsPlusDxe и так далее.
Если пилить программный рейд, то достаточно пояснить, как с него считать загрузчик, дальнейшее — дело ядра Linux, которое этим загрузчиком запустится (или является в случае использования EFI_STUB).
Если пилить программный рейд, то достаточно пояснить, как с него считать загрузчик, дальнейшее — дело ядра Linux, которое этим загрузчиком запустится (или является в случае использования EFI_STUB).
Статья интересная, но возвращает нас к вопросу о том, что ненормальные вендоры вот-вот запретят шить левый биос, если уже не запретили. Нет ли планов сделать добавление драйверов по ходу пьесы без перепрошивки биоса? Тот же SecureBoot мог бы обеспечить защиту от левака. Сегодня появился NVMe, завтра ещё что-нибудь появится…
PS: С ностальгией вспоминаю OpenFirmware, где прямо в консоли «биоса» можно было наваять дровинку на Fort'е и сохранить её в NVRAM.
PS: С ностальгией вспоминаю OpenFirmware, где прямо в консоли «биоса» можно было наваять дровинку на Fort'е и сохранить её в NVRAM.
Есть такая функция у нас на новых платах, называется MPFA, куда сам пользователь без перепрошивки остального БИОСа может добавить кучу разного, в том числе и целый новый Firmware Volume, который при следующей загрузке будет передан диспетчеру DXE, и оттуда будет исполнено все, что нужно. Понятно, что это — даже не дыра в безопасности, а открытые ворота в прошивку, но для того, чтобы сохранить что-то в MPFA, нужно сначала ввести пароль на BIOS, и после 3 неудачных попыток ввод блокируется до перезагрузки, т.е. авторизованный пользователь модифицирует то, что ему нужно, а удаленный атакующий идет лесом.
Собираются ли внедрить что-то похожее в стандартные реализации UEFI — не знаю, я об этом ничего не слышал, но тенденция, как верно подмечено, совершенно противоположная — «закрыть и не пущать». Меня это не устраивает, и начальника моего тоже, поэтому у congatec весь этот Hardware Verified Boot и прочие схемы защиты платформы от её же покупателя будут включены только для клиентов, которые требуют этого в обязательном порядке.
Собираются ли внедрить что-то похожее в стандартные реализации UEFI — не знаю, я об этом ничего не слышал, но тенденция, как верно подмечено, совершенно противоположная — «закрыть и не пущать». Меня это не устраивает, и начальника моего тоже, поэтому у congatec весь этот Hardware Verified Boot и прочие схемы защиты платформы от её же покупателя будут включены только для клиентов, которые требуют этого в обязательном порядке.
E — Extensible. Во истину корпоративный маразм крепчает. Придумать такой стэк, предусмотреть в нём возможность расширяемости, чтобы потом придумать как костылями эту расширямость ограничить до compile time — ради этого нужно придумать антипремию Тьюринга и вручить! )
Жалко, что ваша линейка продуктов такая узкоспециализированная.
Жалко, что ваша линейка продуктов такая узкоспециализированная.
Ну так Extensible же во все поля, буквально, только не для конечного пользователя. Для него есть ESP и переменные DriverXXXX и KeyXXXX, расширяй функциональность — не хочу, но только после окончания фазы BDS.
Пусть делают что хотят, пока BootGuard не включают. Все остальное при желании может быть (обязательно будет) отломано энтузиастами.
Пусть делают что хотят, пока 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.binSplitDbxContent.ps1 - https://www.powershellgallery.com/packages/SplitDbxContent/
ключ Microsoft Windows Production CA 2011, которым MS подписывает собственные загрузчики
Ключ истекает в 2026 году, поэтому лучше добавлять ещё и Windows UEFI CA 2023 - ключ, которым MS будет подписывать загрузчики в будущем.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Укрощаем UEFI SecureBoot