Что делает отладка процессора

Обновлено: 02.05.2024

В этом разделе описывается, как использовать общие команды отладки ядра для отладки основных понятий при сбоях тестирования надежности устройств.

Установка символов

символы содержимого комплекта оборудования для лаборатории Windows можно найти на веб-сайте сервера общедоступных символов майкрософт. Дополнительные сведения о общедоступном сервере символов Майкрософт см. в разделе Использование сервера символов Майкрософт для получения отладочных файлов символов. Можно задать символы в отладчике ядра, выполнив команду . сочувствие (задать путь к символам) .

В этом примере команда. чувствия задает путь сервера public Symbols в отладчике.

! анализ-v

При анализе сбоев тестов, вызванных проверками системных ошибок отладчика ядра, первая команда, которую следует выдать после установки символов, — это. Analyze. Эта команда определяет код проверки ошибки, причину проверки ошибки и трассировку стека, в которой отображается компонент, вызвавший сбой. Дополнительные сведения об этой команде см. в разделе Использование расширения. Analyze .

Проверка трассировок стека тестового процесса

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

Чтобы получить список всех процессов, выполняющихся на тестовом компьютере, можно использовать расширение ! process 0 0 , чтобы найти адрес блока тестового процесса епроцесс.

Затем можно использовать расширение ! Process/p/r для получения полных трассировок стека из тестовых процессов.

Дополнительные сведения о расширении процесса см. в разделе ! Process и . Process (задать контекст процесса).

Обратите внимание, что! выходные данные процесса содержат счетчики тактов для каждого потока, выполняющегося в процессе. При исследовании тестовых зависаний потоки с большим количеством тактов, содержащим компоненты ВДТФ в стеке (то есть имена модулей, начинающиеся с "ВДТФ" в стеке), следует тщательно проанализировать, так как эти потоки могут привести к безошибочному зависанию и завершению работы тестов из-за истечения времени ожидания.

В этом примере ! процесс 0 0, ! процесс/p/rи ! Process Extensions определяет тестовый поток с очень большим числом тактов, что предотвращает выполнение теста:

Переключение контекста на потоки и фреймы для просмотра локальных переменных

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

Переключить контекст на поток с помощью команды . Thread (задать контекст регистрации) .

Выведите дамп стека вместе с номерами кадров с помощью команды kn (см. раздел ведение журнала стеков и дампа).

Переключитесь в контекст фрейма с помощью команды . Frame (задайте локальный контекст) .

Просмотрите локальные переменные с помощью команды DV (отображение локальных переменных) .

Для дампа локальных переменных необходимо использовать закрытые символы.

В этом примере для дампа локальных переменных из кадра стека используются команды . Thread, kn, . Frameи DV .

! пнптриаже

При отладке основных принципов проверки надежности устройств можно использовать команду ! пнптриаже для вывода списка активных потоков PnP. Обратите внимание, что ! пнптриаже выходные данные содержат счетчики тактов для каждого потока PnP, который выполняется в системе. При исследовании тестовых зависаний следует внимательно рассмотреть потоки с высокими счетчиками тактов, так как эти потоки могут привести к безвозвратному зависанию и постепенному сбою из-за истечения времени ожидания.

Расширения отладки драйверов

Следующие расширения отладчика ядра могут отлаживать проблемы с драйверами, которые могут возникать при выполнении тестов надежности устройств: ! дрвобж, ! девноде, ! девобж, ! девстакки ! IRP. Дополнительные сведения об этих расширениях см. в разделе расширения режима ядра.

Расширения отладчика

средства отладки для Windows входят в состав дополнительных расширений отладчика, которые полезны при устранении неполадок, которые могут возникать при выполнении тестов для следующих типов драйверов: USB, служба хранилища, NDIS, Graphics, Kernel-Mode Driver framework (кмдф) и User-Mode driver framework (UMDF). Дополнительные сведения об этих расширениях см. в разделе специализированные расширения. дополнительные сведения об инструментах отладки для Windows см. в статье загрузка и установка средств отладки для Windows.

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

От ошибок никто не застрахован. Это утверждение касается и низкоуровневого программирования, где таких привычных средств, как отладочная печать или программный отладчик, в определенный момент может быть уже недостаточно. Для решения этой проблемы разработчики аппаратных средств используют так называемые внутрисхемные эмуляторы (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].

По мере развития технологий и увеличения тактовых частот 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], что позволяет получать доступ к ряду регистров, которые недоступны из обычных режимов.

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

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

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

Рис. 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 может работать, но остановить выполнение уже нельзя, поэтому нет возможности получить доступ к памяти и регистрам).

В жизненном цикле микропроцессорной системы выделяются три основных этапа: проектирование, изготовление и эксплуатация . Для поддержания микропроцессорной системы в работоспособном состоянии необходимо учитывать как специфику каждого этапа ее жизненного цикла , так и особенности МПС как объекта контроля.

Прежде всего, рассмотрим некоторые основные понятия, связанные с контролем и диагностикой цифровых вычислительных устройств.

Процедура проверки правильности функционирования объекта называется контролем или тестированием. В результате контроля определяется, находится ли объект в исправном состоянии. Если объект находится в неисправном состоянии, то возникает задача поиска неисправности - диагностирования. Процесс устранения найденных неисправностей называется отладкой.

Рассмотрим в первую очередь особенности МП БИС и микропроцессорной системы в целом как объекта контроля, которые затрудняют процедуру контроля и поиска неисправностей.

Высокая сложность БИС. Полная проверка схемы должна обеспечивать проверку ее работоспособности при всех возможных состояниях.

Число возможных состояний определяется количеством внутренних элементов памяти. Взяв для примера только регистровую память однокристального микроконтроллера (32 регистра по 8 разрядов), получим 2 256 состояний. Для полного их перебора с частотой 100 МГц потребуется время порядка 1067 лет! Очевидно, что такой вариант неприемлем и никогда на практике не реализуется. Следовательно, любая МП БИС может содержать неисправности. Самое неприятное в этой ситуации то, что эти неисправности носят характер сбоев, то есть проявляются только при определенном сочетании данных внутри БИС, и поэтому весьма трудно поддаются выявлению.

Аналогичная ошибка была выявлена в конце 2007 года в четырехъядерных серверных процессорах Barcelona, а также в чипах Phenom для настольных компьютеров компании AMD . Она была связана с особенностями реализации буфера быстрого преобразования адреса ( TLB ) кэш-памяти третьего уровня. Ошибка в отдельных ситуациях приводила к зависанию системы.

Иногда отдельные неисправности проявляют себя только на высоких частотах работы БИС. Поэтому некоторые производители схем, определив в ходе тестирования, что отдельные БИС из некоторой партии схем дают сбои на начальной, самой высокой частоте, проверяют ее работоспособность на более низких частотах, где схемы этой партии могут оказаться вполне работоспособными. Именно с указанием такой частоты работы эти БИС и поступают на рынок. Такой подход служит одной из основ "разгона" схем.

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

Обычно требуется регистрация и анализ сигналов на протяжении значительного временного интервала и в связи с редкими и однократными событиями. К числу таких событий, идентификация которых необходима в процессе контроля, относится появление заданных комбинаций сигналов на шинах МПС и даже появление заданной последовательности таких комбинаций: обращение по определенному адресу на запись определенных данных, появление сигнала запроса прерывания определенного типа или даже сигнал помехи . При наступлении такой ситуации следует проанализировать, а следовательно, предварительно запомнить состояние шин на протяжении как нескольких предшествующих тактов, так и нескольких тактов, которые следуют за указанным событием. В то же время для МПС на основе однокристальных микроконтроллеров и ЦСП эта проблема не столь остра, так как реализация большинства функций системы осуществляется внутренними средствами этих микропроцессоров . Поэтому такие системы имеют малое число периферийных схем, а обмен между ними и микропроцессором часто выполняется по последовательным интерфейсам .

Наряду с имеющимися трудностями в процессе контроля и отладки микропроцессорная система имеет ряд достоинств, облегчающих этот процесс.

Вот ты все кодишь, кодишь, отлаживаешь,
отлаживаешь . Стоп! А задумывался ли ты как
работает отладчик? Нет? Тогда слушай.
Начнем с того, что все семейство отладчиков
делится на отладчики приложений и
отладчики ядра. Различие в их реализации,
как правило, заключается в том, что
отладчики приложений используют Debugging API ОС
(функции, структуры), а отладчики ядра -
непосредственно отладочные возможности
процессора (регистры, команды). Очевидно,
что отладчики приложений проще в
реализации, посему с них и начнем.

Отладчики приложений

Описывать я буду Windows Debugging API. Итак, для
того, чтобы начать отладку, поток-отладчик
должен запустить отлаживаемый процесс так,
чтобы ОС знала о том, что запускаемый
процесс будет находиться под отладкой. Для
этого надо запустить отлаживаемую
программу функцией CreateProcess с параметром
dwCreationFlag равным DEBUG_ONLY_THIS_PROCESS (или DEBUG_PROCESS,
если отладчик может отлаживать несколько
процессов одновременно). Теперь отладчик
должен войти в т.н. цикл отладки. Для этого
надо войти в цикл, вызывая функцию WaitForDebugEvent
( while(WaitForDebugEvent(. )==1) ) и после завершения
обработки какого-либо события отладки
вызывать ContinueDebugEvent. Итак, обобщенная схема
работы отладчика:

CreateProcess("путь_к_отлаживаемой_проге". DEBUG_ONLY_THIS_PROCESS. );
while(WaitForDebugEvent(. )==TRUE)
обрабатываем_события(см.далее)
.
.
.

Да, кстати, выше я сказал ПОТОК-отладчик -
это важно (Microsoft recommendation :), чтобы цикл
отладки, описанный выше находился в
отдельном потоке отладчика. Иначе отладчик
будет виснуть во время ожидания событий
отладки. Но это важно для серьезных
отладчиков, а на пока можно этим не
заморачиваться (это тебе так, на будущее).
Теперь нам надо научиться получать события
отладки. Для этого в Win DAPI есть структура
DEBUG_EVENT (посмотри SDK, описывать не буду, т.к.
структура не из маленьких). Указатель на эту
структуру передается первым параметром
функции WaitForDebugEvent, а она в свою очередь
заполняет ее интересной для нас
информацией. Само событие отладки, которое
нужно/можно обрабатывать будет в элементе
DEBUG_EVENT dwDebugEventCode. Итак какие существуют
события отладки:

При возникновении событий отладки
существует множество нюансов, не описанных
мной. Например CREATE_PROCESS_DEBUG_EVENT и
CREATE_THREAD_DEBUG_EVENT возникают ПЕРЕД тем как
процесс или поток начнут выполняться.
Почитай более подробно в MSDN, т.к. сегодня мы
создаем ОЧЧЧЕНЬ простой отладчик.

Ну вот, кое-что уяснили, теперь напишем что-то
похожее на отладчик:

Вот и все. Компиляй, запускай. Я думаю ты
догадался, что в качестве параметра этому
отладчику следует передать путь к
отлаживаемой программе. Теперь ты знаешь
примитивнейшие основы работы отладчика
приложений под Win. Написанный в качестве
примера отладчик даже не столько отладчик,
сколько прога, отображающая события
отладки. Для создания настоящего отладчика
требуется большое усердие и желание. Если
тебя заинтересовала эта тема, прочти, что
написано об отладке в MSDN и вперед!

Отладчики ядра

Плавно подходим к отладчикам ядра.. Оооооо!
Это очень интересно и настолько же сложно.
Как я уже говорил, отладчики ядра
используют ресурсы процессора. Сразу скажу,
что я ограничусь описанием этих ресурсов и
описанием их использования. Примера проги
не будет 🙁 В современных процах Intel (и
совместимых с ними), начиная с 80386 нам
доступны 8 отладочных регистров (DR0-DR7),
позволяющие ставить контрольные точки на
чтение/запись областей памяти и портов
ввода/вывода (начиная с Pentium). И это круто,
скажу я тебе! Всего контрольных точек
только четыре 🙁 Ну ладно, рассмотрим
отладочные регистры DR0-DR7. Наиболее важным
из них является DR7, т.к. именно он является
управляющим регистром отладки, позволяющим
координировать работу точек останова. Да,
кстати все восемь отладочных регистров 32-битные.
Рассмотрим подробнее регистр DR7:

биты 31-30 : поле LEN для т/о (точки останова) 3
биты 29-28 : поле R/W для т/о 3
биты 27-36 : поле LEN для т/о 2
биты 25-24 : поле R/W для т/о 2
биты 23-22 : поле LEN для т/о 1
биты 21-20 : поле R/W для т/о 1
биты 19-18 : поле LEN для т/о 0
биты 17-16 : поле R/W для т/о 0

поле LEN задает длину т/о:
00 - 1 байт
01 - 2 байта
10 - 3 байта
11 - 4 байта

поле R/W задает условие срабатывания т/о:
00 - исполнение команды
01 - запись данных
10 - обращение к порту ввода/вывода (если 3-й
бит регистра CR4 равен 1), иначе не определено
11 - чтение/запись

биты 15-14 : 0-0 (равны нулю)
бит 13 : при его установке любое обращение к
отладочным регистрам (даже из 0 кольца)
вызывает исключение
биты 12-10 : 0-0-1
биты 9-8 : 1-1 (а здесь уже Intel recommendation 🙂
бит 7 : 1 - включить т/о 3
бит 5 : 1 - включить т/о 2
бит 3 : 1 - включить т/о 1
бит 1 : 1 - включить т/о 0
биты 8,6,4,2,0 : то же, что и 7,5,3,1, но сбрасывается
при каждом переключении задачи (актуально
для защищенного режима, в реальном режиме
эти пары регистров равноценны)

Регистры DR0-DR3 задают линейные адреса
четырех точек останова (0-3 соответственно).
Тут есть некоторые пометки: если размер т/о -
слово, то адрес толжен быть четным,
если двойное слово, то адрес должен быть
кратный четырем.
И наконец регистр DR6 отображает состояние
отладки:

биты 31-16 : все выставить в единицу
бит 15 : если 1, то исключение вызвано
переключением задач (опять же, актуально
для защищенного режима)
бит 14 : устанавливается при трассировке
бит 13 : устанавливается, если следующая
команда обращается к любому отладочному
регистру (бит 13 регистра DR7 должен быть
установлен)
бит 12 : 0
биты 11-4 : единицы
бит 3 : сработала т/о 3
бит 2 : сработала т/о 2
бит 1 : сработала т/о 1
бит 0 : сработала т/о 0

Ox-x-x, это тебе не Windows Debugging API 🙂

;Этот пример в Win не работает (и в DOS окне тоже)
mov eax, 0000000011000000110000010 ; длина т/о равна 1 байт,
ставим на чтение/запись памяти
mov ebx, 90000h ;адрес точки останова (кто прочтет/начнет
писАть - сразу пискнет)
mov dr7, eax
mov dr0, ebx

Отладчики же после установки т/о ждут
генерации int 0x1 при обращении к т/о и получая
управление творят беспредел 🙂 С портами все
точно так же, но надо сначала установить в
единицу 3-й бит регистра CR4, и задать адрес
порта в один из регистров DR0-DR3.

Из древних возможностей отладки можно
сказать о контрольных точках останова и
трассировке. Контрольная точка останова
реализуется с помощью опкода 0xCC. Встретив
его, процессор вызывает int 0x3 и запоминает в
стеке регистр флагов, регистр CS, регистр IP,
запрещает преревания (флаг FI в регистре
флагов устанавливается в 0), сбрасывает флаг
трассировки. После этого отладчик опять же
может делать с программой все что угодно. И
о трассировке. Она организуется установкой
флага TF (флаг трассировки) в единицу.
Установил TF в единицу, и процессор после
каждой команды будет вазывать int 0x1,
сохраняя в стеке регистр флагов и регистр IP
и очищая флаг TF. Хитрый отладчик
перехватывал исключение и - опять беспредел
🙂 Для отладки в реальном режиме процессора
отладчик должен был перехватывать
прерывания(исключения) 0x1 и 0x3 и
обрабатывать их по своему усмотрению. В
защищенном режиме в принципе все так же (в
смысле так же надо перехватывать 0x1 и 0x3), но
здесь при возникновении исключения
предоставляется больше информации, но
программировать в защищенном режиме
достаточно сложно. А уж в нулевом кольце
защиты Windows и подавно. Чуть не забыл сказать
об т.н. эмулирующих отладчиках. Эти
отладчики эмулируют выполнение команд
процессора отлаживаемой программы (ну и
регистры проца конечно эмулируют). С точки
зрения защиты от антиотладочного кода это
большое подспорье. Но и на эмулирующие
отладчики управа всегда найдется.

К чему пришли.

Ну вот, теперь ты знаешь, пусть примерно,
как работают отладчики. Да, кстати, SoftIce -
отладчик ядра, а так же единственный из них,
способный отлаживать используя один комп.
"Что значит один комп?" - спросишь ты. А
это значит что остальные известные
отладчики ядра ведут отладку "по модему",
т.е. отлаживаемая система вместе с ядром
отладчика на одном компе, а управление
ядром происходит по сети, другим компом. Вот
так-то. А как правило встроенные в средства
разработки отладчики - не что иное как
отладчики приложений, причем не самые
лучшие. Что же использовать, спосишь ты меня.
Да ты и сам знаешь - SoftIce 🙂 А еще неплохой
отладчик - WinDBG. Он идет вместе с PlatformSDK. Удачи
в ловле жуков!

Читайте также: