> про выдающихся джентельменов (и леди), благодаря которым и была обнаружена большая часть описываемых проблем
Рафаль да Рутковска ;) Ну и интеловская security-команда.
Меня на самом деле удивляет что большинство атак являются vendor-nonspecific. Если не ставят D_LOCK (привет 2006!), то не ставит никто. Если есть проблемы с S3 resume script, то сразу у всех.
А вот косяков реализации конкретных ведоров (всякие buffer overflow, нарушения логики SMI-обработчиков) не слышно. Не исследуют? Или просто вендоров и реализаций куча?
Исследуют, но такие косяки обычно исправляют молча, т.к. IBV не дают разрешение на публикацию деталей уязвимости. Самое смешное, что скрываться в данном случае не только вредно со всех точек зрения, кроме маркетинговой, но и совершенно бессмысленно — о том, что какая-то уязвимость исправлена, можно узнать банально исследуя разницу между двумя версиями прошивки. Причем делать это можно не только вручную, но и автоматически, благодаря проекту Тедди Рида Subzero.io.
Не вернут, и дело точно не в работе, скорее в том, что решения. принятые более 10 лет назад, изменить будет не так просто. Кто о безопасности NVRAM уже задумался — у тех есть и его резервное копирование, и защита от разрушения, и восстановлние после сбоя, и возможность преноса в отдельную микросхему, но массовому рынку это все просто не нужно — «работает, и слава Богу».
Появятся, конечно, рано или поздно, так или иначе.
Но на данный момент "юзерленд по прежнему в полной Ж", а разработка вирусов для Windows стоит дешевле и окупается быстрее, чем разработка руткитов для UEFI.
Главное, что о безопасности задумались вообще, а то ведь 10 лет до этого сидели с открытой на запись микросхемой и не парились совсем, а теперь вот то одну уязвимость закроют, то другую.
парни в Insyde слегка перестарались с защитой, имею девайс с их UEFI без legacy CSM, так вот, новый BootXXXX для внутреннего eMMC можно добавить только если он имеет boot file "/EFI/Microsoft/Boot/bootmgr.efi", никакие другие не сохраняются после перезагрузки. Просто происходит дроп всех BootXXXX, которые не bootmgr.efi или usb-hdd, usb-cdrom.
ковырялся пару дней, попробовал все варианты разбития eMMC, в итоге пришлось вкорячить прикидывающийся «Windows Boot Manager» rEFInd.
Не где-то там а в CMOS — единственном месте где старый BIOS может хранить свои настройки. Доступ туда осуществлялся через 70 и 71 порт, конструкция была очень простой.
В принципе и на современных виндовс можно получить туда доступ установив специальный драйвер который популярен у радиолюбителей (проброс портов в UserSpace). Но всё осложняется тем что доступ не атомарный, в любой момент другой процесс может помешать работе вашего приложения. Виндовс довольно активно обращается туда чтобы считать время, поэтому с большой степенью вероятности попытка попортить настройки записью одного байта приведет только к порче времени, которое не находится под защитой контрольной суммы. Нужно активно писать туда чтобы быть уверенным в успехе.
>> штатная Linux'овая утилита efibootmgr. В зависимости от фазы луны и интенсивности космических лучей, иногда при очередном обновлении ядра у нее получается не только добавить очередную переменную BootXXXX
у меня в этом замечены последние версии Вин10.
История такова, появляется двойная запись на одну инсталлированную Вин10.
Можно в коде активировать костыль, не показывать(hide) первую из дупликаций BootXXXX, но тогда при смене диска на другой, со старой версией виндовс, не видно ни одной записи зарузки.
О безопасности UEFI, часть четвертая