UEFI *

Продолжаем начатый в прошлом посте разговор о безопасности UEFI, об угрозах и имеющихся защитах от них.
В этот раз речь пойдет об SMM, о том, как он устроен и работает, и почему является желанной целью для атаки.
Пропустившим нулевую и первую части сего опуса — рекомендую прочесть сначала их, остальных покорно прошу под кат.

Когда-то давно, в начале 2014 года, я назвал состояние безопасности большинства реализаций UEFI "полумифическим". С тех пор минуло полтора года, дело осторожно двигается с мертвой точки, но до сих пор очень многие производители ПК для конечного пользователя не обращают на эту самую безопасность почти никакого внимания — «пипл хавает».
В этой статье речь пойдет о модели угроз и векторах атаки на UEFI, а также о защитах от перезаписи содержимого микросхемы BIOS — самой разрушительной по возможным последствиям атаки.
Если вам интересно, как устроена защита UEFI и какие именно уязвимости в ней так и остаются неисправленными на большинстве современных систем — добро пожаловать под кат.

В последней части цикла я постараюсь рассказать о новшествах стандарта UEFI 2.5, первые реализации которого должны появиться примерно через полгода на новых платах с процессорами Intel Skylake и AMD R-Series. В первой и второй частях речь шла о более низкоуровневых (и потому менее интересных неспециалистам) стандартах PI 1.4 и ACPI 6.0, здесь же поговорим об изменениях, напрямую влияющих на работу ОС и возможности загрузки по сети. Если вы хотите узнать, что нового в UEFI 2.5, почему PXE уходит в прошлое и зачем UEFI поддержка WiFi и Bluetooth — искренне прошу под кат.

Продолжаем знакомство с новыми возможностями недавно вышедших из под пера UEFI Forum стандартов, и если в предыдущей части речь шла о внутреннем стандарте PI, то на этот раз она пойдет об ACPI 6.0 и его отличиях от предыдущей версии 5.1.
Если вам интересно, что именно изменилось за 10 месяцев разработки стандарта, и какими новшествами нас порадуют или огорчат будущие системы с поддержкой ACPI 6.0 — добро пожаловать под кат.

После полугода разработки организация UEFI Forum выложила наконец в открытый доступ документацию по новым стандартам Platform Initialization 1.4, Advanced Configuration and Power Interface 6.0 и Unified Extensible Firmware Interface 2.5, на базе которых сейчас разрабатывается абсолютное большинство прошивок для ПК и серверов.
Обычно между выпуском новых версий стандартов и первыми прошивками на их базе проходит обычно от 4 до 6 месяцев, но уже сейчас можно предсказать с высокой долей вероятности, какие именно новые возможности появятся в UEFI для платформ на базе процессоров Intel Skylake и AMD Falcon Series.
Я решил разделить описание новшеств на 3 части, иначе оно рискует оказаться очень длинным и читать его никто не станет. Если вас интересуют новшества, описанные в стандарте PI 1.4 и мои комментарии к ним — добро пожаловать под кат.

Помните те времена, когда BIOS был 16-битным с адресным пространством в 1 Мб, а вся информация о загрузчиках писалась в MBR? На смену уже давно пришли более гибкие технологии: UEFI (замена BIOS), и GPT (замена MBR).

Предыстория: Понадобилось мне недавно на свой домашний десктоп поставить 2 системы, чтобы разграничить окружение. Kubuntu для разработки на Ruby on Rails (ибо работаю удаленно), и Windows для всяких игрушек в свободное время. Хочу заметить, что несколько лет назад это было достаточно просто: один раздел для винды и один раздел для линукса, загрузчик записывался в MBR. Однако, технологии не стоят на месте, и оказалось, что настройка dual boot'а теперь несколько изменилась.

Разработка прошивок, даже если она ведется не на ассемблере для экзотических архитектур, а на C для i386/amd64 — дело весьма непростое, да и цена ошибки может быть крайне высокой, вплоть до выхода целевой аппаратной платформы из строя, поэтому использование различных техник предотвращения ошибок на самых ранних этапах разработки — необходимость.

К сожалению, о формальной верификации или использовании MISRA C в случае UEFI-прошивок остается только мечтать (с другой стороны, мало кто хочет тратить на разработку прошивки пару лет и 50% бюджета проекта), поэтому сегодня поговорим о статическом анализе, а точнее — о популярном на Хабре статическом анализаторе PVS-Studio, которым попытаемся найти ошибки в открытом коде UEFI для Intel Galileo.

За результатами проверки покорнейше прошу под кат.

Здравствуйте, коллеги!

Хочу снова поделиться интересным случаем решения проблемы, и сэкономить вам время и нервы на её решении. Принесли мне тут на днях для реанимации ноутбук вот с такими же симптомами:



Сразу сделаю отступление — указанный в описании видео метод реанимации в данном случае не помог совершенно никак. Почему — описано ниже.

Предыстория проста: работали себе пользователи на ноуте спокойно, ничего страшного не делали. Система предложила обновиться до 8.1 — согласились. Система начала обновляться, ушла на перезагрузку и на этом всё. Неустранимый BSOD с кодом ошибки «ACPI_BIOS_ERROR». До меня ноутбук уже таскали к местному знатоку, он попробовал всё, что смог навскидку проверить, после чего развел руками и отправил ко мне, потому что в придачу к стабильному BSODу ноутбук категорически отказывался реагировать на горячие клавиши входа в меню UEFI и/или выбора загрузочного устройства. Совсем, абсолютно. При этом и с внешних устройств грузиться даже не пытался, упорно запускаясь с внутреннего винта и разумеется снова уходя в бесконечное кольцо попыток загрузки.

В одной из предыдущих публикаций[1] мы затронули такой, казалось бы, очевидный вопрос: «Как убедиться в том, что флешка работает в USB 3.0?» Голоса в обсуждении сначала ехидно отметили, что той статье не хватает тэга «садомазо», а затем как бы испугавшись собственного эго, вычеркнули эту мысль из нашего сознания.

Но эта мысль уже ранила неокрепшие умы экспериментаторов. Появилось желание проверить доступность USB 3.0 для любого подключенного устройства еще на этапе старта (например, в UEFI Shell) до запуска операционной системы.

Здравствуйте, уважаемые читатели Хабра.
С вами снова я и мы продолжаем копаться в различных реализациях UEFI во имя добра. Есть у меня один старый китайский GSM-модем, который на моем Dell Vostro 3360 определяется через раз, а на более старых ноутбуках — нормально. После нескольких экспериментов с подключением его через переходник к основному ПК выяснилось, что ему почему-то не нравится подключение через PCIe Gen2, и хотелось бы переключить порт на Gen1, но в UEFI Setup нужной настройки не оказалось. Печально, но не смертельно, ведь очень часто производители устройств не удаляют оригинальные меню производителя UEFI, а просто скрывают их, либо показывают на их месте свои, поэтому после небольшого реверс-инжиниринга оригинальное меню можно вернуть на место, что у меня и получилось. В этот раз одной IDA Demo уже не обойтись, т.к. DXE-драйверы в большинстве современных UEFI собираются для архитектуры x86-64, поэтому вместо нее будем использовать radare2.
На лавры первооткрывателя не претендую и подобным модификациям сто лет в обед, но постараюсь показать, как сделать подобную модификацию самостоятельно.
Если вам все еще интересно — добро пожаловать под кат.

И снова здравствуйте, уважаемые хабрачитатели.

В рамках борьбы за возможность модификации UEFI на ноутбуках HP пришлось отломать еще одну защиту, на этот раз более современную. Видимо, отдел разработки прошивок в HP догадался, что предыдущая защита была не ахти, и потому они решили радикально её улучшить, поэтому метод обхода защиты DXE-тома из предыдущей статьи перестал работать, и мне опять понадобилось вооружаться дизассемблером, разрабатывать конвертер из TE в PE и отвечать на те же вопросы: где находится цифровая подпись, кто именно ее проверяет и как сделать так, чтобы проверка всегда заканчивалась успехом.

Если вас интересуют ответы и описание процесса их поиска — прошу под кат.

Здравствуйте, уважаемые читатели Хабра.

После долгого перерыва с вами опять я и мы продолжаем копаться во внутренностях UEFI. На этот раз я решил показать несколько техник, которые позволяют упростить реверс и отладку исполняемых компонентов UEFI на примере устаревшего-но-все-еще-популярного PEI-модуля SecureUpdating, который призван защищать прошивку некоторых ноутбуков HP от модификации.

Предыстория такова: однажды вечером мне написал знакомый ремонтник ноутбуков из Беларуси и попросил посмотреть, почему ноутбук с замененным VideoBIOS'ом не хочет стартовать, хотя такой же точно рядом успешно стартует. Ответ оказался на поверхности — не стартующий после модификации ноутбук имел более новую версию UEFI, в которую добрые люди из HP интегрировали защиту от модификации DXE-тома (а там и находится нужный нам VideoBIOS вместе с 80% кода UEFI), чтобы злобные вирусы и не менее злобные пользователи ничего там не сломали ненароком. Тогда проблема решилась переносом PEI-модуля SecureUpdating из старой версии UEFI в новую, но через две недели тот же человек обратился вновь, на этот раз на похожем ноутбуке старая версия модуля работать отказалась, и моя помощь понадобилась вновь.
Если вас заинтересовали мои дальнейшие приключения в мире UEFI PEI-модулей с дизассемблером и пропатченными переходами — добро пожаловать под кат.

Пост написан по мотивам публикации «Живительная флешка».

Предисловие

Доброго времени суток, Хабр. Совсем недавно, читая Хабр, наткнулся на статью Живительная флешка, где был описан способ создания мультизагрузочной флешки с набором полезных утилит, разнообразных систем и т.д. И все бы ничего, да вот и тут зарыта собака — обратим внимание на эту ветку комментариев, в которой обсуждается работоспособность мультизагрузки в системах с UEFI. Таким образом я начал собственное расследование искать универсальный способ решения этой проблемы.

Здравствуйте, уважаемые читатели Хабра.
После небольшого перерыва я продолжаю публикацию моих заметок (первая, вторая) о разработке и отладке компонентов UEFI на открытой аппаратной платформе Intel Galileo. В третьей части речь пойдет от подключении JTAG-отладчика на базе FT2232H к Galileo и о настройке отладочного окружения для нее.

Здравствуйте, уважаемые хабровчане.
Опрос в первой части показал, что тема разработки UEFI-драйверов достаточно интересна сообществу, поэтому я приступаю к написанию дальнейших частей этого цикла. В этой речь пойдет о подготовке платы Intel Galileo к работе, необходимом и желательном железе и ПО, сборке и установке BSP. В результате получится недорогая аппаратная платформа, пригодная для аппаратной отладки UEFI-драйверов и доступная любому энтузиасту.

Здравствуйте, уважаемые хабрачитатели.

Многим из вас может быть интересна тема разработки и отладки кода UEFI-драйверов и приложений, которая пока еще недостаточно широко освещена в сети, но к которой мне посчастливилось иметь непосредственное отношение.

В связи с этим я планирую написать цикл статей о разработке и отладке UEFI-драйверов на аппаратной платформе Intel Galileo Gen 1, т.к. эта платформа обладает, на мой взгляд, наилучшим соотношением цена/качество для вышеуказанной задачи.

Первая часть статьи является вводной, в ней я расскажу о стандарте UEFI, проекте TianoCore и его недостатках, o внезапном решении Intel и их плате Galileo, о причинах выбора именно этой аппаратной платформы в качестве базовой и о планах на следующие части.

Инструкция для новичков, о том, как сделать красивый dualboot windows и archlinux (и других ОС) через efi без grub и лишних заморочек.

Фото для привлечения внимания:

Я решил сделать дисковый массив на платформе Intel Atom D410PT. Это материнская плата с пассивным охлаждением процессора, два слота памяти (максимум 4Gb), один слот PCI (который я использовал для контроллера SATA SiliconImage 3512 — 2x1.5Gb/s), 2 SATA (3.0Gb/s) разъема, LAN 100mb/s, и многочисленными USB 2.0 портами (в том числе и на самой материнской плате).
Сама плата поместилась легко в корпус NaviPower PIX-1001 230W. Полное описание моих действий с железом я разместил на своем сайте.

Соответственно, т.к. было решено использовать 4 диска для создания RAID5 массива, то логично вырисовалось решение вынести операционную систему на внешний USB носитель (в моем случае USB HDD Seagate Freeagent GoFlex). Так как установка и настройка системы «с нуля» является зачастую долгим и кропотливым занятием, то я решил что система будет лежать на внешнем диске в контейнере VHDX, а так как материнка поддерживает UEFI, то соответственно и загрузка должна идти используя UEFI. Основная проблема была в том, что в интернете нет понятной инструкции, как это сделать. Вся информация очень разрознена, и описываются только части решения этой задачи.

Одним из важнейших нововведений спецификации Unified Extensible Firmware Interface явилось появление и интеграция в firmware персональной платформы особой операционной среды UEFI Shell, позволяющей выполнять небольшие задачи или UEFI приложения без загрузки операционной системы. В этом контексте, в первую очередь речь идет о задачах, связанных с обслуживанием вычислительной системы: обновление firmware платформы и периферийных устройств, восстановление модулей операционной системы после различных сбоев, а также утилиты системной информации и диагностики. Упоминание об игровых приложениях, а тем более современных 3D играх в этом контексте прозвучит несколько парадоксально. И все же давайте попробуем ответить на вопрос: можно ли написать игру для выполнения в среде UEFI? Если можно, то как? Если нельзя, то почему?

В отличие от систем с архитектурой x86, использование UEFI (Unified Extensible Firmware Interface) на ARM-платформах не стало топом в IT-новостях. Из этого не следует, что расширяемый интерфейс фирменного программного обеспечения – идея только для рынка персональных компьютеров. Спецификация UEFI декларирует универсальные подходы для инициализации любого аппаратного обеспечения и его взаимодействия с операционной системой.

В силу того, что спецификация UEFI поддерживает все распространенные архитектуры вычислительных систем, хотелось бы сравнить их аппаратную производительность с «чистого листа», т.е. до запуска драйверной поддержки. Особенно интересно посмотреть на работу графики на конкурирующих процессорных платформах. Так ли она хороша, как об это говорят ее производители?