Если делать полный ресет — будет, а если нет? Там сейчас всяких ресетов разных видимо-невидимо, а на PCH есть такое отличное устройство Integrated Sensor Hub, к которому пользователь может написать свою прошивку собственную.
Понятно, что это все — страшно дорогая целевая атака, которую нет смысла даже пытаться применять по площадям против условного слесаря Васи (фишинг и рассылка вирусов отлично работают там уже, сложнее ничего не нужно), и статья больше про «это потенциально возможно сделать при условии что А, Б, Ц и звезды верно сошлись», чем про «любое повышение прав до рута позволяет взломать МЕ полностью и любить в нем гусей до старости лет». Тем не менее, баг отличный, и статья отличная, и пацаны — вообще ребята, пусть ищут и пишут еще.
Там сейчас к шине столько всякого хлама подключено, что задирать шину выше +5-10% чревато очень неприятными глюками в самых неожиданных местах вроде контролеров дисков или даже питания. Запрещают этот разгон нынче больше по старой памяти, чем по объективным маркетинговым причинам, на мой взгляд.
Далеко не все защищенные дисковым шифрованием машины имеют физические устройства ввода, и далеко не все таковые устройства имеют программируемые контролеры, пригодные для перехвата секрета из них. При этом интерпозер для SPI/LPC может быть сделал в виде платы размером с ноготь и установлен незаметно в корпус вашего выделенного сервера злонамеренным администратором дата-центра. Короче, если у вас физическая атака вне модели угроз — то внешний TPM может быть лучше внутреннего (он проще, интерфейс к нему стандартизирован, выпускают их разные производители, и потому при потере доверия к одному из них можно перейти на другого), а там, где таковая атака вероятна, внутренний TPM может быть лучшим выбором, плюс он еще и бесплатный зачастую.
В этом сегменте AMD очень долгое время был аутсайдером, и потому у многих вендоров просто нет своих специалистов по работе с их APU, а без таковых платы получаются или жручие, или падучие, или греющиеся как печка.
Те, кто в свое время не перестал выпускать продукцию на AMD (даже если она получалась не очень прибыльной, HP, например) теперь могут быстро наладить выпуск, а не кто залез в Intel с головой теперь думают, где бы им людей нанять срочно вчера, найти нужные (или восстановить утерянные) контакты с AMD, и проверить свои контракты с Intel на предмет подводных камней и троянских коней, чтобы потом не отдать им всю прибыль от продажи чужих процессоров в суде.
Зато значительно проще физически, потому что шина, к которой подключен отдельный TPM — либо LPC, либо SPI, и обе они и низкоскоростные, и старые достаточно, чтобы интерпозер для них имелся у любого минимально подготовленного атакующего.
Хороший встроенный TPM нужно было делать на отдельном кристалле внутри SoC, а не запускать его в виде процесса вместе с еще 2 мегабайтами всякого хлама, и его бы не сломали вместе с этим хламом. К сожалению, делать так получается дорого и долго, и поддержка получается дорогая, а с точки зрения прибыли нет никакой разницы между настоящей безопасностью и почти настоящей, и тем 0.0001% пользователей, которым эта разница действительно жизненно важна, обычно советуют делать свои собственные процессоры из своего собственного кремния на своих собственных заводах.
Статистики у меня нет, только ощущения, и по ним разницы какой-то особой на своих задачах я не заметил ни от программных патчей, ни от обновлений на более новые «исправленные» процессоры, потому что прогресс процессоров Intel после SkyLake практически остановился и идет исключительно за счет увеличения количества ядер на одном кристалле. Выход годных 10нм кристаллов IceLake до сих пор настолько кошмарно низкий, что выпустить их получилось только в виде мобильных огрызков с 9 Вт теплопакета и базовыми частотами в ~1 Ггц. Все остальное как было 14нм (Broadwell, 2014 год), так и остается в нынешнем 2020, и ожидаемые в этом году CometLake (т.е. 10 серия для десктопов и ее друзья — чипсеты 400 серии) — тот же самый SkyLake пятилетней давности, только только с большим количеством ядер за те же деньги.
В общем, если вам ядер не хватало — теперь их больше кладут, но AMD теперь их отгружает значительно бодрее за те же деньги. Если же не хватало чего-то еще, объема памяти, скорости дисковой подсистемы, и т.п. — устранять нужно именно это, и замена процессора на «новый-безопасный» сильно не поможет.
Там еще одна проблема, и за которой обновление отложили: ребята из MS не стали проверять, что оно вообще может быть установлено (т.е. что ключ МС присутствует в KEK), и пытаются писать в dbx даже тогда, когда права на это не имеют, и при этом воспринимают EFI_SECURITY_VIOLATION как критическую ошибку, и пугают пользователей сообщениями о ней. Надеюсь, в следующей итерации это исправят.
По поводу проблем с ноутбуками HP — там сработала система защиты переменных SecureBoot от несанкционированной записи, включенная по умолчанию. Система эта почему-то не удаляет ключ МС из КЕК при работе (это баг, потому что как еще сообщить коду ОС, что писать в db* нельзя?).
В общем, все как всегда: люди придумывают механизм обновления, которым никто никогда не пользовался, и потому он вообще не тестировался, а когда наконец им решили воспользоваться, оказалось, что детали работы этого механизма неизвестны ни тем, кто им решил воспользоваться, ни тем, кто его реализовывал. Бизнес как обычно.
Отнюдь, потому что это не те PRR'ы, а чипсетные, и подавай там напряжение на #WP или нет, на запись со стороны чипсета (а flashrom пишет именно чипсетным контролером) это не повлияет.
Не думаю, что там что-то сильно поменялось с 2015 года, когда я писал про Lenovo в ключе «стараются вроде, но недостаточно, и регулярно оскандаливаются то с одним, то с другим». HP и Dell по прежнему немного лучше в смысле безопасности, но разница не принципиальная, и против некоторых широко известных типов атак (DMA-атаки, например) они все одинаково не защищены.
В данном случае из шелла уже не выйдет, потому что SMM Dispatching к тому моменту давно уже закончился, и новые SMM-драйверы оттуда уже не запустить, так что придется нужный драйвер все равно в прошивку добавлять. Раньше там был баг с тем, что ОРОМы могли запускаться раньше, чем SMM-фаза заканчивалась, но его исправили довольно давно, и сейчас на него надеяться мало смысла.
Лучшим вариантом было бы добавить в прошивку свой SMM модуль, который UEFI бы легально разместил в SMRAM, чтобы не беспокоиться, что нашим кодом будет перезаписано что-то важное.
Вот тут можно сделать еще один шаг — если возможность внедрения собственного кода уже имеется, то можно предоставить собственный обработчик на незадействованный номер SMI, в котором будет не только необходимый шелл-код, но и патчер для всех остальных обработчиков, к которым несложно получить доступ (они связаны в глобальный список mSmiEntryList, и можно итерироваться по нему):
HM77 — это чипсет без поддержки AMT вообще, о чем первая строка и сообщает. Все остальное — это сами настройки уже, т.е. если чипсет сменить, а настройки — нет, то AMT заработает.
Там и у основной прошивки, и у МЕ есть области NVRAM, в которых хранятся переменные, способные меняться при каждой загрузке, так что эти отличия — это нормально вполне.
Опять у нас и safety переводят как «безопасность», и security, в итоге получается совершенно непонятно без контекста, о какой именно безопасности речь.
По теме же — все вот эти декларации о намерениях и комитеты начальников штабов — яйца не стоят выеденного без реальных продуктов, и могут закрыться так же быстро, как и собраться (вспоминается история с FlexRay, у которой в комитете тоже были звезды первой величины, и даже выпустили десяток автомобилей с ним, но потом все само по себе сошло на нет, потому что дорогущая шина оказалась мало кому нужна).
Добавлю про многозадачность еще: давно уже есть возможность использовать простаивающие при обычном запуске прошивки ядра для параллельного выполнения задач (к примеру, на Маках таким образом работает Internet Recovery, т.е. загрузка и проверка хешей кусков образа по 10Мб сделана параллельно и задействует все доступные ядра ЦП) через EfiMpServiceProtocol. В UEFI 2.7 похожий протокол добавили в PEI.
Ну и в качестве вишенки на торт: современные реализации EFI используют IOMMU, виртуальную память и разделение на ring-0 и ring-3 для изоляции опасных с точки зрения внешних атак драйверов, OptionROM'ов и приложений (слайды с презентации с BH).
Я сам не стал бы называть EFI полноценной ОС общего назначения (потому что чтобы стать таковой ей нужен EFI Shell), но не называть ее ОС совсем уже давно не получается даже с натяжкой. Я по прежнему считаю, что прошивка должна быть «создана, чтобы умирать», и потому большая часть нынешней спецификации UEFI в ней совершенно лишняя, и может быть без особых проблем заменена на Линукс или другую полноценную ОС, но у индустрии давно уже свое мнение на этот счет, не совпадающее с моим.
Добавлю тоже со своей колокольни, что язык если использовать по назначению — он доучится до нужного уровня самостоятельно, и если вам понадобится его улучшать (например, дорастете до позиции, в которой вся работа уже не с техникой, а с людьми, и где нужно много и правильно говорить и писать на английском, иначе успеха не добиться) — вы его улучшите неминуемо.
Я не советую останавливаться на B1, потому что это слишком низкий уровень для правильного восприятия культуры (а ее на английском сейчас очень много), т.е. серьезные научные статьи, взрослые книги и фильмы, театральные постановки и прочий контент не получится потреблять непосредственно, а только в адаптированном виде (все эти кошмарные сериалы с одноголосой озвучкой и кривым переводом вида «Рабинович напел»). Даже по нынешним переводным статьям на Хабре понятно, насколько «пережеванным дважды» получается результат такой адаптации…
Короче, учите английский до состояния «читаю реддит также легко, как пикабу, хакерсньюз также легко как хабр, смотрю фильмы в оригинале без субтитров», и откроете для себя огромный кусок информационного пространства, который раньше был доступен только в виде переводов кривых.
Еще есть интересный кейс — для безопасности. На устройстве, на которое прошивка заливается каждый раз при перезагрузке, невозможно закрепиться, и его не получится использовать как плацдарм для последующих персистентных атак. Более того, схема load-FW/lock-until-reset отлично заменяет другие, более сложные схемы безопасной загрузки. По сути, вместо переизобретения СекуреБута для каждого чипа нужно сделать его один раз нормально для главного чипа, и грузить прошивки в периферию уже из доверенной среды.
Если вносить неправильно, то толку от них в смысле безопасности не будет, только производительность упадет.
Вычислять, понятно, все равно придется, но нужно делать это так, чтобы количество (а значит и время) вычислений не зависело от значения байтов секрета (точнее, не было заметно, потому что совсем убрать эту зависимость сложно). Вот отличная подборка техник от известного криптолога, автора книги Serious Cryptography Жана-Филлипа Омассона.
Понятно, что это все — страшно дорогая целевая атака, которую нет смысла даже пытаться применять по площадям против условного слесаря Васи (фишинг и рассылка вирусов отлично работают там уже, сложнее ничего не нужно), и статья больше про «это потенциально возможно сделать при условии что А, Б, Ц и звезды верно сошлись», чем про «любое повышение прав до рута позволяет взломать МЕ полностью и любить в нем гусей до старости лет». Тем не менее, баг отличный, и статья отличная, и пацаны — вообще ребята, пусть ищут и пишут еще.
Те, кто в свое время не перестал выпускать продукцию на AMD (даже если она получалась не очень прибыльной, HP, например) теперь могут быстро наладить выпуск, а не кто залез в Intel с головой теперь думают, где бы им людей нанять срочно вчера, найти нужные (или восстановить утерянные) контакты с AMD, и проверить свои контракты с Intel на предмет подводных камней и троянских коней, чтобы потом не отдать им всю прибыль от продажи чужих процессоров в суде.
Хороший встроенный TPM нужно было делать на отдельном кристалле внутри SoC, а не запускать его в виде процесса вместе с еще 2 мегабайтами всякого хлама, и его бы не сломали вместе с этим хламом. К сожалению, делать так получается дорого и долго, и поддержка получается дорогая, а с точки зрения прибыли нет никакой разницы между настоящей безопасностью и почти настоящей, и тем 0.0001% пользователей, которым эта разница действительно жизненно важна, обычно советуют делать свои собственные процессоры из своего собственного кремния на своих собственных заводах.
В общем, если вам ядер не хватало — теперь их больше кладут, но AMD теперь их отгружает значительно бодрее за те же деньги. Если же не хватало чего-то еще, объема памяти, скорости дисковой подсистемы, и т.п. — устранять нужно именно это, и замена процессора на «новый-безопасный» сильно не поможет.
По поводу проблем с ноутбуками HP — там сработала система защиты переменных SecureBoot от несанкционированной записи, включенная по умолчанию. Система эта почему-то не удаляет ключ МС из КЕК при работе (это баг, потому что как еще сообщить коду ОС, что писать в db* нельзя?).
В общем, все как всегда: люди придумывают механизм обновления, которым никто никогда не пользовался, и потому он вообще не тестировался, а когда наконец им решили воспользоваться, оказалось, что детали работы этого механизма неизвестны ни тем, кто им решил воспользоваться, ни тем, кто его реализовывал. Бизнес как обычно.
Вот тут можно сделать еще один шаг — если возможность внедрения собственного кода уже имеется, то можно предоставить собственный обработчик на незадействованный номер SMI, в котором будет не только необходимый шелл-код, но и патчер для всех остальных обработчиков, к которым несложно получить доступ (они связаны в глобальный список mSmiEntryList, и можно итерироваться по нему):
По теме же — все вот эти декларации о намерениях и комитеты начальников штабов — яйца не стоят выеденного без реальных продуктов, и могут закрыться так же быстро, как и собраться (вспоминается история с FlexRay, у которой в комитете тоже были звезды первой величины, и даже выпустили десяток автомобилей с ним, но потом все само по себе сошло на нет, потому что дорогущая шина оказалась мало кому нужна).
Ну и в качестве вишенки на торт: современные реализации EFI используют IOMMU, виртуальную память и разделение на ring-0 и ring-3 для изоляции опасных с точки зрения внешних атак драйверов, OptionROM'ов и приложений (слайды с презентации с BH).
Я сам не стал бы называть EFI полноценной ОС общего назначения (потому что чтобы стать таковой ей нужен EFI Shell), но не называть ее ОС совсем уже давно не получается даже с натяжкой. Я по прежнему считаю, что прошивка должна быть «создана, чтобы умирать», и потому большая часть нынешней спецификации UEFI в ней совершенно лишняя, и может быть без особых проблем заменена на Линукс или другую полноценную ОС, но у индустрии давно уже свое мнение на этот счет, не совпадающее с моим.
Я не советую останавливаться на B1, потому что это слишком низкий уровень для правильного восприятия культуры (а ее на английском сейчас очень много), т.е. серьезные научные статьи, взрослые книги и фильмы, театральные постановки и прочий контент не получится потреблять непосредственно, а только в адаптированном виде (все эти кошмарные сериалы с одноголосой озвучкой и кривым переводом вида «Рабинович напел»). Даже по нынешним переводным статьям на Хабре понятно, насколько «пережеванным дважды» получается результат такой адаптации…
Короче, учите английский до состояния «читаю реддит также легко, как пикабу, хакерсньюз также легко как хабр, смотрю фильмы в оригинале без субтитров», и откроете для себя огромный кусок информационного пространства, который раньше был доступен только в виде переводов кривых.
Вычислять, понятно, все равно придется, но нужно делать это так, чтобы количество (а значит и время) вычислений не зависело от значения байтов секрета (точнее, не было заметно, потому что совсем убрать эту зависимость сложно). Вот отличная подборка техник от известного криптолога, автора книги Serious Cryptography Жана-Филлипа Омассона.