UEFI *

Перед вами третья часть моего повествования о форматах NVRAM, используемых UEFI-совместимыми прошивками различных производителей. В первой части я рассказывал об NVRAM вообще и о «стандартном» формате VSS, во второй — об интересных блоках, которые можно найти рядом с NVRAM в этом формате, а в этой речь пойдет о целой россыпи различных форматов, используемых в прошивках на платформе Phoenix SCT: FlashMap, EVSA, Intel uCode, CMDB, SLIC pubkey и SLIC marker.
Если вам интересно, что умудрились напридумывать на замену VSS разработчики из Phoenix — добро пожаловать под кат, только предупреждаю сразу, статья получилась достаточно длинной.

Продолжаем разговор о форматах NVRAM в UEFI-совместимых прошивках, начатый в первой части. На этот раз на повестке дня форматы блока Fsys из прошивок компании Apple, блока FTW из прошивок, следующих заветам проекта TianoCore, и блока FDC, который можно найти в прошивках, основанных на кодовой базе компании Insyde.
Если вам интересно, зачем нужны и как выглядят не-NVRAM данные, которые можно обнаружить рядом с NVRAM в прошивках различных производителей — добро пожаловать под кат.

Здравствуйте, уважаемые читатели. Когда-то очень давно, почти 3 года назад, я написал пару статей о форматах данных, используемых в UEFI-совместимых прошивках. С тех пор в этих форматах мало что изменилось, поэтому писать про них снова я не буду. Тем не менее, в тех статьях был достаточно серьезный пробел — отсутствовали какие-либо упоминания об NVRAM и используемых для её хранения форматах, т.к. тогда разбор NVRAM мне был попросту неинтересен, ибо те же данные можно получить из UEFI Shell на работающей системе буквально одной командой dmpstore.
По прошествии трех лет выяснилось, что хранилище NVRAM умеет разваливаться по различным причинам, и чаще всего это событие приводит к «кирпичу», т.е. воспользоваться вышеупомянутой командой уже не получится, а данные (или то, что от них осталось) надо доставать. Собрав пару развалившихся NVRAM'ов вручную в Hex-редакторе, я сказал "хватит это терпеть!", добавил поддержку разбора форматов NVRAM в UEFITool NE, и решил написать цикл статей об этих форматах по горячим следам и свежей памяти.
В первой части поговорим о том, что вообще такое этот NVRAM, и рассмотрим формат VSS и его вариации. Если интересно — добро пожаловать под кат.

Появляется такая задача не часто, но все-же, нужно преобразовать уже установленную систему, загружаемую в BIOS (или UEFI режиме) в UEFI режим (в BIOS соответственно).
Кому интересно, читаем далее:

В прошлой статье про SecureBoot мне очень не хватало возможности сделать снимок экрана при настройке UEFI через BIOS Setup, но тогда выручило перенаправление текстовой консоли в последовательный порт. Это отличное решение, но доступно оно на немногих серверных материнских платах, и через него можно получить только псевдографику, а хотелось бы получить настоящую — она и выглядит приятнее, и вырезать ее каждый раз из окна терминала не надо.
Вот именно этим мы и займемся в этой статье, а заодно я расскажу, что такое DXE-драйвер и как написать, собрать и протестировать такой самостоятельно, как работают ввод с клавиатуры и вывод на экран в UEFI, как найти среди подключенных устройств хранения такое, на которое можно записывать файлы, как сохранить что-нибудь в файл из UEFI и как адаптировать какой-то внешний код на С для работы в составе прошивки.
Если вам все еще интересно — жду вас под катом.

Данные обещания надо выполнять, тем более, если они сделаны сначала в заключительной части опуса о безопасности UEFI, а потом повторены со сцены ZeroNights 2015, поэтому сегодня поговорим о том, как заставить UEFI SecureBoot работать не на благо Microsoft, как это чаще всего настроено по умолчанию, а на благо нас с вами.
Если вам интересно, как сгенерировать свои собственные ключи для SecureBoot, как установить их вместо стандартных (или вместе с ними), как подписать ваш любимый EFI-загрузчик, как запретить загрузку неподписанного или подписанного чужими ключами кода, как выглядит интерфейс для настройки SecureBoot у AMI, Insyde и Phoenix и почему это, по большому счету, совершенно не важно — добро пожаловать под кат, но опасайтесь большого количества картинок и длинных консольных команд.

Согласно спецификации Unified Extensible Firmware Interface программная среда, обеспечивающая выполнение инициализационных процедур до загрузки операционной системы, не поддерживает многопотоковую обработку. Основная причина – однопотоковая идеология UEFI и, как следствие, нереентерабельность сервисных процедур UEFI API. Вместе с тем, ряд задач не связанных с вызовом сервисных функций (например, тестирование оперативной памяти) не только допускают параллельное выполнение несколькими программными потоками, но и получают от такого похода прибавку производительности.

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

Если вам интересно, чем безопасности прошивки могут помочь STM, SGX и PSP — жду вас под катом.

Желая показать бунтарский дух и наплевательство на традиции, ссылки на предыдущие части не даю — сами ищите их там.

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

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

Впервые о SecureBoot речь зашла в стандарте UEFI 2.2 в 2011 году, но окончательно все аспекты были реализованы в версии 2.3.1C в начале 2012 года. Основным разработчиком технологии была Microsoft, которая сразу же заявила, что для получения сертификата Windows 8 Ready для своей еще не выпущенной новой ОС требуется реализация и включение SecureBoot по умолчанию на всех новых ПК. Это заявление вызвало волну резкой критики со стороны сторонников свободного ПО, которая успешно докатилась и до Хабра.
Если вам интересно, чем именно закончилось противостояние MS и сообщества, как SecureBoot выглядит после почти 4 лет взросления, и какие атаки на него все еще возможны — добро пожаловать под кат.

Стоп, чуть не забыл: по доброй традиции, набор ссылок на предыдущие части, для тех, кто умудрился их пропустить.

Продолжаем говорить о безопасности UEFI, на этот раз речь пойдет об атаках на NVRAM и защите от них.
Неплохая, казалось бы, идея о том, что на микросхеме SPI можно хранить настройки практически вечно, не полагаясь на ненадежную и зависящую от батарейного питания CMOS SRAM, сыграла с разработчиками UEFI весьма злую шутку, теперь NVRAM с каждой новой версией стандарта обрастает все большим количеством костылей и подпорок, и конца этому процессу не видно. Если вам интересно, что именно пытаются подпереть костылем — эта статья для вас.
По традиции, всех, кто еще по каким-то причинам не читал первые три части — рекомендую начать с них, остальных с нетерпением жду под катом.

Продолжаем разговор о безопасности UEFI.
На этот раз речь пойдет об опубликованной в конце 2014 года серьезной уязвимости в реализации ACPI S3 (Sleep Mode), ее эксплуатации и последствиях. Основная «фишка» этой уязвимости в том, что она вскрыла целый класс проблем безопасности 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 и/или выбора загрузочного устройства. Совсем, абсолютно. При этом и с внешних устройств грузиться даже не пытался, упорно запускаясь с внутреннего винта и разумеется снова уходя в бесконечное кольцо попыток загрузки.