Использовать отладку ядра для отладки основ устройств. сбои при тестировании надежности
В этом разделе описывается, как использовать общие команды отладки ядра для отладки основных понятий при сбоях тестирования надежности устройств.
Установка символов
В этом примере команда. чувствия задает путь сервера public Symbols в отладчике.
! анализ-v
Проверка трассировок стека тестового процесса
Основные принципы работы с устройствами. тесты надежности часто выполняются как Te.ProcessHost.exe или Te.exe на тестовом компьютере. Полезно просматривать трассировки стека из этих тестовых процессов при исследовании проверок системных ошибок или зависаний теста. В случае проверок ошибок трассировка стека может помочь определить тестовый случай, который был протестирован во время сбоя. В случае зависаний теста трассировки стека обозначают все тестовые потоки, препятствующие выполнению теста.
Затем можно использовать расширение ! Process/p/r для получения полных трассировок стека из тестовых процессов.
Обратите внимание, что! выходные данные процесса содержат счетчики тактов для каждого потока, выполняющегося в процессе. При исследовании тестовых зависаний потоки с большим количеством тактов, содержащим компоненты ВДТФ в стеке (то есть имена модулей, начинающиеся с «ВДТФ» в стеке), следует тщательно проанализировать, так как эти потоки могут привести к безошибочному зависанию и завершению работы тестов из-за истечения времени ожидания.
В этом примере ! процесс 0 0, ! процесс/p/rи ! Process Extensions определяет тестовый поток с очень большим числом тактов, что предотвращает выполнение теста:
Переключение контекста на потоки и фреймы для просмотра локальных переменных
Чтобы просмотреть локальные переменные из кадра стека, необходимо выполнить следующие действия.
Выведите дамп стека вместе с номерами кадров с помощью команды kn (см. раздел ведение журнала стеков и дампа).
Для дампа локальных переменных необходимо использовать закрытые символы.
! пнптриаже
При отладке основных принципов проверки надежности устройств можно использовать команду ! пнптриаже для вывода списка активных потоков PnP. Обратите внимание, что ! пнптриаже выходные данные содержат счетчики тактов для каждого потока PnP, который выполняется в системе. При исследовании тестовых зависаний следует внимательно рассмотреть потоки с высокими счетчиками тактов, так как эти потоки могут привести к безвозвратному зависанию и постепенному сбою из-за истечения времени ожидания.
Расширения отладки драйверов
Следующие расширения отладчика ядра могут отлаживать проблемы с драйверами, которые могут возникать при выполнении тестов надежности устройств: ! дрвобж, ! девноде, ! девобж, ! девстакки ! IRP. Дополнительные сведения об этих расширениях см. в разделе расширения режима ядра.
Расширения отладчика
средства отладки для Windows входят в состав дополнительных расширений отладчика, которые полезны при устранении неполадок, которые могут возникать при выполнении тестов для следующих типов драйверов: USB, служба хранилища, NDIS, Graphics, Kernel-Mode Driver framework (кмдф) и User-Mode driver framework (UMDF). Дополнительные сведения об этих расширениях см. в разделе специализированные расширения. дополнительные сведения об инструментах отладки для Windows см. в статье загрузка и установка средств отладки для Windows.
Отладчик ядра
Отладчик ядра — программное обеспечение, работающее на уровне ядра операционной системы и позволяющее отлаживать ядро и его компоненты.
Содержание
Применение
Отладчики ядра находят множество применений. Вот некоторые из них:
Так как очень часто программное обеспечение не поставляется с исходными текстами, а лишь в бинарном виде и сами уязвимости имеют машинно-зависимый характер, то эти две проблемы требует специальных инструментов. При статическом исследовании программы такими инструментами как дизассемблер многие детали поведения программы остаются не узнанными, например те локации памяти куда идет доступ со стороны программы, более трудно установить пути исполнения кода программы. Отладчик позволяет контролировать программу во время выполнения и изучать те изменения, которые в ней происходят на любом этапе выполнения. Возможности отладчика по отображению состояния стека программы, регистров процессора позволяют узнать различную информацию о реакции программы на те или иные события, логику выполнения кода. Это позволяет решить как первую, так и вторую задачу, указанную выше. Примером того как это делается может служить 3 глава из книги Хакинг: искусство эксплойта [1]
Основные принципы функционирования
Для нормального функционирования отладчика уровня ядра требуется внесение изменений в ядро операционной системы. Довольно часто это решается при помощи внедрения в ядро дополнительных модулей. Фактически отладчик уровня ядра перехватывает глобально системные функции, которые отвечают за:
Так же отладчик ядра контролирует обращение к различным таблицам ядра. Ещё один важный момент это управление состоянием процессора, так как процессоры поддерживают пошаговую трассировку и точки останова на аппаратном уровне.
Наиболее известные представители данного класса ПО
Проблемы при применении
Очень важно что отладчик должен быть совместим с ядром операционной системы, где используется, так как отладчик модифицирует основные структуры ядра, которые имеют свойство меняться от версии к версии. Применение некорректной версии отладчика может привести к непредсказуемому поведению системы.
Иной довольно серьёзной проблемой является конфликт между драйверами уровня ядра других приложений и отладчика. Примером может служить невозможность работы программы Daemon Tools при активном отладчике ядра. Некоторые программы отказываются функционировать, если обнаружат наличие отладчика в системе или попытки их отладки
Записки программиста
Скандальная правда об отладке ядерного кода в Linux
Как это всегда бывает в мире Linux, нормальной документации нет. Когда мне захотелось разобраться, как в это время суток разработчики отлаживают модули ядра Linux, а также само ядро, мне пришлось прочитать, наверное, около двадцати статей, разбросанных по всему интернету. Из этих источников половина содержала устаревшую информацию в стиле «Линус запретил использовать отладчики, смиритесь». Еще половина освещала вопрос где-то на 1/10. В итоге, скорее вопреки, чем благодаря, мне все-таки удалось более-менее разобраться в вопросе и собрать всю информацию в одном месте. Не благодарите.
Важно! Далее предполагается, что вы уже умеете пользоваться отладчиком GDB, а также собирать ядро Linux из исходных кодов. Кстати, последняя статья содержит ссылки на множество интересных материалов по разработке ядра Linux.
SysRq-сочетания клавиш
Начнем немного издалека. В мире Linux есть такое понятие, как SysRq-сочетания клавиш. На PC им соответствуют сочетания Alt + PrintScreen + что-то. Предназначены они главным образом для отладочных целей, а значит нам не повредит про них знать.
Чтобы ядро поддерживало SysRq-сочетания, оно должно быть собрано с соответствующей опцией (в Ubuntu включена по умолчанию). Кроме того, их поддержку нужно явно активировать одной из следующих команд:
Чтобы не вводить их заново после перезагрузки, можно отредактировать файл /etc/sysctl.conf.
Примеры некоторых интересных сочетаний:
Вывод некоторых сочетаний довольно длинный и целиком на экране он не умещается. К счастью, вывод дублируется в файл /var/log/kern.log.
Само собой разумеется, по SSH эти сочетания клавиш не работают. Если физического доступа к машине нет, можно делать все то же самое как-то так:
Приведенная выше команда эквивалентна нажатию SysRq+P. Все это, на самом деле, очень ценная информация, которая скоро нам пригодится!
Как уронить ядро и получить корку
Простейший способ отладки ядра и его модулей заключается в том, чтобы уронить ядро, записать корку, затем проанализировать корку. В Ubuntu по умолчанию корки не пишутся, этот функционал нужно настроить.
После установки этого пакета требуется перезагрузка. После перезагрузки проверяем, что в /proc/cmdline был добавлен параметр crashkernel.
Если все настроено, пробуем уронить ядро. К счастью, мы уже знаем, как это делается:
Система перезагрузится и в каталоге /var/crash будет записана корка!
Анализ корок и /proc/kcore в отладчике GDB
В Linux есть такой волшебный файл /proc/kcore, позволяющий обращаться на чтение к памяти работающего ядра. С точки зрения отладчика нет разницы, анализировать этот файл, или корки, полученные нами выше.
Как вы можете помнить, для анализа coredump’а отладчику помимо корки нужен и сам исполняемый файл. В случае с ядром Linux этот файл называется vmlinux, но его не так-то просто получить. Дело в том, что Linux настолько жирный, что он сжимает этот самый исполняемый файл и выкидывает из него все «лишнее». Полученный в итоге файл сохраняется в /boot/vmlinuz-что-то-там (с буквой z на конце, а не x).
Это обычный ELF-файл (только очень большой, у меня он весит около 400 Мб) на который можно натравить readelf, objdump и прочие утилиты.
Также vmlinux можно получить из файла /boot/vmlinuz*. В исходниках ядра для этого есть специальный скрипт:
Однако в извлеченном таким образом файле vmlinux полностью отсутствует информация о символах. Если вы когда-нибудь «сжимали» исполняемые файлы при помощи утилиты strip, то вот тут причина та же. К счастью, символы можно восстановить при помощи скрипта kdress:
/ vmlinux \
/ boot / System.map-4.7.0-custom
Можно убедиться, что у полученного файла vmlinux есть символы:
Итак, теперь, имея файл vmlinux, можно проанализировать корку или /proc/kcore:
При использовании нормального vmlinux работает вообще все:
При использовании восстановленного vmlinux можно делать так:
В целом анализ корки ядра мало чем отличается от анализа корок обычных приложений. Умение анализировать корки очень важно при изучении причин падения ядра. Но, увы, при таком подходе вся информация статична и доступна только на чтение. Поэтому идем дальше.
Удаленная отладка ядра по последовательному порту
Далее предполагается, что у вас есть две машины, соединенные между собой через последовательный порт. В реальной жизни машины с последовательными портами сейчас встречаются редко. Хотя вот тут, например, кое-кому удалось прикрутить последовательный порт к Raspberry Pi, так что всякое может быть. Я лично предпочитаю использовать виртуальные машины. Как соединить по последовательному порту виртуалки, работающие под VirtualBox или KVM, ранее рассказывалось в посте Памятка по отладке ядра и драйверов во FreeBSD.
На машину, с которой будем отлаживать ядро, предварительно следует залить файл vmlinux, а также исходники ядра. От последних, впрочем, как уже отмечалось, будет мало пользы.
На машине, которую будем отлаживать, говорим:
После выполнения этой команды в SysRq+H вы увидите новое сочетание SysRq+G, позволяющее войти в отладчик. Почему бы им сразу и не воспользоваться:
На второй машине говорим:
В отладчике выполняем команду:
Если все было сделано правильно, вы обнаружите себя за отладкой работающей системы с возможностью ставить брейкпоинты, менять значения переменных (хотя, скорее, памяти и регистров) и так далее. Пожалуй, единственное отличие от отладки обычных приложений заключается в том, что вы не можете прервать выполнение ядра нажатием в отладчике Ctr+C. Вместо этого нужно снова послать SysRq+G из отлаживаемой системы.
Отладка на ранних этапах загрузки системы
Иногда нужно отлаживать систему на самых ранних этапах ее работы. Вот как это делается в Linux.
При загрузке системы в меню GRUB’а выбираем наше ядро и нажимаем E. Попадем в простой текстовый редактор (как это примерно выглядит), где нужно найти место с указанием параметров ядра. Допишите следующие параметры:
Затем нажмите F10, чтобы загрузиться с указанными параметрами.
Итак, чтобы в следующий раз нам пришлось меньше вводить, в /etc/default/grub найдите параметр GRUB_CMDLINE_LINUX_DEFAULT и допишите в него:
Само собой разумеется, описанные выше действия можно использовать для временного или постоянного указания вообще любых параметров ядра Linux.
Заключение
Поздравляю, теперь вы знаете все об отладке ядерного кода в Linux. А как вы отлаживаете ядро Linux и его модули?
Отладка ядра Windows
Термин «отладка ядра» означает изучение внутренней структуры данных ядра и (или) пошаговую трассировку функций в ядре. Эта отладка является весьма полезным способом исследования внутреннего устройства Windows, поскольку она позволяет получить отображения внутренней системной информации, недоступной при использовании каких-либо других средств, и дает четкое представление о ходе выполнения кода в ядре.
Прежде чем рассматривать различные способы отладки ядра, давайте исследуем набор файлов, который понадобится для осуществления любого вида такой отладки.
Символы для отладки ядра
Файлы символов содержат имена функций и переменных, а также схему и формат структур данных. Они генерируются программой-компоновщиком (linker) и используются отладчиками для ссылок на эти имена и для их отображения во время сеанса отладки. Эта информация обычно не хранится в двоичном коде, поскольку при выполнении кода она не нужна. Это означает, что без нее двоичный код становится меньше по размеру и выполняется быстрее. Но это также означает, что при отладке нужно обеспечить отладчику доступ к файлам символов, связанных с двоичными образами, на которые идут ссылки во время сеанса отладки.
Для использования любого средства отладки в режиме ядра с целью исследования внутреннего устройства структуры данных ядра Windows (списка процессов, блоков потоков, списка загруженных драйверов, информации об использовании памяти и т. д.) вам нужны правильные файлы символов и, как минимум, файл символов для двоичного образа ядра — Ntoskrnl.exe. Файлы таблицы символов должны соответствовать версии того двоичного образа, из которого они были извлечены. Например, если установлен пакет Windows Service Pack или какое-нибудь исправление, обновляющее ядро, нужно получить соответствующим образом обновленные файлы символов.
Как работает отладчик
Описывать я буду Windows Debugging API. Итак, для
того, чтобы начать отладку, поток-отладчик
должен запустить отлаживаемый процесс так,
чтобы ОС знала о том, что запускаемый
процесс будет находиться под отладкой. Для
этого надо запустить отлаживаемую
программу функцией CreateProcess с параметром
dwCreationFlag равным DEBUG_ONLY_THIS_PROCESS (или DEBUG_PROCESS,
если отладчик может отлаживать несколько
процессов одновременно). Теперь отладчик
должен войти в т.н. цикл отладки. Для этого
надо войти в цикл, вызывая функцию WaitForDebugEvent
( while(WaitForDebugEvent(. )==1) ) и после завершения
обработки какого-либо события отладки
вызывать ContinueDebugEvent. Итак, обобщенная схема
работы отладчика:
CreateProcess(«путь_к_отлаживаемой_проге». DEBUG_ONLY_THIS_PROCESS. );
while(WaitForDebugEvent(. )==TRUE)
<
обрабатываем_события(см.далее)
.
.
.
При возникновении событий отладки
существует множество нюансов, не описанных
мной. Например 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
биты 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 🙂
Отладчики же после установки т/о ждут
генерации int 0x1 при обращении к т/о и получая
управление творят беспредел 🙂 С портами все
точно так же, но надо сначала установить в
единицу 3-й бит регистра CR4, и задать адрес
порта в один из регистров DR0-DR3.
