Проблема там не в DrtiverXXXX, который работает как задумано, а в VariableLock, который работает совершенно не так, как задумано, потому что как задумано (и как описано в его описании) он работать вполне может, но тогда он окажется не нужен для его основного применения (защиты переменной Setup после того, как приложение BIOS Setup гарантировано отработало), поэтому все практические реализации этого протокола спецификации хором решили не соответствовать.
На самом деле, вся эта ерунда, которой Intel здесь пытается заниматься - это даже не "припарки мертвому" (потому что минимально подготовленного атакующего она не останавливает никак), а скорее "защита от дурака", и очередное "ну мы ведь приняли меры". Вот уязвимость "все подряд пишут всякое в Setup" - вот "решение", а то, что это решение ничего не решает, а только видимость создает - это совсем другой вопрос уже, меря приняты, "к пуговицам претензии есть?". И вот такое оно в UEFI - практически всё, к сожалению.
Первое: доступ этот может быть физическим, и затруднить его в таком случае довольно непросто: придется закапывать дорожки внутрь платы, специальным образом разводить SPI-чип (потому что конденсаторы фильтровочные теперь не поставить, т.к. они по определению будут на поверхности, либо придется в плату закапывать и их, а это нестандартный процесс, который кратно дороже выйдет), лишаться разъема In-System Programming (т.е. заранее напаивать уже прошитые SPI-чипы в корпусе TFBGA24). Это все - обычные инженерные задачи ("ну надо так надо"), но они заметно удорожают плату, и потому переживут этап BOM cost optimization в исключительных случаях (игровые консоли, продающиеся в убыток, с надеждой вернуть убыток за счет лицензионных игр, например).
Второе: современный x86 ПК хранит на SPI-чипе не только условный BIOS, но и множество других прошивок, которым необходимо и читать с него данные, и писать их, в том числе во время работы системы. Раньше это решалось подключением отдельного чипа CMOS SRAM, но таковые либо малоёмкие (если недорогие), либо дорогие (если хоть сколько-нибудь емкие), да и доступ к ним все равно происходит через CPU IO-порты, т.е. доступен любому атакующему с правами рута (а локальное повышение привилегий в любой популярной ОС большой тройки - практически решенный вопрос, десяток новых CVE каждый месяц не даст соврать). Более того, наличие UEFI NVRAM подразумевает возможность записи новых переменных во время работы ОС, поэтому какая-то часть SPI-чипа все равно должна оставаться R/W.
Третье: это все реально можно сделать лучше, поставить два чипа, отдав второй чисто под R/W-регионы, и закрыв первый от записи физическим переключателем, и это уже делается вполне на дорогом промышленно оборудовании, обслуживаемом профессионалами с высокими зарплатами, но на домашней электронике для простого пользователя это все приведет исключительно к убыткам, перегрузке технической поддержки, и т.п. Пользователь обычный чаще всего вообще не в курсе, что у него есть какая-то прошивка, а там в прошивке тем временем 30+ мегабайт кода на С, который просто невозможно "сразу сделать хорошо" при текущих способах разработки системного ПО. Если не научиться обновлять эту самую прошивку незаметно для пользователя каждую неделю (да хотя бы раз в пару месяцев, не до жиру), то очень скоро почти все ваши системы на руках у пользователей будут иметь известные незакрытые уязвимости, через которые их будут грызть черви, а вы ничего с этим сделать не сможете.
В общем, лучше можно сделать гарантировано, и способы есть для этого известные, и примеры, но пока производителя не начнут бить палкой либо сами пользователи (через потерю репутации, но там зачастую терять уже давно нечего), либо государство (через регулирование и штрафы) - лучше ничего не будет, потому что "и так берут".
Я видел работоспособные Protected Ranges на машинах Dell/Alienware, использовавших AMI AptioV, но и они там были настроены криво (потому что разработчики не в курсе, что PRRы нужно выравнивать с обеих сторон по границе в 16 (иногда 64) кб, а у них на границе было как раз начало тома DXE, лежавшего сразу за томом с NVRAM).
Только в некоторых, в основном на ноутбуках, AIO, серверах и т.п. системах, которые поставляются в сборе, и для которых для производителя есть смысл защищать прошивку (в том числе и от пользователя).
Процессоры Intel поддерживают BootGuard начиная с Haswell/Broadwell, но фьюзы (одноразовые электрически-пережигаемые дорожки) у Intel находятся в чипсете, а не в процессоре (ну, кроме случаев SoC, когда чипсет и процессор установлены под одной крышкой), и потому для откручивания BG достаточно замены чипсета и сброс конфигурации CSME и FIT при помощи Flash Image Tool. У AMD их аналог BootGuard поддерживается, ЕМНИП, с Zen 1 (может быть чуть раньше даже, но на Merlin Falcon PSP уже был, а BG - еще нет, вроде бы), и фьюзы находятся в процессоре, и для удаления BG придется менять именно его.
HP на современных машинах использует BootGuard для защиты SEC и PEI, как обычно, а для всего остального (в том числе NVRAM, внезапно, отчего они умеют задорно окирпичиваться при попытке Windows Update доставить обновления переменных SecureBoot) они придумали SureStart.
Dell, насколько я знаю, использует те же решения IBV, что и все остальные.
Эта же статья - не выдерживает никакой критики, потому что написана либо БЛМкой, либо человеком, который ничего не понимает в том, о чем пишет.
Ложь начинается прямо с заголовка: "В четырех линейках чипов мирового производителя AMD устранена уязвимость благодаря Positive Technologies". Никакой уязвимости в "четырех линейках чипов ... AMD" не устранено, потому что уязвимость была не в чипах, а в SMM-драйвере, о чем прямо и буквально пишут и автор вышеупомянутой статьи, и сами AMD: Incorrect use of LocateProtocol Service by a privileged attacker with local access could potentially result in privilege escalation from Ring 0 to System Management Mode (SMM) potentially resulting in Arbitrary Code Execution.
AMD recommends updating to the Platform Initialization (PI) versions indicated below.
Platform Initialization (PI) - это не "микропрограммное обеспечение", это часть прошивки, отвечающая за инициализацию процессора, чипсета и ОЗУ, и микрокоду (тому самому "микропрограммному обеспечению") эта часть ортогональна целиком.
Ребят, я вас очень уважаю, в том числе за то, что помогаете делать прошивки безопаснее, но давайте не будем путать уязвимости в компонентах прошивки с уязвимостями в процессорах, тем более, что автор оригинальной статьи у вас же и работает. Опубликуйте лучше перевод оригинала на русский язык, вместе со всеми расследованиями и скриншотами, и за него вам тут и я, и остальные все интересующиеся поставят вагон плюсов.
Непонятно, почему вы прошивку полноценную называете "загрузчиком".
У вас здесь прошивка, собранная из FSP и EDK2 на минималках, достаточная, чтобы с одной стороны загружать вашу целевую ОС, а с другой - общаться с IPMI от AMI так, чтобы он не слишком сильно матерился. "Загрузчиком" у вас является следующая стадия, т.е. то, на что ваша прошивка передает управление (bootmgfw.efi, shell.efi, grub.efi, ядро Linux с EFI_STUB, etc.)
Для нас это доказательство того, что даже в мире закрытых платформ можно добиться полного контроля над железом ― если есть упорство, любопытство и готовность к экспериментам.
Лучше убрать отсюда слово "полного", потому что в таком виде это смешно. У вас весь код фазы PEI и часть кода DXE (компоненты FSP) - закрытые и под закрытыми лицензиями, а дали их вам на условиях AS IS фактически "погонять-покрутить". Не говоря уже про компоненты Intel ME, без которых ваша платформа не загрузится, и о которых вы даже не упоминаете, тоже выданные вам в виде BLOBа на тех же условиях.
Никто не спорит с тем, что на современных платформах Intel, для которых их милостью доступен FSP, можно написать свою относительно работающую прошивку, но при этом до "полного контроля на железом" на них все еще как раком до Китая.
Опять же, я очень рад, что российские компании наконец-то начали делать что-то свое (пусть и на основе FSP и EDK2), а не говнокод IBV покупать, и по существу претензий у меня нет - так держать, молодцы, ребята!
Стартовая точка нашего BIOS — это монолит, PEI-модуль, который даже при большом желании сложно расколоть, не имея исходников на руках.
Уверен, что IDA 9.1 с плагином efiXplorer позволит любому достаточно подготовленному атакующему "расколоть" ваш модуль за 5 минут.
Попытка проникнуть в нашу систему, на наш взгляд, займет так много времени у злоумышленника, что в конечном итоге того не стоит.
Если злоумышленник подготовлен, ему хватит 10 минут на снять дамп региона БИОС, выпатчить всю эту "защиту", и залить изменения обратно. Это с учетом того, что ему приходится работать без выпаивания SPI-чипа.
Что касается образа в открытом доступе: пока что в компании приняли решение не выкладывать образ в открытый доступ, но, возможно, однажды что-то изменится.
Дело ваше, но дамп вашей прошивки очень скоро можно будет найти на сайтах для ремонтников, и вы ничего не сможете с этим сделать.
Когда я найду образ, я покажу вам, как быстро можно сделать патч, отключающий вашу "защиту", и как просто это автоматизировать. А пока посоветую все же реализовать поддержку BootGuard в дополнение к уже существующим хешам и подписям, иначе для атакующего вся ваша "защита" - это ерунда на один раз, т.е. один раз получил управление в DXE или контроль над содержимым SPI-чипа - и все, ничего больше не поможет.
А можно дамп вашей прошивки посмотреть? А то одно дело рассказывать, как хорошо ее защита выглядит из Chipsec, а совсем другое - убедиться, что кроме PRRов и SMM_BWP там есть еще и остальные необходимые элементы цепочки доверия с аппаратным корнем: BootGuard, ваше продолжение BG для фазы DXE, и т.п. Без них все описанные защиты тривиально обходятся программатором на чипе CH341A за 300 рублей.
Отдельно хочется (в очередной раз) удивиться и раздосадоваться типичному российскому подходу "если вам надо - пишите нам":
Для получения актуальной прошивки свяжитесь с нами по электронной почте support@graviton.ru.
Никто из уважающих себя и пользователя производителей железа так не делает, и всю документацию и файлы с обновлениями у них можно скачать "без регистрации и смс", а тем более обращений в поддержку.
Всей прошивки - исключена практически, а для NVRAM конкретно вместе с хранилищем основных переменных либо делают резервное (чтобы если основное вышло из строя, можно было загрузиться и восстановить то, что выжило, а остальное взять из копии), либо используют отдельный блок и драйвер для Fault Tolerant Write.
Если немного раскрыть идею про "накапливать", можно сделать атрибут для SetVariable вроде "переменная не очень важная, можно кэшировать, если 0, писать разу на флеш, если 1", и в зависимости от него в кэше делать упаковку тех, кому не срочно (т.е. "ждем пока накопится 128 байт изменений, сливаем всех в один блок"), и писать сразу в целый блок тех, кому срочно.
Получится не очень плотно, если срочных будет много, но тут я не вижу вариантов.
Ограничения слишком неприятные получаются, если упаковывать плотнее. По факту у нас запись блоками по 128 байт, и в старые блоки нельзя писать, так что для данных, которые надо обновить, у нас по факту ровно одно место, куда можно писать их - следующий свободный 128-байтовый блок. А дальше там любая переменная размером от 1 до 126 (пусть будет счетчик поколений в 2 байта, для ровного счета) - это одна запись блок. Можно попробовать каждый раз при записи решать задачу о рюкзаке, и пытаться впихнуть сколько-то уже существующих переменных (бампнуть им поколение тоже) в один блок вместе с новой, но может быть медленно и печально (сложность нормального решения такой задачи - почти квадратичная, а у нас МК слабый). В общем, можно разменять производительность на более плотную упаковку, либо нахер выкинуть такой флеш и поставить нормальный SPI/I2C NOR и пошло оно все это в жопу.
А вообще, если еще немного подумать, никакого толку от решения задачи о рюкзаке не будет, если не "накапливать" где-то в ОЗУ несколько вызовов SetVariable перед тем, как на флеш писать. Если писать по одной переменной за раз - никакими оптимизациями там ничего не сделать, потому что мы за один раз в любом случае инвалидируем (т.е. раньше туда можно было писать, теперь - нет) один блок в 128 байт, и потому ничего там меньше все равно сэкономить не выйдет.
Если переменных немного, и место экономить не нужно, то можно сделать минимальный размер переменной в 128 байт, и писать именно с такой грануляцией. Тогда получается, что нам нужно научиться отличать "валидные" переменные от "устаревших", для этого подойдет банальный счетчик "поколений", т.е. функция GetVariable внутри себя проходит по всем записям на флеше, и возвращает значение той, у которой счетчик больше. SetVariable делает то же самое, только пишет в свободное место новую запись с инкрементированным счетчиком. Чтобы не ловить переполнения, счетчик можно сделать 2 или даже 4-байтным.
Как только хранилище заполнилось - стереть все, что сейчас "устарело" по 8 кб за раз, и перенести все оставшееся в начало, сбросив счетчики. Там будет еще проблема небольшая с Fault Tolerant Write, но она решается выделением одного 8кб блока и переносом данных через него.
Если прямо совсем одноразовой - лучше на такой NVRAM не делать. Если же одноразовой-до-страния-блока, можно попробовать ставить в последнем блоке перед свободными счетчик "столько-то блоков до меня - активные, остальные - мусор", и писать все содержимое заново каждый раз при добавлении новой записи. Когда свободные блоки закончатся - стереть все, кроме активных, скопировать активные из конца в начало, стереть в конце. Нагрузка на флеш будет - атас, но работать будет.
Следующая уязвимость с идентификатором CVE-2025-47827 обнаружена исследователем Заком Дидкоттом. Она содержится в модуле igel-flash-driver для ядра Linux, разработанном компанией IGEL Technology. Суть в следюущем: ошибка при верификации криптографической подписи может приводить к загрузке с использованием вредоносной файловой системы.
Несмотря на красивые картинки, которые уважаемый исследователь у себя рисует, уязвимость эта не является обходом UEFI SecureBoot, потому что фаза BDS заканчивается на вызове ExitBootServices, и никаким, даже самым волшебным kexec вернуться к состоянию "было до" без перезагрузки уже не получится. Так ведь можно все уязвимость в драйверах для Windows в обход SB записать...
Обход UEFI SecureBoot - это получение управления в фазе BDS (или раньше, но там уже говорят о перехвате контроля на DXE, а обход SB - это побочный результат), и этому критерию удовлетворяют и CVE-2025-3052, и CVE-2025-4275, и остальные проблемы обходы SecureBoot, которые Binarly нашли до этого.
Переменной, которая разблокировала бы старое меню, скорее всего нет, но если формы для них есть и не скрыты, можно попробовать запустить UMAF и посмотреть, доступны ли они.
"Святая святых" пошла чинить крайне серьезную проблему - загрузочные вирусы, с которыми из ОС вообще ничего не сделать, а в ответ конкуренты и "сообщество" так яростно пошло их за это шельмовать, что результат получился компромиссом ни-нам-ни-вам.
Сносить ничего не надо, нужно все загрузчики подписать своим сертификатом, не доверять предоустановленной иерархии сертификатов, и подписывать все, что прошивка может исполнять, вручную самостоятельно.
Только вот это готовы делать три с половиной анонимуса, а MS доставили защиту от загрузочных вирусов на каждый х86 ПК 13 лет назад, пусть дырявую-хреновую, но тем не менее. И буткит теперь в дикой природе найти - очень редкое событие, раз в год плюс-минус, т.е. для обычного пользователя и от дешевых атак защита вполне себе работает.
Не то, чтобы она прямо требовалась, но если коротко - потому что инфраструктура для подписывания миллирда разношерстных загрузчиков и управления сотней ключей для этого - очень дорого стоит, и потому когда Microsoft спросил всех остальных участников рынка "кто будет оплачивать банкет", других желающих почему-то не нашлось.
Там вообще надо долго рассказывать, но в итоге получилось удивительно дерьмовое решение, в котором т.н. shim подписан ключом MS (UEFI CA, которым подписана чертова прорва всего, в том числе уязвимого), сам этот shim доверяет всему, что записано в переменной MOKList, которая от перезаписи из ОС защищена (как Задорнов говорил, внимание!) отсутствием атрибута RT.
По человечески, надо всю эту бессмысленную хрень давно уже выкидывать и заново проектировать с учетом того, что на дворе 25 год, и скоро без PQC безопасную загрузку перестанут покупать. Но пока в UEFI Forum заседают три с половиной пенсионера, а за развитие EDK2 отвечают два разработчика из Intel - ничего не изменится.
Проблема там не в DrtiverXXXX, который работает как задумано, а в VariableLock, который работает совершенно не так, как задумано, потому что как задумано (и как описано в его описании) он работать вполне может, но тогда он окажется не нужен для его основного применения (защиты переменной Setup после того, как приложение BIOS Setup гарантировано отработало), поэтому все практические реализации этого протокола спецификации хором решили не соответствовать.
На самом деле, вся эта ерунда, которой Intel здесь пытается заниматься - это даже не "припарки мертвому" (потому что минимально подготовленного атакующего она не останавливает никак), а скорее "защита от дурака", и очередное "ну мы ведь приняли меры". Вот уязвимость "все подряд пишут всякое в Setup" - вот "решение", а то, что это решение ничего не решает, а только видимость создает - это совсем другой вопрос уже, меря приняты, "к пуговицам претензии есть?". И вот такое оно в UEFI - практически всё, к сожалению.
Не заметил за ними никаких изменений к лучшему, к сожалению.
Первое: доступ этот может быть физическим, и затруднить его в таком случае довольно непросто: придется закапывать дорожки внутрь платы, специальным образом разводить SPI-чип (потому что конденсаторы фильтровочные теперь не поставить, т.к. они по определению будут на поверхности, либо придется в плату закапывать и их, а это нестандартный процесс, который кратно дороже выйдет), лишаться разъема In-System Programming (т.е. заранее напаивать уже прошитые SPI-чипы в корпусе TFBGA24). Это все - обычные инженерные задачи ("ну надо так надо"), но они заметно удорожают плату, и потому переживут этап BOM cost optimization в исключительных случаях (игровые консоли, продающиеся в убыток, с надеждой вернуть убыток за счет лицензионных игр, например).
Второе: современный x86 ПК хранит на SPI-чипе не только условный BIOS, но и множество других прошивок, которым необходимо и читать с него данные, и писать их, в том числе во время работы системы. Раньше это решалось подключением отдельного чипа CMOS SRAM, но таковые либо малоёмкие (если недорогие), либо дорогие (если хоть сколько-нибудь емкие), да и доступ к ним все равно происходит через CPU IO-порты, т.е. доступен любому атакующему с правами рута (а локальное повышение привилегий в любой популярной ОС большой тройки - практически решенный вопрос, десяток новых CVE каждый месяц не даст соврать). Более того, наличие UEFI NVRAM подразумевает возможность записи новых переменных во время работы ОС, поэтому какая-то часть SPI-чипа все равно должна оставаться R/W.
Третье: это все реально можно сделать лучше, поставить два чипа, отдав второй чисто под R/W-регионы, и закрыв первый от записи физическим переключателем, и это уже делается вполне на дорогом промышленно оборудовании, обслуживаемом профессионалами с высокими зарплатами, но на домашней электронике для простого пользователя это все приведет исключительно к убыткам, перегрузке технической поддержки, и т.п. Пользователь обычный чаще всего вообще не в курсе, что у него есть какая-то прошивка, а там в прошивке тем временем 30+ мегабайт кода на С, который просто невозможно "сразу сделать хорошо" при текущих способах разработки системного ПО. Если не научиться обновлять эту самую прошивку незаметно для пользователя каждую неделю (да хотя бы раз в пару месяцев, не до жиру), то очень скоро почти все ваши системы на руках у пользователей будут иметь известные незакрытые уязвимости, через которые их будут грызть черви, а вы ничего с этим сделать не сможете.
В общем, лучше можно сделать гарантировано, и способы есть для этого известные, и примеры, но пока производителя не начнут бить палкой либо сами пользователи (через потерю репутации, но там зачастую терять уже давно нечего), либо государство (через регулирование и штрафы) - лучше ничего не будет, потому что "и так берут".
Я видел работоспособные Protected Ranges на машинах Dell/Alienware, использовавших AMI AptioV, но и они там были настроены криво (потому что разработчики не в курсе, что PRRы нужно выравнивать с обеих сторон по границе в 16 (иногда 64) кб, а у них на границе было как раз начало тома DXE, лежавшего сразу за томом с NVRAM).
Только в некоторых, в основном на ноутбуках, AIO, серверах и т.п. системах, которые поставляются в сборе, и для которых для производителя есть смысл защищать прошивку (в том числе и от пользователя).
Процессоры Intel поддерживают BootGuard начиная с Haswell/Broadwell, но фьюзы (одноразовые электрически-пережигаемые дорожки) у Intel находятся в чипсете, а не в процессоре (ну, кроме случаев SoC, когда чипсет и процессор установлены под одной крышкой), и потому для откручивания BG достаточно замены чипсета и сброс конфигурации CSME и FIT при помощи Flash Image Tool. У AMD их аналог BootGuard поддерживается, ЕМНИП, с Zen 1 (может быть чуть раньше даже, но на Merlin Falcon PSP уже был, а BG - еще нет, вроде бы), и фьюзы находятся в процессоре, и для удаления BG придется менять именно его.
HP на современных машинах использует BootGuard для защиты SEC и PEI, как обычно, а для всего остального (в том числе NVRAM, внезапно, отчего они умеют задорно окирпичиваться при попытке Windows Update доставить обновления переменных SecureBoot) они придумали SureStart.
Dell, насколько я знаю, использует те же решения IBV, что и все остальные.
К Тимофею - никаких вопросов, как и к его статье на английском от 15 апреля. Отлично написано, скриншоты красивые, уязвимость простая как мычание.
Эта же статья - не выдерживает никакой критики, потому что написана либо БЛМкой, либо человеком, который ничего не понимает в том, о чем пишет.
Ложь начинается прямо с заголовка: "В четырех линейках чипов мирового производителя AMD устранена уязвимость благодаря Positive Technologies". Никакой уязвимости в "четырех линейках чипов ... AMD" не устранено, потому что уязвимость была не в чипах, а в SMM-драйвере, о чем прямо и буквально пишут и автор вышеупомянутой статьи, и сами AMD: Incorrect use of LocateProtocol Service by a privileged attacker with local access could potentially result in privilege escalation from Ring 0 to System Management Mode (SMM) potentially resulting in Arbitrary Code Execution.
AMD recommends updating to the Platform Initialization (PI) versions indicated below.
Platform Initialization (PI) - это не "микропрограммное обеспечение", это часть прошивки, отвечающая за инициализацию процессора, чипсета и ОЗУ, и микрокоду (тому самому "микропрограммному обеспечению") эта часть ортогональна целиком.
Ребят, я вас очень уважаю, в том числе за то, что помогаете делать прошивки безопаснее, но давайте не будем путать уязвимости в компонентах прошивки с уязвимостями в процессорах, тем более, что автор оригинальной статьи у вас же и работает. Опубликуйте лучше перевод оригинала на русский язык, вместе со всеми расследованиями и скриншотами, и за него вам тут и я, и остальные все интересующиеся поставят вагон плюсов.
Непонятно, почему вы прошивку полноценную называете "загрузчиком".
У вас здесь прошивка, собранная из FSP и EDK2 на минималках, достаточная, чтобы с одной стороны загружать вашу целевую ОС, а с другой - общаться с IPMI от AMI так, чтобы он не слишком сильно матерился. "Загрузчиком" у вас является следующая стадия, т.е. то, на что ваша прошивка передает управление (bootmgfw.efi, shell.efi, grub.efi, ядро Linux с EFI_STUB, etc.)
Лучше убрать отсюда слово "полного", потому что в таком виде это смешно. У вас весь код фазы PEI и часть кода DXE (компоненты FSP) - закрытые и под закрытыми лицензиями, а дали их вам на условиях AS IS фактически "погонять-покрутить". Не говоря уже про компоненты Intel ME, без которых ваша платформа не загрузится, и о которых вы даже не упоминаете, тоже выданные вам в виде BLOBа на тех же условиях.
Никто не спорит с тем, что на современных платформах Intel, для которых их милостью доступен FSP, можно написать свою относительно работающую прошивку, но при этом до "полного контроля на железом" на них все еще как раком до Китая.
Опять же, я очень рад, что российские компании наконец-то начали делать что-то свое (пусть и на основе FSP и EDK2), а не говнокод IBV покупать, и по существу претензий у меня нет - так держать, молодцы, ребята!
Уверен, что IDA 9.1 с плагином efiXplorer позволит любому достаточно подготовленному атакующему "расколоть" ваш модуль за 5 минут.
Если злоумышленник подготовлен, ему хватит 10 минут на снять дамп региона БИОС, выпатчить всю эту "защиту", и залить изменения обратно. Это с учетом того, что ему приходится работать без выпаивания SPI-чипа.
Дело ваше, но дамп вашей прошивки очень скоро можно будет найти на сайтах для ремонтников, и вы ничего не сможете с этим сделать.
Когда я найду образ, я покажу вам, как быстро можно сделать патч, отключающий вашу "защиту", и как просто это автоматизировать. А пока посоветую все же реализовать поддержку BootGuard в дополнение к уже существующим хешам и подписям, иначе для атакующего вся ваша "защита" - это ерунда на один раз, т.е. один раз получил управление в DXE или контроль над содержимым SPI-чипа - и все, ничего больше не поможет.
А можно дамп вашей прошивки посмотреть? А то одно дело рассказывать, как хорошо ее защита выглядит из Chipsec, а совсем другое - убедиться, что кроме PRRов и SMM_BWP там есть еще и остальные необходимые элементы цепочки доверия с аппаратным корнем: BootGuard, ваше продолжение BG для фазы DXE, и т.п. Без них все описанные защиты тривиально обходятся программатором на чипе CH341A за 300 рублей.
Отдельно хочется (в очередной раз) удивиться и раздосадоваться типичному российскому подходу "если вам надо - пишите нам":
Никто из уважающих себя и пользователя производителей железа так не делает, и всю документацию и файлы с обновлениями у них можно скачать "без регистрации и смс", а тем более обращений в поддержку.
Всей прошивки - исключена практически, а для NVRAM конкретно вместе с хранилищем основных переменных либо делают резервное (чтобы если основное вышло из строя, можно было загрузиться и восстановить то, что выжило, а остальное взять из копии), либо используют отдельный блок и драйвер для Fault Tolerant Write.
Если немного раскрыть идею про "накапливать", можно сделать атрибут для SetVariable вроде "переменная не очень важная, можно кэшировать, если 0, писать разу на флеш, если 1", и в зависимости от него в кэше делать упаковку тех, кому не срочно (т.е. "ждем пока накопится 128 байт изменений, сливаем всех в один блок"), и писать сразу в целый блок тех, кому срочно.
Получится не очень плотно, если срочных будет много, но тут я не вижу вариантов.
Ограничения слишком неприятные получаются, если упаковывать плотнее. По факту у нас запись блоками по 128 байт, и в старые блоки нельзя писать, так что для данных, которые надо обновить, у нас по факту ровно одно место, куда можно писать их - следующий свободный 128-байтовый блок. А дальше там любая переменная размером от 1 до 126 (пусть будет счетчик поколений в 2 байта, для ровного счета) - это одна запись блок. Можно попробовать каждый раз при записи решать задачу о рюкзаке, и пытаться впихнуть сколько-то уже существующих переменных (бампнуть им поколение тоже) в один блок вместе с новой, но может быть медленно и печально (сложность нормального решения такой задачи - почти квадратичная, а у нас МК слабый). В общем, можно разменять производительность на более плотную упаковку, либо нахер выкинуть такой флеш и поставить нормальный SPI/I2C NOR и пошло оно все это в жопу.
А вообще, если еще немного подумать, никакого толку от решения задачи о рюкзаке не будет, если не "накапливать" где-то в ОЗУ несколько вызовов SetVariable перед тем, как на флеш писать. Если писать по одной переменной за раз - никакими оптимизациями там ничего не сделать, потому что мы за один раз в любом случае инвалидируем (т.е. раньше туда можно было писать, теперь - нет) один блок в 128 байт, и потому ничего там меньше все равно сэкономить не выйдет.
Если переменных немного, и место экономить не нужно, то можно сделать минимальный размер переменной в 128 байт, и писать именно с такой грануляцией. Тогда получается, что нам нужно научиться отличать "валидные" переменные от "устаревших", для этого подойдет банальный счетчик "поколений", т.е. функция GetVariable внутри себя проходит по всем записям на флеше, и возвращает значение той, у которой счетчик больше. SetVariable делает то же самое, только пишет в свободное место новую запись с инкрементированным счетчиком. Чтобы не ловить переполнения, счетчик можно сделать 2 или даже 4-байтным.
Как только хранилище заполнилось - стереть все, что сейчас "устарело" по 8 кб за раз, и перенести все оставшееся в начало, сбросив счетчики. Там будет еще проблема небольшая с Fault Tolerant Write, но она решается выделением одного 8кб блока и переносом данных через него.
Если прямо совсем одноразовой - лучше на такой NVRAM не делать. Если же одноразовой-до-страния-блока, можно попробовать ставить в последнем блоке перед свободными счетчик "столько-то блоков до меня - активные, остальные - мусор", и писать все содержимое заново каждый раз при добавлении новой записи. Когда свободные блоки закончатся - стереть все, кроме активных, скопировать активные из конца в начало, стереть в конце. Нагрузка на флеш будет - атас, но работать будет.
Я предпочитаю OpenWRT и роутеры, для которых производитель нативно заявляет его поддержку. В России у меня Cudy WR3000H, в Германии - GL.Inet Flint 2.
Несмотря на красивые картинки, которые уважаемый исследователь у себя рисует, уязвимость эта не является обходом UEFI SecureBoot, потому что фаза BDS заканчивается на вызове ExitBootServices, и никаким, даже самым волшебным kexec вернуться к состоянию "было до" без перезагрузки уже не получится. Так ведь можно все уязвимость в драйверах для Windows в обход SB записать...
Обход UEFI SecureBoot - это получение управления в фазе BDS (или раньше, но там уже говорят о перехвате контроля на DXE, а обход SB - это побочный результат), и этому критерию удовлетворяют и CVE-2025-3052, и CVE-2025-4275, и остальные проблемы обходы SecureBoot, которые Binarly нашли до этого.
Переменной, которая разблокировала бы старое меню, скорее всего нет, но если формы для них есть и не скрыты, можно попробовать запустить UMAF и посмотреть, доступны ли они.
"Святая святых" пошла чинить крайне серьезную проблему - загрузочные вирусы, с которыми из ОС вообще ничего не сделать, а в ответ конкуренты и "сообщество" так яростно пошло их за это шельмовать, что результат получился компромиссом ни-нам-ни-вам.
Сносить ничего не надо, нужно все загрузчики подписать своим сертификатом, не доверять предоустановленной иерархии сертификатов, и подписывать все, что прошивка может исполнять, вручную самостоятельно.
Только вот это готовы делать три с половиной анонимуса, а MS доставили защиту от загрузочных вирусов на каждый х86 ПК 13 лет назад, пусть дырявую-хреновую, но тем не менее. И буткит теперь в дикой природе найти - очень редкое событие, раз в год плюс-минус, т.е. для обычного пользователя и от дешевых атак защита вполне себе работает.
Не то, чтобы она прямо требовалась, но если коротко - потому что инфраструктура для подписывания миллирда разношерстных загрузчиков и управления сотней ключей для этого - очень дорого стоит, и потому когда Microsoft спросил всех остальных участников рынка "кто будет оплачивать банкет", других желающих почему-то не нашлось.
Там вообще надо долго рассказывать, но в итоге получилось удивительно дерьмовое решение, в котором т.н. shim подписан ключом MS (UEFI CA, которым подписана чертова прорва всего, в том числе уязвимого), сам этот shim доверяет всему, что записано в переменной MOKList, которая от перезаписи из ОС защищена (как Задорнов говорил, внимание!) отсутствием атрибута RT.
По человечески, надо всю эту бессмысленную хрень давно уже выкидывать и заново проектировать с учетом того, что на дворе 25 год, и скоро без PQC безопасную загрузку перестанут покупать. Но пока в UEFI Forum заседают три с половиной пенсионера, а за развитие EDK2 отвечают два разработчика из Intel - ничего не изменится.