Pull to refresh
313
0
Николай Шлей@CodeRush

Firmware Security Engineer

Send message
Смотря откуда начинать, если у вас уже все заведено и есть BIOS и его сервисы (т.е. либо старый интерфейс interrupt call, либо новый UEFI) — никакой разницы нет, память уже работает, карту бери у прошивки и действуй.
Если же ничего нет, даже стека, а вы сами из флеша исполняетесь — заводить современный контролер памяти DDR3/DDR4 (т.е. опросить сам контролер, добраться до SPD через SMBus, считать оттуда конфигурацию, отправить контролеру нужные команды в нужном порядке, выполнить тренировку, отключить неработающие модули, и все остальное) намного сложнее, чем раньше.
Еррату не забудь еще, которую никто не читает.
«Мы обнаружили, что при определенных условиях у нас процессор намертво зависает. Чинить мы это, конечно, не будем, поэтому вы просто софт с вот такими инструкциями не запускайте».
Или еще лучше, «мы тут после нескольких лет производства обнаружили, что наше замечательное железо с DMA иногда пишет в физическую память по вот этим адресам, и портит там все. Не кладите туда ничего важного больше.»
Тут с отладчиком то не отладишь, а без отладчика можно вообще с ума сдуреть.
Самая большая проблема в том, что этот подход не масштабируется. Это у вас пока еще ОС маленькая, и ума хватает охватить ее целиком, думать как процессор, и вот это все. Реальные системы давно уже не укладываются целиком в голову одного человека, и потому нужно всеми силами разгружать эту самую голову, автоматизировать всю рутину, изучать инструменты, подходы, заниматься упрощением, декомпозицией, короче — снижением когнитивной нагрузки. Чем проще в вашем коде разобраться — тем этот код лучше, и даже если сейчас вы сами в нем сейчас разбираетесь досконально и «сразу видите ошибку», уже завтра это обязательно изменится.
Ошибки, которые сразу видно, можно даже за ошибки не считать, потому что они тривиально находятся и справляются, и вот после того, как их исправили, начинается самое интересное — ошибки в железе, ошибки, которые не повторяются, ошибки, связанные с взаимодействием нескольких частей системы, и т.п., и чем больше инструментов вы освоите (санитайзеры, статические анализаторы, визуализаторы карты памяти, обработчики точек останова, и все остальное, придуманное для отладки именно «тяжелых случаев») — тем лучше будет и для вас, и для пользователей вашей ОС, если таковые появятся.
Умение пользоваться инструментами, облегчающими жизнь и ускоряющими разработку — намного важнее умения обходиться без них, потому что время — ресурс невосполнимый. Опыт работы без отладчика придет сам, когда придется попасть в ситуацию вроде вашей, и можно даже специально тренировать этот навык иногда, когда время позволяет, но разработка ОС общего назначения на уже работающем оборудовании с доступными (и весьма развитыми) средствами отладки — это мазохизм в чистом виде.
А главное — никаких отладчиков, выводи в текстовый режим, либо в окошечки — повисло — ставь return'ы.
Для чего так себя мучать?
Сейчас есть DCI, который на современных десктопных платах включается тривиально, и в продаже открытой до сих пор есть Intel Galileo, у которой JTAG доступен через OpenOCD.
Понятно когда приходится прошивку на ранних стадиях через порт 80 отлаживать, потому что вокруг вообще ничего не инициализированно, но писать полноценную ОС без отладчика — это мазохизм и потеря времени.
Автоматизируйте все, что видите — сборку, развертывание, EFI stub напишите, чтобы легаси загрузку не использовать (заодно не придется в защищенный режим переходить, вы и так уже там), тратьте время непосредственно на ОС, а развертывание и тестирование пусть скрипты делают — им не скучно.
У i-Tool два недостатка (при вагоне достоинств) — плохая изоляция ручки, от чего она ощутимо греется при долгой работе, и не очень удачный механизм крепления жал (нужно сразу купить вторую гайку, потому что снимать ее с горячего жала довольно неприятно, пару раз чуть не получил этим жалом в глаз). В остальном — отличный инструмент.
c1 = -1;
… // Вот тут с с1 может и не случиться ничего, зависит от условий
freq[c1] += freq[c2];
Видимо не зря тут анализатор переживает…
У меня есть таковая от 2013 года, и только про самые первые шаги. Вообще посоветую вот эту статью, в которой авторы занимаются оптимизацией скорости загрузки, хотя она и не про «что происходит», а про «какого хрена так медленно», но и нужный вам вопрос тоже освещен неплохо.
При этом оно в главе про загрузчики, ага.

Про шпионское ПО я даже комментировать не стал, потому что там ничего другого, кроме как послать по вектору еще раз, в голову не приходит. Фанаты — они фанаты и есть, им сколько не рассказывай, почему так, а не иначе — все равно останешься махровым проприетарщиком, продавшимся капиталистам за корзину печенья.
Практически все, что здесь написано — не выдерживает никакой критики, извините. Просто по порядку первые несколько вещей:
В системах x86_64 есть программный пакет Intel Management Engine (IME) для удаленного управления системами.
Это не программный пакет, а аппаратно-программный комплекс.

Согласно собственному инструменту Intel, в IME есть непропатченные уязвимости.
Которые были пропатчены сразу же.

Траммелл Хадсон (Trammell Hudson) создал проект me_cleaner
Треммелл не имеет отношения к этому проект, а создал его итальянский студент Никола Корна.

Прошивка IME и программа System Management Mode (SMM), которая следует за ней на загрузке, основаны на операционной системе Minix и запускаются на отдельном процессоре Platform Controller Hub, а не основном ЦП системы.
PCH — это северный мост, и на отдельном процессоре запускается только прошивка ME, а SMM — это режим основного процессора x86, и код, работающий в нем, не имеет никакого отношения к Minix.
Затем SMM запускает на основном процессоре программу Universal Extensible Firmware Interface (UEFI)
Буллшит, UEFI — это не программа, а интерфейс, а SMM к UEFI вообще отношения не имеет, и тем более не реализует его. Запускается при старте не UEFI, а PI/AGESA, и первый код SMM стартует значительно позже, в фазе DXE.

Задача загрузчика — предоставить только что включенному процессору необходимые ресурсы для запуска операционной системы общего назначения вроде Linux. Во время включения нет не только виртуальной памяти, но и DRAM до момента поднятия ее контроллера. Затем загрузчик включает источники питания и сканирует шины и интерфейсы, чтобы найти образ ядра и корневую файловую систему.
Вот это все — вовсе не задача загрузчика. Задача загрузчика — считать с диска ядро ОС, распаковать его, отобразить в память и передать ему управление. Все описанное в цитате делается прошивкой, в задачи которой, кроме инициализации железа, входит еще и предоставление интерфейса для загрузчиков, абстрагирующего их от оборудования. Одним из таких интерфейсов как раз и является UEFI, пришедший на смену более старому интерфейсу BIOS Interrupt Call.

Дальше читать не стал, прошу пардону. К переводчику претензий особых не имею, а автору посоветую идти в жопу почитать нормальных книг и самому сначала понять, как система работает, а не звон слушать очередной, тем более ретранслировать его в виде подобных статей.
Поправлю сам себя, там Cortex-A, в первом поколении были А5, что сейчас у Rysen/EPYC — не знаю, но скорее всего что-то боее мощное.
Не знаю точно, выполняет ли PMU свой кусок AGESA Boot Loader на том же ядре, или на соседнем (скорее все же на соседнем), но со стороны прошивки это выглядит как «подготовил таблицы, отправил их в PSP mailbox, дождался ответа, вуаля — память готова», со слотовой DIMM такая магия даже удобнее, но как только начинает хотеться странного, памяти там себе на обе стороны платы напаять, вот это все, как магия дает сбой и начинаются танцы с бубном.
Не, для PSP выделили отдельное ядро Cortex-M, а SMU как исполнялось на LM32, так и продолжает (могло измениться в новых процессорах, я после FP4 с AMD не работал).
Про почему — а к чему там иметь доступ из SMU? К профилям питания, или к шине SMBUS? Таким же образом можно EC в обычном ПК сломать — это довольно просто, прошивки к ним до сих пор мало кто подписывает, только толку не очень много, мне в голову приходит только кейлоггер, и то если клавиатура по PS/2 к EC подключена.
Все технологии вроде SecureFlash (а особенно те, которые прошивают прямо в рантайме через SMM-обработчик) — это защита периметра, т.е. будучи сломанными однажды, от атак изнутри уже не помогут никак. Код у AMI известного качества, поэтому уязвимости в нем продолжают находить регулярно (1, 2), плюс сами OEMы на безопасность часто плюют и продолжают либо держать прошивку открытой на запись, либо ключ от этой записи под ковриком хранят.
Спасибо большое за исследование, может быть теперь мне перестанут люди говорить, что я занимаюсь никому не нужной фигней, пытаясь в UEFI безопасность починить…

Одного только прошу (у авторов оригинального исследования тоже просил, и они обещали исправить) — выкиньте весь вот этот пассаж про SecureBoot:
Первый механизм безопасности, который мог бы заблокировать подобную атаку – это Secure Boot. Когда Secure Boot включен, каждый загружаемый по требованию прошивки компонент самой прошивки должен быть правильно подписан, таким образом гарантируется ее целостность.

UEFI SecureBoot не защищает и не может защищать от атак на прошивку изнутри самой прошивки (всем известная проблема курицы и яйца мешает), он защищает от запуска внешних по отношению к прошивке компонентов — загрузчиков, драйверов, EFI-приложений, т.п.
Если же у вас вредоносный код уже на SPI flash, то отловить его можно только внешними технологиями вроде TPM Measured Boot (который сам по себе тоже можно обойти, но сложнее в разы) и Verified Boot (который должен быть правильно настроен производителем ПК).

Я всеми руками за то, чтобы как можно больше людей включили и пользовались UEFI SecureBoot но создавать ложное чувство уверенности в нем не следует, и от атак такого уровня он не защищает.
Это как сказать, что самолет и есть самолет, чего производители настолько их усложняют? Летали бы дальше на этажерках, которые можно обслуживать одним человеком, и которым не нужно аэропорта, но нет, понавыдумывали Боингов и Аэробусов, в которых черт ногу сломит…

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

В итоге вместо этого синтезируется процессор «общего назначения», но попроще, и задача выполняется уже программой для него. Программу можно улучшить без замены самого процессора, программу намного легче отлаживать, программисты дешевле в конце концов. При этом процесс синтеза таких процессорных ядер уже отработан, а свободного места под очередной на кристалле море. Так появился микрокод (там еще не совсем общее назначение, но уже близко), когда декодер операций стало невыносимо писать, потом SMU/PMC (когда невыносимо стало управлять питанием), потом ICC (частотами), потом ME (собрали почти весь разрозненный управляющий софт под одной крышей и запустили в РТОС).

Есть и другая сторона этой медали «переходи на софт или умри» — такой переход резко упрощает реализацию новых идей, и потому вместе с хорошими идеями реализуются и не очень хорошие. Эй пацаны, хотите DRM прямо в чипсете — нате, хотите удаленное управление прямо там же, бесплатно — держите, хотите Java-машину и запуск апплетов прямо там же — пожалуйте, только денег заплатите, чтобы мы вам апплет подписали. А когда ядер много стало свободных, их стали двигать как бесплатный микроконтролер общего назначения, который уже ко всей чипсетной периферии подключен, и который можно программировать, заменив им отдельно стоящий EC/BMC.

Короче, миром опять правит не тайная ложа, а явная лажа. Я не могу отрицать заговора спецслужб или происки марсиан, но я легко могу для себя объяснить нынешнюю ситуацию и без них.
Эта опция (BIOS PSP Support) — такое же отключение PSP, как незапуск HeciDxe — отключение ME. Нормально PSP на процессорах с ним отключить нельзя — он память тренирует и S3 bootscript хранит, так что Intel и в этом плане лучше.
Конфигурацию усложняют, а вот интерфейс к ней — упрощают, и на разнице между v11 и v12 это хорошо видно. Я очень надеюсь, что к них кто-то там понял, что нынешние их технологии просто невозможно настроить так, чтобы в них не зияло дыр, и стал чинить вот это, потому что иначе всем этим технологиям — грош цена.
Мне самому, в принципе, пофигу уже, потому что Т2 закрывает эти вопросы раз и насовсем, но у остальной индустрии Т2 нет, да и у Apple пока что машин с Т2 — три штуки ровно, и они все дорогие.
С такой «успешной» security history всех популярных ОС, можно смело считать, что у локального атакующего эти права уже есть. В конце концов, SecureBoot никто так и не включает, а без него тот же локальный атакующий может загрузить на вашей системе хоть EFI Shell, хоть Linux, и иметь там любые права.

Information

Rating
Does not participate
Date of birth
Registered
Activity

Specialization

Инженер встраиваемых систем, Системный инженер
Ведущий