October 16th, 2018

JTAG в каждый дом: полный доступ через USB

https://habr.com/company/pt/blog/341946/

Исследователи Positive Technologies активировали аппаратную отладку (JTAG) для Intel Management Engine, которая позволяет получить полный доступ ко всем устройствам PCH (Platform Controller Hub), используя технологию Intel DCI (через интерфейс USB). Мы планируем поделиться подробностями на одной из ближайших конференций. А о том, как активировать этот интерфейс, но для основного процессора, расскажем ниже.


[Spoiler (click to open)]
От ошибок никто не застрахован. Это утверждение касается и низкоуровневого программирования, где таких привычных средств, как отладочная печать или программный отладчик, в определенный момент может быть уже недостаточно. Для решения этой проблемы разработчики аппаратных средств используют так называемые внутрисхемные эмуляторы (in-circuit emulators) или специальный отладочный интерфейс JTAG, если он присутствует на целевой платформе (IEEE1149.1 [1]). Эти отладочные механизмы появились еще в 80-х годах прошлого века [2]. Со временем производители микросхем расширяли возможности этих интерфейсов. Благодаря этому разработчики смогли получать детальную информацию об энергопотреблении, находить узкие места в высокопроизводительных алгоритмах и получили много других возможностей.

Для исследователей безопасности аппаратные средства отладки также представляют интерес. Они позволяют получить низкоуровневый доступ к системе в обход основных средств обеспечения безопасности, изучать поведение целевой платформы и ее недокументированные возможности. Очевидно, что подобные возможности оказались привлекательны и для спецслужб [3].

Долгое время доступ к этим технологиям для процессоров Intel имелся только у ограниченного круга лиц, что было связанно с необходимостью использования дорогого специализированного оборудования. Но с выходом процессоров семейства Skylake ситуация кардинально изменилась: отладочные механизмы были встроены в PCH [4], что позволяет использовать столь мощный инструмент обычным пользователям — включая и злоумышленников, которые могут таким образом получить полный контроль над процессором. Из соображений безопасности по умолчанию эти механизмы не активированы, но в данной статье мы покажем, что их можно заставить работать на оборудовании, которое доступно в обычных компьютерных магазинах.

Эволюция отладочных средств на процессорах Intel

1. От in-circuit emulator к JTAG

Первоначально in-circuit emulator (ICE) для процессоров Intel 80286 представлял собой отдельный компьютер («большую синюю коробку» [5]), который включал клавиатуру и монитор. ICE подключался вместо процессора отлаживаемой системы и эмулировал его поведение. Такой эмулятор позволял устанавливать точки останова, изменять память и регистры процессора, производить запись и чтение.

Позднее Intel представила новый аппаратный отладчик I2ICE (рис. 1), который уже не заменял собой штатный процессор. С помощью специальных переходников пользователь подключался к отлаживаемой системе, а для общения с хост-машиной такой аппаратный отладчик использовал стандартный последовательный порт на скорости 9600 Бод [5].



Рис. 1. Intel I2ICE — один из первых внутрисхемных отладчиков для процессоров Intel 80386 (recycledgoods.com/intel-series-iv-emul-system-iii514b.html)

По мере развития технологий и увеличения тактовых частот Intel отказывается от разработки отдельных полнофункциональных средств отладки и частично переносит ее внутрь процессора, в виде специального недокументированного режима ICE-mode (который по принципам работы очень напоминал другой режим — System Management Mode (SMM), у некоторых разработчиков того времени было стойкое убеждение, что SMM — не что иное, как документированный и расширенный ICE-mode [6]). В свою очередь, всеобщая стандартизация отладочных механизмов в электронной промышленности приводит к тому, что в некоторых процессорах Intel 80486 появляется поддержка тестового интерфейса IEEE1149.1 (JTAG) [7].

Joint Test Action Group (JTAG) на самом деле является названием рабочей группы, которая разработала стандарт Standard Test Access Port and Boundary-Scan Architecture (IEEE1149.1 [1]). Он позволяет использовать стандартную аппаратуру тестирования и отладки для широкого класса устройств. Со временем сокращение JTAG стало ассоциироваться со стандартом IEEE1149. В современных микросхемах он широко распространен в промышленности и используется для тестирования, прошивки, отладки и выходного контроля микросхем при производстве. Физически JTAG представляет собой четыре или пять выделенных линий, которые образуют тестовый порт TAP (Test Access Port). Стандарт предусматривает объединение устройств в цепочку, позволяя получать доступ к каждому подключенному устройству (рис. 2).



Рис. 2. Объединение отлаживаемых устройств в JTAG-цепочку

Часто разработчики аппаратуры расширяют базовую функциональность JTAG, вводя новые возможности; процессоры Intel не стали в этом смысле исключением, начиная с Pentium появляется более дешевый и мощный вариант внешнего отладчика, который использует специальный зондовый режим (probe mode).

2. Режим зондовой отладки

Режим зондовой отладки (probe mode) является еще одним недокументированным режимом работы процессоров Intel. Он используется для диагностики и отладки. Его невозможно активировать без доступа к JTAG-регистрам процессора. В probe mode процессор может изменять память, производить запись и чтение из портов ввода-вывода. В данном режиме прерывается нормальное выполнение инструкций и процессор переходит в режим бездействия, ожидая команд по интерфейсу JTAG. Такое поведение принципиально отличает данный механизм от ICE-mode, когда инструкции на процессоре продолжали выполняться. При входе в probe mode останавливается предварительная выборка и декодирование команд. Команды от JTAG для модификации или чтения поступают непосредственно в исполнительные блоки процессора, тем самым минуя этапы предварительной выборки и декодирования [8], что позволяет получать доступ к ряду регистров, которые недоступны из обычных режимов.

Probe mode реализован как расширение JTAG с добавлением нескольких регистров и дополнительных сигналов R/S#, PRDY (подробнее о том, как реализован режим probe mode, см. [8], [9]). Сторонние компании наравне с Intel выпускают JTAG-адаптеры для процессоров x86, в которых обеспечивается поддержка этого расширения, но мы рассмотрим только оригинальные аппаратные средства отладки.

3. Современные аппаратные средства и технологии отладки процессоров Intel

Современные процессоры Intel предоставляют JTAG через три интерфейса:

Intel In-Target Probe eXtended Debug Port (ITP-XDP) (рис.3);
Intel Direct Connect Interface (DCI) — специализированная технология, которая предоставляет JTAG-интерфейс через порт USB 3.0. Существуют две возможности подключения (рис. 4):


— USB3 Hosting DCI (USB-Debug cable) — через обычный DbC-кабель;
— BSSB Hosting DCI (Intel SVT Closed Chassis Adapter) — через специализированный адаптер (рис. 5).



Рис. 3. ITP-XDP



Рис. 4. Типы подключения DCI



Рис 5. Intel SVT Closed Chassis Adapter

Интерфейс Intel ITP-XDP имеет закрытый протокол, требует специализированного разъема на плате и специализированного программного обеспечения Intel System Studio (на сайте производителя доступна пробная версия). К недостаткам также стоит отнести высокую цену (около 3000 долларов США) и необходимость подписывать документы о неразглашении информации (Corporate Non-Disclosure Agreement) [10]. Высокая цена и CNDA делают данный отладчик недоступным для рядового разработчика или домашнего использования.

Однако начиная с процессоров семейства Skylake Intel внедрил технологию Direct Connect Interface (DCI), ее достаточно поверхностное описание можно найти в документации [4]. Данная технология ставит своей целью упростить разработку мобильных устройств, из чего вытекает ее недостаток: ее можно активировать без каких-либо аппаратных модификаций (при наличии JTAG линий между PCH и CPU). Также стоит отметить, что подключение с использованием адаптера Intel SVT использует линии USB 3.0, но реализует свой протокол, что позволяет работать с целевой системой в режимах глубокого сна. К сожалению, адаптер SVT при своей относительно низкой цене (390 долларов США) также доступен для покупки только после подписания CNDA.

Самым интересным для рядового программиста вариантом, который при этом не требует подписания каких-либо документов перед использованием, является USB3 Hosting DCI. Он представляет JTAG-интерфейс через обычный отладочный кабель USB 3.0. При активации DCI на целевой системе порт USB 3.0 переходит в режим slave и начинает принимать команды от хостовой системы.

Один из важных вопросов относительно USB 3.0 DbC DCI Hosting заключается в том, через любой ли внешний порт USB 3.0 возможно подключение к DCI — или требуется отладочный порт, доступный только на специальных системных платах для разработчиков. Следует рассмотреть данный вопрос подробнее.

В среде системных разработчиков существует путаница, порожденная тем, что сама по себе отладка через USB появилась достаточно давно (со времен USB 2.0) и в данный момент используется многими разработчиками для программной отладки ядер операционных систем и UEFI приложений. Однако программная отладка через USB (в windbg, UEFI debug agent и т. п.) не имеет ничего общего с механизмами аппаратной отладки через JTAG, кроме собственно транспорта. Спецификация контроллера шины USB 2.0 (EHCI, Enhanced Host Controller Interface) предоставляет специальный механизм, который называется Debug Port (PCI capability), с помощью которого возможно взаимодействие между сервером (программным или аппаратным) на отлаживаемой машине и клиентом на хосте. В частности, ядро Windows поддерживает отладку через EHCI Debug Port (при этом нужен отладочный кабель USB 2.0, с интегрированным устройством USB 2.0). При этом, действительно, не каждый внешний порт USB 2.0 мог работать как Debug Port, а эта возможность была закреплена за определенными портами, которые могли быть и не выведены наружу. Все зависело от производителя оборудования. Поэтому разработчики специально искали оборудование с выведенным наружу Debug Port, для отладки по USB. Таким образом, Debug Port — это атрибут USB-порта.

Однако ситуация полностью изменилась с появлением USB 3.0 и спецификации контроллера этой шины XHCI (eXtended Host Controller Interface). Данная спецификация также поддерживает отладку по USB, однако она претерпела существенное развитие и стала называться USB Debug Capability (DbC). Согласно XHCI, DbC является не атрибутом порта, а свойством конкретного контроллера XHCI. То есть, если данный XHCI-контроллер поддерживает DbC, то возможность отладки по USB 3.0 будет доступна на любом (в том числе и внешнем) порте USB 3.0. При этом DbC автоматический выберет первый порт, к которому подключен отладочным кабелем клиент, выполняющий транзакции USB 3.0.

Здесь важно отметить, что первые XHCI-контроллеры не поддерживали DbC, поэтому на системах с такими котроллерами отладка по USB была невозможна. Однако в PCH версии 100 и выше (для Skylake) компания Intel встроила свой собственный контроллер XHCI, который поддерживает DbC. Технология Intel DCI (которая и появилась начиная с процессоров Skylake) использует USB 3.0 DbС в качестве транспорта, для подключения JTAG-клиента. USB 2.0 Debug Port он не использует.

Таким образом, через любой порт USB 3.0 можно подключиться к DCI и осуществлять JTAG-отладку.

Активация DCI

Как же можно активировать этот отладочный интерфейс? Мы нашли три способа:

через EFI Human Interface Infrastructure;
PCH Strap (Intel Flash Image Tool);
P2SB device.



1. Активация через EFI Human Interface Infrastructure

EFI Human Interface Infrastructure — специальный механизм, который позволяет создавать пользовательский интерфейс в UEFI, обрабатывать и контролировать пользовательский ввод. Если посмотреть строение современных UEFI BIOS, можно найти в них множество скрытых опций, которые недоступны пользователю, но обрабатываются. На этом и основан наш первый способ. EFI HII определяет значения по умолчанию для всех опций, в том числе и скрытых. Найдя опцию, связанную с DCI, можно ее активировать для настройки по умолчанию, а затем, установив в BIOS заводские настройки, активировать DCI. Отредактировать эти настройки позволяет утилита AMI BIOS Configuration Program 5.0. Отредактированный образ программируется в SPI-flash программатором или через штатный механизм прошивки BIOS, если позволяют права доступа.

Однако у этого способа есть недостаток: система не загрузится, если активирован Boot Guard, так как утилита изменяет модуль EFI.



2. Активация через Flash Descriptor Region



DCI также можно активировать через настройку специальных битов конфигурации PCH — либо вручную (они находятся в Flash Descriptor Region), либо c помощью утилиты Flash Image Tool. Данный способ работает даже при включенном Boot Guard.

3. Активация через P2SB-устройство

В конце концов, можно попробовать действовать напрямую — через устройство P2SB. В документации на разные поколения PCH можно найти специальный индекс и регистр, используя который можно активировать DCI на лету, если BIOS не заблокировал изменение настройки DCI.



Данный способ является уязвимостью, так как если BIOS не блокирует запись в регистр ECTRL, то из-за особенностей работы (возможности сохранения конфигурации между перезагрузками после выключения питания) позволяет активировать DCI один раз, а далее использовать JTAG-интерфейс как аппаратный backdoor в систему (например, отключать экран блокировки).
Мы провели исследование [12], в результате которого выяснилось, что крупнейшие производители материнских плат не устанавливают блокировку данного регистра, что позволяет активировать DCI и использовать этот механизм, например, для перезаписи BIOS в обход всех средств защиты, включая проверку цифровой подписи.

Резюме

Наличие отладочных механизмов в современных процессорах Intel позволяет облегчить разработку модулей UEFI, операционных систем, гипервизоров. Исследователи безопасности получают низкоуровневый механизм привилегированного доступа к аппаратуре, который может быть использован для поиска зловредного ПО, исследования недокументированных возможностей аппаратуры или драйверов специфического оборудования. Но, как любой отладочный механизм, DCI может использоваться и злоумышленниками для несанкционированного доступа к данным.

В качестве защиты от таких атак мы рекомендуем активировать Boot Guard, проверять бит активации DCI и запрет отладки в регистре IA32_DEBUG_INTERFACE (при этом DCI может работать, но остановить выполнение уже нельзя, поэтому нет возможности получить доступ к памяти и регистрам).

Авторы: Максим Горячий, Марк Ермолов.

Источники

1. 1149.1-1990 — IEEE Standard Test Access Port and Boundary-Scan Architecture.
2. www.jtag.com/en/content/about-jtag-technologies
3. resources.infosecinstitute.com/close-look-nsa-monitor-catalog-server-hacking
4. 6th Generation Intel Core Processor I/O Datasheet. Vol. 2.
5. In-Circuit Emulation, Robert R. Collins (rcollins.org/ddj/Jul97).
6. Intel's System Management Mode by Robert R. Collins // Dr. Dobb's Journal. January 1997.
7. Гук М. Процессоры Intel от 8086 до Pentium II — СПб: Питер, 1998.
8. Overview of Pentium Probe Mode by Robert R. Collins (rcollins.org/articles/probemd/ProbeMode.html).
9. Гук М. Процессоры Pentium II, Pentium Pro и просто Pentium — СПб: Питер, 1999.
10. www-ssl.intel.com/content/www/us/en/forms/design/registration-privileged.html
11. www.asset-intertech.com/products/jtag-interposers-and-arium-jtag-adapters
12. habrahabr.ru/company/pt/blog/321440

Разработка и отладка UEFI-драйверов на Intel Galileo, часть 3: начинаем аппаратную отладку

На пямять из откопанного на просторах интернета



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

Вступление и отказ от ответственности
[Spoiler (click to open)]По уже сложившейся традиции, следует упомянуть, что все нижеуказанные сведения вы используете на свой страх и риск, автор не несет ответственности за возможные потери работоспособности платы, времени, настроения и/или веры в человечество. Всё описанное почерпнуто из открытых источников, список которых приведен в конце этой статьи, и эта публикация не может считаться нарушением NDA с моей стороны.

Отправная точка
На данный момент я предполагаю, что у вас уже есть плата Intel Galileo, для которой вы собрали прошивку и образ Yocto Linux и можете сделать это снова в любой момент. Останавливаться еще раз на сборке ПО для Galileo я в этой части статьи не буду — прочтите прошлую часть, если нужно.
Также подразумевается наличие у вас отладчика, совместимого с OpenOCD, лучше всего — на базе чипов серии FTDI FTxx32H, т.к. именно такие используются инженерами Intel для написания и тестирования отладочных средств для Galileo. Не могу гарантировать, что другие отладчики будут ли не будут работать — не проверял. В этой статье в качестве отладчика я буду использовать breakout-плату на FT2232H, которая от «взрослых» отладчиков на том же чипе отличается только отсутствием красивого корпуса и микросхемы сдвига логических уровней, для отладки на Galileo не нужной.

Железная часть
С железной частью все довольно просто — нужно лишь правильно соединить контакты разъема JTAG на Galileo с нужными выводами FT2232H.
Выводы у чипов серии FTxx32H обозначены маркировкой xyBUSz, где вместо x — обозначение канала (A, B, C или D), вместо y — обозначение первого (D) или второго (C ) набора выводов каждого канала, а вместо z — номер вывода (0-7 для первого и 0-9 для второго набора выводов).
Для работы с JTAG подключение нужно проводить по следующей схеме:

xDBUS0 <-> TCK
xDBUS1 <-> TDI
xDBUS2 <-> TDO
xDBUS3 <-> TMS

TRST можно подключить к любому свободному выводу того же канала, в моем случае это xCBUS0, вы можете использовать любой другой, но в конфигурацию OpenOCD придется внести соответствующее изменение.

Программная часть
Достаем Intel System Studio
А вот здесь все немного более сложно, особенно для пользователей Windows, у которых нет возможности выполнить sudo apt-get install openocd и через 10 секунд начать писать конфигурацию для своего отладчика. Ребята из Intel об этом знают, поэтому и включили OpenOCD и GDB в дистрибутив Intel System Studio 2015 Beta, скачать который можно отсюда после регистрации. В нем же имеется Intel System Debugger, выступающий в роли GUI к GDB и предназначенный для тех, кто пока еще не постиг Дао настолько, чтобы работать с ним напрямую из консоли. Ваш покорный слуга уже встал на этот Путь, но он труден, а соблазн использовать GUI велик, ведь Intel даже поддержку отладки UEFI добавили не так давно. В результате я таки поддался, предлагаю поддаться и вам.
После регистрации, загрузки и установки ISS необходимо предпринять несколько дополнительных действий: написать конфигурацию для своего отладчика (по умолчанию имеются конфигурации только для TinCanTools FLYSWATTER2 и Olimex ARM-USB-OCD-H), подключить отладочные символы, чтобы можно было отлаживать код на C, а не на ассемблере. В Windows также потребуется установить драйвер libusbK для выбранного канала отладчика вместо стандартного драйвера FTDI, чтобы OpenOCD смог его найти. Приступим.

Пишем конфигурацию для OpenOCD
Настройка OpenOCD состоит обычно из двух частей: написания конфигурации отладчика и отлаживаемой платы. От второго добрые разработчики Intel нас избавили, а первое будем делать по аналогии. Перейтите в директорию, в которую вы установили System Studio, а оттуда — в debugger\openocd\scripts\interface\ftdi, и скопируйте файл olimex-arm-usb-ocd-h.cfg, назвав копию debugger.cfg. Откройте полученный файл в любимом редакторе и удалите строки ftdi_device_desc, ftdi_layout_signal nSRST, ftdi_layout_signal LED, в строке ftdi_vid_pid измените VID и PID отладчика на ваши значения. Если вы используете каналы B, C или D, добавьте строку ftdi_channel 1, ftdi_channel 2 или ftdi_channel 3 соответственно. Сохраните изменения и конфигурация для вашего отладчика готова.
Если вы хотите узнать, что означают магические числа в строке ftdi_layout_init, настроить дополнительные сигналы или перенести TRST с xCBUS0 на другой вывод — добро пожаловать в документацию.
Готовый вариант debugger.cfg для breakout-платы на FT2232H

Устанавливаем драйвер libusbK
Пользователи Linux могут смело пропускать этот шаг, т.к. у них нужный драйвер уже установлен. Ползователям же Windows необходимо установить вышеупомянутый драйвер вместо стандартного. Сделать это можно несколькими способами, самым простым из которых является, на мой взгляд, использование утилиты Zadig. Скачиваем и запускаем последнюю версию, ставим галочку List All Devices в меню Options, выбираем свое устройство из списка, выбираем в качестве драйвера libusbK и нажимаем кнопку Replace Driver.
Если все сделано верно — выглядеть окно программы будет примерно так:



Проверяем работу OpenOCD
Теперь необходимо проверить, что отладчик подключен верно и OpenOCD может использовать его для доступа к Galileo по JTAG. Для этого необходмо запустить openocd, указав в качестве параметров конфигурационные файлы для отладчика (debugger.cfg, созданный на первом шаге) и для платы (входит в поставку ISS). Для этого нужно запустить командную строку от администратора, сменить текущую директорию на debugger\openocd\bin, и оттуда выполнить команду

openocd -f ..\scripts\intefrace\ftdi\debugger.h -f ..\scripts\board\quark_x10xx_board.cfg

Если вы все сделали верно, команда выведет приблизительно следующее:

Info : clock speed 4000 kHz
Info : JTAG tap: quark_x10xx.cltap tap/device found: 0x0e681013 (mfg: 0x009, part: 0xe681, ver: 0x0) enabling core tap
Info : JTAG tap: quark_x10xx.cpu enabled

Если же у вас вместо этого только

Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED

значит что-то не так либо с драйвером, либо с конфигурацией отладчика.

Достаем отладочные символы
Если сборка прошивки для Galileo, описанная в предыдущей части, происходила в вашей основной системе — можете этот шаг пропустить. У меня же она происходила в виртуальной машине, поэтому для source-based отладки необходимо достать из нее исходный код прошивки и файлы с отладочной информацией.
Скопируйте директорию Quark_EDKII_vX.Y.Z из вашего домашнего каталога в ВМ на рабочий стол основной ОС, запустите Intel Debugger при скриптом xdb_remote (в Windows ссылка на него есть в меню Start->ISS->Debugger Startup->Quark SoC), откройте окно Options->Source Directories..., создайте на первой вкладке правило замены старого пути до скопированной директории на новый, в моем случае это "\home\congatec\Galileo" -> «C:\Users\Nikolaj\Desktop», а на второй вкладке добавьте эту же директорию в список Source Directories. Оба этих действия помогут отладчику самостоятельно найти исходный код отлаживаемых модулей.

Подключаемся к Galileo
Запустите OpenOCD и Intel Debugger, как описано выше, нажмите Reset на Galileo, а затем кнопку Connect в окне отладчика. Если в окне Assembler появился листинг того модуля, на котором произошла остановка при подключении отладчика — отлично, можно приступать к аппаратной отладке. Чтобы проверить, нет ли ошибки на предыдущем шаге, выполните остановку в DXE-фазе (3-5 секунд после перезагрузки платы) и введите команды efi «setsuffix .debug» и efi loadthis в поле с приглашением xdb>. Если все было сделано верно, то отладочные символы будут успешно загружены, а отладчик перейдет из вкладки Assembler в редактор исходного кода. Если в ответ на loadthis вы получаете сообщение «System Table Not Found» — попробуйте остановить исполнение чуть позже или чуть раньше.

Заключение и планы
В следующей части статьи мы напишем простой DXE-драйвер, наладим быструю сборку прошивки с ним и попробуем отладить его, используя как подготовленный в этой статье Intel Debugger, так и другие отладочные средства. Спасибо за внимание, до встречи в следующей части.
P.S. Уважаемый НЛО, может быть теперь ты сможешь добавить профильный хаб UEFI? Было бы очень здорово.