Магистр ДонНТУ Баринов Сергей Сергеевич

Баринов Сергей Сергеевич

Факультет: Компьютерные науки и технологии
Кафедра: Компьютерная инженерия
Специальность: Системное программирование
Тема выпускной работы: Разработка и исследование средств отладки режима ядра операционной системы Microsoft Windows
Руководитель: профессор, д.т.н. Святный Владимир Андреевич
Консультант: старший преподаватель Шевченко Ольга Георгиевна

Реферат выпускной работы магистра
«Разработка и исследование средств отладки режима ядра
операционной системы Microsoft Windows»

Актуальность работы

Отладка — это процесс определения и устранения причин ошибок в программном обеспечении. В некоторых проектах отладка занимает до 50 % общего времени разработки. Многие специалисты считают отладку самым трудным аспектом программирования [1].

Начиная с внедрения БЭВМ (в частности, во время внедрения ЕС ЭВМ) и по настоящий момент средствам для подготовки и отладки программ не уделялось достаточное внимание, более того, зачастую не допускалась сама возможность возникновения ошибки, что ставило программистов в жесткие условия. В результате это приводило к крайней неэффективности использования компьютера. На данный момент отладка является неотъемлемой частью цикла разработки программного обеспечения.

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

Инструментарий разработки прикладного программного обеспечения предлагает программисту широкий спектр возможностей. Любая интегрированная среда разработки включает в себя и возможность отладки без необходимости использования сторонних утилит. Если же речь идет о системном программном обеспечении и разработке драйверов в частности, то в силу его специфики процесс разработки чрезвычайно затруднен и мало автоматизирован. Все фазы разработки, в числе которых и отладка, являются раздельными. Для проведения каждой из них требуются особые условия: написание программного кода выполняется на полноценной компьютерной системе, отладка — на отладочной системе, тестирование — в зависимости от обстоятельств и т.д. Сам же отладчик режима ядра более сложен в освоении и, соответственно, менее дружественен.

В целом можно говорить о недостатке средств отладки ядра. Хотя таковые средства имеются в наличии, зачастую говорить об альтернативах не приходится. Многие программисты говорят о первом негативном опыте при знакомстве с отладчиками режима ядра.

Анализ проблемы

Многие современные архитектуры центральных процессоров, такие как Intel x86 и ее расширения, предоставляют защитный механизм, оперирующий на уровне сегментов и страниц памяти. Этот механизм предоставляет возможность аппаратного ограничения доступа к определенным сегментам или страницам на основе уровня привилегий. Это позволяет операционной системе защищать свой критический код и данные, помещая их в более привилегированные сегменты, чем код приложений. Защитный механизм процессоров семейства Intel x86 оперирует четырьмя уровнями привилегий, называемых также кольцами (рис. 1). Процессор использует уровни привилегий для предотвращения доступа программного кода с меньшим уровнем привилегий к сегменту памяти с большим уровнем неконтролируемым способом [2].

Уровни привилегий процессора семейства Intel x86

Рисунок 1. Уровни привилегий процессора семейства Intel x86

Для предотвращения доступа приложений к критически важным системным данным и данным других приложений операционная система Microsoft Windows опирается на защитный механизм процессора. Она использует только два уровня привилегий, именуя низший уровень пользовательским режимом, а высший — режимом ядра. Исполняемый код приложений работает в пользовательском режиме, тогда как код операционной системы — в режиме ядра. В режиме ядра предоставляется доступ ко всему пространству оперативной памяти и разрешается выполнение любых машинных команд процессора. Тогда как программный код пользовательского режима вынужден обращаться к сервисам операционной системы для выполнения всех критический операций.

Операционная система Microsoft Windows является многозадачной, и благодаря режиму сегментации процессора каждой задаче (процессу) предоставляется собственное линейное адресное пространство виртуальной памяти размером 2 ГБ. Один и тот же виртуальный адрес проецируется для каждого процесса в различные физические адреса, поэтому процесс не в состоянии повредить пространство памяти другого процесса случайно или намеренно. В то же время пространство памяти, используемое операционной системой, разделяется всеми процессам (но доступ к нему имеет только программный код, исполняемый в режиме ядра) (рис. 2).

Структура виртуального адресного пространства

Рисунок 2. Структура виртуального адресного пространства

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

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

Цели и задачи

Конечной целью работы является создание собственного отладчика режима ядра, который должен упростить процесс отладки, снизив порог вхождения. Для этого разрабатываемый отладчик должен иметь современный дружественный графический интерфейс пользователя. На данный момент таким требованиям к построению интерфейса более всего отвечает графическая подсистема Windows Presentation Foundation (WPF), входящая в Microsoft .NET Framework начиная с версии 3.0.

    Таким образом, для создания отладчика необходима реализация следующих задач:
  • анализ сложностей отладки режима ядра;
  • анализ существующих решений;
  • изучение аппаратных отладочных механизмов архитектуры процессоров Intel x86;
  • исследование отладочных механизмов, предоставляемых ядром ОС Windows;
  • исследование функциональных особенностей отладчика Windows Debugger;
  • изучение спецификации модулей расширений Windows Debugger;
  • разработка системного программного обеспечения отладки;
  • разработка прикладного программного обеспечения отладки.

Обзор исследований и разработок

Основные средства отладки режима ядра предоставляются самим производителем операционной системы Windows в рамках свободно распространяемого пакета «Debugging Tools for Windows». Средства включают графический и консольный отладчики WinDbg и KD соответственно (далее Windows Debugger). Работа этих отладчиков опирается на механизмы, предусмотренные разработчиками операционной системы и заложенные в ее ядре [4].

Основным режимом для Windows Debugger является режим интерпретатора команд. Благодаря модульной структуре, наряду с поставляемыми разработчиками командами Windows Debugger поддерживает сторонние модули, называемыми расширениями. В действительности большинство встроенных команд также оформлено в виде расширений.

Windows Debugger ориентирован на удаленную интерактивную и аварийные отладки, при использовании которых раскрываются все его возможности. В тоже время полноценная локальная интерактивная отладка не поддерживается: отладчик позволяет только просматривать некоторые структуры ядра.

Существует модуль расширения для Windows Debugger под названием LiveKD, созданный Марком Руссиновичем, который в некотором смысле реализует локальную интерактивную отладку. LiveKD на ходу создает дамп памяти рабочей системы и использует его для отладки [5].

Отладчик Windows Debugger использует отладочное ядро Microsoft Debugger Engine, дающее возможность манипулировать отлаживаемой системой [6]. В сообществе Microsoft CodePlex размещен проект управляемой библиотеки для взаимодействия с Microsoft Debugger Engine API [7]. Его автором является Nicolae Mogoreanu. В рамках проекта предоставляется два набора классов: первым будет легко пользоваться людям, знакомым с Debugger Engine API, второй более соответствует стилю .NET. Библиотека дает возможность извлекать информацию из дампов памяти и из памяти запущенного приложения. Однако этот проект не позволяет производить отладку режима ядра, поскольку ориентирован на отладку приложений пользовательского режима.

Пакет инструментов «Debugging Tools for Windows» регулярно обновляется и поддерживает все современные операционный системы Windows.

Отладчик ядра SoftICE, выпускавшийся компанией Compuware в пакете программ DriverStudio, традиционно выступал альтернативой пакету «Debugging Tools for Windows». Отличительной чертой SoftICE являлась реализация локальной интерактивной отладки на поддерживаемом аппаратном обеспечении. Отладчик практически полностью мог контролировать работу операционной системы.

С 3 апреля 2006 года продажа продуктов семейства «DriverStudio» была прекращена по причине «множества технических и деловых проблем, а также общего состояния рынка». Последней версией операционной системы, поддержка которой была реализована, является Windows XP Service Pack 2. Как правило, пакеты сервисных обновлений не изменяют прикладной интерфейс операционной системы, но номера системных вызовов и другая недокументированная информация может претерпевать изменение. Отладчик SoftICE опирался на жестко-прописанные адреса внутренних структур данных. Как следствие — с выходом Service Pack 3 совместимость была нарушена. Очевидно, что более поздние версии операционной системы Windows также не поддерживаются.

Syser Kernel Debugger создан небольшой китайской компанией Sysersoft как замена отладчику SoftICE. Первая финальная версия была выпущена в 2007 году. Как и SoftICE, Syser Kernel Debugger способен выполнять интерактивную отладку на работающей системе. Поддерживаемыми являются только 32-разрядные редакции современных версий Windows [8].

Компания Breakpoints Live специализируется на решениях в области отладки приложений, как режима пользователя, так и режима ядра. Предлагаемый ей интерактивный отладчик DebugLive Debugger имеет веб-ориентированный дружественный интерфейс, который должен снизить порог вхождения и облегчить процесс отладки [9]. Отладчик не реализует собственный отладочный стек, а использует отладочное ядро Microsoft Debugger Engine.

Дмитрий Востоков, сертифицированный технический специалист Microsoft, с 2003 года работающий в компании Citrix и давно занимающийся исследованием особенностей отладки режима ядра, является автором нескольких книг по этой теме [10].

На данный момент Windows Debugger является основным инструментом среди разработчиков модулей ядра. Его также использует команда разработчиков ядра операционной системы Windows.

Как показал поиск, в Украине практически нет исследователей, занимающихся вопросами отладки ядра операционной системы Windows. Что касается Донецкого национального технического университета, то ряд авторов в своих статьях затрагивали темы, связанные с режимом ядра.

Полученные результаты

Работа отладчика Windows Debugger опирается на динамически подключаемую библиотеку DbgEng.dll, представляющую собой отладочное ядро (debugging engine) операционной системы и дающую возможность манипулировать отлаживаемой системой (рис. 3). В свою очередь, отладочное ядро использует вспомогательную отладочную библиотеку DbgHelp.dll. Обе библиотеки включены в состав современных версий операционной системы Windows.

Приостановка работы отлаживаемой системы

Рисунок 3. Приостановка работы отлаживаемой системы
(анимация, 8 кадров, 6 повторений, 18 кБ)

Взаимодействие с отладочным ядром осуществляется посредством СОМ-технологии (Component Object Model). Для работы с отладочной средой из управляемого кода необходима соответствующая сборка, инкапсулирующая работу с COM-объектами в соответствии с описанным шаблоном и называемая сборкой взаимодействия. Компания Microsoft не поставляет сборку взаимодействия с отладочным ядром Windows. Поэтому интерфейсы были описаны вручную, хотя этот путь трудоемок и предрасполагает к ошибкам.

    Все описанные интерфейсы являются внутренними для сборки и невидимы за ее пределами. Вместо этого экземпляры COM-объектов, реализующих эти интерфейсы, являются закрытыми членами высокоуровневых классов и создаются внутри них. Это абстрагирует программиста от вопросов COM-взаимодействия и позволяет сосредоточиться на использовании функциональных возможностей сборки. В общем случае, при описании высокоуровневых классов использовалась следующая методика:
  • методы GetX и SetX заменялись на одно свойство, доступное для чтения и записи;
  • методы, имеющие различные имена из-за невозможности перегрузки, приводились к одному имени;
  • структуры, содержащие служебную информацию, такую как размер строки или количество элементов массива, заменялись упрощенными версиями, поскольку для управляемого кода эта информация является избыточной;
  • при необходимости многократного вызова метода с индексом в качестве параметра для запроса списка элементов применялись коллекции;
  • целые числа без знака по возможности заменялись числами со знаком для соответствия со стандартной системой типов (Common Type System), что дает возможность использовать сборку в управляемых языках, не поддерживающих числа без знаков, таких как VB.NET;
  • интерфейсы обратного вызова, предназначавшиеся для уведомления программы об изменениях в отладочном ядре, реализовывались закрытыми подклассами, которые вызывали соответствующие обработчики языковых событий;
  • имена методов приводились в соответствие с правилами именования.

Заключение

    На данный момент в сборке взаимодействия реализованы следующие возможности:
  • подключение к удаленной системе;
  • приостановка и возобновление работы удаленной системы по требованию;
  • получение уведомлений о событиях (изменение состояния регистров, памяти, возникновении исключений и прерываний и др.);
  • просмотр и изменение всех регистров процессора (включая системные регистры).

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

Литература

  1. Макконнелл С. Совершенный код. Мастер-класс / Пер. с англ. — М.: Издательский дом «Русская редакция»; СПб.: Питер, 2005. — 896 стр.: ил.
  2. Intel Corporation. Intel 64 and IA-32 Architectures Software Developer's Manual. Volume 3A: System Programming Guide, Part 1 [Электронный ресурс] — Электрон. дан. — 2007. — Режим доступа: http://developer.intel.com/design/processor/manuals/253668.pdf
  3. Руссинович М. и Соломон Д. Внутреннее устройство Microsoft Windows: Windows Server 2003, Windows XP и Windows 2000. Мастер класс. / Пер. с англ. — 4-е изд. — М.: Издательско-торговый дом «Русская редакция»; СПб.: Питер; 2005. — 992 стр.: ил.
  4. Microsoft Corporation. MSDN Library. Debugging Tools for Windows [Электронный ресурс] — Электрон. дан. — 2010. — Режим доступа: http://msdn.microsoft.com/en-us/library/ff551063(v=vs.85).aspx
  5. Mark Russinovich. Windows Sysinternals. LiveKd [Электронный ресурс] — Электрон. дан. — 2010. — Режим доступа: http://technet.microsoft.com/en-us/sysinternals/bb897415
  6. Microsoft Corporation. MSDN Library. Debugger Engine and Extension APIs [Электронный ресурс] — Электрон. дан. — 2010. — Режим доступа: http://msdn.microsoft.com/en-us/library/ff540525(v=vs.85).aspx
  7. Nicolae Mogoreanu. Managed Library for interacting with Debugger Tools for Windows Engine API [Электронный ресурс] — Электрон. дан. — 2010. — Режим доступа: http://mdbglib.codeplex.com
  8. SyserSoft. Syser Kernel Debugger [Электронный ресурс] — Электрон. дан. — 2011. — Режим доступа: http://www.sysersoft.com
  9. Breakpoints Live. Web based Debugging Software [Электронный ресурс] — Электрон. дан. — 2011. — Режим доступа: http://www.breakpoints.com
  10. Dmitry Vostokov. About [Электронный ресурс] — Электрон. дан. — 2011. — Режим доступа: http://www.dumpanalysis.org/blog/index.php/about