Ученый в очередной раз изнасиловал журналиста, к сожалению.
Я не спорю, что баг серьезный, и этот конкретный баг — только первая ласточка среди всех проблем с синхронными SMI, которые ждут своего часа. Дело в том, что, как и в свое время а ассинхронными SMI, никто из разработчиков технологии не воспринимал её как вектор атаки, и потому ревью кода обработчиков синхронных SMI практически не проводилось, ибо все считали, что вызвать эти самые обработчики атакующий не сможет, он ведь не знает нужного хендла (SmmBase->Communicate) или GUIDа (SmmCommunicate->Communicate), и формат буфера ему тоже неизвестен, да и вообще, кому это надо все. А потом пришел Дима и не просто все сломал, а еще и выложил все карты на стол.
Но вернемся к изнасилованию: в нынешнем виде эксплоит является приложением для UEFI shell, т.е. этот шелл нужно еще запустить как-то, т.е. нужен физический доступ к машине и отключенный SecureBoot (привет коментаторам, которые его костерят). Чтобы обойти это ограничение, нужна собственная реализация Communicate, которая тоже будет работать только из UEFI OS (для legacy OS обработчики синхронных SMI диспетчером не вызываются вообще, такая своеобразная защита от дурака). Сделать это можно, и я не сомневаюсь ни на секунду, что Дима это рано или поздно сделает, но сейчас поводов для паники нет никаких.
Более того, на платах Gigabyte, Asrock, ASUS, и прочих десктопных платах такого рода этот конкретный эксплоит вообще не имеет значения, ибо там можно достичь того же эффекта (получить полный доступ к SPI flash) значительно более простыми способами, так что эксплоит, даже если он на этих устаревших платах и работает, опасности для них не представляет, ибо нет смысла просачиваться через вентиляцию, когда у тебя либо двери вообще нет, либо ключ от нее — под ковриком.
Отдельно хочу возразить людям, которые в очередной раз убеждают меня в том, что современное железо буквально само инициализируется и там хватит микрокода на пару килобайт, а остальное все Великий и Открытый Линукс сделает за нас. Почти год, ребята. Почти год своей жизни, работая 40 часов в неделю, я потратил на то, чтобы довести плату conga-TR3 из состояния голое мертвое железо до состояния прошла все тесты и готова к массовому производству, имея при этом всю документацию, референсную реализацию UEFI и поддержку со стороны AMI и AMD. Если вы можете сделать то же самое хотя бы за полгода — подавайте резюме в любую компанию, Apple/Microsoft/Dell/HP/Lenovo/etc, любую — и вас там оторвут с руками, предложив не меньше $200к в год, релокацию, жилье, шахматы и поэтесс. И напишите мне оттуда потом, чтобы я еще сильнее загрустил, что тормоз такой.
Проверять этот лог можно и самой прошивкой, например, на событии EndOfDxe. Не сошлось с эталоном — дальше не грузимся. Понятно, что все это, без настоящего аппаратного корня доверия, будет рано или поздно отломано, поэтому HWVB внедрили практически все производители процессоров, которые хотят продать клиентам нормальную доверенную загрузку, а не суррогат.
С BootGuard вы ничего никуда не инжектируете, ибо процессор сначала проверяет, что у подписи первой половины тома PEI хеш совпал с тем, что в чипсет прошит при производстве, а затем только ресет отпускает. Т.е. попробуете влезть в фазу SEC — и система просто откажется включаться, перешиваем, запускаем — не запускается.
Выпаять TPM теперь тоже нельзя, т.к. он теперь в чипсет встроен, как у Intel начиная с BayTrail, так и у AMD начиная с Merlin Falcon.
Если говорить об атаках на более старые системы без BG и с внешним TPM — там все можно, конечно, но очень и очень непросто, ибо придется трассировать реально каждый вызов Extend, которые там начинаются с PeiAfterMem и до BDS их там получается порядка тысячи. Не заметил один — весь лог на смарку, откатывайся. Понятно, что это можно автоматизировать и обойти, но стоимость таких решений получается чуть ли не выше стоимости защищаемой ими информации, т.е. главная задача ИБ защитой таки решена.
TPM — устройство пассивное, и потому позволил тут вовсе не «Intel'овский TPM», драйвер PCI прошивки. Чаще всего, устройства PCI в measurement log не добавляют, т.к. их можно добавить позже при помощи Hotplug, плюс это создает кучу неудобств из серии «отключил сетевуху — отвалился BitLocker».
Прекрасно, снимаю шляпу.
Когда найду немного времени — напишу подробнее про TPM и firmware TPM, а то там конь не валялся и легенды про ужасный DRM ходят.
Непонятно, почему не использовать qmake для генерации проекта для VS, XCode, Ninja и черта лысого, чтобы у вас был MOC и остальные плюшки автоматически.
Для VS проект из файла .PRO генерируется вот так:
У ARM'ов там с одной стороны U-boot, который развивается семимильными шагами, а с другой стороны — UEFI, который тоже уже практически готов и наберет свою долю так или иначе, просто потому, что UEFI Forum — не самая слабая организация. Что же до coreboot, то там из применений для «массового зрителя» одни хромобуки и остаются, пожалуй, на ARM или нет.
Пока еще поддерживаются, но в будущем поддержка останется только у Wombat, скорее всего.
SAGE очень жаль, реально, прекрасная Gizmo2 осталась без прошивки, куча хороших людей потеряли работу, что будет с coreboot — совсем не ясно теперь, даже с учетом гугла…
Подозреваю, что на 1600 не проходит какой-то из тестов, которые в обычной жизни либо не встречаются совсем, либо встречаются крайне редко. Пример из моей практики прямо сейчас: на моей плате на AMD Merlin Falcon некоторые типы памяти SODIMM DDR4 (зависит от чипов, максимальной частоты и SPD, конкретнее я пока не знаю) откзываются определяться (и машина зависает с пост-кодом 0x5D, последним до начала тренировки памяти) во время теста «10000 инициированных ОС софт-ресетов с включенной сетевой картой и сохранением логов на сервере». Максимальная частота памяти на этой платформе — 2133 Мгц, если ограничить ее на 1866 Мгц — все хорошо, и почти любая память (за исключением прототипов с проблемами в SPD) проходит любые тесты. Т.к. сам тест длится кучу времени, а тренирувку памяти на этой платформе выполняет закрытый код PMU, на который может влиять только AMD, то мне, как автору прошивки, в миллион раз проще ограничить частоту сверху (еще и при ambient +80*C легче будет обеспечить работоспособность), чем отлаживать это поведение в обнимку с аппаратным отладчиком AMD Wombat в течение пары месяцев. Вот примерно из таких соображений и лимитируют, та же история с белыми списками совместимого оборудования, которые всех бесят, примерно та же — с QVL на модули памяти и остальным. А маркетологи были бы очень рады рекламировать совместимость с более быстрой памятью, но тут им слова не дали.
После того, как оказалось, что к себе домой гугломобиль и гуглолюдей остальные люди пускать не намерены, а данные о помещениях этому самому гуглу как-то нужно собирать, появилась идея встроить в очередной «смартфон» сканер этих самых помещений. При этом, понятно, всем расскажут, что вот оно — будущее, а тот факт, что та же задача решается пространственным воображением за миллисекунды — никого не волнует, т.к. из воображения гугл пока еще данные доставать не научился, зато из «смартфонов» — еще как.
Автор схемы, скорее всего, под PE_RST_N имел в виду вывод микроконтролера, т.к. именно так он назван в даташите на него. PERST# — имя сигнала (или сети) PCIe reset, к которому нога PE_RST_N подключена. Две разные сущности — два разных имени, ничего необычного.
Плюс поставил, хоть и стена текста. Одно только покоробило: PE_RST_N и PERST# — выделенное сразу дает понять, что активный уровень этого сигнала — низкий, и это не недостаток качества документации, а недостаток знаний принятых в индустрии обозначений.
Спасибо за статью, хоть она и насквозь рекламная.
Одна просьба: пользуйте, пожалуйста, стандартное оформление статей вместо этого «модного», а то за один только дурацкий эффект «меееедленное появление текста при прокрутке» хочется убивать, ведь на него тратися время и он сбивает фокус. В итоге, уже к середине статьи хочется взять адблок и вырезать к чертовой бабушке весь джаваскрипт со страницы. И шрифт слишком крупный, и текст зажат между пустыми белыми полями, и изображение сверху не несет никакой нагрузки… Пожалейте читателей, иначе их очень быстро не станет совсем.
Программы пишутся не только (и не столько) для компьютеров, но и для программистов. И писать их нужно так, чтобы их мог читать, понимать и изменять человек, а не машина. А тут предлагается ради упрощения парсеров и улучшения подсказок (которыми не пользуется процентов 30-40 разработчиков на низкоуровневых языках) сломать последовательно и редакторы, и компиляторы, и системы контроля версий, и вообще практически все наработки вокруг программирования за последние 50 лет ради того, чтобы разработчикам утилит было проще жить. Бинарные логи systemd и реестр Windows — теперь у вас в IDE, ура!
Пока не придуман прямой интерфейс мозг-машина и мозг-мозг, текст — лучшее, что у нас есть. Пожалуйста, не трогайте его, с ним все хорошо и так.
Ключевые слова в вашем комментарии — «для себя и своих проектов». В этом случае хороши любые средства, и любое программирование, хоть велосипедов, хоть нет — на пользу. А вот на деньги компании стоит заниматься решением задач, а не написанием своего кода на каждый чих. Если эти задачи можно решить вообще без кода — лучше решать их именно так, ибо у ненаписанного кода нулевые затраты на сопровождение, а если нельзя — стоит в любом случае рассмотреть использование готовых решений, прежде чем бросаться писать собственное.
Я вот прямо сейчас пытаюсь решить задачу замены QString, QByteArray и QDir/QFile/QFileInfo на отдельные классы вне Qt, чтобы отвязать от нее свой движок для разбора файлов UEFI. И если с последними еще как-то можно справиться при помощи boost:fs, а второй эмулировать поверх std::basic_string<uint8_t>, то что делать с QString — решительно непонятно. На что заменить tr().arg()? Как сделать конструктор, принимающий форматную строку и переменное число аргументов, не занимаясь при этом велосипедостроением. Пока использую cbstring и его метод format, но это боль, кровь, кишки и переписывание тысячи строк кода.
Даже в области работы с железом и прошивками сложность решений такова, что подобная стратегия — пустая трада времени специалиста и денег компании. Если вы этим занимаесь дома в качестве хобби — прекрасно, но если вы вместо использования готовых, оттестированных, качественных решений предпочитаете собственный велосипед, который нужно сначала весь написать, затем отладить, а затем поддерживать (причем чаще всего силами других специалистов) — вы либо гениальный разработчик, либо кошмарный велостроитель.
Повторное использование отлаженного кода — одна из целей любого программирования начиная с процедурного, т.е. с 60 годов прошлого века, и желание «все взять и переписать» нужно у новичков купировать сразу же, иначе никакой пользы они не принесут. Понятно, что случаи бывают разные, и иногда решений либо нет совсем, либо они не устраивают по каким-то объективным причинам, но «не понимаю, как устроено» и «я уверен, что могу написать лучше» — причины весьма плохие.
Я не спорю, что баг серьезный, и этот конкретный баг — только первая ласточка среди всех проблем с синхронными SMI, которые ждут своего часа. Дело в том, что, как и в свое время а ассинхронными SMI, никто из разработчиков технологии не воспринимал её как вектор атаки, и потому ревью кода обработчиков синхронных SMI практически не проводилось, ибо все считали, что вызвать эти самые обработчики атакующий не сможет, он ведь не знает нужного хендла (SmmBase->Communicate) или GUIDа (SmmCommunicate->Communicate), и формат буфера ему тоже неизвестен, да и вообще, кому это надо все. А потом пришел Дима и не просто все сломал, а еще и выложил все карты на стол.
Но вернемся к изнасилованию: в нынешнем виде эксплоит является приложением для UEFI shell, т.е. этот шелл нужно еще запустить как-то, т.е. нужен физический доступ к машине и отключенный SecureBoot (привет коментаторам, которые его костерят). Чтобы обойти это ограничение, нужна собственная реализация Communicate, которая тоже будет работать только из UEFI OS (для legacy OS обработчики синхронных SMI диспетчером не вызываются вообще, такая своеобразная защита от дурака). Сделать это можно, и я не сомневаюсь ни на секунду, что Дима это рано или поздно сделает, но сейчас поводов для паники нет никаких.
Более того, на платах Gigabyte, Asrock, ASUS, и прочих десктопных платах такого рода этот конкретный эксплоит вообще не имеет значения, ибо там можно достичь того же эффекта (получить полный доступ к SPI flash) значительно более простыми способами, так что эксплоит, даже если он на этих устаревших платах и работает, опасности для них не представляет, ибо нет смысла просачиваться через вентиляцию, когда у тебя либо двери вообще нет, либо ключ от нее — под ковриком.
Отдельно хочу возразить людям, которые в очередной раз убеждают меня в том, что современное железо буквально само инициализируется и там хватит микрокода на пару килобайт, а остальное все Великий и Открытый Линукс сделает за нас. Почти год, ребята. Почти год своей жизни, работая 40 часов в неделю, я потратил на то, чтобы довести плату conga-TR3 из состояния голое мертвое железо до состояния прошла все тесты и готова к массовому производству, имея при этом всю документацию, референсную реализацию UEFI и поддержку со стороны AMI и AMD. Если вы можете сделать то же самое хотя бы за полгода — подавайте резюме в любую компанию, Apple/Microsoft/Dell/HP/Lenovo/etc, любую — и вас там оторвут с руками, предложив не меньше $200к в год, релокацию, жилье, шахматы и поэтесс. И напишите мне оттуда потом, чтобы я еще сильнее загрустил, что тормоз такой.
Выпаять TPM теперь тоже нельзя, т.к. он теперь в чипсет встроен, как у Intel начиная с BayTrail, так и у AMD начиная с Merlin Falcon.
Если говорить об атаках на более старые системы без BG и с внешним TPM — там все можно, конечно, но очень и очень непросто, ибо придется трассировать реально каждый вызов Extend, которые там начинаются с PeiAfterMem и до BDS их там получается порядка тысячи. Не заметил один — весь лог на смарку, откатывайся. Понятно, что это можно автоматизировать и обойти, но стоимость таких решений получается чуть ли не выше стоимости защищаемой ими информации, т.е. главная задача ИБ защитой таки решена.
Когда найду немного времени — напишу подробнее про TPM и firmware TPM, а то там конь не валялся и легенды про ужасный DRM ходят.
Для VS проект из файла .PRO генерируется вот так: Для XCode — вот так:
SAGE очень жаль, реально, прекрасная Gizmo2 осталась без прошивки, куча хороших людей потеряли работу, что будет с coreboot — совсем не ясно теперь, даже с учетом гугла…
Одна просьба: пользуйте, пожалуйста, стандартное оформление статей вместо этого «модного», а то за один только дурацкий эффект «меееедленное появление текста при прокрутке» хочется убивать, ведь на него тратися время и он сбивает фокус. В итоге, уже к середине статьи хочется взять адблок и вырезать к чертовой бабушке весь джаваскрипт со страницы. И шрифт слишком крупный, и текст зажат между пустыми белыми полями, и изображение сверху не несет никакой нагрузки… Пожалейте читателей, иначе их очень быстро не станет совсем.
Программы пишутся не только (и не столько) для компьютеров, но и для программистов. И писать их нужно так, чтобы их мог читать, понимать и изменять человек, а не машина. А тут предлагается ради упрощения парсеров и улучшения подсказок (которыми не пользуется процентов 30-40 разработчиков на низкоуровневых языках) сломать последовательно и редакторы, и компиляторы, и системы контроля версий, и вообще практически все наработки вокруг программирования за последние 50 лет ради того, чтобы разработчикам утилит было проще жить. Бинарные логи systemd и реестр Windows — теперь у вас в IDE, ура!
Пока не придуман прямой интерфейс мозг-машина и мозг-мозг, текст — лучшее, что у нас есть. Пожалуйста, не трогайте его, с ним все хорошо и так.
Повторное использование отлаженного кода — одна из целей любого программирования начиная с процедурного, т.е. с 60 годов прошлого века, и желание «все взять и переписать» нужно у новичков купировать сразу же, иначе никакой пользы они не принесут. Понятно, что случаи бывают разные, и иногда решений либо нет совсем, либо они не устраивают по каким-то объективным причинам, но «не понимаю, как устроено» и «я уверен, что могу написать лучше» — причины весьма плохие.
Rust с каждым релизом все ближе к UEFI, скоро, скоро праздник будет и на моей улице, и я смогу писать на нем DXE- и SMM-драйверы почти без костылей.