Text
                    
Посвящается Дэйву Катлеру — отцу ядра Windows IW4_Titul_dop.PM6 1 26.10.2007, 12:43
Mark E. Russinovich David A. Solomon Microsoft ® Windows Internals Fourth Edition: ® Windows Server™ 2003, Windows XP, and Windows 2000 IW4_Titul_dop.PM6 2 26.10.2007, 12:43
Марк Руссинович Дэвид Соломон Внутреннее устройство Microsoft Windows : ® ® Windows Server™ 2003, Windows XP и Windows 2000 4е издание МАСТЕРКЛАСС 2008 IW4_Titul_dop.PM6 3 26.10.2007, 12:43
УДК 004.45 ББК 32.973.26–018.2 P89 Руссинович М. и Соломон Д. P89 Внутреннее устройство Microsoft Windows: Windows Server 2003, Windows XP и Windows 2000. Мастеркласс. / Пер. с англ. — 4е изд. — М.: Издатель ство «Русская редакция», 2008. — 992 стр.: ил. ISBN 978-5–7502–0085–6 («Русская редакция») Книга посвящена внутреннему устройству и алгоритмам работы основных компонентов операционной системы Microsoft Windows — Windows Server 2003, Windows XP и Windows 2000 — и файловой системы NTFS. Детально рассмотрены системные механизмы: диспетчеризация ловушек и прерыва ний, DPC, APC, LPC, RPC, синхронизация, системные рабочие потоки, глобаль ные флаги и др. Также описываются все этапы загрузки операционной сис темы и завершения ее работы. В четвертом издании книги больше внимания уделяется глубокому анализу и устранению проблем, изза которых про исходит крах операционной системы или изза которых ее не удается загру зить. Кроме того, рассматриваются детали реализации поддержки аппарат ных платформ AMD x64 и Intel IA64. Книга состоит из 14 глав, словаря тер минов и предметного указателя. Книга предназначена системным админис траторам, разработчикам серьезных приложений и всем, кто хочет понять, как устроена операционная система Windows. Названия всех команд, диалоговых окон и других интерфейсных элементов операционной системы приведены как на английском языке, так и на русском. УДК 004.45 ББК 32.973.26018.2 © 2005-2012, Translation Russian Edition Publishers. Authorized Russian translation of the English edition of Microsoft® Windows® Internals: Microsoft Windows Server™ 2003, Windows XP, and Windows 2000, Fourth Edition, ISBN 9780735619173 © JDavid Solomon, Mark Russinovich. This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same. © 2005-2012, перевод ООО «Издательство «Русская редакция». Авторизованный перевод с английского на русский язык произведения Microsoft® Windows® Internals: Microsoft Windows Server™ 2003, Windows XP, and Windows 2000, Fourth Edition, ISBN 9780735619173 © JDavid Solomon, Mark Russinovich. Этот перевод оригинального издания публикуется и продается с разрешения O’Reilly Media, Inc., которая владеет или распоряжается всеми правами на его публикацию и продажу. © 2005-2012, оформление и подготовка к изданию, ООО «Издательство «Русская редакция». Microsoft, а также товарные знаки, перечисленные в списке, расположенном по адресу: http://www.microsoft.com/about/legal/en/us/IntellectualProperty/Trademarks/EN-US.aspx являются товарными знаками или охраняемыми товарными знаками корпорации Microsoft в США и/или других странах. Все другие товарные знаки являются собственностью соответствующих фирм. Все названия компаний, организаций и продуктов, а также имена лиц, используемые в примерах, вымышлены и не имеют никакого отношения к реальным компаниям, организациям, продуктам и лицам. IW4_Titul_dop.PM6 4 26.10.2007, 12:43
Оглавление Предыстория Предисловие Благодарности Введение ГЛАВА 1 Концепции и инструменты XIII XVI XVII XIX 1 Версии операционных систем Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Базовые концепции и термины . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Windows API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Сервисы, функции и процедуры . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Процессы, потоки и задания . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Виртуальная память . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Режим ядра и пользовательский режим . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Terminal Services и несколько сеансов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Объекты и описатели . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Безопасность . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Реестр . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Unicode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Изучение внутреннего устройства Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Оснастка Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Windows Support Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Ресурсы Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Отладка ядра . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Platform Software Development Kit (SDK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Device Driver Kit (DDK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Утилиты Sysinternals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 ГЛАВА 2 Архитектура системы 38 Требования и цели проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Модель операционной системы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Обзор архитектуры . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Переносимость . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Симметричная многопроцессорная обработка . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Масштабируемость . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Различия между клиентскими и серверными версиями . . . . . . . . . . . . . . . . . . . . . . . 50 Проверочный выпуск . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Ключевые компоненты системы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Подсистемы окружения и их DLL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Ntdll.dll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Исполнительная система . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Ядро . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Уровень абстрагирования от оборудования . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Драйверы устройств . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Системные процессы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
VI Оглавление ГЛАВА 3 Системные механизмы 91 Диспетчеризация ловушек . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Диспетчеризация прерываний . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Диспетчеризация исключений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Диспетчеризация системных сервисов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Диспетчер объектов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Объекты исполнительной системы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Структура объектов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Синхронизация . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Синхронизация ядра при высоком IRQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Синхронизация при низком IRQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Системные рабочие потоки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Глобальные флаги Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 LPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Трассировка событий ядра . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Wow64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 Системные вызовы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Диспетчеризация исключений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Пользовательские обратные вызовы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Перенаправление файловой системы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Перенаправление реестра и отражение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Запросы управления вводом>выводом . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 16>разрядные программы установки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Печать . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Ограничения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 ГЛАВА 4 Механизмы управления Реестр . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Просмотр и изменение реестра . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Использование реестра . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Типы данных в реестре . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Логическая структура реестра . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Анализ и устранение проблем с реестром . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Внутренние механизмы реестра . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Сервисы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Сервисные приложения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Учетные записи сервисов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Диспетчер управления сервисами . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Запуск сервиса . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ошибки при запуске . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Критерии успешной загрузки и последняя удачная конфигурация . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Сбои сервисов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Завершение работы сервиса . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Разделяемые процессы сервисов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Программы управления сервисами . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Windows Management Instrumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Архитектура WMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Провайдеры . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CIM и язык Managed Object Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 196 196 197 198 199 205 211 227 228 233 239 242 245 246 248 249 250 252 253 254 256 257
Оглавление VII Пространство имен WMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Классы сопоставления . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Реализация WMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Защита WMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 262 264 266 266 ГЛАВА 5 267 Запуск и завершение работы системы Процесс загрузки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Что предшествует загрузке на платформах x86 и x64 . . . . . . . . . . . . . . . . . . . . . . . Загрузочный сектор и Ntldr на платформах x86 и x64 . . . . . . . . . . . . . . . . . . . . . . . Процесс загрузки на платформе IA64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Инициализация ядра и компонентов исполнительной системы . . . . . . . . . . . Smss, Csrss и Winlogon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Автоматически запускаемые образы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Анализ проблем при загрузке и запуске системы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Последняя удачная конфигурация . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Безопасный режим . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Консоль восстановления . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Решение распространенных проблем загрузки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Завершение работы системы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 267 271 280 282 286 289 290 291 291 296 298 304 306 ГЛАВА 6 307 Процессы, потоки и задания Внутреннее устройство процессов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Структуры данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Переменные ядра . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Счетчики производительности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Сопутствующие функции . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Что делает функция CreateProcess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Этап 1: открытие образа, подлежащего выполнению . . . . . . . . . . . . . . . . . . . . . . . . Этап 2: создание объекта «процесс» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Этап 3: создание первичного потока, его стека и контекста . . . . . . . . . . . . . . . . Этап 4: уведомление подсистемы Windows о новом процессе . . . . . . . . . . . . . . Этап 5: запуск первичного потока . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Этап 6: инициализация в контексте нового процесса . . . . . . . . . . . . . . . . . . . . . . . Внутреннее устройство потоков . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Структуры данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Переменные ядра . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Счетчики производительности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Сопутствующие функции . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Рождение потока . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Наблюдение за активностью потоков . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Планирование потоков . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Обзор планирования в Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Уровни приоритета . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Сопутствующие утилиты . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Приоритеты реального времени . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Состояния потоков . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . База данных диспетчера ядра . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Квант . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Сценарии планирования . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Переключение контекста . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 307 314 315 315 317 319 322 326 327 328 328 331 331 338 338 339 340 341 344 344 346 349 351 352 356 358 362 365
VIII Оглавление Поток простоя . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Динамическое повышение приоритета . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Многопроцессорные системы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Алгоритмы планирования потоков в многопроцессорных системах . . . . . Объекты>задания . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366 366 376 386 389 394 ГЛАВА 7 395 Управление памятью Введение в диспетчер памяти . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Компоненты диспетчера памяти . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Внутренняя синхронизация . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Конфигурирование диспетчера памяти . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Исследование используемой памяти . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Сервисы диспетчера памяти . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Большие и малые страницы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Резервирование и передача страниц . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Блокировка памяти . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Гранулярность выделения памяти . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Разделяемая память и проецируемые файлы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Защита памяти . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Запрет на выполнение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Копирование при записи . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Диспетчер куч . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Address Windowing Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Системные пулы памяти . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Настройка размеров пулов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Мониторинг использования пулов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ассоциативные списки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Утилита Driver Verifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Структуры виртуального адресного пространства . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Структуры пользовательского адресного пространства на платформе x86 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Структура системного адресного пространства на платформе x86 . . . . . . . . Пространство сеанса на платформе x86 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Системные PTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Структуры 64>разрядных адресных пространств . . . . . . . . . . . . . . . . . . . . . . . . . . . . Трансляция адресов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Трансляция виртуальных адресов на платформе x86 . . . . . . . . . . . . . . . . . . . . . . . . Ассоциативный буфер трансляции . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Physical Address Extension (PAE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Трансляция виртуальных адресов на платформе IA64 . . . . . . . . . . . . . . . . . . . . . . . Трансляция виртуальных адресов на платформе x64 . . . . . . . . . . . . . . . . . . . . . . . . Обработка ошибок страниц . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Недействительные PTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Прототипные PTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Операции ввода>вывода, связанные с подкачкой страниц . . . . . . . . . . . . . . . . . . Конфликты ошибок страницы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Страничные файлы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Дескрипторы виртуальных адресов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Объекты>разделы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Рабочие наборы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Подкачка по требованию . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 396 397 398 398 402 403 404 406 406 407 409 412 415 416 422 424 424 427 432 433 437 440 441 443 446 446 449 449 457 458 460 461 462 464 465 467 468 468 473 475 482 482
Оглавление IX Средство логической предвыборки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Правила размещения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Управление рабочими наборами . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Диспетчер настройки баланса и подсистема загрузки>выгрузки . . . . . . . . . . . Системный рабочий набор . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . База данных PFN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Динамика списков страниц . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Подсистема записи модифицированных страниц . . . . . . . . . . . . . . . . . . . . . . . . . . . Структуры данных PFN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Уведомление о малом или большом объеме памяти . . . . . . . . . . . . . . . . . . . . . . . . . Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 487 488 491 492 494 498 500 502 505 509 ГЛАВА 8 510 Защита Классы безопасности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trusted Computer System Evaluation Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Common Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Компоненты системы защиты . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Защита объектов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Проверка прав доступа . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Дескрипторы защиты и управление доступом . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Права и привилегии учетных записей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Права учетной записи . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Привилегии . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Суперпривилегии . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Аудит безопасности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Вход в систему . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Инициализация Winlogon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Этапы входа пользователя . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Политики ограниченного использования программ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510 510 512 514 518 518 533 544 545 546 552 553 555 557 558 563 565 ГЛАВА 9 566 Подсистема ввода-вывода Компоненты подсистемы ввода>вывода . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Диспетчер ввода>вывода . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Типичная обработка ввода>вывода . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Драйверы устройств . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Типы драйверов устройств . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Структура драйвера . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Объекты «драйвер» и «устройство» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Открытие устройств . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Обработка ввода>вывода . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Типы ввода>вывода . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Пакеты запроса ввода>вывода . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Запрос ввода>вывода к одноуровневому драйверу . . . . . . . . . . . . . . . . . . . . . . . . . . . Запрос ввода>вывода к многоуровневому драйверу . . . . . . . . . . . . . . . . . . . . . . . . . . Порты завершения ввода>вывода . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Driver Verifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Диспетчер Plug and Play (PnP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Уровень поддержки Plug and Play . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Поддержка Plug and Play со стороны драйвера . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Загрузка, инициализация и установка драйвера . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Установка драйвера . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566 568 569 571 571 578 580 585 591 591 595 602 608 615 620 622 623 623 626 635
X Оглавление Диспетчер электропитания . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Работа диспетчера электропитания . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Участие драйверов в управлении электропитанием . . . . . . . . . . . . . . . . . . . . . . . . . Как драйвер управляет электропитанием устройства . . . . . . . . . . . . . . . . . . . . . . . Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640 642 643 647 647 ГЛАВА 10 649 Управление внешней памятью Базовая терминология . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Драйверы дисков . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ntldr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Драйвер класса дисков, порт> и минипорт>драйверы . . . . . . . . . . . . . . . . . . . . . . . . Объекты «устройство» для дисков . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Диспетчер разделов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Управление томами . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Базовые диски . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Динамические диски . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Управление составными томами . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Пространство имен томов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Операции ввода>вывода на томах . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Служба виртуального диска . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Служба теневого копирования тома . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649 650 651 651 655 657 657 659 661 668 674 683 684 686 691 ГЛАВА 11 692 Диспетчер кэша Основные возможности диспетчера кэша . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Единый централизованный системный кэш . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Диспетчер памяти . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Когерентность кэша . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Кэширование виртуальных блоков . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Кэширование потоков данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Поддержка восстанавливаемых файловых систем . . . . . . . . . . . . . . . . . . . . . . . . . . . Управление виртуальной памятью кэша . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Размер кэша . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LargeSystemCache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Виртуальный размер кэша . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Размер рабочего набора кэша . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Физический размер кэша . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Структуры данных кэша . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Общесистемные структуры данных кэша . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Структуры данных кэша, индивидуальные для каждого файла . . . . . . . . . . . . . Интерфейсы файловых систем . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Копирование данных в кэш и из него . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Кэширование с применением интерфейсов проецирования и фиксации . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Кэширование с применением прямого доступа к памяти . . . . . . . . . . . . . . . . . . . Быстрый ввод>вывод . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Опережающее чтение и отложенная запись . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Интеллектуальное опережающее чтение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Кэширование с обратной записью и отложенная запись . . . . . . . . . . . . . . . . . . . Дросселирование записи . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Системные потоки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692 693 693 694 695 695 696 697 699 699 701 702 704 707 707 708 713 714 716 718 719 722 722 724 727 729 730
Оглавление ГЛАВА 12 Файловые системы XI 731 Файловые системы Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CDFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FAT12, FAT16 и FAT32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NTFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Архитектура драйвера файловой системы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Локальные FSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Удаленные FSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Работа файловой системы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Драйверы фильтров файловой системы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Анализ проблем в файловой системе . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Базовый и расширенный режимы Filemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Методики анализа проблем с применением Filemon . . . . . . . . . . . . . . . . . . . . . . . . Цели разработки и особенности NTFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Требования к файловой системе класса «high end» . . . . . . . . . . . . . . . . . . . . . . . . . . . Драйвер файловой системы NTFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Структура NTFS на диске . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Тома . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Кластеры . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Главная таблица файлов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Структура файловых ссылок . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Записи о файлах . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Имена файлов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Резидентные и нерезидентные атрибуты . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Сжатие данных и разреженные файлы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Файл журнала изменений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Индексация . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Идентификаторы объектов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Отслеживание квот . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Консолидированная защита . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Точки повторного разбора . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Поддержка восстановления в NTFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Эволюция архитектуры файловых систем . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Протоколирование . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Восстановление . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Восстановление плохих кластеров в NTFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Механизм EFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Первое шифрование файла . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Процесс расшифровки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Резервное копирование шифрованных файлов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732 732 732 733 736 737 737 738 742 748 754 755 756 761 761 774 777 777 777 778 785 785 788 790 794 798 799 801 802 802 804 805 805 809 814 818 822 826 831 833 834 ГЛАВА 13 835 Поддержка сетей Сетевая архитектура Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Эталонная модель OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Сетевые компоненты Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Сетевые API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Windows Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Remote Procedure Call (RPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . API>интерфейсы доступа к Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835 836 837 839 839 847 852
XII Оглавление Именованные каналы и почтовые ящики . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NetBIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Другие сетевые API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Поддержка нескольких редиректоров . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Маршрутизатор многосетевого доступа . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Многосетевой UNC>провайдер . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Разрешение имен . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WINS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Драйверы протоколов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Расширения TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Драйверы NDIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Разновидности минипорт>драйверов NDIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NDIS, ориентированная на логические соединения . . . . . . . . . . . . . . . . . . . . . . . . . Remote NDIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Привязка . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Многоуровневые сетевые сервисы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Удаленный доступ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Служба репликации файлов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853 861 864 865 866 869 870 871 871 871 875 879 884 885 888 889 890 892 892 892 894 895 896 897 ГЛАВА 14 898 Анализ аварийного дампа Почему происходит крах Windows? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . «Синий экран» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Файлы аварийного дампа . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Генерация аварийного дампа . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Windows Error Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Анализ аварийных дампов через Интернет . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Базовый анализ аварийных дампов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notmyfault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Базовый анализ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Детальный анализ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Средства анализа проблем, вызывающих крах . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Переполнение буфера и особый пул . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Перезапись кода и защита системного кода от записи . . . . . . . . . . . . . . . . . . . . . . Углубленный анализ аварийных дампов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Засорение стека . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Зависание или отсутствие отклика системы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Если аварийного дампа нет . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898 900 902 905 906 907 908 909 910 912 914 915 917 919 920 921 925 Словарь терминов Предметный указатель Об авторах 927 951 969
Предисловие Microsoft Windows была частью моей жизни целых 14 лет. За это время — от версии к версии — наша операционная система развивалась вширь и вглубь. Сегодня работа над Windows — один из самых важных и сложных проектов в мире. В выпуске Windows участвуют более 5000 инженеров. Среди пользо# вателей Windows есть представители уже почти всех культур, она использу# ется как на крупных предприятиях, так и маленькими детьми. Пользователи Windows постоянно требуют ее совершенствования практически во всех сферах — от эффективной работы на крупнейших серверах до применения в дошкольном обучении. Windows поставляется в самых разных ипоста# сях — от встраиваемых версий и выпусков для медиа#центров до редакций для центров обработки данных. Все эти продукты опираются на одни и те же базовые компоненты Windows, которые развиваются и совершенствуются в каждой новой версии. Это фундаментальная книга о внутреннем устройстве базовых компонен# тов Windows. Если вы хотите как можно быстрее освоить принципы внут# ренней работы Windows, тогда эта книга для вас. Освоение всех частей столь основательного продукта — задача устрашающая. Но если вы начнете с ба# зовых концепций системы, сложить фрагменты головоломки воедино будет гораздо легче. С эволюцией самой Windows развивается и эта книга — сей# час публикуется ее четвертое издание. Мы уже давно используем ее для обу# чения новых сотрудников Microsoft, так что предлагаемые вам материалы проверены на практике. Если вы вроде меня, значит, вам тоже нравится разбираться в том, как уст# роены вещи. Чтение книжек типа «как использовать то#то и то#то» меня ни# когда не удовлетворяло. Когда понимаешь, как именно устроена вещь, пользу# ешься ею гораздо эффективнее и, честно говоря, с бóльшим удовольствием. Если вас интересует Windows «с изнанки», вы выбрали подходящую книгу. Дэвид и Марк проделали превосходную работу, написав книгу о техничес# кой «изнанке» Windows. А инструменты, которые они предлагают вам, — от# личное средство для самостоятельного обучения и диагностики. Прочитав эту книгу, вы будете гораздо лучше понимать, как взаимодействуют между собой различные компоненты и подсистемы, какие усовершенствования внесены в новую версию и как выжать из них максимум возможного. Это был долгий путь — и он все еще продолжается. Так что открывайте книгу, а заодно и капот, под которым бьется сердце одной из самых потря# сающих операционных систем. Джим Олчин, вицепрезидент группы платформ корпорации Microsoft
Благодарности В первую очередь мы хотим особо поблагодарить следующих людей. 쐽 Дэйва Катлера (Dave Cutler), заслуженного старшего инженера и пер вого архитектора Microsoft Windows NT. Дэйв разрешил Дэвиду Соломо ну (David Solomon) доступ к исходному коду и всячески поддерживал его преподавательскую деятельность, посвященную объяснению деталей внутреннего устройства Windows NT, а также его работу над вторым и третьим изданием книги. Помимо рецензирования главы по процессам и потокам, Дэйв ответил на массу вопросов об архитектуре ядра и напи сал об истории создания Windows для нашей книги. 쐽 Джима Олчина (Jim Allchin), нашего главного спонсора, — за предис ловие к этой книге и за отстаивание интересов нашего дела в Microsoft. 쐽 Роба Шорта (Rob Short), вицепрезидента, который позаботился о том, чтобы нам предоставили ресурсы и доступ к нужным людям. Мы также выражаем признательность двум разработчикам из отдела Win dows за подготовку новых материалов, включенных в это издание: 쐽 Адриану Маринеску (Adrian Marinescu), который написал заметно раз росшийся раздел по диспетчеру куч в главе, где рассматривается диспет чер памяти. 쐽 Самеру Арафеху (Samer Arafeh), который предоставил материалы по Wow64. Спасибо нашему старому приятелю, Джеффри Рихтеру (Jeffrey Richter), с которым мы часто вместе обедаем, за врезку «Как насчет .NET и WinFX?» в главе 1 и за постоянное напоминание о том, как мало людей, понастояще му интересующихся тем, о чем мы говорим в своей книге. В этой книге не было бы такой глубины и точности изложения техничес ких сведений без поддержки, замечаний и предложений ключевых членов команды разработчиков Microsoft Windows. Вот эти люди: Murali Brahmadesam Molly Brown Duncan Bryce Daniel Bucherer Neal Christian Neill Clift Mike Danseglio Joseph Davies Cenk Ergan Tom Fout Nar Ganapathy David Golds Robert Gu Jeff Hamblin Pat Hoffer Anthony Jones Tom Jones Joseph Joy Shreeniwas Kelkar Connie La Chasse Mike Lai Paul Leach Gerald Maffeo Aaron Margosis Iain McDonald Kamen Moutafov Adi Oltean Vince Orgovan Daniel Pravat Dragos Sambotin Jon Schwartz Rob Short Paul Sliwowicz Chittur Subbaraman Cristian Teodorescu Andre Vachon Landy Wang Richard Ward Brad Waters Bruce Worthington Mark Zbikowsk Khawar Zuberi
XVIII Благодарности БЕЗОПАСНОСТЬ Были и другие, кто отвечал на наши вопросы в коридорах или кафетери ях, — если мы вас пропустили, пожалуйста, простите нас! Мы также выражаем благодарность Джейми Ханрахан (Jamie Hanrahan) из Azius Developer Training (www.azius.com), которая в соавторстве с Дэвидом под готовила учебный курс по внутренней архитектуре исходной версии Windows. На основе этого курса было написано второе издание этой книги. Джейми, у которой настоящий талант доходчиво объяснять сложнейшие вещи, предоста вила нам отдельные материалы, а также ряд схем и иллюстраций. Спасибо Дэйву Проберту (Dave Probert) за то, что разместил в сети наши черновые материалы для распространения среди рецензентов внутри Microsoft. Благодарим Джонатана Славза (Jonathan Sloves) из AMD, с помощью ко торого нам предоставили тестовые системы AMD64; они очень помогли нам в написании материалов по 64разрядной архитектуре и в переносе ряда утилит Sysinternals на платформу x64. Наконец, мы хотим выразить благодарность следующим сотрудникам Microsoft Press за их вклад в эту книгу. 쐽 Робину Ван!Штеенбергу (Robin van Steenburgh), рецензенту издатель ства, за терпение в работе с нами над этим проектом. 쐽 Салли Стикни (Sally Stickney), которая на первых порах попрежнему была редактором нашего проекта, но потом ее закрутил водоворот адми нистративных дел. Мы очень скучали без вас! 쐽 Валери Вулли (Valerie Woolley), которая приняла бразды правления от Салли и стала нашим новым редактором проекта. Вы замечательная и не такая резкая, как Салли! 쐽 Роджеру Лебланку (Roger LeBlanc), который одолел все главы и сумел сократить в них текст, найти несогласованности и вообще довести нашу рукопись до высоких стандартов Microsoft Press. Дэвид Соломон и Марк Руссинович сентябрь 2004 г.
Г Л А В А 1 Концепции и инструменты В этой главе мы познакомим вас с основными концепциями и терминами операционной системы Microsoft Windows, которые будут использоваться в последующих главах, в том числе с Windows API, процессами, потоками, вир туальной памятью, режимом ядра и пользовательским режимом, объектами, описателями (handles), защитой, реестром. Мы также расскажем об инстру ментах, с помощью которых вы сможете исследовать внутреннее устройство Windows. К ним относятся, например, отладчик ядра, оснастка Performance и важнейшие утилиты с сайта www.sysinternals.com. Кроме того, мы поясним, как пользоваться Windows Device Driver Kit (DDK) и Platform Software Deve lopment Kit (SDK) в качестве источника дополнительной информации о внутреннем устройстве Windows. Вы должны хорошо понимать все, что написано в этой главе, — в осталь ной части книги мы предполагаем именно так. Версии операционных систем Windows Эта книга охватывает три последние версии операционной системы Micro soft Windows, основанные на кодовой базе Windows NT: Windows 2000, Win dows XP (32 и 64разрядные версии) и Windows Server 2003 (32 и 64раз рядные версии). Текст относится ко всем трем версиям, если не оговорено иное. В таблице 11 перечислены выпуски кодовой базы Windows NT, номе ра версий и названия продуктов. Таблица 1-1. Выпуски операционной системы Windows Название продукта Номер версии Windows NT 3.1 3.1 Дата выпуска Июль 1993 г. Windows NT 3.5 3.5 Сентябрь 1994 г. Windows NT 3.51 3.51 Май 1995 г. Windows NT 4.0 4.0 Июль 1996 г. Windows 2000 5.0 Декабрь 1999 г. Windows XP 5.1 Август 2001 г. Windows Server 2003 5.2 Март 2003 г.
2 ГЛ А В А 1 БЕЗОПАСНОСТЬ Windows NT и Windows 95 При первом выпуске Windows NT компания Microsoft дала ясно по нять, что это долгосрочная замена Windows 95 (и ее последующих выпусков — Windows 98 и Windows Millennium Edition). Вот список некоторых архитектурных различий и преимуществ Windows NT (и ее последующих выпусков) над Windows 95 (и ее последующими выпус ками). 쐽 Windows NT поддерживает многопроцессорные системы, а Win dows 95 — нет. 쐽 Файловая система Windows NT поддерживает средства защиты, на пример управление избирательным доступом (discretionary access control). В файловой системе Windows 95 этого нет. 쐽 Windows NT — полностью 32разрядная (а теперь и 64разрядная) операционная система, в ней нет 16разрядного кода, кроме того, который предназначен для выполнения 16разрядных Windows приложений. Windows 95 содержит большой объем старого 16раз рядного кода из предшествующих операционных систем — Win dows 3.1 и MSDOS. 쐽 Windows NT полностью реентерабельна, а многие части Windows 95 нереентерабельны (в основном это касается 16разрядного кода, взятого из Windows 3.1). Большинство функций, связанных с гра фикой и управлением окнами (GDI и USER), включают именно не реентерабельный код. Когда 32разрядное приложение в Windows 95 пытается вызвать системный сервис, реализованный как нере ентерабельный 16разрядный код, оно должно сначала получить общесистемную блокировку (или мьютекс), чтобы предотвратить вход других потоков в нереентерабельную кодовую базу. Еще хуже, что 16разрядное приложение удерживает такую блокировку в те чение всего времени своего выполнения. В итоге, хотя ядро Win dows 95 содержит 32разрядный планировщик с поддержкой мно гопоточности и вытесняющей многозадачности, приложения час то работают как однопоточные изза того, что большая часть сис темы реализована как нереентерабельный код. 쐽 Windows NT позволяет выполнять 16разрядные Windowsприло жения в выделенном адресном пространстве, а Windows 95 всегда выполняет такие приложения в общем адресном пространстве, в котором они могут навредить друг другу и привести к зависанию системы. 쐽 Разделяемая (общая) память процесса в Windows NT видна только тем процессам, которые имеют проекцию на один и тот же блок разделяемой памяти. В Windows 95 вся общая память видна и дос тупна для записи всем процессам. Таким образом, любой процесс
ГЛАВА 9 Концепции и инструменты 3 может чтото записать и повредить какието данные в общей памя ти, используемые другими процессами. 쐽 Некоторые критически важные страницы памяти, занимаемые опе рационной системой Windows 95, доступны для записи из пользо вательского режима, а значит, обычное приложение может повре дить содержимое этих страниц и привести к краху системы. Единственное, что умеет Windows 95 и чего никогда не смогут де лать операционные системы на основе Windows NT, — выполнять все старые программы для MSDOS и Windows 3.1 (а именно программы, требующие прямого доступа к оборудованию), а также 16разрядные драйверы устройств MSDOS. Если одной из основных целей разработ ки Windows 95 была 100%я совместимость с MSDOS и Windows 3.1, то исходной целью разработки Windows NT — возможность выполне ния большинства существующих 16разрядных приложений при ус ловии сохранения целостности и надежности системы. Базовые концепции и термины В книге будут часто встречаться ссылки на концепции и структуры, с кото рыми некоторые читатели, возможно, не знакомы. Здесь мы определимся с используемой в дальнейшем терминологией. Windows API Это системный интерфейс программирования в семействе операционных систем Microsoft Windows, включая Windows 2000, Windows XP, Windows Server 2003, Windows 95, Windows 98, Windows Millennium Edition (Me) и Windows CE. Каждая операционная система реализует разное подмножество Windows API. Windows 95, Windows 98, Windows Me и Windows CE в этой книге не рассматриваются. ПРИМЕЧАНИЕ Windows API описывается в документации Platform Software Development Kit (SDK). (См. раздел «Platform Software Develop ment Kit (SDK)» далее в этой главе.) Эту документацию можно бесплат но просмотреть на сайте msdn.microsoft.com. Она также поставляется с Microsoft Developer Network (MSDN) всех уровней подписки. (MSDN — это программа Microsoft для поддержки разработчиков. Подробности см. на сайте msdn.microsoft.com.) Отличное описание того, как програм мировать с использованием базового Windows API, см. в четвертом из дании книги Джеффри Рихтера (Jeffrey Richter) «Microsoft Windows для профессионалов» (Русская Редакция, 2000). До появления 64разрядных версий Windows XP и Windows Server 2003 интерфейс программирования 32разрядных версий операционных систем Windows назывался Win32 API, чтобы отличать его от исходного 16разряд ного Windows API. В этой книге термин «Windows API» относится к 32разряд
4 ГЛ А В А 1 БЕЗОПАСНОСТЬ ному интерфейсу программирования Windows 2000, а также к 32 и 64раз рядным интерфейсам программирования Windows XP и Windows Server 2003. Windows API включает тысячи вызываемых функций, которые сгруппи рованы в следующие основные категории: 쐽 базовые сервисы (Base Services); 쐽 сервисы компонентов (Component Services); 쐽 сервисы пользовательского интерфейса (User Interface Services); 쐽 сервисы графики и мультимедиа (Graphics and Multimedia Services); 쐽 коммуникационное взаимодействие и совместная работа (Messaging and Collaboration); 쐽 сети (Networking); 쐽 Webсервисы (Web Services). Основное внимание в нашей книге уделяется внутреннему устройству ключевых базовых сервисов, в частности поддержки процессов и потоков (threads), управления памятью, вводавывода и защиты. Как насчет .NET и WinFX? .NET Framework состоит из библиотеки классов, называемой Frame work Class Library (FCL), и общеязыковой исполняющей среды (Com mon Language Runtime, CLR), которая предоставляет среду для выпол нения управляемого кода с такими возможностями, как компиляция по требованию (justintime compilation, JIT compilation), верификация типов, сбор мусора и защита по правам доступа кода (code access secu rity). Благодаря этому CLR создает среду разработки, которая повыша ет продуктивность труда программистов и уменьшает вероятность появления распространенных ошибок программирования. Отличное описание .NET Framework и ее базовой архитектуры см. в книге Джеф фри Рихтера «Программирование на платформе Microsoft .NET Frame work» (Русская Редакция, 2003). CLR реализована как классический COMсервер, код которой хра нится в стандартной Windows DLL пользовательского режима. Факти чески все компоненты .NET Framework реализованы как стандартные Windows DLL пользовательского режима, занимающие уровень поверх неуправляемых функций Windows API. (Никакие компоненты .NET Framework не работают в режиме ядра.) На рис. 11 показаны взаимо связи этих компонентов.
ГЛАВА 9 Рис. 1-1. Концепции и инструменты Взаимосвязи компонентов .NET Framework WinFX — «новый Windows API». Это результат эволюционного раз вития .NET Framework, которая будет поставляться с версией Windows под кодовым названием «Longhorn», следующим выпуском Windows. WinFX также можно установить в Windows XP и Windows Server 2003. WinFX образует фундамент для приложений следующего поколения, создаваемых для операционной системы Windows. История создания Win32 API Интересно, что поначалу Win32 не рассматривался как интерфейс про граммирования для Microsoft Windows NT. Поскольку проект Windows NT начинался как замена OS/2 версии 2, основным интерфейсом програм мирования был 32разрядный OS/2 Presentation Manager API. Однако год спустя на рынке появилась Microsoft Windows 3.0, быстро ставшая очень популярной. В результате Microsoft сменила курс и перенацелила проект Windows NT на будущую замену семейства продуктов Windows, а не OS/2. Вот на этомто перепутье и встал вопрос о создании Windows API — до этого Windows API существовал только как 16разрядный интерфейс. Хотя в Windows API должно было появиться много новых функций, отсутствующих в Windows 3.1, Microsoft решила сделать новый API по возможности совместимым с именами функций, семантикой и типа ми данных в 16разрядном Windows API, чтобы максимально облег чить бремя переноса существующих 16разрядных Windowsприложе ний в Windows NT. Поэтому тот, кто, впервые глядя на Windows API, удивляется, почему многие имена и интерфейсы функций кажутся противоречивыми, должен учитывать, что одной из причин такой противоречивости было стремление сделать Windows API совмести мым со старым 16разрядным Windows API. 5
6 ГЛ А В А 1 БЕЗОПАСНОСТЬ Сервисы, функции и процедуры Несколько терминов в документации Windows для пользователей и програм мистов имеет разный смысл в разных контекстах. Например, понятие «сер вис» (service) может относиться к вызываемой функции операционной сис темы, драйверу устройства или серверному процессу (в последнем случае сервис часто называют службой). Ниже показано, что означают подобные термины в этой книге. 쐽 Функции Windows API Документированные, вызываемые подпрог раммы в Windows API, например CreateProcess, CreateFile и GetMessage. 쐽 Неуправляемые («родные») системные сервисы (или исполняе мые системные сервисы) Недокументированные низкоуровневые сервисы операционной системы, которые можно вызывать в пользова тельском режиме. Так, NtCreateProcess — это внутрисистемный сервис, вы зываемый Windowsфункцией CreateProcess при создании нового процес са. (Определение неуправляемых функций см. в разделе «Диспетчериза ция системных сервисов» главы 3.) 쐽 Функции (или процедуры) ядра Подпрограммы внутри операцион ной системы Windows, которые можно вызывать только в режиме ядра (определение мы дадим чуть позже). Например, ExAllocatePool — проце дура, вызываемая драйверами устройств для выделения памяти из систем ных куч (динамически распределяемых областей памяти) Windows. 쐽 Windowsсервисы Процессы, запускаемые диспетчером управления сервисами в Windows. (Хотя в документации на реестр драйверы уст ройств Windows определяются как сервисы, мы не пользуемся таким тер мином в этой книге.) Например, сервис Task Scheduler выполняется в про цессе пользовательского режима, который поддерживает команду at (ана логичную UNIXкоманде at или cron). 쐽 DLL (динамически подключаемая библиотека) Набор вызывае мых подпрограмм, включенных в один двоичный файл, который прило жения, использующие эти подпрограммы, могут динамически загружать во время своего выполнения. В качестве примера можно привести моду ли Msvcrt.dll (библиотека исполняющей подсистемы C) и Kernel32.dll (одна из библиотек подсистемы Windows API). DLL активно используют ся компонентами и приложениями Windows пользовательского режима. Преимущество DLL над статическими библиотеками в том, что приложе ния могут разделять DLLмодули, а Windows гарантирует, что в памяти будет находиться лишь по одному экземпляру используемых DLL. Процессы, потоки и задания Хотя на первый взгляд кажется, что программа и процесс — понятия прак тически одинаковые, они фундаментально отличаются друг от друга. Про грамма представляет собой статический набор команд, а процесс — это кон тейнер для набора ресурсов, используемых при выполнении экземпляра
ГЛАВА 9 Концепции и инструменты 7 программы. На самом высоком уровне абстракции процесс в Windows вклю чает следующее: 쐽 закрытое виртуальное адресное пространство — диапазон адресов вир туальной памяти, которым может пользоваться процесс; 쐽 исполняемую программу — начальный код и данные, проецируемые на виртуальное адресное пространство процесса; 쐽 список открытых описателей (handles) различных системных ресур сов — семафоров, коммуникационных портов, файлов и других объектов, доступных всем потокам в данном процессе; 쐽 контекст защиты (security context), называемый маркером доступа (ac cess token) и идентифицирующий пользователя, группы безопасности и привилегии, сопоставленные с процессом; 쐽 уникальный идентификатор процесса (во внутрисистемной терминоло гии называемый идентификатором клиента); 쐽 минимум один поток. Каждый процесс также указывает на свой родительский процесс (про цесссоздатель). Однако, если родитель существует, эта информация не об новляется. Поэтому есть вероятность, что некий процесс указывает на уже несуществующего родителя. Это не создает никакой проблемы, поскольку никто не полагается на наличие такой информации. Следующий экспери мент иллюстрирует данный случай. ЭКСПЕРИМЕНТ: просмотр дерева процессов Большинство утилит не отображает такой уникальный атрибут, как идентификатор родительского процесса. Значение этого атрибута можно получить программно или с помощью оснастки Performance, запросив значение счетчика Creating Process ID [Код (ID) создавшего процесса]. Дерево процессов показывается утилитой Tlist.exe (из Win dows Debugging Tools), если вы указываете ключ /t. Вот образец выво да этой команды: C:\>tlist /t System Process (0) System (2) smss.exe (21) csrss.exe (24) winlogon.exe (35) services.exe (41) spoolss.exe (69) llssrv.exe (94) LOCATOR.EXE (96) RpcSs.exe (112) inetinfo.exe (128) lsass.exe (44) nddeagnt.exe (119) см. след. стр.
8 ГЛ А В А 1 БЕЗОПАСНОСТЬ explorer.exe (123) Program Manager OSA.EXE (121) WINWORD.EXE (117) Microsoft Word  msch02(s).doc cmd.exe (72) Command Prompt  tlist /t tlist.EXE (100) Взаимоотношения процессов (дочернийродительский) Tlist пока зывает отступами. Имена процессов, родительские процессы которых на данный момент завершились, выравниваются по левому краю, по тому что установить их родственные связи невозможно — даже если процессыпрапредки еще существуют. Windows сохраняет идентифи катор только родительского процесса, так что проследить его созда теля нельзя. Чтобы убедиться в этом, выполните следующие операции. 1. Откройте окно командной строки. 2. Наберите start cmd для запуска второго окна командной строки. 3. Откройте диспетчер задач. 4. Переключитесь на второе окно командной строки. 5. Введите mspaint для запуска Microsoft Paint. 6. Щелкните второе окно командной строки. 7. Введите exit. (Заметьте, что окно Paint остается.) 8. Переключитесь в диспетчер задач. 9. Откройте его вкладку Applications (Приложения). 10. Щелкните правой кнопкой мыши задачу Command Prompt (Команд ная строка) и выберите Go To Process (Перейти к процессам). 11. Щелкните процесс Cmd.exe, выделенный серым цветом. 12. Щелкнув правой кнопкой мыши, выберите команду End Process Tree (Завершить дерево процессов). 13. В окне Task Manager Warning (Предупреждение диспетчера задач) щелкните кнопку Yes (Да). Первое окно командной строки исчезнет, но вы попрежнему смо жете наблюдать окно Paint, так как оно является внуком первого из завершенных процессов Command Prompt. А поскольку второй (роди тельский процесс Paint) тоже завершен, связь между родителем и вну ком потеряна. Для просмотра (и модификации) процессов и информации, связанной с ними, существует целый набор утилит. Следующие эксперименты демонст рируют, как получить ту или иную информацию о процессе с помощью не которых из этих утилит. Они включаются непосредственно в саму Windows, а также в Windows Support Tools, Windows Debugging Tools, ресурсы Windows и Platform SDK; ряд утилит можно получить с сайта www.sysinternals.com. Многие из этих утилит выводят перекрывающиеся подмножества информа ции о базовых процессах и потоках, иногда идентифицируемые по разным именам.
ГЛАВА 9 Концепции и инструменты 9 Вероятно, наиболее широко применяемая утилита для анализа активно сти процессов — Task Manager (Диспетчер задач). (Любопытно, что в ядре Windows нет такого понятия, как задача, так что Task Manager на самом деле является инструментом для управления процессами.) Следующий экспери мент показывает разницу между тем, что Task Manager перечисляет как при ложения и процессы. ЭКСПЕРИМЕНТ: просмотр информации о процессах через диспетчер задач Диспетчер задач Windows отображает список выполняемых в систе ме процессов. Его можно запустить тремя способами: 1) нажав клави ши Ctrl+Shift+Esc; 2) щелкнув панель задач правой кнопкой мыши и выбрав команду Task Manager (Диспетчер задач); 3) нажав клавиши Ctrl+Alt+Del. После запуска диспетчера задач откройте вкладку Pro cesses (Процессы). Заметьте, что процессы идентифицируются по име ни образа, экземплярами которого они являются. В отличие от неко торых объектов в Windows процессам нельзя присваивать глобальные имена. Для просмотра более подробных сведений выберите из меню View (Вид) команду Select Columns (Выбрать столбцы) и укажите, ка кая дополнительная информация вас интересует. Если вкладка Processes окна диспетчера задач со всей очевидностью показывает список процессов, то содержимое вкладки Applications (Приложения) нуждается в пояснениях. На ней отображается список видимых окон верхнего уровня всех объектов «рабочий стол» интерак тивного объекта WindowStation. (По умолчанию существуют два объек та «рабочий стол», но вы можете создать дополнительные рабочие сто лы через Windowsфункцию CreateDesktop.) Колонка Status (Состоя ние) дает представление о том, находится ли поток — владелец окна в состоянии ожидания Windowsсообщения. «Running» («Выполняет ся») означает, что поток ожидает ввода в окно, а «Not Responding» («Не см. след. стр.
10 ГЛ А В А 1 БЕЗОПАСНОСТЬ отвечает») — что не ожидает (т. е. занят либо ждет завершения опера ции вводавывода или освобождения какоголибо синхронизирующе го объекта). Вкладка Applications позволяет идентифицировать процесс, кото рому принадлежит поток, владеющий какимлибо окном задачи. Для этого щелкните правой кнопкой мыши имя задачи и выберите коман ду Go To Process (Перейти к процессам). Утилита Process Explorer (с сайта www.sysinternals.com) показывает боль ше информации о процессах и потоках, чем любой другой доступный ин струмент; вот почему она используется нами во многих экспериментах, ко торые вы увидите в этой книге. Ниже перечислены некоторые уникальные сведения, выводимые утилитой Process Explorer, и ее возможности: 쐽 полное имя (вместе с путем) выполняемого образа; 쐽 маркер защиты процесса (список групп и привилегий); 쐽 выделение изменений в списке процессов и потоков; 쐽 список сервисов внутри процессов — хостов сервисов с выводом отобра жаемого имени (display name) и описания; 쐽 процессы, которые являются частью задания, и детальные сведения о за даниях; 쐽 процессы, выполняющие .NET/WinFXприложения, и сведения, специ фичные для .NET (например, список доменов приложений и счетчики производительности, относящиеся к CLR); 쐽 время запуска процессов и потоков;
ГЛАВА 9 Концепции и инструменты 11 쐽 полный список файлов, проецируемых в память (не только DLLмодулей); 쐽 возможность приостановки процесса; 쐽 возможность принудительного завершения индивидуальных потоков; 쐽 простота выявления процессов, использующих наибольшую долю про цессорного времени за определенный период. (Оснастка Performance позволяет просматривать процент использования процессора для задан ного набора процессов, но не показывает автоматически процессы, соз данные после начала сеанса мониторинга.) Process Explorer также упрощает доступ к информации, предоставляемой другими утилитами, создавая единую точку ее просмотра: 쐽 дерево процессов с возможностью свертывания отдельных частей этого дерева; 쐽 открытые описатели в процессе без предварительной настройки (утили ты Microsoft для вывода открытых описателей требуют предварительной установки общесистемного флага и перезагрузки); 쐽 список DLL (и файлов, проецируемых в память) в какомлибо процессе; 쐽 активность потоков в какомлибо процессе; 쐽 стеки потоков пользовательского режима (с сопоставлением адресов именам, используя механизм поддержки символов для инструментов от ладки); 쐽 стеки системных потоков режима ядра (с сопоставлением адресов именам, используя механизм поддержки символов для инструментов отладки); 쐽 разница в переключении контекстов (context switch delta) (более нагляд ное представление активности процессора, как поясняется в главе 6); 쐽 лимиты памяти режима ядра (пулов подкачиваемой и неподкачиваемой памяти) (остальные утилиты показывают только текущие размеры). Попробуем провести первый эксперимент с помощью Process Explorer. ЭКСПЕРИМЕНТ: просмотр детальных сведений о процессах с помощью Process Explorer Скачайте последнюю версию Process Explorer с сайта www.sysinter nals.com и запустите ее. При первом запуске вы увидите сообщение о том, что на данный момент символы не сконфигурированы. Когда они корректно сконфигурированы, Process Explorer может обращаться к символьной информации для отображения символьного имени стар товой функции потока и функций в его стеке вызовов (для этого нуж но дважды щелкнуть процесс и выбрать вкладку Threads). Эта инфор мация полезна для идентификации того, что именно делают потоки внутри процесса. Для доступа к символам вы должны установить Debug ging Tools (об этом мы еще поговорим в данной главе). Потом щелк нуть Options, выбрать Configure Symbols и набрать подходящий путь Symbols. Например: см. след. стр.
12 ГЛ А В А 1 БЕЗОПАСНОСТЬ В предыдущем примере для доступа к символам использовался сер вер символов по требованию (ondemand symbol server), а копии фай лов символов хранились на локальном компьютере в папке c:\symbols. Подробнее о конфигурировании сервера символов см. по ссылке http:/ /www.microsoft.com/whdc/ddk/debugging/symbols.mspx. При запуске Process Explorer по умолчанию выводит список про цессов в верхней половине окна, а список открытых описателей для выбранного на данный момент процесса — в нижней половине. Если вы задержите курсор мыши над именем процесса, Process Explorer так же показывает описание образа, название компании и полный путь. Вот как использовать некоторые базовые возможности Process Exp lorer: 1. Отключите нижнюю секцию, сбросив View, Show Lower Pane. (Ниж няя секция может отображать открытые описатели или проециру емые DLL и файлы — об этом речь пойдет в главах 3 и 7.) 2. Обратите внимание на то, что процессы, являющиеся хостами сер висов, по умолчанию выделяются розовым цветом. Ваши собствен ные процессы выделяются синим. (Эти цвета можно настроить.)
ГЛАВА 9 Концепции и инструменты 13 3. Задержите курсор мыши над именем образа и обратите внимание на то, что в подсказке отображается полный путь. 4. Щелкните View, Select Columns и добавьте путь образа. 5. Отсортируйте по колонке процессов и вы увидите, что представле ние в виде дерева исчезло. (Вы можете либо вывести представление в виде дерева, либо сортировать по любой из отображаемых коло нок.) Снова щелкните для сортировки по алфавиту в обратном по рядке (от Z к A). После этого очередной щелчок вернет представ ление в виде дерева. 6. Сбросьте View, Show Processes From All Users для отображения толь ко ваших процессов. 7. Перейдите в Options, Difference Highlight Duration и смените значе ние на 5 секунд. Потом запустите новый процесс (какой угодно) и обратите внимание на то, что этот процесс выделяется зеленым в течение 5 секунд. Закройте новый процесс и заметьте, что этот про цесс выделяется красным в течение 5 секунд, прежде чем исчезнуть из древовидного списка. Эта функция может пригодиться для об наружения создаваемых и завершаемых процессов в системе. 8. Наконец, дважды щелкните какойнибудь процесс и изучите вклад ки, доступные в окне свойств процесса. (Эти вкладки понадобятся нам в дальнейших экспериментах; там же мы поясним, какую ин формацию они сообщают.) Поток (thread) — некая сущность внутри процесса, получающая процес сорное время для выполнения. Без потока программа процесса не может выполняться. Поток включает следующие наиболее важные элементы: 쐽 содержимое набора регистров процессора, отражающих состояние про цессора; 쐽 два стека, один из которых используется потоком при выполнении в ре жиме ядра, а другой — в пользовательском режиме; 쐽 закрытую область памяти, называемую локальной памятью потока (thre adlocal storage, TLS) и используемую подсистемами, библиотеками испол няющих систем (runtime libraries) и DLL; 쐽 уникальный идентификатор потока (во внутрисистемной терминологии также называемый идентификатором клиента: идентификаторы процес сов и потоков генерируются из одного пространства имен и никогда не перекрываются); 쐽 иногда потоки обладают своим контекстом защиты, который обычно используется многопоточными серверными приложениями, подменяю щими контекст защиты обслуживаемых клиентов. Переменные регистры, стеки и локальные области памяти называются контекстом потока. Поскольку эта информация различна на каждой аппа ратной платформе, на которой может работать Windows, соответствующая
14 ГЛ А В А 1 БЕЗОПАСНОСТЬ структура данных специфична для конкретной платформы. Windowsфун кция GetThreadContext предоставляет доступ к этой аппаратнозависимой информации (называемой блоком CONTEXT). Волокна и потоки Волокна (fibers) позволяют приложениям планировать собственные «потоки» выполнения, не используя встроенный механизм планиро вания потоков на основе приоритетов. Волокна часто называют «об легченными» потоками. Они невидимы ядру, так как Kernel32.dll реа лизует их в пользовательском режиме. Для использования волокна нужно вызвать Windowsфункцию ConvertThreadToFiber, которая пре образует поток в волокно. Полученное волокно может создавать до полнительные волокна через функцию CreateFiber (у каждого волок на может быть свой набор волокон). Выполнение волокна (в отличие от потока) не начинается до тех пор, пока оно не будет вручную вы брано вызовом SwitchToFiber. Волокно работает до завершения или до переключения процессора на другое волокно вызовом все той же Swit chToFiber. Подробнее о функциях, связанных с волокнами, см. докумен тацию Platform SDK. Хотя у потоков свой контекст выполнения, каждый поток внутри одного процесса делит его виртуальное адресное пространство (а также остальные ресурсы, принадлежащие процессу). Это означает, что все потоки в процес се могут записывать и считывать содержимое памяти любого из потоков данного процесса. Однако потоки не могут случайно сослаться на адресное пространство другого процесса. Исключение возможно в ситуации, когда тот предоставляет часть своего адресного пространства как раздел общей памяти (shared memory section), в Windows API называемый объектом «про екция файла» (file mapping object), или когда один из процессов имеет пра во на открытие другого процесса и использует функции доступа к памяти между процессами, например ReadProcessMemory и WriteProcessMemory. Кроме закрытого адресного пространства и одного или нескольких пото ков у каждого процесса имеются идентификация защиты и список открытых описателей таких объектов, как файлы и разделы общей памяти, или синхро низирующих объектов вроде мьютексов, событий и семафоров (рис. 12). Каждый процесс обладает контекстом защиты, который хранится в объекте — маркере доступа. Маркер доступа содержит идентификацию за щиты и определяет полномочия данного процесса. По умолчанию у потока нет собственного маркера доступа, но он может получить его, и это позво лит ему подменять контекст защиты другого процесса (в том числе выпол няемого на удаленной системе Windows). Подробнее на эту тему см. главу 8. Дескрипторы виртуальных адресов (virtual address descriptors, VAD) — это структуры данных, используемые диспетчером памяти для учета виртуаль ных адресов, задействованных процессом (см. главу 7).
ГЛАВА 9 Рис. 1-2. Концепции и инструменты 15 Процесс и его ресурсы Windows предоставляет расширение для модели процессов — задания (jobs). Они предназначены в основном для того, чтобы группами процессов можно было оперировать и управлять как единым целым. Объектзадание позволяет устанавливать определенные атрибуты и накладывать ограниче ния на процесс или процессы, сопоставленные с заданием. В этом объекте также хранится информация обо всех процессах, которые были сопостав лены с заданием, но к настоящему времени уже завершены. В какихто от ношениях объектзадание компенсирует отсутствие иерархического дере ва процессов в Windows, а в какихто — даже превосходит по своим возмож ностям дерево процессов UNIX. Более детальное описание внутренней структуры заданий, процессов и потоков, механизмов создания потоков и процессов, а также алгоритмов планирования потоков вы найдете в главе 6. Виртуальная память В Windows реализована система виртуальной памяти, основанная на плос ком (линейном) адресном пространстве. Она создает каждому процессу ил люзию того, что у него есть собственное большое и закрытое адресное про странство. Виртуальная память дает логическое представление, не обязатель но соответствующее структуре физической памяти. В период выполнения диспетчер памяти, используя аппаратную поддержку, транслирует, или про ецирует (maps), виртуальные адреса на физические, по которым реально хранятся данные. Управляя проецированием и защитой страниц памяти, опе рационная система гарантирует, что ни один процесс не помешает другому и не сможет повредить данные самой операционной системы. На рис. 13 показано, как три смежные страницы виртуальной памяти проецируются на три разрозненные страницы физической памяти.
16 Рис. 1-3. ГЛ А В А 1 БЕЗОПАСНОСТЬ Проецирование виртуальной памяти на физическую Поскольку у большинства компьютеров объем физической памяти на много меньше общего объема виртуальной памяти, задействованной выпол няемыми процессами, диспетчер памяти перемещает, или подкачивает (pa ges), часть содержимого памяти на диск. Подкачка данных на диск освобож дает физическую память для других процессов или самой операционной си стемы. Когда поток обращается к странице виртуальной памяти, сброшен ной на диск, диспетчер виртуальной памяти загружает эту информацию с диска обратно в память. Для использования преимуществ подкачки в прило жениях никакого дополнительного кода не требуется, так как диспетчер па мяти опирается на аппаратную поддержку этого механизма. Размер виртуального адресного пространства зависит от конкретной аппаратной платформы. На 32разрядных x86системах теоретический мак симум для общего виртуального адресного пространства составляет 4 Гб. По умолчанию Windows выделяет нижнюю половину этого пространства (в диапазоне адресов от x00000000 до x7FFFFFFF) процессам, а вторую по ловину (в диапазоне адресов от x80000000 до xFFFFFFFF) использует в собст венных целях. Windows 2000 Advanced Server, Windows 2000 Datacenter Ser ver, Windows XP (SP2 и выше) и Windows Server 2003 поддерживают загру зочные параметры /3GB и /USERVA, которые указываются в файле Boot.ini (см. главу 5), что позволяет процессам, выполняющим программы со специ альным флагом в заголовке исполняемого образа, использовать до 3 Гб зак рытого адресного пространства и оставляет операционной системе только 1 Гб. Этот вариант дает возможность приложению вроде сервера базы дан ных хранить в адресном пространстве своего процесса бóльшие порции ба зы данных и тем самым уменьшить частоту проецирования отдельных пред ставлений этой базы. Две структуры виртуальных адресных пространств, поддерживаемые 32разрядной Windows, показаны на рис. 14.
ГЛАВА 9 Рис. 1-4. Концепции и инструменты 17 Структуры адресных пространств для 32-разрядных Windows Хотя три гигабайта лучше двух, этого все равно недостаточно для проеци рования очень больших баз данных. В связи с этим в 32разрядных Windows появился механизм Address Windowing Extension (AWE), который позволяет 32разрядному приложению выделять до 64 Гб физической памяти, а затем проецировать представления (views), или окна (windows), на свое 2гигабайт ное виртуальное адресное пространство. Применение AWE усложняет управ ление проекциями виртуальной памяти на физическую, но снимает пробле му прямого доступа к объему физической памяти, превышающему лимиты 32разрядного адресного пространства процесса. 64разрядная Windows предоставляет процессам гораздо большее адрес ное пространство: 7152 Гб на Itaniumсистемах и 8192 Гб на x64системах. На рис. 15 показана упрощенная схема структур 64разрядных адресных пространств (детали см. в главе 7). Заметьте, что эти размеры отражают не архитектурные лимиты для данных платформ, а ограничения реализации в текущих версиях 64разрядной Windows. Рис. 1-5. Структуры адресных пространств для 64-разрядной Windows Подробнее о реализации диспетчера памяти, в том числе о трансляции адресов и управлении физической памятью в Windows, см. главу 7. Режим ядра и пользовательский режим Для предотвращения доступа приложений к критически важным данным операционной системы и устранения риска их модификации Windows ис пользует два режима доступа к процессору (даже если он поддерживает более двух режимов): пользовательский (user mode) и ядра (kernel mode). Код
18 ГЛ А В А 1 БЕЗОПАСНОСТЬ приложений работает в пользовательском режиме, тогда как код операци онной системы (например, системные сервисы и драйверы устройств) — в режиме ядра. В режиме ядра предоставляется доступ ко всей системной па мяти и разрешается выполнять любые машинные команды процессора. Пре доставляя операционной системе более высокий уровень привилегий, чем прикладным программам, процессор позволяет разработчикам операцион ных систем реализовать такие архитектуры, которые не дают возможности сбойным приложениям нарушать стабильность работы всей системы. ПРИМЕЧАНИЕ В архитектуре процессора Intel x86 определено четы ре уровня привилегий, или колец (rings), предназначенных для защиты кода и данных системы от случайной или умышленной перезаписи ко дом с меньшим уровнем привилегий. Windows использует уровень при вилегий 0 (или кольцо 0) для режима ядра и уровень привилегий 3 (или кольцо 3) для пользовательского режима. Почему Windows использует только два уровня? Дело в том, что на некоторых из ранее поддержи вавшихся аппаратных платформ (например, Compaq Alpha и Silicon Graphics MIPS) реализовано лишь два уровня привилегий. Хотя каждый Windowsпроцесс имеет свою (закрытую) память, код опе рационной системы и драйверы устройств, работающие в режиме ядра, де лят единое виртуальное адресное пространство. Каждая страница в вирту альной памяти помечается тэгом, определяющим, в каком режиме должен работать процессор для чтения и/или записи данной страницы. Страницы в системном пространстве доступны лишь в режиме ядра, а все страницы в пользовательском адресном пространстве — в пользовательском режиме. Страницы только для чтения (например, содержащие лишь исполняемый код) ни в каком режиме для записи недоступны. Windows не предусматривает никакой защиты системной памяти от ком понентов, работающих в режиме ядра. Иначе говоря, код операционной си стемы и драйверов устройств в режиме ядра получает полный доступ к сис темной памяти и может обходить средства защиты Windows для обращения к любым объектам. Поскольку основная часть кода Windows выполняется в режиме ядра, крайне важно, чтобы компоненты, работающие в этом режи ме, были тщательно продуманы и протестированы. Это также подчеркивает, насколько надо быть осторожным при загрузке драйвера устройства от стороннего поставщика: перейдя в режим ядра, он получит полный доступ ко всем данным операционной системы. Такая уяз вимость стала одной из причин, по которым в Windows введен механизм проверки цифровых подписей драйверов, предупреждающий пользователя о попытке установки неавторизованного (неподписанного) драйвера (под робнее на эту тему см. главу 9). Кроме того, механизм Driver Verifier (вери фикатор драйверов) помогает разработчикам драйверов устройств находить в них ошибки (вызывающие, например, утечку памяти или переполнения буферов). Driver Verifier поясняется в главе 7.
ГЛАВА 9 Концепции и инструменты 19 Как вы увидите в главе 2, прикладные программы могут переключаться из пользовательского режима в режим ядра, обращаясь к системному сервису. Например, Windowsфункции ReadFile в ходе своего выполнения приходит ся вызывать внутреннюю подпрограмму Windows — онато и считывает дан ные из файла. Так как эта подпрограмма обращается к внутрисистемным структурам данных, она должна выполняться в режиме ядра. Переключение из пользовательского режима в режим ядра осуществляется специальной командой процессора. Операционная система перехватывает эту команду, обнаруживает запрос системного сервиса, проверяет аргументы, которые поток передал системной функции, и выполняет внутреннюю подпрограм му. Перед возвратом управления пользовательскому потоку процессор пере ключается обратно в пользовательский режим. Благодаря этому операцион ная система защищает себя и свои данные от возможной модификации пользовательскими процессами. ПРИМЕЧАНИЕ Переключение из пользовательского режима в режим ядра (и обратно) не влияет на планирование потока, так как контекст в этом случае не переключается. О диспетчеризации системных сер висов см. главу 3. Так что ситуация, когда пользовательский поток часть своего времени работает в пользовательском режиме, а часть — в режиме ядра, совершенно нормальна. А поскольку подсистема, отвечающая за поддержку графики и окон, функционирует в режиме ядра, то приложения, интенсивно работаю щие с графикой, большую часть времени действуют в режиме ядра, а не в пользовательском режиме. Самый простой способ проверить это — запус тить приложение вроде Microsoft Paint или Microsoft Pinball и с помощью одного из счетчиков оснастки Performance (Производительность), перечис ленных в таблице 12, понаблюдать за показателями времени работы в поль зовательском режиме и в режиме ядра. Таблица 1-2. Счетчики, позволяющие контролировать время работы в различных режимах Объект: счетчик Описание Processor: % Privileged Time (Процессор: % работы в при вилегированном режиме) Процентная доля времени, в течение которого от дельный процессор (или все процессоры) работал в режиме ядра Processor: % User Time (Процессор: % работы в поль зовательском режиме) Процентная доля времени, в течение которого от дельный процессор (или все процессоры) работал в пользовательском режиме Process: % Privileged Time (Процесс: % работы в приви легированном режиме) Процентная доля времени, в течение которого по токи данного процесса выполнялись в режиме ядра Process: % User Time (Процесс: % работы в пользовательском режиме) Процентная доля времени, в течение которого по токи данного процесса выполнялись в пользова тельском режиме см. след. стр.
20 ГЛ А В А 1 Таблица 1-2. БЕЗОПАСНОСТЬ (продолжение) Объект: счетчик Описание Thread: % Privileged Time (Поток: % работы в привиле гированном режиме) Процентная доля времени, в течение которого данный поток выполнялся в режиме ядра Thread: % User Time (Поток: % работы в пользовательском режиме) Процентная доля времени, в течение которого данный поток выполнялся в пользовательском режиме ЭКСПЕРИМЕНТ: наблюдение за активностью потоков с помощью QuickSlice QuickSlice позволяет в динамике наблюдать за соотношением време ни, проведенного каждым процессом в режиме ядра и в пользователь ском режиме. На диаграмме красная часть столбца отражает количе ство процессорного времени в режиме ядра, а синяя — в пользователь ском режиме. (Хотя в книге эти столбцы воспроизведены в чернобе лом цвете, на самом деле они всегда красные и синие.) Сумма всех по казателей, отображаемых столбцами в окне QuickSlice, должна соот ветствовать 100% процессорного времени. Для запуска QuickSlice щел кните кнопку Start (Пуск), выберите команду Run (Выполнить) и вве дите Qslice.exe (в переменной PATH должен быть указан путь к ресур сам Windows). Например, попробуйте запустить такое интенсивно ис пользующее графику приложение, как Paint (Mspaint.exe). Откройте QuickSlice, расположив его окно рядом с окном Paint, и нарисуйте в Paint несколько кривых. В это время вы сможете наблюдать за выпол нением Mspaint.exe в окне QuickSlice, как показано ниже. Чтобы получить дополнительную информацию о потоках процес са, дважды щелкните имя нужного процесса или соответствующий цветной столбик на диаграмме. Вы увидите список потоков этого про цесса и относительное процессорное время, используемое каждым потоком (в рамках процесса, а не всей системы).
ГЛАВА 9 Концепции и инструменты 21 ЭКСПЕРИМЕНТ: режим ядра и пользовательский режим С помощью оснастки Performance вы можете выяснить, сколько време ни ваша система работает в режиме ядра и в пользовательском режиме. 1. Запустите оснастку Performance (Производительность), открыв ме ню Start (Пуск) и последовательно выбрав команды Programs (Про граммы), Administrative Tools (Администрирование), Performance (Производительность). 2. Щелкните на панели инструментов кнопку Add (Добавить) (на этой кнопке изображен большой знак плюс). 3. Выберите в списке объект Processor (Процессор), щелкните счет чик % Privileged Time (% работы в привилегированном режиме) и, удерживая клавишу Ctrl в нажатом состоянии, щелкните счетчик % User Time (% работы в пользовательском режиме). 4. Щелкните кнопку Add (Добавить), а затем Close (Закрыть). 5. Быстро подвигайте мышью. При этом вы должны заметить всплеск на линии % Privileged Time (рис. 16), который отражает время, за траченное на обслуживание прерываний от мыши, и время, пона добившееся подсистеме поддержки окон на отрисовку графики (эта подсистема, как поясняется в главе 2, работает преимуществен но как драйвер устройства в режиме ядра). 6. Закончив, щелкните на панели инструментов кнопку New Counter Set (Новый набор счетчиков) (или просто закройте оснастку). За той же активностью можно понаблюдать через Task Manager (Диспетчер задач). Просто перейдите в нем на вкладку Performance (Быстродействие), а затем выберите из меню View (Вид) команду Show Kernel Times (Вывод времени ядра). Процент загруженности процес сора отражается зеленым цветом, а процент времени работы в режи ме ядра — красным. см. след. стр.
22 ГЛ А В А 1 БЕЗОПАСНОСТЬ Рис. 1-6. Оснастка Performance, показывающая, как распределяется время работы процессора между двумя режимами — пользовательским и ядра Чтобы увидеть, как сама оснастка Performance использует время в двух режимах, запустите ее снова, но добавьте те же счетчики для объекта Process (Процесс). 1. Если вы закрыли оснастку Performance, снова запустите ее. (Если она уже работает, откройте новый экран, щелкнув на панели инст рументов кнопку New Counter Set.) 2. Щелкните кнопку Add на панели инструментов. 3. Выберите в списке объект Process. 4. Выберите счетчики % Privileged Time и % User Time. 5. В списке экземпляров объекта выберите все процессы (кроме про цесса _Total). 6. Щелкните кнопку Add, а затем Close. 7. Быстро подвигайте мышью. 8. Нажмите комбинацию клавиш Ctrl+H для активизации режима вы деления — текущий выбранный счетчик будет выделен белым цве том в Windows 2000 и черным в Windows XP или Windows Server 2003. 9. Прокрутите список всех счетчиков в нижней части окна оснастки, чтобы определить процессы, потоки которых выполнялись при перемещении мыши, и обратите внимание на то, в каком режиме они выполнялись — пользовательском или ядра. Вы должны заметить, как значения счетчиков для процесса оснаст ки Performance — ищите mmc в колонке Instance (Экземпляр) — рез ко увеличиваются при перемещении мыши, поскольку код приложе ния выполняется в пользовательском режиме, а вызываемые им Win dowsфункции — в режиме ядра. Вы также заметите, что при переме щении мыши увеличивается активность работы в режиме ядра пото
ГЛАВА 9 Концепции и инструменты 23 ка процесса csrss. Он представляет поток необработанного ввода (raw input thread) подсистемы Windows, принимающий ввод от клавиату ры и мыши и передающий его процессу, к которому он подключен. (Подробнее о системных потоках см. главу 2.) Наконец, процесс с име нем Idle, потоки которого, как вы убедитесь, тратят почти 100% свое го времени в режиме ядра, на самом деле не является процессом. Это лжепроцесс, используемый для учета тактов процессора в состоянии простоя. Таким образом, когда Windows нечего делать, она предается этому занятию в режиме ядра. Terminal Services и несколько сеансов Terminal Services (службы терминала) обеспечивают в Windows поддержку нескольких интерактивных сеансов пользователей на одной системе. С по мощью Terminal Services удаленный пользователь может установить сеанс на другой машине, зарегистрироваться на ней и запускать приложения на сер вере. Сервер предоставляет клиенту графический пользовательский интер фейс (GUI), а клиент возвращает серверу пользовательский ввод. (Это отли чается от того, как ведет себя X Windows на UNIXсистемах, где разрешает ся выполнять индивидуальные приложения на сервере, а клиенту предостав ляется удаленный дисплей, так как удаленным является весь сеанс пользова теля — не только одно приложение.) Первый сеанс входа на физической консоли компьютера считается кон сольным сеансом, или нулевым сеансом (session zero). Дополнительные се ансы можно создать с помощью программы соединения с удаленным рабо чим столом (Mstsc.exe), а в Windows XP — через механизм быстрого пере ключения пользователей (об этом позже). Возможность создания удаленного сеанса поддерживается Windows 2000 Server, но не Windows 2000 Professional. Windows XP Professional позволяет одному удаленному пользователю подключаться к машине, однако если кто то начинает процедуру входа в консоли, рабочая станция блокируется (т. е. систему можно использовать либо локально, либо удаленно, но не и то, и другое одновременно). Windows 2000 Server и Windows Server 2003 поддерживают два одновремен ных удаленных сеанса. (Это упрощает удаленное управление, например облег чает применение инструментов, требующих от администратора входа на уда ленный компьютер.) Windows 2000 Advanced Server, Datacenter Server и все из дания Windows Server 2003 способны поддерживать более двух сеансов одно временно при условии правильного лицензирования и настройки системы в качестве сервера терминала. Хотя Windows XP Home и Professional не поддерживают несколько удален ных подключений к рабочему столу, они все же поддерживают несколько сеансов, созданных локально через механизм быстрого переключения поль зователей. (Этот механизм отключается в Windows XP Professional, если си стема присоединяется к домену.) Когда пользователь выбирает выключение
24 ГЛ А В А 1 БЕЗОПАСНОСТЬ своего сеанса вместо выхода [например, последовательным выбором Start (Пуск), Log Off (Выход из системы) и Switch User (Смена пользователя) или нажатием клавиши L при одновременном удерживании клавиши Windows], текущий сеанс (т. е. процессы, выполняемые в этом сеансе, и все структуры данных, глобальные для сеанса и описывающие его) остается в системе, а Windows возвращается к основному окну входа. Если в систему входит но вый пользователь, создается новый сеанс. Для приложений, которым нужно знать, выполняются ли они в сеансе сервера терминала, предназначен набор Windows APIфункций, позволяю щих программно распознавать такую ситуацию и контролировать различ ные аспекты служб терминала. (Детали см. в Platform SDK.) В главе 2 кратко описывается, как создаются сеансы, и проводится не сколько экспериментов, показывающих, как просматривать информацию о сеансе с помощью различных инструментов, включая отладчик ядра. В раз деле «Диспетчер объектов» главы 3 поясняется, как создается сеансовый эк земпляр системного пространства имен для объектов и как приложения могут узнавать о других своих экземплярах в той же системе. Наконец, в гла ве 7 рассказывается, как диспетчер памяти настраивает данные, глобальные для сеанса, и управляет ими. Объекты и описатели В операционной системе Windows объект — это единственный экземпляр периода выполнения (runtime instance) статически определенного типа объекта. Тип объекта состоит из общесистемного типа данных, функций, оперирующих экземплярами этого типа данных, и набора атрибутов. Если вы пишете Windowsприложения, вам наверняка знакомы такие объекты, как процесс, поток, файл и событие, — продолжать можно еще долго. Эти объек ты базируются на объектах более низкого уровня, создаваемых и управляе мых Windows. В Windows процесс является экземпляром объекта типа «про цесс», файл — экземпляром объекта типа «файл» и т. д. Атрибут объекта (object attribute) — это поле данных в объекте, частич но определяющее состояние этого объекта. Например, объект типа «про цесс», имеет атрибуты, в число которых входят идентификатор процесса, базовый приоритет и указатель на объект маркера доступа. Методы объекта (средства для манипулирования объектами) обычно считывают или изменя ют какиелибо атрибуты. Так, метод open процесса мог бы принимать иден тификатор процесса и возвращать указатель на этот объект. ПРИМЕЧАНИЕ Не путайте параметр ObjectAttributes, предоставляемый вызывающей программой при создании объекта через Windows API или его родные сервисы, с термином «атрибуты объекта», имеющим более общий смысл. Самое главное различие между объектом и обычной структурой данных заключается в том, что внутренняя структура объекта скрыта. Чтобы полу чить данные из объекта или записать в него какуюто информацию, вы долж
ГЛАВА 9 Концепции и инструменты 25 ны вызвать его сервис. Прямое чтение или изменение данных внутри объек та невозможно. Тем самым реализация объекта отделяется от кода, который просто использует его, а это позволяет менять реализацию объекта, не мо дифицируя остальной код. Объекты очень удобны для поддержки четырех важных функций опера ционной системы: 쐽 присвоения понятных имен системным ресурсам; 쐽 разделения ресурсов и данных между процессами; 쐽 защиты ресурсов от несанкционированного доступа; 쐽 учета ссылок (благодаря этому система узнает, когда объект больше не используется, и автоматически уничтожает его). Не все структуры данных в Windows являются объектами. В объекты по мещаются лишь те данные, которые нужно разделять, защищать, именовать или делать доступными программам пользовательского режима (через сис темные сервисы). Структуры, используемые только одним из компонентов операционной системы для поддержки какихто внутренних функций, к объектам не относятся. Подробнее объекты и их описатели (ссылки на эк земпляр объекта) рассматриваются в главе 3. Безопасность Windows с самого начала разрабатывалась как защищенная система, удовлет воряющая требованиям различных правительственных и промышленных стандартов безопасности, например спецификации Common Criteria for Infor mation Technology Security Evaluation (CCITSE). Подтверждение правитель ством рейтинга безопасности операционной системы позволяет ей конкури ровать в сферах, требующих повышенной защиты. Разумеется, многим из этих требований должна удовлетворять любая многопользовательская система. Базовые возможности защиты в Windows таковы: избирательная защита любых разделяемых системных объектов (файлов, каталогов, процессов, потоков и т. д.), аудит безопасности (для учета пользователей и инициируе мых ими операций), аутентификация паролей при входе и предотвращение доступа одного из пользователей к неинициализированным ресурсам (на пример, к памяти или дисковому пространству), освобожденным другим пользователем. Windows поддерживает два вида контроля доступа к объектам. Первый из них — управление избирательным доступом (discretionary access control) — является механизмом, который как раз и связывается большинством пользо вателей с защитой. Это метод, при котором владельцы объектов (например, файлов или принтеров) разрешают или запрещают доступ к ним для других пользователей. При входе пользователь получает набор удостоверений защи ты (security credentials), или контекст защиты (security context). Когда он пы тается обратиться к объекту, его контекст защиты сверяется со списком управ ления доступом (access control list, ACL) для данного объекта, чтобы опреде лить, имеет ли он разрешение на выполнение запрошенной операции.
26 ГЛ А В А 1 БЕЗОПАСНОСТЬ Второй метод — управление привилегированным доступом (privileged access control) — необходим в тех случаях, когда управления избирательным досту пом недостаточно. Данный метод гарантирует, что пользователь сможет обра титься к защищенным объектам, даже если их владелец недоступен. Например, если какойто сотрудник увольняется из компании, администратору нужно получить доступ к файлам, которые могли быть доступны только бывшему со труднику. В таких случаях Windows позволяет администратору стать владель цем этих файлов и при необходимости управлять правами доступа к ним. Защита пронизывает весь интерфейс Windows API. Подсистема Windows реализует защиту на основе объектов точно так же, как и сама операцион ная система. При первой попытке доступа приложения к общему (разделяе мому) объекту подсистема Windows проверяет, имеет ли это приложение соответствующие права. Если проверка завершается успешно, подсистема Windows разрешает приложению доступ. Подсистема Windows реализует защиту для общих объектов, часть из ко торых построена на основе родных объектов Windows. К Windowsобъектам относятся объекты рабочего стола, меню, окна, файлы, процессы, потоки и ряд синхронизирующих объектов. Детальное описание защиты в Windows см. в главе 8. Реестр Если вы работали хоть с какойнибудь операционной системой Windows, то, вероятно, слышали о реестре или даже просматривали его. Рассказать о внут реннем устройстве Windows, не упоминая реестр, вряд ли возможно, так как это системная база данных с информацией, необходимой для загрузки и конфигурирования системы; в ней содержатся общесистемные параметры, контролирующие работу Windows, база данных защиты и конфигурацион ные настройки, индивидуальные для каждого пользователя. Кроме того, реестр — это окно, через которое можно заглянуть в пере менные системные данные, чтобы, например, выяснить текущее состояние аппаратной части системы (какие драйверы устройств загружены, какие ре сурсы они используют и т. д.) или значения счетчиков производительности Windows. Счетчики производительности, которые на самом деле в реестре не хранятся, доступны через функции реестра (см. главу 4). Хотя у многих пользователей и администраторов Windows никогда не возникает необходимости работать непосредственно с реестром (бóльшую часть параметров можно просматривать или модифицировать с помощью стандартных административных утилит), он все же является источником полезной информации о внутренних структурах данных Windows, так как содержит множество параметров, влияющих на быстродействие и поведе ние системы. (Будьте крайне осторожны, напрямую изменяя параметры ре естра: любые изменения могут отрицательно сказаться на быстродействии или, что гораздо хуже, привести к краху системы.) Ссылки на различные разделы реестра, относящиеся к описываемым ком понентам, будут встречаться на протяжении всей книги. Большинство таких
ГЛАВА 9 Концепции и инструменты 27 разделов находится в ветви HKEY_LOCAL_MACHINE, которую мы сокращенно называем HKLM. Подробнее о реестре и его внутренней структуре см. главу 4. Unicode Windows отличается от большинства других операционных систем тем, что в качестве внутреннего формата для хранения и обработки текстовых строк использует Unicode. Unicode — это стандартная кодировка, которая поддер живает многие известные в мире наборы символов и в которой каждый сим вол представляется 16битным (двухбайтовым) кодом. (Подробнее о Unicode см. www.unicode.org и документацию на компактдисках MSDN Library.) Поскольку многие приложения имеют дело с 8битными (однобайтовы ми) ANSIсимволами, Windowsфункции, принимающие строковые парамет ры, существуют в двух версиях: для Unicode и для ANSI. В Windows 95, Win dows 98 и Windows ME реализована лишь часть Unicodeверсий Windows функций, поэтому приложения, рассчитанные на выполнение как в одной из этих операционных систем, так и в NTподобных Windows, обычно ис пользуют ANSIверсии функций. Если вы вызываете ANSIверсию Windows функции, входные строковые параметры перед обработкой системой пре образуются в Unicode, а выходные — из Unicode в ANSI (перед возвратом приложению). Таким образом при использовании в Windows устаревшего сервиса или фрагмента кода, написанного в расчете на ANSIстроки, эта опе рационная система будет вынуждена преобразовывать ANSIсимволы в Uni code. Однако Windows никогда не преобразует данные внутри файлов — ре шения о том, в какой кодировке хранить текстовую информацию в файлах, принимают лишь сами приложения. В предыдущих версиях Windows ее азиатский и ближневосточный выпус ки представляли собой надмножество базовых американского и европейс кого выпусков, в которые включались дополнительные Windowsфункции для обработки более сложных раскладок клавиатур и принципов ввода тек ста (например, набора текста справа налево). Начиная с Windows 2000, все языковые выпуски содержат одинаковые Windowsфункции. Единая для всех стран двоичная кодовая база Windows способна поддерживать множество языков за счет простого добавления нужных компонентов языковой поддер жки. Используя эти Windowsфункции, разработчики могут создавать уни версальные приложения, способные работать со множеством языков. Изучение внутреннего устройства Windows Хотя большая часть информации, представленная в этой книге, получена при чтении исходного кода Windows и общении с разработчиками, вы не обяза ны принимать все на веру. Многие детали внутреннего устройства Windows можно вытащить на свет с помощью самых разнообразных средств, в том числе поставляемых с Windows, входящих в Windows Support Tools и ресур сы Windows, а также с использованием отладочных средств самой Windows. Чуть позже мы вкратце рассмотрим эти пакеты инструментальных средств.
28 ГЛ А В А 1 БЕЗОПАСНОСТЬ Чтобы упростить вам исследование внутреннего устройства Windows, мы часто даем в книге врезки «Эксперимент» с пошаговыми инструкциями для изучения какоголибо аспекта поведения Windows. (Вы уже видели такие врезки в этой главе.) Советуем проводить эти эксперименты — это позволит увидеть в действии многие вещи, о которых рассказывается в книге. В таблице 13 перечислены все используемые нами инструменты и утилиты. Таблица 1-3. Средства просмотра внутренней информации Windows Утилита Имя образа Источник Startup Programs Viewer AUTORUNS www.sysinternals.com Dependency Walker DEPENDS Support Tools, Platform SDK DLL List LISTDLLS www.sysinternals.com EFS Information Dumper EFSDUMP www.sysinternals.com File Monitor FILEMON www.sysinternals.com Global Flags GFLAGS Support Tools Handle Viewer HANDLE www.sysinternals.com Junction JUNCTION www.sysinternals.com Отладчики ядра WINDBG, KD Средства отладки, Platform SDK, Windows DDK Live Kernel Debugging LIVEKD Ресурсы Windows Object Viewer WINOBJ www.sysinternals.com Open Handles OH Ресурсы Windows Page Fault Monitor PFMON Support Tools, Ресурсы Windows, Platform SDK Pending File Moves PENDMOVES www.sysinternals.com Performance PERFMON.MSC Утилита Windows PipeList PIPELIST www.sysinternals.com Pool Monitor POOLMON Support Tools, Windows DDK Process Explorer PROCEXP www.sysinternals.com Get SID PSGETSID www.sysinternals.com Process Statistics PSTAT Support Tools, Ресурсы Windows, Platform SDK, www.reskit.com Process Viewer PVIEWER (в Support Tools) или PVIEW (в Platform SDK) Support Tools, Platform SDK Quick Slice QSLICE Ресурсы Windows Registry Monitor REGMON www.sysinternals.com Service Control SC Windows XP, Platform SDK, Ресурсы Windows Task (Process) List TLIST Средства отладки Task Manager TASKMGR Утилита Windows TDImon TDIMON www.sysinternals.com
ГЛАВА 9 Концепции и инструменты 29 Оснастка Performance Мы часто ссылаемся на этот инструмент, доступный через папку Administrative Tools (Администрирование) в меню Start (Пуск) или через Control Panel (Па нель управления). Оснастка Performance (Производительность) предназначе на для мониторинга системы, просмотра журналов, в которых регистрируют ся значения счетчиков производительности, и оповещения при достижении заданных пороговых значений тех или иных счетчиков. Говоря об оснастке Performance, мы подразумеваем лишь ее функцию системного мониторинга. Оснастка Performance способна сообщить о том, как работает система, го раздо больше, чем любая другая, отдельно взятая утилита. Она предусматрива ет сотни счетчиков для различных объектов. По каждому счетчику можно по лучить краткое описание. Чтобы увидеть описание, выберите счетчик в окне Add Counters (Добавить счетчики) и щелкните кнопку Explain (Объяснение). Или откройте справочный файл Performance Counter Reference с компактдис ка «Ресурсы Windows». Информацию о том, как интерпретировать показания счетчиков для устранения «узких мест» в системе или для планирования про пускной способности сервера, см. раздел «Performance Monitoring» в книге «Windows 2000 Server Operations Guide» из набора Windows 2000 Server Resource Kit. Для Windows XP и Windows Server 2003 см. документацию Performance Counters Reference в Windows Server 2003 Resource Kit. Заметьте, что все счетчики производительности Windows доступны про граммным путем. Краткое описание соответствующих компонентов см. в разделе «HKEY_PERFORMANCE_DATA» главы 4. Windows Support Tools Windows Support Tools включают около 40 утилит, полезных в администри ровании систем на базе Windows и устранении неполадок в них. Многие из этих утилит раньше были частью ресурсов Windows NT 4. Вы можете установить Support Tools, запустив Setup.exe из папки \Support\ Tools в дистрибутиве любого издания Windows. Support Tools одинаковы в Win dows 2000 Professional, Server, Advanced Server и Datacenter Server, а для Windows XP, равно как и для Windows Server 2003, существует своя версия Support Tools. Ресурсы Windows Ресурсы Windows (Windows Resource Kits) расширяют Support Tools, предла гая дополнительные утилиты для администрирования и поддержки систем. Утилиты Windows Server 2003 Resource Kit можно бесплатно скачать с www.microsoft.com (выполните поиск по ключевым словам «resource kit tools»). Их можно установить в Windows XP или Windows Server 2003. Ресурсы Windows 2000 существуют в двух изданиях: Windows 2000 Pro fessional Resource Kit и Windows 2000 Server Resource Kit* (самая последняя * Последнее издание переведено на русский язык издательством «Русская Редак ция» и выпущено в 2001 г. в виде серии «Ресурсы Microsoft Windows 2000 Server», которая включает 4 книги: «Сети TCP/IP», «Сопровождение сервера», «Распреде ленные системы» и «Межсетевое взаимодействие». — Прим. перев.
30 ГЛ А В А 1 БЕЗОПАСНОСТЬ его версия — Supplement 1). Хотя последний набор представляет собой над множество первого и может быть установлен на системах с Windows 2000 Professional, утилиты, входящие только в Windows 2000 Server Resource Kit, ни в одном из наших экспериментов не используются. В отличие от утилит Windows Server 2003 Resource Kit эти утилиты нельзя скачать бесплатно. Однако Windows 2000 Server Resource Kit поставляется с подписками на MSDN и TechNet. Отладка ядра Отладка ядра подразумевает изучение внутренних структур данных ядра и/ или пошаговый проход по функциям в ядре. Это полезный способ исследо вания внутреннего устройства Windows, потому что он позволяет увидеть внутрисистемную информацию, недоступную при использовании каких либо других способов, и получить более ясное представление о схеме выпол нения кода внутри ядра. Отладку ядра можно проводить с помощью разнообразных утилит: Win dows Debugging Tools от Microsoft, LiveKD от www.sysinternals.com или SoftIce от Compuware NuMega. Прежде чем описывать эти средства, давайте рас смотрим файл, который понадобится при любом виде отладки ядра. Символы для отладки ядра Файлы символов (symbol files) содержат имена функций и переменных. Они генерируются компоновщиком (linker) и используются отладчиками для ссылки и отображения этих имен в сеансе отладки. Эта информация обыч но не хранится в двоичном образе, потому что она не нужна при выполне нии кода. То есть двоичные образы имеют меньший размер и работают бы стрее. Но это означает, что вам нужно позаботиться о том, чтобы у отладчи ка был доступ к файлам символов, сопоставляемым с образами, на которые вы ссылаетесь в сеансе отладки. Для изучения внутренних структур данных ядра Windows (например, списка процессов, блоков потока, списка загруженных драйверов, информа ции об использовании памяти и т. д.) вам понадобятся подходящие файлы символов как минимум для образа ядра, Ntoskrnl.exe. (Подробнее этот файл рассматривается в разделе «Обзор архитектуры» главы 2.) Файлы таблиц сим волов должны соответствовать версии образа. Так, если вы установили Win dows Service Pack или какоето оперативное исправление, то должны полу чить обновленные файлы символов хотя бы для образа ядра; иначе возник нет ошибка изза неправильной контрольной суммы при попытке отладчи ка ядра загрузить их. Хотя можно скачать и установить символы для разных версий Windows, обновленные символы для оперативных исправлений доступны не всегда. Самый простой способ получить подходящую версию символов для отлад ки — обратиться к Microsoftсерверу символов с запросом, в котором исполь зуется специальный синтаксис пути к символам, как в отладчике. Например,
ГЛАВА 9 Концепции и инструменты 31 следующий путь к символам заставляет средства отладки загружать требуе мые символы с Интернетсервера символов и сохранять локальную копию в папке c:\symbols: srv*c:\symbols*http://msdl.microsoft.com/download/symbols Подробные инструкции о том, как пользоваться сервером символов, см. в справочном файле Debugging Tools или на Webстранице www.microsoft. com/whdc/ddk/debugging/symbols.mspx. Windows Debugging Tools Пакет Windows Debugging Tools содержит дополнительные средства отлад ки, применяемые в этой книге для исследования внутреннего устройства Windows. Вы найдете их последние версии по ссылке www.microsoft.com/ whdc/ddk/debugging. Эти средства можно использовать для отладки как про цессов пользовательского режима, так и ядра (см. следующую врезку). ПРИМЕЧАНИЕ Windows Debugging Tools регулярно обновляются и вы пускаются независимо от версий операционной системы Windows, по этому почаще проверяйте наличие новых версий отладочных средств. Отладка в пользовательском режиме Средства отладки можно подключать к процессу пользовательского режима, чтобы исследовать и/или изменять память процесса. Суще ствует два варианта подключения к процессу: 쐽 Invasive (инвазивный) Если не указано иное, то, когда вы под ключаетесь к выполняемому процессу, Windowsфункция DebugAc tiveProcess устанавливает соединение между отладчиком и отлажи ваемым процессом. Это позволяет изучать и/или изменять память процесса, устанавливать точки прерывания (breakpoints) и выпол нять другие отладочные действия. В Windows 2000 при завершении отладчика закрывается и отлаживаемый процесс. Однако в Windows XP отладчик можно отключать, не уничтожая целевой процесс. 쐽 Noninvasive (неинвазивный) В этом случае отладчик просто открывает процесс через функцию OpenProcess. Он не подключает ся к процессу как отладчик. Это позволяет изучать и/или изменять па мять целевого процесса, но не дает возможности устанавливать точ ки прерывания. Преимущество данного варианта в том, что в Windows 2000 можно закрыть отладчик, не завершая целевой процесс. С помощью отладочных средств также можно открывать файлы дампов процессов пользовательского режима. Что представляют со бой эти файлы, поясняется в главе 3 в разделе по диспетчеризации исключений. Microsoft предлагает отладчики ядра в двух версиях: командной строки (Kd.exe) и с графическим пользовательским интерфейсом (Windbg.exe). Оба
32 ГЛ А В А 1 БЕЗОПАСНОСТЬ инструмента предоставляют одинаковый набор команд, так что выбор кон кретной утилиты определяется сугубо личными пристрастиями. С помощью этих средств вы можете вести отладку ядра в трех режимах. 쐽 Откройте файл дампа, полученный в результате краха системы с Windows (подробнее о таких дампах см. главу 14). 쐽 Подключитесь к работающей системе и изучите ее состояние (или по ставьте точки прерывания, если вы отлаживаете код драйвера устройства). Эта операция требует двух компьютеров — целевого и управляющего. Целевой считается отлаживаемая система, а управляющей — та, в которой выполняется отладчик. Целевая система может быть либо локальной (со единенной с управляющей нульмодемным кабелем или по IEEE 1394), либо удаленной (соединенной по модему). Вы должны загрузить целевую систему со спецификатором /DEBUG, или нажать при загрузке клавишу F8 и выбрать Debug Mode, или добавить соответствующую запись в файл Boot.ini. 쐽 В случае Windows XP и Windows Server 2003 подключитесь к локальной системе и изучите ее состояние. Это называется локальной отладкой ядра. Чтобы инициировать такую отладку ядра, выберите в меню File ко манду Kernel Debug, перейдите на вкладку Local и щелкните OK. Пример окна с выводом показан на рис. 17. Некоторые команды отладчика ядра в этом режиме не работают (например, просмотр стеков ядра и создание дампа памяти командой .dump невозможны). Однако вы можете пользо ваться бесплатной утилитой LiveKd с сайта www.sysinternals.com в тех слу чаях, когда родные средства локальной отладки не срабатывают (см. сле дующий раздел). Рис. 1-7. Локальная отладка ядра
ГЛАВА 9 Концепции и инструменты 33 Подключившись в режиме отладки ядра, вы можете использовать одну из многих команд расширения отладчика (команды, которые начинаются с «!») для вывода содержимого внутренних структур данных, например потоков, процессов, пакетов запроса на вводвывод и информации, связанной с уп равлением памятью. Команды отладчика ядра и их вывод будут обсуждаться при рассмотрении соответствующей тематики. А пока добавим, что коман да dt (display type) может форматировать свыше 400 структур ядра благода ря тому, что файлы символов ядра для Windows 2000 Service Pack 3, Windows XP и Windows Server 2003 содержат информацию о типах, которая и позво ляет отладчику форматировать структуры. ЭКСПЕРИМЕНТ: отображение информации о типах для структур ядра Чтобы вывести список структур ядра, чья информация о типах вклю чена в символы ядра, наберите dt nt!_* в отладчике ядра. Пример час ти вывода показан ниже: lkd> dt nt!_* nt!_LIST_ENTRY nt!_LIST_ENTRY nt!_IMAGE_NT_HEADERS nt!_IMAGE_FILE_HEADER nt!_IMAGE_OPTIONAL_HEADER nt!_IMAGE_NT_HEADERS nt!_LARGE_INTEGER Команда dt позволяет искать конкретные структуры по шаблонам. Например, если вы ищете имя структуры для объекта прерывания (in terrupt object), введите dt nt!_*interrupt*: lkd> dt nt!_*interrupt* nt!_KINTERRUPT nt!_KINTERRUPT_MODE После этого с помощью команды dt можно отформатировать эту структуру: lkd> dt nt!_kinterrupt nt!_KINTERRUPT +0x000 Type : +0x002 Size : +0x004 InterruptListEntry +0x00c ServiceRoutine : +0x010 ServiceContext : +0x014 SpinLock : +0x018 TickCount : +0x01c ActualLock : +0x020 DispatchAddress : +0x024 Vector : +0x028 Irql : Int2B Int2B : _LIST_ENTRY Ptr32 Ptr32 Void Uint4B Uint4B Ptr32 Uint4B Ptr32 Uint4B UChar см. след. стр.
34 ГЛ А В А 1 +0x029 +0x02a +0x02b +0x02c +0x02d +0x030 +0x034 +0x038 +0x03c БЕЗОПАСНОСТЬ SynchronizeIrql FloatingSave Connected Number ShareVector Mode ServiceCount DispatchCount DispatchCode : : : : : : : : : UChar UChar UChar Char UChar _KINTERRUPT_MODE Uint4B Uint4B [106] Uint4B Заметьте, что по умолчанию dt не показывает подструктуры (структу ры внутри структур). Для рекурсивного прохода по подструктурам, ис пользуйте ключ –r. Например, указав этот ключ для отображения объек та ядра «прерывание», вы увидите формат структуры _LIST_ENTRY, хра нящейся в поле InterruptListEntry: lkd> dt nt!_kinterrupt –r nt!_KINTERRUPT +0x000 Type : +0x002 Size : +0x004 InterruptListEntry +0x000 Flink +0x000 Flink +0x004 Blink +0x004 Blink +0x000 Flink +0x004 Blink +0x00c ServiceRoutine : Int2B Int2B : : Ptr32 : Ptr32 : Ptr32 : Ptr32 : Ptr32 : Ptr32 Ptr32 _LIST_ENTRY _LIST_ENTRY _LIST_ENTRY _LIST_ENTRY В справочном файле Windows Debugging Tools объясняется, как устанав ливать и использовать отладчики ядра. Дополнительные сведения о приме нении отладчиков ядра, предназначенных в основном разработчикам драй веров устройств, см. в документации Windows DDK. Есть также несколько полезных статей в Knowledge Base по отладчикам ядра. Выполните поиск по ключевому слову «debugref» в Windows Knowledge Base (онлайновой базе данных технических статей) на support.microsoft.com. Утилита LiveKd LiveKd — бесплатная утилита от www.sysinternals.com, которая позволяет ис пользовать стандартные отладчики ядра от Microsoft на «живой» системе — без подключения второго компьютера. Если встроенная поддержка локаль ной отладки ядра действует только в Windows XP и Windows Server 2003, то LiveKd обеспечивает такую отладку в Windows NT 4.0, Windows 2000, Win dows XP и Windows Server 2003. LiveKd запускается точно так же, как Windbg или Kd. Эта утилита переда ет любые указанные параметры командной строки выбранному вами отлад чику. По умолчанию LiveKd запускает отладчик Kd. Для запуска GUIотлад
ГЛАВА 9 Концепции и инструменты 35 чика (Windbg), задайте ключ –w. Чтобы получить подсказку по ключам Live Kd, укажите ключ –?. LiveKd предоставляет отладчику смоделированный файл аварийного дам па (crash dump), поэтому вы можете выполнять в LiveKd любые операции, поддерживаемые для аварийных дампов. Поскольку LiveKd хранит смодели рованный дамп в физической памяти, отладчик ядра может попасть в такую ситуацию, в которой структуры данных находятся в рассогласованном со стоянии в процессе их изменения системой. При каждом запуске отладчик получает снимок состояния системы; если вы хотите обновить этот снимок, выйдите из отладчика (командой q), и LiveKd спросит вас, нужно ли начать сначала. Если отладчик, выводя информацию на экран, вошел в цикл, нажми те клавиши Ctrl+C, чтобы прервать вывод, выйдите из отладчика и запусти те его снова. Если он завис, нажмите клавиши Ctrl+Break, которые заставят завершить процесс отладчика. После этого вам будет предложено снова за пустить отладчик. SoftICE Еще один инструмент, не требующий двух машин для прямой отладки яд ра, — SoftICE, который можно приобрести у Compuware NuMega (www.com puware.com). SoftICE обладает во многом теми же возможностями, что и Win dows Debugging Tools, но поддерживает переход между кодом пользова тельского режима и режима ядра. Он также поддерживает DLLмодули рас ширения ядра Microsoft, поэтому большинство команд, описываемых нами в книге, будут работать и в SoftICE. На рис. 18 показан пользовательский интерфейс SoftICE, появляющийся при нажатии клавиши активизации Soft ICE (по умолчанию — Ctrl+D); этот интерфейс представляет собой окно на рабочем столе системы, в которой он выполняется. Рис. 1-8. Интерфейс SoftICE
36 ГЛ А В А 1 БЕЗОПАСНОСТЬ Platform Software Development Kit (SDK) Platform SDK является частью подписки на MSDN уровня Professional и выше; кроме того, его можно бесплатно скачать с msdn.microsoft.com. В нем содер жатся документация, заголовочные файлы и библиотеки C, необходимые для компиляции и компоновки Windowsприложений. (Microsoft Visual C++ тоже поставляется с этими файлами, но их версии в Platform SDK всегда более новые и соответствуют самым последним версиям операционных систем Windows.) В Platform SDK для нас будут представлять интерес заголовочные файлы Windows API (\Program Files\Microsoft SDK\Include) и несколько ути лит (Pfmon.exe, Pstat.exe, Pview.exe, Vadump.exe и Winobj.exe). Некоторые из них также поставляются с Ресурсами Windows и Support Tools. Наконец, от дельные утилиты поставляются с Platform SDK и MSDN Library как примеры исходного кода. Device Driver Kit (DDK) Windows DDK является частью подписки на MSDN уровня Professional и выше, но в отличие от Platform SDK его нельзя скачать бесплатно (впрочем, можно заказать CDROM за минимальную цену). Документация Windows DDK включается в MSDN Library. Хотя DDK нацелен на разработчиков драйверов устройств, он представ ляет собой богатый источник информации о внутреннем устройстве Win dows. Например, в главе 9 мы даем описание архитектуры подсистемы вво давывода, модели драйверов и структур данных базовых драйверов уст ройств, но не вдаемся в детали соответствующих функций ядра. А в докумен тации Windows DDK исчерпывающе описаны все внутрисистемные функ ции и драйверы устройств. Кроме документации в DDK входят заголовочные файлы, определяющие ключевые внутренние структуры данных, константы и интерфейсы многих внутрисистемных подпрограмм (в частности, обратите внимание на файлы Ntddk.h и Wdm.h). Эти файлы очень полезны в исследовании внутренних структур данных Windows с помощью отладчика ядра, так как мы даем лишь обобщенное описание внутренних структур, а в заголовочных файлах мож но найти все подробности о каждом поле таких структур. В DDK также де тально поясняются некоторые структуры данных (вроде заголовков для дис петчера объектов, блоки ожидания, события, мутанты, семафоры и др.). Поэтому, если вы хотите поглубже покопаться в подсистеме вводавыво да и в модели драйверов, читайте документацию DDK (особенно руководства KernelMode Driver Architecture Design Guide и Reference). Еще один превос ходный источник — книга Уолта Они (Walt Oney) «Programming the Microsoft Windows Driver Model, Second Edition» (Microsoft Press). Утилиты Sysinternals Во многих экспериментах мы используем свободно распространяемые ути литы, которые можно скачать с www.sysinternals.com. Большинство этих ути
ГЛАВА 9 Концепции и инструменты 37 лит написано Марком Руссиновичем, соавтором этой книги. К наиболее по пулярным утилитам относятся Process Explorer, Filemon и Regmon. Многие из этих утилит требуют установки и запуска драйверов устройств, работающих в режиме ядра, а значит, вам понадобятся полномочия администратора. Резюме В этой главе вы познакомились с ключевыми техническими концепциями и терминами Windows, которые будут использоваться во всей книге. Вы так же получили первое представление о многих полезных инструментах, по зволяющих изучать внутренние структуры данных Windows. Теперь вы го товы вместе с нами приступить к исследованию внутреннего устройства системы. Мы начнем с общего обзора архитектуры системы и ее основных компонентов.
Г Л А В А 2 Архитектура системы Теперь, познакомившись с необходимыми терминами, понятиями и инстру ментами, мы можем рассмотреть задачи, которые ставились при разработ ке операционной системы Microsoft Windows. В этой главе описывается об щая архитектура системы: ключевые компоненты, принципы их взаимодей ствия и контекст выполнения. Чтобы получить базовое представление о внутреннем устройстве Windows, давайте сначала обсудим требования и цели, обусловившие структуру и спецификацию этой системы. Требования и цели проекта Характеристики Windows NT в 1989 году определялись следующими требо ваниями. Операционная система должна: 쐽 быть истинно 32разрядной, реентерабельной, поддерживать вытесняю щую многозадачность и работу с виртуальной памятью; 쐽 работать на разных аппаратных платформах; 쐽 хорошо масштабироваться в системах с симметричной мультипроцес сорной обработкой; 쐽 быть распределенной вычислительной платформой, способной высту пать в роли как клиента сети, так и сервера; 쐽 поддерживать большинство существующих 16разрядных приложений MSDOS и Microsoft Windows 3.1; 쐽 отвечать требованиям правительства к соответствию POSIX 1003.1; 쐽 отвечать требованиям правительства и промышленности к безопаснос ти операционных систем; 쐽 обеспечивать простоту адаптации к глобальному рынку за счет поддер жки Unicode. Для создания системы, соответствующей предъявленным требованиям, нужно было принять тысячи решений. Поэтому перед командой разработ чиков Windows NT на начальном этапе проекта были поставлены следующие цели. 쐽 Расширяемость Код должен быть написан так, чтобы системы можно было легко наращивать и модифицировать по мере изменения потреб ностей рынка.
ГЛАВА 9 Архитектура системы 39 쐽 Переносимость Система должна работать на разных аппаратных ар хитектурах и обладать способностью к сравнительно легкому переносу на новые аппаратные архитектуры, если на рынке возникнет такая по требность. 쐽 Отказоустойчивость и надежность Система должна быть защищен ной как от внутренних сбоев, так и от внешних деструктивных действий. У приложений не должно быть возможности нарушить работу операци онной системы или других приложений. 쐽 Совместимость Хотя Windows NT должна расширить существующую технологию, ее пользовательский интерфейс и API должны быть совмес тимы с предыдущими версиями Windows и MSDOS. Она также должна уметь взаимодействовать с другими системами вроде UNIX, OS/2 и NetWare. 쐽 Производительность С учетом ограничений, налагаемых поставлен ными целями, система должна быть максимально быстрой и отзывчивой независимо от аппаратной платформы. По мере изучения деталей внутренней структуры Windows вы увидите, насколько успешно были реализованы все эти требования и цели. Но сна чала мы рассмотрим общую модель Windows и сравним ее с другими совре менными операционными системами. Модель операционной системы В большинстве многопользовательских операционных систем приложения отделены от собственно операционной системы: код ее ядра выполняется в привилегированном режиме процессора (называемом режимом ядра), ко торый обеспечивает доступ к системным данным и оборудованию. Код при ложений выполняется в непривилегированном режиме процессора (назы ваемом пользовательским) с неполным набором интерфейсов, ограничен ным доступом к системным данным и без прямого доступа к оборудованию. Когда программа пользовательского режима вызывает системный сервис, процессор перехватывает вызов и переключает вызывающий поток в режим ядра. По окончании работы системного сервиса операционная система пе реключает контекст потока обратно в пользовательский режим и продолжа ет его выполнение. Windows, как и большинство UNIXсистем, является монолитной опера ционной системой — в том смысле, что бóльшая часть ее кода и драйверов использует одно и то же пространство защищенной памяти режима ядра. Это значит, что любой компонент операционной системы или драйвер уст ройства потенциально способен повредить данные, используемые другими компонентами операционной системы.
40 ГЛ А В А 2 БЕЗОПАСНОСТЬ Основана ли Windows на микроядре? Хотя некоторые объявляют ее таковой, Windows не является операци онной системой на основе микроядра в классическом понимании это го термина. В подобных системах основные компоненты операцион ной системы (диспетчеры памяти, процессов, вводавывода) выполня ются как отдельные процессы в собственных адресных пространствах и представляют собой надстройки над примитивными сервисами мик роядра. Пример современной системы с архитектурой на основе мик роядра — операционная система Mach, разработанная в Carnegie Mel lon University. Она реализует крошечное ядро, которое включает сер висы планирования потоков, передачи сообщений, виртуальной памя ти и драйверов устройств. Все остальное, в том числе разнообразные API, файловые системы и поддержка сетей, работает в пользовательс ком режиме. Однако в коммерческих реализациях на основе микро ядра Mach код файловой системы, поддержки сетей и управления па мятью выполняется в режиме ядра. Причина проста: системы, постро енные строго по принципу микроядра, непрактичны с коммерческой точки зрения изза слишком низкой эффективности. Означает ли тот факт, что большая часть Windows работает в режи ме ядра, ее меньшую надежность в сравнении с операционными сис темами на основе микроядра? Вовсе нет. Рассмотрим следующий сце нарий. Допустим, в коде файловой системы имеется ошибка, которая время от времени приводит к краху системы. Ошибка в коде режима ядра (например, в диспетчере памяти или файловой системы) скорее всего вызовет полный крах традиционной операционной системы. В истинной операционной системе на основе микроядра подобные компоненты выполняются в пользовательском режиме, поэтому тео ретически ошибка приведет лишь к завершению процесса соответ ствующего компонента. Но на практике такая ошибка все равно вызо вет крах системы, так как восстановление после сбоя столь критичес ки важного процесса невозможно. Все эти компоненты операционной системы, конечно, полностью защи щены от сбойных приложений, поскольку такие программы не имеют пря мого доступа к коду и данным привилегированной части операционной системы (хотя и способны вызывать сервисы ядра). Эта защита — одна из причин, по которым Windows заслужила репутацию отказоустойчивой и стабильной операционной системы в качестве сервера приложений и плат формы рабочих станций, обеспечивающей быстродействие основных сис темных сервисов вроде поддержки виртуальной памяти, файлового ввода вывода, работы с сетями и доступа к общим файлам и принтерам. Компоненты Windows режима ядра также построены на принципах объектноориентированного программирования (ООП). Так, для получения информации о какомлибо компоненте они, как правило, не обращаются к его
ГЛАВА 9 Архитектура системы 41 структурам данных. Вместо этого для передачи параметров, доступа к струк турам данных и их изменения используются формальные интерфейсы. Однако, несмотря на широкое использование объектов, представляющих разделяемые системные ресурсы, Windows не является объектноориенти рованной системой в строгом понимании этого термина. Бóльшая часть си стемного кода написана на С в целях переносимости и изза широкой рас пространенности средств разработки на С. В этом языке нет прямой поддер жки конструкций и механизмов ООП вроде динамического связывания ти пов данных, полиморфных функций или наследования классов. Обзор архитектуры Теперь обратимся к ключевым компонентам системы, составляющим ее ар хитектуру. Упрощенная версия этой архитектуры показана на рис. 21. Уч тите, что упрощенная схема не отражает всех деталей архитектуры (напри мер, здесь не показаны уровни сетевых компонентов и различных типов драйверов устройств). Рис. 2-1. Упрощенная схема архитектуры Windows На рис. 21 прежде всего обратите внимание на линию, разделяющую те части Windows, которые выполняются в режиме ядра и в пользовательском режиме. Прямоугольники над этой линией соответствуют процессам пользо вательского режима, а компоненты под ней — сервисам режима ядра. Как говорилось в главе 1, потоки пользовательского режима выполняются в за щищенных адресных пространствах процессов (хотя при выполнении в режиме ядра они получают доступ к системному пространству). Таким об разом, процессы поддержки системы, сервисов, приложений и подсистем окружения имеют свое адресное пространство. Существует четыре типа пользовательских процессов: 쐽 фиксированные процессы поддержки системы (system support proces ses) — например, процесс обработки входа в систему и диспетчер сеан сов, не являющиеся сервисами Windows (т. е. не запускаемые диспетче ром управления сервисами);
42 ГЛ А В А 2 БЕЗОПАСНОСТЬ 쐽 процессы сервисов (service processes) — носители Windowsсервисов вро де Task Scheduler и Spooler. Многие серверные приложения Windows, на пример Microsoft SQL Server и Microsoft Exchange Server, тоже включают компоненты, выполняемые как сервисы; 쐽 пользовательские приложения (user applications) — бывают шести типов: для 32разрядной Windows, 64разрядной Windows, 16разрядной Windows 3.1, 16разрядной MSDOS, 32разрядной POSIX и 32разрядной OS/2; 쐽 подсистемы окружения (environment subsystems) — реализованы как часть поддержки среды операционной системы, предоставляемой поль зователям и программистам. Изначально Windows NT поставлялась с тре мя подсистемами окружения: Windows, POSIX и OS/2. Последняя была изъята в Windows 2000. Что касается Windows XP, то в ней исходно по ставляется только подсистема Windows — улучшенная подсистема POSIX доступна как часть бесплатного продукта Services for UNIX. Обратите внимание на прямоугольник «DLL подсистем», расположенный на рис. 21 под прямоугольниками «процессы сервисов» и «пользовательские приложения». В Windows пользовательские приложения не могут вызывать родные сервисы операционной системы напрямую, вместо этого они рабо тают с одной или несколькими DLL подсистем. Их назначение заключается в трансляции документированных функций в соответствующие внутренние (и обычно недокументированные) вызовы системных сервисов Windows. Трансляция может осуществляться как с помощью сообщения, посылаемо го процессу подсистемы окружения, обслуживающему пользовательское приложение, так и без него. Windows включает следующие компоненты режима ядра. 쐽 Исполнительная система (executive) Windows, содержащая базовые сер висы операционной системы, которые обеспечивают управление памя тью, процессами и потоками, защиту, вводвывод и взаимодействие меж ду процессами. 쐽 Ядро (kernel) Windows, содержащее низкоуровневые функции операци онной системы, которые поддерживают, например, планирование пото ков, диспетчеризацию прерываний и исключений, а также синхрониза цию при использовании нескольких процессоров. Оно также предостав ляет набор процедур и базовых объектов, применяемых исполнительной системой для реализации структур более высокого уровня. 쐽 Драйверы устройств (device drivers), в состав которых входят драйверы аппаратных устройств, транслирующие пользовательские вызовы функ ций вводавывода в запросы, специфичные для конкретного устройства, а также сетевые драйверы и драйверы файловых систем. 쐽 Уровень абстрагирования от оборудования (hardware abstraction layer, HAL), изолирующий ядро, драйверы и исполнительную систему Windows от специфики оборудования на данной аппаратной платформе (напри мер, от различий между материнскими платами).
ГЛАВА 9 Архитектура системы 43 쐽 Подсистема поддержки окон и графики (windowing and graphics system), реализующая функции графического пользовательского интерфейса (GUI), более известные как Windowsфункции модулей USER и GDI. Эти функции обеспечивают поддержку окон, элементов управления пользо вательского интерфейса и отрисовку графики. В таблице 21 перечислены имена файлов основных компонентов Win dows. (Вы должны знать их, потому что в дальнейшем мы будем ссылаться на некоторые системные файлы по именам.) Каждый из этих компонентов подробно рассматривается в этой и последующих главах. Таблица 2-1. Основные системные файлы Windows Имя файла Компоненты Ntoskrnl.exe Исполнительная система и ядро Ntkrnlpa.exe Исполнительная система и ядро с поддержкой механизма (только 32разрядные Physical Address Extension (PAE), позволяющего адресовать системы) 64 Гб физической памяти Hal.dll Уровень абстрагирования от оборудования Win32sk.sys Часть подсистемы Windows, работающая в режиме ядра Ntdll.dll Внутренние функции поддержки и интерфейсы (stubs) диспетчера системных сервисов с функциями исполнитель ной системы Kernel32.dll, Advapi32.dll, User32.dll, Gdi32.dll Основные DLL подсистемы Windows Прежде чем детально рассматривать эти компоненты, давайте проясним, как достигается переносимость Windows между различными аппаратными платформами. Переносимость Windows рассчитана на разные аппаратные платформы, включая как CISC системы Intel, так и RISCсистемы. Windows NT первого выпуска поддержи вала архитектуры x86 и MIPS. Спустя некоторое время была добавлена под держка Alpha AXP производства DEC (DEC была приобретена Compaq, а по зднее произошло слияние компаний Compaq и Hewlett Packard). (Хотя Alpha AXP был 64разрядным процессором, Windows NT работала с ним в 32раз рядном режиме. В ходе разработки Windows 2000 была создана ее 64разряд ная версия специально под Alpha AXP, но в свет она так и не вышла.) В Win dows NT 3.51 ввели поддержку четвертой процессорной архитектуры — Motorola PowerPC. В связи с изменениями на рынке необходимость в под держке MIPS и PowerPC практически отпала еще до начала разработки Win dows 2000. Позднее Compaq отозвала поддержку архитектуры Alpha AXP, и в Windows 2000 осталась поддержка лишь архитектуры x86. В самые после дние выпуски — Windows XP и Windows Server 2003 — добавлена поддерж ка трех семейств 64разрядных процессоров: Intel Itanium IA64, AMD x8664 и Intel 64bit Extension Technology (EM64T) для x86 (эта архитектура совме
44 ГЛ А В А 2 БЕЗОПАСНОСТЬ стима с архитектурой AMD x8664, хотя есть небольшие различия в поддер живаемых командах). Последние два семейства процессоров называются системами с 64!разрядными расширениями и в этой книге обозначаются как x64. (Как 32разрядные приложения выполняются в 64разрядной Windows, объясняется в главе 3.) Переносимость Windows между системами с различной аппаратной ар хитектурой и платформами достигается главным образом двумя способами. 쐽 Windows имеет многоуровневую структуру. Специфичные для архитекту ры процессора или платформы низкоуровневые части системы вынесе ны в отдельные модули. Благодаря этому высокоуровневая часть системы не зависит от специфики архитектур и аппаратных платформ. Ключевые компоненты, обеспечивающие переносимость операционной системы, — ядро (содержится в файле Ntoskrnl.exe) и уровень абстрагирования от оборудования (HAL) (содержится в файле Hal.dll). Функции, специфичные для конкретной архитектуры (переключение контекста потоков, диспет черизация ловушек и др.), реализованы в ядре. Функции, которые могут отличаться на компьютерах с одинаковой архитектурой (например, в сис темах с разными материнскими платами), реализованы в HAL. Еще один компонент, содержащий большую долю кода, специфичного для конкрет ной архитектуры, — диспетчер памяти (memory manager), но если рас сматривать систему в целом, такого кода все равно немного. 쐽 Подавляющее большинство компонентов Windows написано на С и лишь часть из них — на С++. Язык ассемблера применяли только при создании частей системы, напрямую взаимодействующих с системным оборудова нием (например, при написании обработчика ловушек прерываний) или требующих исключительного быстродействия (скажем, при переключе нии контекста). Ассемблерный код имеется не только в ядре и HAL, но и в составе некоторых других частей операционной системы: процедур, реализующих взаимоблокировку, механизма вызова локальных процедур (LPC), части подсистемы Windows, выполняемой в режиме ядра, и даже в некоторых библиотеках пользовательского режима (например, в коде запуска процессов в Ntdll.dll — системной библиотеке, о которой будет рассказано в этой главе несколько позже). Симметричная многопроцессорная обработка Многозадачность (multitasking) — механизм операционной системы, позво ляющий использовать один процессор для выполнения нескольких потоков. Однако истинно одновременное выполнение, например, двух потоков воз можно, только если на компьютере установлено два процессора. При мно гозадачности система лишь создает видимость одновременного выполнения множества потоков, тогда как многопроцессорная система действительно выполняет сразу несколько потоков — по одному на каждом процессоре. Как уже говорилось в начале этой главы, одной из ключевых целей раз работки Windows была поддержка многопроцессорных компьютерных сис
ГЛАВА 9 Архитектура системы 45 тем. Windows является операционной системой, поддерживающей симмет! ричную многопроцессорную обработку (symmetric multiprocessing, SMP). В этой модели нет главного процессора; операционная система, как и пользо вательские потоки, может выполняться на любом процессоре. Кроме того, все процессоры используют одну и ту же память. При асимметричной мно! гопроцессорной обработке (asymmetric multiprocessing, ASMP) система, на против, выбирает один из процессоров для выполнения кода ядра операци онной системы, а другие процессоры выполняют только пользовательский код. Различия между этими двумя моделями показаны на рис. 22. Рис. 2-2. Симметричная и асимметричная многопроцессорная обработка Windows XP и Windows Server 2003 поддерживают два новых типа мно гопроцессорных систем: логические процессоры (hyperthreading) и NUMA (NonUniform Memory Architecture). Об этом кратко рассказывается в абза це ниже. (Полное описание поддержки планирования потоков для таких систем см. в разделе по планированию потоков в главе 6.) Логические процессоры — это технология, созданная Intel; благодаря ей на одном физическом процессоре может быть несколько логических. Каж дый логический процессор имеет свое состояние, но исполняющее ядро (execution engine) и набортный кэш (onboard cache) являются общими. Это позволяет одному из логических процессоров продолжать работу, пока дру гой логический процессор занят (например, обработкой прерывания, кото рая не дает потокам выполняться на этом логическом процессоре). Алгорит мы планирования в Windows XP были оптимизированы под компьютеры с такими процессорами.
46 ГЛ А В А 2 БЕЗОПАСНОСТЬ В NUMAсистемах процессоры группируются в блоки, называемые узла ми (nodes). В каждом узле имеются свои процессоры и память, и он соеди няется с остальными узлами специальной шиной. Windows в NUMAсисте ме попрежнему работает как SMPсистема, в которой все процессоры име ют доступ ко всей памяти, — просто доступ к памяти, локальной для узла, осуществляется быстрее, чем к памяти в других узлах. Система стремится повысить производительность, выделяя потокам время на процессорах, ко торые находятся в том же узле, что и используемая память. Она также пыта ется выделять память в пределах узла, но при необходимости выделяет па мять и из других узлов. Хотя Windows изначально разрабатывалась для поддержки до 32 процес соров, многопроцессорной модели не свойственны никакие внутренние особенности, которые ограничивали бы число используемых процессоров до 32. Просто это число легко представить битовой маской с помощью ма шинного 32разрядного типа данных. И действительно, 64разрядные вер сии Windows поддерживают до 64 процессоров, потому что размер слова на 64разрядных процессорах равен 64 битам. Реальное число поддерживаемых процессоров зависит от конкретного выпуска Windows (см. таблицы 23 и 24). Это число хранится в параметре реестра HKLM\SYSTEM\CurrentControlSet\Control\Session\Manager\Licensed Processors. (Учтите, что модификация этого параметра считается нарушени ем условий лицензионного соглашения на программное обеспечение, да и для увеличения числа поддерживаемых процессоров требуется нечто боль шее, чем простое изменение данного параметра.) Для большей производительности ядро и HAL имеют одно и многопро цессорную версии. В случае Windows 2000 это относится к шести ключевым системным файлам (см. примечание ниже), а в 32разрядных Windows XP и Windows Server 2003 — только к трем (см. таблицу 22). В 64разрядных си стемах Windows ядра PAE нет, поэтому одно и многопроцессорные систе мы отличаются лишь ядром и HAL. Соответствующие файлы выбираются и копируются в локальный каталог \Windows\System32 на этапе установки. Чтобы определить, какие файлы были скопированы, см. файл \Windows\Repair\Setup.log, где перечисляются все файлы, копировавшиеся на локальный системный диск, и каталоги на дистрибутивном носителе, откуда они были взяты.
ГЛАВА 9 Архитектура системы 47 Таблица 2-2. Системные файлы, специфичные для однои многопроцессорных систем Имя файла на системном диске Имя однопроцессорной версии на дистрибутивном носителе Имя многопроцессорной версии на дистрибутивном носителе Ntoskrnl.exe Ntoskrnl.exe Ntkrnlmp.exe Ntkrnlpa.exe (ядро PAE; только 32разрядные системы) Ntkrnlpa.exe в \Windows\ <arch>\Driver.cab Ntkrpamp.exe в \Windows\ <arch>\Driver.cab Hal.dll Зависит от типа системы Зависит от типа системы (см. список HAL в таблице 26) (см. список HAL в таблице 26) Только Windows 2000 Win32k.sys \I386\UNIPROC\Win32k.sys Win32k.sys в \I386\ Driver.cab Ntdll.dll \I386\UNIPROC\Ntdll.dll \I386\Ntdll.dll Kernel32.dll \I386\UNIPROC\Kernel32.dll \I386\Kernel32.dll ПРИМЕЧАНИЕ В папке \I386\UNIPROC в дистрибутиве Windows 2000 находится файл Winsrv.dll. Хотя он помещен в папку UNIPROC, назва ние которой указывает на однопроцессорную версию, на самом деле для одно и многопроцессорных систем существует только одна вер сия этого образа. ЭКСПЕРИМЕНТ: поиск файлов поддержки многопроцессорных систем в Windows 2000 Вы можете убедиться в том, что для многопроцессорной 32разрядной системы Windows 2000 используются другие файлы, просмотрев све дения о драйверах для Computer (Компьютер) в Device Manager (Дис петчер устройств). 1. Откройте окно свойств системы, дважды щелкнув System (Система) в окне Control Panel (Панель управления) или щелкнув правой кнопкой мыши My Computer (Мой компьютер) на рабочем столе и выбрав из контекстного меню команду Properties (Свойства). 2. Перейдите на вкладку Hardware (Оборудование). 3. Щелкните кнопку Device Manager (Диспетчер устройств). 4. Раскройте объект Computer (Компьютер). 5. Дважды щелкните дочерний узел объекта Computer. 6. Откройте вкладку Driver (Драйвер). 7. Щелкните кнопку Driver Details (Сведения о драйверах). В многопроцессорной системе вы должны увидеть диалоговое окно, показанное ниже.
48 ГЛ А В А 2 БЕЗОПАСНОСТЬ Специальные версии этих ключевых системных файлов для однопроцес сорных систем созданы для максимального повышения производительнос ти. Синхронизация работы нескольких процессоров — задача принципиаль но более сложная, и благодаря «однопроцессорным» версиям системных файлов устраняются издержки этой синхронизации, которая в однопроцес сорных системах (а они составляют подавляющее большинство систем под управлением Windows) не нужна. Интересно, что «однопроцессорная» и «многопроцессорная» версии Ntoskrnl создаются за счет условной компиляции одного и того же исходного кода, а «однопроцессорные» версии Ntdll.dll и Kernel32.dll для Windows 2000 требу ют замены машинных x86команд LOCK и UNLOCK, используемых для синх ронизации множества потоков, командой NOP (которая ничего не делает). Остальные системные файлы Windows (включая все утилиты, библиоте ки и драйверы устройств) одинаковы как в многопроцессорных, так и в од нопроцессорных системах. При разработке нового программного обеспе чения — Windowsприложения или драйвера устройства — вы должны учи тывать этот подход и тестировать свое программное обеспечение как в одно, так и в многопроцессорных системах. ЭКСПЕРИМЕНТ: определение текущей версии Ntoskrnl В Windows 2000 и выше нет утилиты, показывающей, с какой версией Ntoskrnl вы работаете. Однако при каждой загрузке в журнале систе мы регистрируется, какая версия ядра запускается — одно или мно гопроцессорная, отладочная или конечная (см. следующую иллюстра цию). Выберите из меню Start (Пуск) команду Programs (Программы), затем Administrative Tools (Администрирование) и Event Viewer (Про смотр событий). Далее выберите System Log (Журнал системы) и дваж ды щелкните запись с кодом события 6009 — она создается при заг рузке системы.
ГЛАВА 9 Архитектура системы 49 Эта запись не содержит сведений о том, загружена ли PAEверсия образа ядра, поддерживающая более 4 Гб физической памяти (Ntkrnlpa.exe). Однако вы можете узнать это, проверив значение пара метра SystemStartOptions в разделе реестра HKLM\SYSTEM\Current ControlSet\Control. Кроме того, при загрузке PAEверсии ядра парамет ру PhysicalAddressExtension в разделе реестра HKLM\SYSTEM\Current ControlSet\Control\Session Manager\Memory Management присваивает ся значение, равное 1. Есть и другой способ определить, установлена ли многопроцессор ная версия Ntoskrnl (или Ntkrnlpa): запустите Windows Explorer (Про водник), в каталоге \Windows\System32 щелкните правой кнопкой мы ши файл Ntoskrnl.exe и выберите из контекстного меню команду Pro см. след. стр.
50 ГЛ А В А 2 БЕЗОПАСНОСТЬ perties (Свойства). Перейдите на вкладку Version (Версия) и выберите свойство Original Filename (Исходное имя файла). Если вы работаете с многопроцессорной версией, то увидите диалоговое окно, показан ное на предыдущей странице. Наконец, просмотрев файл \Windows\Repair\Setup.log, можно точ но выяснить, какие файлы ядра и HAL были выбраны при установке. Масштабируемость Масштабируемость (scalability) — одна из ключевых целей многопроцес сорных систем. Для корректного выполнения в SMPсистемах операционная система должна строго соответствовать определенным требованиям. Решить проблемы конкуренции за ресурсы и другие вопросы в многопроцессорных системах сложнее, чем в однопроцессорных, и это нужно учитывать при разработке системы. Некоторые особенности Windows оказались решающи ми для ее успеха как многопроцессорной операционной системы: 쐽 способность выполнять код операционной системы на любом доступном процессоре и на нескольких процессорах одновременно; 쐽 несколько потоков одного процесса можно параллельно выполнять на разных процессорах; 쐽 тонкая синхронизация внутри ядра (спинблокировки, спинблокировки с очередями и др.; см. главу 3), драйверов устройств и серверных процес сов позволяет выполнять больше компонентов на нескольких процессо рах одновременно; 쐽 механизмы вроде портов завершения вводавывода (см. главу 9), облегча ющие эффективную реализацию многопоточных серверных процессов, хорошо масштабируемых в многопроцессорных системах. Масштабируемость ядра Windows со временем улучшалась. Например, в Windows Server 2003 имеются очереди планирования, индивидуальные для каждого процессора, что дает возможность планировать потоки параллель но на нескольких машинах. О планировании потоков в многопроцессорных системах см. главу 6, а о синхронизации в таких системах — главу 3. Различия между клиентскими и серверными версиями Windows поставляется в клиентских и серверных версиях. В Windows 2000 клиентская версия называется Windows 2000 Professional. Существует также три серверных версии Windows 2000: Windows 2000 Server, Advanced Server и Datacenter Server. У Windows XP шесть клиентских версий: Windows XP Home Edition, Win dows XP Professional, Windows XP Starter Edition, Windows XP Tablet PC Edition, Windows XP Media Center Edition и Windows XP Embedded. Последние три являются надмножествами Windows XP Professional и в книге детально не рассматриваются, так как все они построены на том же базовом коде, что и Windows XP Professional.
ГЛАВА 9 Архитектура системы 51 Windows Server 2003 выпускается в шести разновидностях: Windows Ser ver 2003 Web Edition, Standard Edition, Small Business Server, Storage Server, Enterprise Edition и Datacenter Edition. Эти версии различаются по следующим параметрам: 쐽 числу поддерживаемых процессоров; 쐽 объему поддерживаемой физической памяти; 쐽 возможному количеству одновременных сетевых соединений (например, в клиентской версии допускается максимум 10 одновременных соедине ний со службой доступа к общим файлам и принтерам); 쐽 наличием в выпусках Server сервисов, не входящих в Professional (напри мер, служб каталогов, поддержкой кластеризации и многопользователь ской службы терминала). Эти различия для Windows 2000 суммируются в таблице 23. Та же инфор мация, но применительно к Windows XP и Windows Server 2003 дана в таб лице 24. Детальное сравнение различных выпусков Windows Server 2003 см. по ссылке http://www.microsoft.com/windowsserver2003/evaluation/features/ compareeditions.mspx. Таблица 2-3. Различия между Windows 2000 Professional и Server Выпуск Windows 2000 Professional Windows 2000 Server Windows 2000 Advanced Server Windows 2000 Datacenter Server Число процессоров 2 4 8 32 Объем физической памяти, Гб 4 4 8 64 Таблица 2-4. Различия между Windows XP и Windows Server 2003 Объем физической памяти, Гб (32разрядная Число процессоров (64-разрядная версия) Windows XP 1 Home Edition 4 Неприменимо Неприменимо Неприменимо Windows XP 2 Professional 4 2 Windows Server 2003 Web Edition 2 2 Неприменимо Неприменимо Неприменимо Windows 2 Server 2003 Small Business Server 2 Неприменимо Неприменимо Неприменимо Windows Server 2003 Standard Edition 4 Неприменимо Неприменимо Неприменимо Число процессоров (32-разрядная версия) 4 Объем физической памяти, Гб (версии для для Itanium) 16 Объем физической памяти, Гб (версии для x64) 16 см. след. стр.
52 ГЛ А В А 2 БЕЗОПАСНОСТЬ Таблица 2-4. (окончание) Число процессоров (32-разрядная версия) Объем физической памяти, Гб (32разрядная Число процессоров (64-разрядная версия) Объем физической памяти, Гб (версии для для Itanium) Объем физической памяти, Гб (версии для x64) Windows Server 2003 Enterprise Edition 8 32 8 64 64 Windows Server 2003 Datacenter Edition 32 128 (на x64); 64 (на x86) 64 512 (1024 Гб в SP1) Неприменимо Хотя существует несколько клиентских и серверных выпусков операци онной системы Windows, у них общий набор базовых системных файлов, в том числе: ядро, Ntoskrnl.exe (а также версия PAE, Ntkrnlpa.exe), библиотеки HAL, драйверы, основные системные утилиты и DLL. Эти файлы идентичны для всех выпусков Windows 2000. ПРИМЕЧАНИЕ Windows XP была первым клиентским выпуском кодо вой базы Windows NT, который поставляется без соответствующих серверных версий. Вместо этого разработки продолжались, и пример но год спустя после выхода Windows XP была выпущена Windows Ser ver 2003. Таким образом, базовые системные файлы Windows XP и Windows Server 2003 не идентичны. Однако они не столь значимы (и во многих случаях компоненты не изменялись). Итак, если образ ядра для Windows 2000 Professional и Windows 2000 Server одинаков (и сходен для Windows XP и Windows Server 2003), то как же система определяет, какой именно выпуск загружается? Для этого она про веряет значения параметров ProductType и ProductSuite в разделе реестра HKLM\SYSTEM\CurrentControlSet\Control\ProductOptions. Параметр Product Type используется, чтобы отличить клиентскую систему от серверной (лю бого выпуска). Список допустимых значений этого параметра приведен в таблице 25. Результат проверки помещается в глобальную системную пере менную MmProductType, значение которой может быть запрошено драйве ром устройства через функцию MmIsThisAnNtAsSystem режима ядра, описан ную в документации Windows DDK. Таблица 2-5. Значения параметра реестра ProductType Выпуск Windows Значение ProductType Windows 2000 Professional, Windows XP Professional, Windows XP Home Edition WinNT Windows Server (контроллер домена) LanmanNT Windows Server (только сервер) ServerNT
ГЛАВА 9 Архитектура системы 53 Другой параметр, ProductSuite, позволяет различать серверные версии Windows (Standard, Enterprise, Datacenter Server и др.), а также Windows XP Home от Windows XP Professional. Для проверки текущего выпуска Windows пользовательские программы вызывают Windowsфункцию VerifyVersionInfo, описанную в Platform SDK. Драйверы могут вызвать функцию RtlGetVersion режима ядра, документированную в Windows DDK. Итак, если базовые файлы в целом одинаковы для клиентских и сервер ных версий, то чем же отличается их функционирование? Серверные сис темы оптимизированы для работы в качестве высокопроизводительных сер веров приложений, а клиентские, несмотря на поддержку серверных воз можностей, — для персональных систем. Так, некоторые решения по выде лению ресурсов (например, о числе и размере системных пулов памяти, ко личестве внутрисистемных рабочих потоков и размере системного кэша данных) при загрузке принимаются поразному, в зависимости от типа про дукта. Политика принятия таких решений, как обслуживание диспетчером памяти запросов системы и процессов на выделение памяти, у серверной и клиентской версий тоже различается. В равной мере это относится и к осо бенностям планирования потоков по умолчанию (детали см. в главе 6). Су щественные отличия в функционировании этих двух продуктов будут отме чены в соответствующих главах. Любые материалы в нашей книге, если явно не указано иное, относятся к обеим версиям — клиентской и серверной. Проверочный выпуск Специальная отладочная версия Windows 2000 Professional, Windows XP Professional или Windows Server 2003 называется проверочным выпуском (checked build). Она доступна только подписчикам MSDN уровня Professional (или выше). Проверочный выпуск представляет собой перекомпилирован ный исходный код Windows, для которого флаг «DBG» (заставляющий вклю чать код отладки и трассировки этапа компиляции) был установлен как TRUE. Кроме того, чтобы облегчить восприятие машинного кода, отключа ется обработка двоичных файлов, при которой структура кода оптимизиру ется для большего быстродействия (см. раздел «PerformanceOptimized Code» в справочном файле Debugging Tools). Проверочный выпуск предназначен главным образом разработчикам драйверов устройств, поскольку эта версия выполняет более строгую провер ку ошибок при вызове функций режима ядра драйверами устройств или дру гим системным кодом. Например, если драйвер (или какойто иной код ре жима ядра) неверно вызывает системную функцию, контролирующую пере даваемые параметры, то при обнаружении этой проблемы система останав ливается, предотвращая повреждение структур данных и возможный крах.
54 ГЛ А В А 2 БЕЗОПАСНОСТЬ ЭКСПЕРИМЕНТ: определяем, является ли данная система проверочным выпуском Встроенной утилиты, которая позволяла бы увидеть, с каким выпуском вы имеете дело — проверочным или готовым, нет. Однако эта инфор мация доступна через свойство «Debug» WMIкласса (Windows Mana gement Instrumentation) Win32_OperatingSystem. Следующий сценарий на Visual Basic отображает содержимое этого свойства: strComputer = "." Set objWMIService = GetObject("winmgmts:" _ & "{impersonationLevel=impersonate}!\\" & _ strComputer & "\root\cimv2”) Set colOperatingSystems = objWMIService.ExecQuery _ ("SELECT * FROM Win32_OperatingSystem"S) For Each objOperatingSystem in colOperatingSystems Wscript.Echo "Caption: " & objOperatingSystem.Caption Wscript.Echo "Debug: " & objOperatingSystem.Debug Wscript.Echo "Version: " & objOperatingSystem.Version Next Чтобы опробовать его в действии, наберите код этого сценария и сохраните как файл. Вот пример вывода: C:\>cscript osversion.vbs Microsoft (R) Windows Script Host Version 5.6 Copyright (C) Microsoft Corporation 19962001. All rights reserved. Caption: Microsoft Windows XP Professional Debug: False Version: 5.1.2600 Эта система не является проверочным выпуском, так как флаг De bug равен False. Значительная часть дополнительного кода в собранных таким образом двоичных файлах является результатом работы макроса ASSERT, определен ного в заголовочном файле Ntddk.h, который входит в состав DDK. Этот мак рос проверяет некое условие (например, правильность структуры данных или параметра) и, если значение выражения получается равным FALSE, вы зывает функцию RtlAssert режима ядра, которая в свою очередь обращается к DbgPrint, передающей текст отладочного сообщения в буфер отладочных сообщений (debug message buffer). Если отладчик ядра подключен, это сооб щение выводится на экран, а за ним автоматически появляется запрос к пользователю, какое действие следует предпринять (игнорировать, завер шить процесс или поток и т. д.). Если система загружена без отладчика ядра (в отсутствие ключа /DEBUG в файле Boot.ini) и этот отладчик сейчас не подключен, неудачный тест ASSERT вызовет крах системы. Список тестов
ГЛАВА 9 Архитектура системы 55 ASSERT, выполняемых некоторыми вспомогательными процедурами ядра, см. в разделе «Checked Build ASSERTs» документации Windows DDK. ПРИМЕЧАНИЕ Сравнив файл Ntoskrnl.exe с Ntkrnlmp.exe или Ntkrnlpa. exe с Ntkrpamp.exe в проверочной версии системы, вы убедитесь, что они идентичны и являются «многопроцессорными» версиями соответ ствующих файлов. Иначе говоря, в проверочной версии системы нет отладочных вариантов файлов для однопроцессорных систем. Проверочный выпуск также полезен системным администраторам, так как в нем можно включить детальную трассировку для определенных ком понентов. (Подробные инструкции см. в статье 314743 «HOWTO: Enable Verbose Debug Tracing in Various Drivers and Subsystems» в Microsoft Knowledge Base.) Вывод такой трассировки посылается в буфер отладочных сообщений с помощью функции DbgPrint, о которой мы уже упоминали. Для просмот ра отладочных сообщений к целевой системе можно подключить отладчик ядра (что потребует загрузки целевой системы в отладочном режиме), ис пользовать команду !dbgprint в процессе локальной отладки ядра или при менить утилиту Dbgview.exe с сайта www.sysinternals.com. Для использования возможностей отладочной версии операционной си стемы необязательно устанавливать весь проверочный выпуск. Можно про сто скопировать проверочную версию образа ядра (Ntoskrnl.exe) и соответ ствующий HAL (Hal.dll) в обычную систему. Преимущество этого подхода в том, что он позволяет тщательно протестировать драйверы устройств и дру гой код ядра, не устанавливая медленнее работающие версии всех компонен тов системы. О том, как это сделать, см. раздел «Installing Just the Checked Operating System and HAL» в документации Windows DDK. Поскольку Micro soft не поставляет проверочный выпуск Windows 2000 Server, вы можете применить этот способ и получить проверочную версию ядра в системе Windows 2000 Server. Наконец, проверочная версия пригодится и для тестирования кода поль зовательского режима, но только в том смысле, что в проверочной версии системы устанавливаются другие интервалы ожидания (тайминги). (Это свя зано с тем, что в ядре выполняются дополнительные проверки, а сами ком поненты компилируются без оптимизации.) В таких условиях часто проявля ются ошибки, связанные с синхронизацией нескольких потоков приложения. Ключевые компоненты системы Теперь, ознакомившись с высокоуровневой архитектурой Windows, копнем поглубже и рассмотрим роль каждого ключевого компонента системы. На рис. 23 отражена более подробная схема системной архитектуры Windows. Заметьте, что на ней все равно не показаны некоторые компоненты (в част ности, компоненты сетевой поддержки, о которых пойдет речь в главе 13). Основные элементы этой схемы детально описываются в последующих главах. В главе 3 рассказывается об основных механизмах управления,
56 ГЛ А В А 2 БЕЗОПАСНОСТЬ используемых системой (в том числе о диспетчере объектов, прерываниях и т. п.), в главе 5 — о процессах запуска и завершения Windows, а в главе 4 — о таких механизмах управления, как реестр, процессы сервисов и Windows Management Instrumentation (WMI). В остальных главах не менее подробно поясняется внутреннее устройство и функционирование ключевых элемен тов — процессов, потоков, подсистемы управления памятью, защиты, диспет чера вводавывода, диспетчера кэша, файловой системы NTFS, сетевой под держки и др. Рис. 2-3. Архитектура Windows
ГЛАВА 9 Архитектура системы 57 Подсистемы окружения и их DLL Как показано на рис. 23, в Windows имеется три подсистемы окружения: OS/2, POSIX и Windows. Как мы уже говорили, подсистема OS/2 была удалена в Windows 2000. Начиная с Windows XP, базовая подсистема POSIX не постав ляется с Windows, но ее гораздо более совершенную версию можно получить бесплатно как часть продукта Services for UNIX. Подсистема Windows отличается от остальных двух тем, что без нее Win dows работать не может (эта подсистема обрабатывает все, что связано с кла виатурой, мышью и экраном, и нужна даже на серверах в отсутствие интерак тивных пользователей). Фактически остальные две подсистемы запускаются только по требованию, тогда как подсистема Windows работает всегда. Стартовая информация подсистемы хранится в разделе реестра HKLM\ SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems. Значения параметров в этом разделе показаны на рис. 24. Рис. 2-4. Просмотр стартовой информации Windows в Registry Editor Значением параметра Required является список подсистем, загружаемых при запуске системы. Параметр состоит из двух строк: Windows и Debug. В параметре Windows указывается спецификация файла подсистемы Windows, Csrss.exe (аббревиатура от Client/Server RunTime Subsystem; см. примечание ниже). Параметр Debug остается незаполненным (он используется для внут реннего тестирования) и не выполняет никаких функций. Параметр Optional указывает, что подсистемы OS/2 и POSIX запускаются по требованию. Пара метр Kmode содержит имя файла той части подсистемы Windows, которая работает в режиме ядра, — Win32k.sys (об этом файле чуть позже). Подсистемы окружения предоставляют прикладным программам некое подмножество базовых сервисов исполнительной системы Windows. Каждая подсистема обеспечивает доступ к разным подмножествам встроенных сер висов Windows. Это значит, что приложения, созданные для одной подсис темы, могут выполнять операции, невозможные в другой подсистеме. Так, Windowsприложения не могут использовать POSIXфункцию fork. Каждый исполняемый образ (EXE) принадлежит одной — и только од ной — подсистеме. При запуске образа код, отвечающий за создание процес са, получает тип подсистемы, указанный в заголовке образа, и уведомляет со ответствующую подсистему о новом процессе. Тип указывается специфика
58 ГЛ А В А 2 БЕЗОПАСНОСТЬ тором /SUBSYSTEM в команде link в Microsoft Visual C++; его можно просмот реть с помощью утилиты Exetype, входящей в состав ресурсов Windows. ПРИМЕЧАНИЕ Процесс подсистемы Windows назван Csrss.exe пото му, что в Windows NT все подсистемы изначально предполагалось вы полнять как потоки внутри единственного общесистемного процес са. Когда подсистемы POSIX и OS/2 были выделены в собственные про цессы, имя файла процесса подсистемы Windows осталось прежним. Смешивать вызовы функций разных подсистем нельзя. Иными словами, приложения POSIX могут вызывать только сервисы, экспортируемые подсис темой POSIX, а приложения Windows — лишь сервисы, экспортируемые под системой Windows. Как вы еще убедитесь, это ограничение послужило одной из причин, по которой исходная подсистема POSIX, реализующая весьма ограниченный набор функций (только POSIX 1003.1), не стала полез ной средой для переноса в нее UNIXприложений. Мы уже говорили, что пользовательские приложения не могут вызывать системные сервисы Windows напрямую. Вместо этого они обращаются к DLL подсистем. Эти DLL предоставляют документированный интерфейс между программами и вызываемой ими подсистемой. Так, DLL подсистемы Win dows (Kernel32.dll, Advapi32.dll, User32.dll и Gdi32.dll) реализуют функции Windows API. DLL подсистемы POSIX (Psxdll.dll) реализует POSIX API. ЭКСПЕРИМЕНТ: определение типа подсистемы, для которой предназначен исполняемый файл Вы можете определить, для какой подсистемы предназначен исполня емый файл с помощью утилиты Exetype из набора ресурсов Windows или утилиты Dependency Walker (Depends.exe), входящей в состав Win dows Support Tools и Platform SDK. Попробуем, например, выяснить тип подсистемы для двух принципиально разных Windowsобразов: Notepad.exe (простого текстового редактора) и Cmd.exe (поддержки командной строки Windows). C:\>exetype \windows\system32\notepad.exe File “\windows\system32\notepad.exe“ is of the following type: Windows NT 32 bit machine Built for the Intel 80386 processor Runs under the Windows GUI subsystem C:\>exetype \windows\system32\cmd.exe File “\windows\system32\cmd.exe“ is of the following type: Windows NT 32 bit machine Built for the Intel 80386 processor Runs under the Windows characterbased subsystem
ГЛАВА 9 Архитектура системы 59 Это показывает, что Notepad является GUIпрограммой, а Cmd — консольной, или программой текстового режима. Хотя вывод утили ты Exetype сообщает о наличии двух разных подсистем для GUI и кон сольных программ, на самом деле существует лишь одна подсистема Windows. Кроме того, Windows не поддерживает процессор Intel 386 (или 486, если это имеет какоето значение) — текст сообщений, вы водимых программой Exetype, просто не обновили. При вызове приложением одной из функций DLL подсистемы возможно одно из трех. 쐽 Функция полностью реализована в пользовательском режиме внутри DLL подсистемы. Иначе говоря, никаких сообщений процессу подсистемы окружения не посылается, и вызова сервисов исполнительной системы Windows не происходит. После выполнения функции в пользовательском режиме результат возвращается вызвавшей ее программе. Примерами таких функций могут служить GetCurrentProcess (всегда возвращает –1, значение, определенное для ссылки на текущий процесс во всех функци ях, связанных с процессами) и GetCurrentProcessId (идентификатор про цесса не меняется в течение его срока жизни, поэтому его можно полу чить из кэша, что позволяет избежать переключения в режим ядра). 쐽 Функция требует одного или более вызовов исполнительной системы Windows. Например, Windowsфункции ReadFile и WriteFile обращаются к внутренним недокументированным сервисам вводавывода — соответ ственно к NtReadFile и NtWriteFile. 쐽 Функция требует выполнения какихлибо операций в процессе подсис темы окружения (такие процессы, работающие в пользовательском режи ме, отвечают за обслуживание клиентских приложений, выполняемых под их контролем). В этом случае подсистеме окружения выдается кли ентсерверный запрос через сообщение с требованием выполнить какую либо операцию, и DLL подсистемы, прежде чем вернуть управление выз вавшей программе, ждет соответствующего ответа. Некоторые функции вроде CreateProcess и CreateThread могут требовать выполнения как второго, так и третьего пункта. Хотя структура Windows позволяет поддерживать несколько независимых подсистем окружения, с практической точки зрения было бы неудобно вклю чать в состав каждой подсистемы свой код для обработки окон и отображе ния вводавывода. Это привело бы к дублированию системных функций и в конечном счете негативно отразилось бы на объеме и производительности системы. Поскольку главной подсистемой была Windows, разработчики реши ли разместить эти базовые функции именно в ней. Так что другие подсисте мы для отображения вводавывода вызывают соответствующие сервисы Win dows. (Кстати, посмотрев на тип подсистемы в заголовках их файлов, вы убе дитесь, что фактически они являются исполняемыми файлами Windows.) Теперь поближе познакомимся с каждой подсистемой окружения.
60 ГЛ А В А 2 БЕЗОПАСНОСТЬ Подсистема Windows Эта подсистема состоит из следующих основных элементов. 쐽 Процесса подсистемы окружения (Csrss.exe), предоставляющего: 쐽 поддержку консольных (текстовых) окон; 쐽 поддержку создания и удаления процессов и потоков; 쐽 частичную поддержку процессов 16разрядной виртуальной DOSма шины (VDM); 쐽 множество других функций, например GetTempFile, DefineDosDevice, ExitWindowsEx, а также несколько функций поддержки естественных языков. 쐽 Драйвера режима ядра (Win32k.sys), включающего: 쐽 диспетчер окон, который управляет отрисовкой и выводом окон на экран, принимает ввод с клавиатуры, мыши и других устройств, а так же передает пользовательские сообщения приложениям; 쐽 Graphics Device Interface (GDI), который представляет собой библиоте ку функций для устройств графического вывода. В GDI входят функции для манипуляций с графикой и отрисовки линий, текста и фигур. 쐽 DLLмодулей подсистем (Kernel32.dll, Advapi32.dll, User32.dll и Gdi32.dll), транслирующих вызовы документированных функций Windows API в вызовы соответствующих (и в большинстве своем недокументирован ных) сервисов режима ядра из Ntoskrnl.exe и Win32k.sys. 쐽 Драйверов графических устройств, представляющих собой специфичные для конкретного оборудования драйверы графического дисплея, принте ра и минипортдрайверы видеоплат. Для формирования элементов управления пользовательского интерфейса на экране, например окон и кнопок, приложения могут вызывать стандарт ные функции USER. Диспетчер окон передает эти вызовы GDI, а тот — драй верам графических устройств, где они форматируются для дисплея. Драйвер дисплея работает в паре с соответствующим минипортдрайвером видеопла ты, обеспечивая полную поддержку видео. GDI предоставляет набор стандартных функций двухмерной графики, которые позволяют приложениям, не имеющим представления о графичес ких устройствах, обращаться к ним. GDIфункции играют роль посредника между приложениями и драйверами дисплея и принтера. GDI интерпрети рует запросы приложений на вывод графики и посылает соответствующие запросы драйверам. Он также предоставляет приложениям стандартный унифицированный интерфейс для использования самых разнообразных устройств графического вывода. Этот интерфейс обеспечивает независи мость кода приложений от конкретного оборудования и его драйверов. GDI выдает свои запросы с учетом возможностей конкретного устройства, час то разделяя запрос на несколько частей для обработки. Так, некоторые уст ройства сами умеют формировать эллипсы, а другие требуют от GDI интер
ГЛАВА 9 Архитектура системы 61 претировать эллипсы как набор пикселов с определенными координатами. Подробнее об архитектуре подсистемы вывода графики и драйвере дисплея см. раздел «Design Guide» в книге «Graphics Drivers» из Windows DDK. До Windows NT 4 диспетчер окон и графические сервисы были частью процесса подсистемы Windows пользовательского режима. В Windows NT 4 основная часть кода, ответственного за обработку окон и графики, перене сена из контекста процесса подсистемы Windows в набор вызываемых сер висов, выполняемых в режиме ядра (в файл Win32k.sys). Этот перенос был осуществлен в основном для повышения общей производительности систе мы. Отдельный серверный процесс, содержащий графическую подсистему, требовал многочисленных переключений контекста потоков и процессов, что отнимало большое количество тактов процессора и значительные ре сурсы памяти, даже несмотря на высокую оптимизацию исходной архитек туры этой подсистемы. Например, каждый клиентский поток обслуживается парным серверным потоком в процессе подсистемы Windows, ожидающем запросов от клиент ского потока. Для передачи сообщений между потоками используется спе циальный механизм взаимодействия между процессами, так называемый быстрый LPC (fast LPC). В отличие от обычного переключения контекста потоков передача данных между парными потоками через быстрый LPC не вызывает в ядре события перепланирования, что позволяет серверному по току выполняться в течение оставшегося кванта времени клиентского потока (вне очереди, определенной планировщиком). Более того, для быстрой пе редачи больших структур данных, например битовых карт, используются разделяемые буферы памяти, и клиенты получают прямой доступ (только для чтения) к ключевым структурам данных сервера, а это сводит к минимуму необходимость в частом переключении контекста между клиентами и сер вером Windows. GDIоперации выполняются в пакетном режиме. При этом серия графи ческих объектов, запрошенных Windowsприложениями, не обрабатывает ся сервером и не прорисовывается на устройстве вывода до тех пор, пока не будет заполнена вся очередь GDI. Размер очереди можно установить через Windowsфункцию GdiSetBatchLimit. В любой момент все объекты из очере ди можно сбросить вызовом функции GdiFlush. С другой стороны, неизме няемые свойства и структуры данных GDI после получения от процессов подсистемы Windows кэшируются клиентскими процессами для ускорения последующего доступа к ним. Однако, несмотря на такую оптимизацию, общая производительность системы попрежнему не соответствовала требованиям приложений, интен сивно работающих с графикой. Очевидным решением проблемы стал пере вод подсистемы поддержки окон и графики в режим ядра, что позволило избежать потребности в дополнительных потоках и связанных с ними пе реключениями контекста. Кроме того, как только приложения вызывают диспетчер окон и GDI, эти подсистемы теперь получают прямой доступ к
62 ГЛ А В А 2 БЕЗОПАСНОСТЬ компонентам исполнительной системы Windows без перехода из пользова тельского режима в режим ядра и обратно. Прямой доступ особенно важен в случае вызова GDI через видеодрайверы, когда взаимодействие с видеообо рудованием требует высокой пропускной способности. Так что же остается в той части процесса подсистемы Windows, которая работает в пользовательском режиме? Поскольку консольные программы не перерисовывают окна, все операции по отрисовке и обновлению консоль ных и текстовых окон проводятся именно этой частью Windows. Увидеть ее деятельность несложно: просто откройте окно командной строки и перета щите поверх него другое окно. Вы увидите, что процесс подсистемы Win dows начинает расходовать процессорное время, перерисовывая консоль ное окно. Кроме поддержки консольных окон, только небольшая часть Win dowsфункций посылает сообщения процессу подсистемы Windows. К ним относятся функции, отвечающие за создание и завершение процессов и по токов, назначение букв сетевым дискам, создание временных файлов. Как правило, Windowsприложение нечасто переключает (если вообще переклю чает) контекст в процесс подсистемы Windows. Не пострадала ли стабильность Windows от перевода USER и GDI в режим ядра? Некоторые интересуются, не повлияет ли на стабильность системы перевод такой значительной части кода в режим ядра. Но риск сниже ния стабильности системы минимален. Дело в том, что до Windows NT 4 (равно как и в настоящее время) ошибка вроде нарушения доступа (access violation) в процессе подсистемы Windows пользовательского режима (Csrss.exe) приводила к краху системы, потому что процесс подсистемы Windows был и остается жизненно важным для функци онирования всей системы. Поскольку структуры данных, определяю щие окна на экране, содержатся именно в этом процессе, его гибель приводит к уничтожению пользовательского интерфейса. Однако да же при функционировании Windows в качестве сервера без интерак тивных процессов система не могла бы работать без Csrss, поскольку серверные процессы иногда используют оконные сообщения для кон троля внутреннего состояния приложений. Так что в Windows ошиб ки вроде нарушения доступа в том же коде, только выполняемом в ре жиме ядра, просто быстрее приводят к краху — исключения в режиме ядра требуют прекращения работы системы. Правда, теоретически появляется другая опасность. Поскольку этот код выполняется в режиме ядра, ошибка (например, применение не верного указателя) может повредить защищенные структуры данных режима ядра. До Windows NT 4 это могло привести к нарушению дос тупа, так как запись в страницы режима ядра из пользовательского режима не разрешается. Но результатом стал бы крах системы. Теперь же при выполнении кода в режиме ядра запись на какуюлибо страни
ГЛАВА 9 Архитектура системы 63 цу памяти по неверному указателю не обязательно вызовет немедлен ный крах системы. Но, если при этом будут повреждены какието структуры данных, крах скорее всего произойдет. Тем не менее возни кает риск, что изза такого указателя будет повреждена не структура данных, а буфер памяти, и это приведет к возврату пользовательской программе или записи на диск неверных данных. Существует еще одно негативное последствие перевода графичес ких драйверов в режим ядра. Ранее некоторые части графического драйвера выполнялись в Csrss, а остальные части — в режиме ядра. Те перь весь драйвер работает только в режиме ядра. Так как не все драй веры поддерживаемых Windows графических устройств разрабатыва ются Microsoft, она тесно сотрудничает с производителями оборудо вания, чтобы гарантировать разработку ими надежных и эффектив ных драйверов. Все поставляемые с системой драйверы тестируются так же тщательно, как и другие компоненты исполнительной системы. Наконец, важно понимать, что такая схема (при которой подсис тема поддержки окон и графики выполняется в режиме ядра) не явля ется принципиально рискованной. Идентичный подход используется для многих других драйверов устройств (например, сетевых карт и жестких дисков). Все эти драйверы, выполняемые в режиме ядра, ни когда не снижали надежности Windows NT. Некоторые распространяют измышления насчет снижения эффек тивности вытесняющей многозадачности Windows изза перевода диспетчера окон и GDI в режим ядра. Теория, которая стоит за этой точкой зрения, — увеличивается время, затрачиваемое на дополни тельную обработку Windows в режиме ядра. Это мнение возникло в результате ошибочного понимания архитектуры Windows. Действи тельно, во многих других операционных системах, формально под держивающих вытесняющую многозадачность, планировщик никог да не вытесняет потоки, выполняемые в режиме ядра, или вытесняет, но лишь в отдельных ситуациях. Однако в Windows любые потоки, выполняемые в режиме ядра, планируются и вытесняются так же, как и потоки пользовательского режима, — код исполнительной системы полностью реентерабелен. Помимо многих других соображений, это просто необходимо для достижения высокого уровня масштабируемо сти системы на оборудовании с поддержкой SMP. Другое направление спекуляций касалось снижения масштабируе мости SMP в результате уже описанных изменений. Теоретические обоснования были такими: раньше во взаимодействии между прило жением и диспетчером окон или GDI участвовали два потока: один — в приложении и один — в Csrss.exe. Поэтому в SMPсистемах, где эти потоки могут выполняться параллельно, пропускная способность воз растает. Это свидетельствует о непонимании технологий, применяв шихся до Windows NT 4. В большинстве случаев клиентские приложе ния вызывают процесс подсистемы Windows синхронно, т. е. клиент см. след. стр.
64 ГЛ А В А 2 БЕЗОПАСНОСТЬ ский поток полностью блокируется в ожидании обработки вызова сер верным потоком и возобновляется только после этого. Так что ника кой параллелизм в SMPсистемах недостижим. Это явление легко на блюдать в SMPсистемах на примере приложений, интенсивно рабо тающих с графикой. При этом обнаружится, что в двухпроцессорной системе каждый процессор загружен на 50%; также легко заметить единственный поток Csrss, отделенный от потока приложения. Дей ствительно, поскольку два потока тесно взаимодействуют и находят ся в сходном состоянии, для поддержания синхронизации процессо рам приходится постоянно сбрасывать кэш. Именно по этой причи не однопоточные графические приложения в SMPсистемах под уп равлением Windows NT 3.51 обычно выполняются медленнее, чем в однопроцессорных системах. В результате изменений, внесенных в Windows NT 4, удалось повы сить пропускную способность SMPсистем для приложений, интенсив но использующих диспетчер окон и GDI, — особенно когда в прило жении работает более одного потока. При наличии двух потоков при ложения на двухпроцессорной машине под управлением Windows NT 3.51 за процессорное время конкурируют в общей сложности четыре потока (два — в приложении и два — в Csrss). Хотя в каждый момент к выполнению готовы, как правило, лишь два потока, их рассогласован ность ведет к потере локальности ссылок и синхронизации кэша. Это происходит скорее всего изза переключения потоков приложения с одного процессора на другой. В Windows NT 4 каждый из двух пото ков приложения по сути имеет собственный процессор, а механизм автоматической привязки потоков в Windows пытается постоянно вы полнять данный поток на одном и том же процессоре, максимально увеличивая локальность ссылок и сводя к минимуму потребность в синхронизации кэшпамяти индивидуальных процессоров. В заключение отметим, что повышение производительности в ре зультате перевода диспетчера окон и GDI из пользовательского режи ма в режим ядра достигнуто без скольконибудь значимого снижения стабильности и надежности системы — даже в случае нескольких се ансов, созданных в конфигурации с поддержкой Terminal Services. Подсистема POSIX POSIX, название которой представляет собой аббревиатуру от «portable ope rating system interface based on UNIX» (переносимый интерфейс операцион ной системы на основе UNIX), — это совокупность международных стандар тов на интерфейсы операционных систем типа UNIX. Стандарты POSIX сти мулировали производителей поддерживать совместимость реализуемых ими UNIXподобных интерфейсов, тем самым позволяя программистам легко переносить свои приложения между системами.
ГЛАВА 9 Архитектура системы 65 В Windows реализован лишь один из многих стандартов POSIX, а имен но POSIX.1, который официально называется ISO/IEC 99451:1990, или IEEE POSIX стандарта 1003.11990. Этот стандарт изначально был включен в ос новном для соответствия требованиям правительства США, установленным во второй половине 80х годов. В федеральном стандарте Federal Information Processing Standard (FIPS) 1512, разработанном государственным институ том стандартов и технологий (NIST), содержится требование совместимос ти с POSIX 1. Windows NT 3.5, 3.51 и 4 прошли тестирование на соответствие FIPS 1512. Поскольку совместимость с POSIX.1 была одной из обязательных целей, в Windows включена необходимая базовая поддержка подсистемы POSIX.1 — например, функция fork, реализованная в исполнительной системе Windows, и поддержка файловой системой Windows жестких файловых связей (hard file links). Однако POSIX.1 определяет лишь ограниченный набор сервисов (управ ление процессами, взаимодействие между процессами, простой символьный вводвывод и т. д.), и поэтому подсистема POSIX в Windows не является пол ноценной средой программирования. Так как вызов функций из разных под систем Windows невозможен, набор функций, доступный приложениям POSIX по умолчанию, строго ограничен сервисами, определяемыми POSIX.1. Смысл этих ограничений в следующем: приложение POSIX не может создать поток или окно в Windows, а также использовать RPC или сокеты. Для преодоления этого ограничения предназначен продукт Microsoft Windows Services for UNIX, включающий (в версии 3.5) улучшенную подсис тему окружения POSIX, которая предоставляет около 2000 функций UNIX и 300 инструментов и утилит в стиле UNIX. (Детали см. на www.microsoft.com/ windows/sfu/default.asp). Эта улучшенная подсистема POSIX реально помогает переносить UNIX приложения в Windows. Однако, поскольку эти программы все равно связа ны с исполняемыми файлами POSIX, Windowsфункции им недоступны. Что бы UNIXприложения, переносимые в Windows, могли использовать Win dowsфункции, нужно приобрести специальные пакеты для переноса UNIX программ в Windows, подобные продуктам MKS Toolkit, разработанные ком панией Mortice Kern Systems Inc. (www.mkssoftware.com). Тогда UNIXприло жения можно перекомпилировать и заново собрать как исполняемые фай лы Windows и начать постепенный переход на «родные» Windowsфункции. ЭКСПЕРИМЕНТ: наблюдаем старт подсистемы POSIX Подсистема POSIX по умолчанию сконфигурирована на запуск в мо мент начала выполнения приложения POSIX. Таким образом, старт подсистемы POSIX можно наблюдать, запустив какуюнибудь програм му POSIX, например одну из утилит POSIX из Windows Services for UNIX (небольшой набор утилит вы найдете и в каталоге \Apps\POSIX на ком пактдиске ресурсов Windows 2000; они не устанавливаются как часть см. след. стр.
66 ГЛ А В А 2 БЕЗОПАСНОСТЬ ресурсов). Для запуска подсистемы POSIX следуйте инструкциям, при веденным ниже. 1. Откройте окно командной строки. 2. Запустите Process Explorer и убедитесь, что подсистема POSIX еще не запущена (т. е. процесса Psxss.exe в системе нет). Также убедитесь, что Process Explorer отображает список процессов как дерево (на жмите Ctrl+T). 3. Запустите POSIXпрограмму (например C Shell или Korn Shell, по ставляемую с Windows Services for UNIX) или утилиту POSIX из ре сурсов Windows 2000, например \Apps\POSIX\Ls.exe. 4. Вернитесь в Process Explorer и обратите внимание на новый про цесс Psxss.exe, являющийся дочерним процессом Smss.exe (который в зависимости от выбранного интервала подсветки может какоето время оставаться выделенным как новый процесс). Для компиляции и сборки приложения POSIX в Windows нужны заголовочные файлы и библиотеки POSIX из Platform SDK. Исполняе мые файлы POSIX связываются с библиотекой подсистемы POSIX, Psxdll.dll. Поскольку Windows по умолчанию сконфигурирована на запуск подсистемы POSIX только по требованию, при первом запуске приложения POSIX должен запуститься процесс подсистемы POSIX (Psxss.exe). Его выполнение продолжается до перезагрузки системы. (Если вы завершите процесс подсистемы POSIX, запуск приложений POSIX станет невозможен до следующей перезагрузки системы.) При ложение POSIX не выполняется самостоятельно; для него запускается специальный файл поддержки Posix.exe, создающий дочерний про цесс, из которого и запускаются приложения POSIX. Подсистема OS/2 Подсистема окружения OS/2, как и подсистема POSIX, обладает довольно ограниченной функциональностью и поддерживает лишь 16разрядные приложения OS/2 версии 1.2 c символьным или графическим вводомвыво дом. Кроме того, Windows запрещает прикладным программам прямой до ступ к оборудованию и поэтому не поддерживает приложения OS/2, исполь зующие расширенный вводвывод видео или включающие сегменты приви легированного вводавывода, которые пытаются выполнять инструкции IN/ OUT (для доступа к некоторым аппаратным устройствам). Приложения, вы дающие машинные команды CLI/STI, могут работать в Windows, но на вре мя выполнения команды STI все другие приложения OS/2 в системе и пото ки процессов OS/2, выдающих команды CLI, приостанавливаются. Как показано на рис. 25, подсистема OS/2, использующая 32разрядное виртуальное адресное пространство Windows, может предоставить прило жениям OS/2 версии 1.2 до 512 Мб памяти, снимая тем самым исходное ог раничение этой версии на объем адресуемой памяти (до 16 Мб).
ГЛАВА 9 Архитектура системы 67 Мозаичная область (tiled area) — это 512 Мб заранее резервируемого виртуального адресного пространства, откуда передается и куда возвраща ется память, выделяемая под сегменты, которыми пользуются 16разрядные приложения. Для каждого процесса подсистема OS/2 ведет таблицу локаль ных дескрипторов (local descriptor table, LDT), в которой сегменты разделя емой памяти занимают один и тот же LDTслот для всех процессов OS/2. Рис. 2-5. Структура виртуальной памяти подсистемы OS/2 Как будет детально показано в главе 6, потоки являются элементами вы полняемой программы и, как таковые, подлежат планированию (подключе нию к процессору по определенной схеме). В OS/2 всего 64 уровня приори тетов (от 0 до 63), а в Windows — 32 (от 0 до 31). Несмотря на это, 64 уровня приоритетов OS/2 проецируются на динамические приоритеты Windows с 1го по 15й. Потоки OS/2, выполняемые в Windows, никогда не получают приоритеты реального времени (16–31). Как и подсистема POSIX, подсистема OS/2 автоматически запускается при первой активизации OS/2совместимого образа и продолжает выполняться до перезагрузки всей системы. Подробнее о выполнении приложений POSIX и OS/2 в Windows см. главу 6. Ntdll.dll Ntdll.dll — специальная библиотека системной поддержки, нужная в основ ном при использовании DLL подсистем. Она содержит функции двух типов:
68 ГЛ А В А 2 БЕЗОПАСНОСТЬ 쐽 интерфейсы диспетчера системных сервисов (system service dispatch stubs) к сервисам исполнительной системы Windows; 쐽 внутренние функции поддержки, используемые подсистемами, DLL под систем и другими компонентами операционной системы. Первая группа функций предоставляет интерфейс к сервисам исполни тельной системы Windows, которые можно вызывать из пользовательского режима. Таких функций более 200, например NtCreateFile, NtSetEvent и т. д. Как уже говорилось, большинство из них доступно через Windows API (од нако некоторые из них предназначены только для применения внутри са мой операционной системы). Для каждой из этих функций в Ntdll существует точка входа с тем же име нем. Код внутри функции содержит специфичную для конкретной аппарат ной архитектуры команду перехода в режим ядра для вызова диспетчера системных сервисов (о нем рассказывается в главе 3), который после про верки некоторых параметров вызывает уже настоящий сервис режима ядра из Ntoskrnl.exe. Ntdll также включает множество функций поддержки, например загруз чик образов (функции, имена которых начинаются с Ldr), диспетчер куч, функции для взаимодействия с процессом подсистемы Windows (функции, имена которых начинаются с Csr), а также универсальные процедуры биб лиотек периода выполнения (функции, имена которых начинаются с Rtl). Там же находится диспетчер APC (asynchronous procedure call) пользователь ского режима и диспетчер исключений. (Подробнее об APC и исключениях см. главу 3.) Исполнительная система Исполнительная система (executive) находится на верхнем уровне Ntoskrnl.exe (ядро располагается на более низком уровне). В ее состав входят функции следующего типа. 쐽 Экспортируемые функции, доступные для вызова из пользовательского режима. Эти функции называются системными сервисами и экспортиру ются через Ntdll. Большинство сервисов доступно через Windows API или API других подсистем окружения. Однако некоторые из них недоступны через документированные функции (примером могут служить LPC, функ ции запросов вроде NtQueryInformationProcess, специализированные фун кции типа NtCreatePagingFile и т. д.). 쐽 Функции драйверов устройств, вызываемые через функцию DeviceIoCont! rol. Последняя является универсальным интерфейсом от пользовательс кого режима к режиму ядра для вызова функций в драйверах устройств, не связанных с чтением или записью. 쐽 Экспортируемые функции, доступные для вызова только из режима ядра и документированные в Windows DDK или Windows Installable File System (IFS) Kit (см. www.microsoft.com/whdc/ddk/ifskit.default.mspx).
ГЛАВА 9 Архитектура системы 69 쐽 Экспортируемые функции, доступные для вызова только из режима ядра, но не описанные в Windows DDK или IFS Kit (например, функции, кото рые используются видеодрайвером, работающим на этапе загрузки, и чьи имена начинаются с Inbv). 쐽 Функции, определенные как глобальные, но не экспортируемые симво лы. Включают внутренние функции поддержки, вызываемые в Ntoskrnl; их имена начинаются с Iop (функции поддержки диспетчера вводавывода) или с Mi (функции поддержки управления памятью). 쐽 Внутренние функции в какомлибо модуле, не определенные как глобаль ные символы. Исполнительная система состоит из следующих основных компонентов (каждый из них подробно рассматривается в последующих главах книги). 쐽 Диспетчер конфигурации (см. главу 4), отвечающий за реализацию и уп равление системным реестром. 쐽 Диспетчер процессов и потоков (см. главу 6), создающий и завершающий процессы и потоки. Низкоуровневая поддержка процессов и потоков ре ализована в ядре Windows, а исполнительная система дополняет эти низ коуровневые объекты своей семантикой и функциями. 쐽 Монитор состояния защиты (см. главу 8), реализующий политики безо пасности на локальном компьютере. Он охраняет ресурсы операционной системы, осуществляя аудит и контролируя доступ к объектам в период выполнения. 쐽 Диспетчер ввода!вывода (см. главу 9), реализующий аппаратнонезави симый вводвывод и отвечающий за пересылку вводавывода нужным драйверам устройств для дальнейшей обработки. 쐽 Диспетчер Plug and Play (см. главу 9), определяющий, какие драйверы нужны для поддержки конкретного устройства, и загружающий их. Тре бования каждого устройства в аппаратных ресурсах определяются в про цессе перечисления. В зависимости от требований каждого устройства диспетчер PnP распределяет такие ресурсы, как порты вводавывода, IRQ, каналы DMA и области памяти. Он также отвечает за посылку соответству ющих уведомлений об изменениях в аппаратном обеспечении системы (при добавлении или удалении устройств). 쐽 Диспетчер электропитания (см. главу 9), который координирует собы тия, связанные с электропитанием, и генерирует уведомления системы управления электропитанием, посылаемые драйверам. Когда система не занята, диспетчер можно настроить на остановку процессора для сниже ния энергопотребления. Изменение энергопотребления отдельных уст ройств возлагается на их драйверы, но координируется диспетчером электропитания. 쐽 Подпрограммы WDM Windows Management Instrumentation (см. главу 4), позволяющие драйверам публиковать информацию о своих рабочих ха рактеристиках и конфигурации, а также получать команды от службы
70 ГЛ А В А 2 БЕЗОПАСНОСТЬ WMI пользовательского режима. Потребители информации WMI могут находиться как на локальной машине, так и на любом компьютере в сети. 쐽 Диспетчер кэша (см. главу 11), повышающий производительность фай лового вводавывода за счет сохранения в основной памяти дисковых данных, к которым недавно было обращение (это также уменьшает чис ло обращений к диску для записи, поскольку модифицированные данные предварительно накапливаются в памяти в течение определенного пери ода). Как вы увидите, диспетчер кэша выполняет эту задачу, используя поддержку проецируемых файлов со стороны диспетчера памяти. 쐽 Диспетчер памяти (см. главу 7), реализующий виртуальную память — схему управления памятью, позволяющую выделять каждому процессу большое закрытое адресное пространство, объем которого может превы шать доступную физическую память. Диспетчер памяти также обеспечи вает низкоуровневую поддержку диспетчера кэша. 쐽 Средство логической предвыборки (см. главу 7), ускоряющее запуск сис темы и процессов за счет оптимизации загрузки данных, к которым про исходит обращение при запуске системы или процессов. Кроме того, в состав исполнительной системы входят четыре основные группы функций поддержки, используемые вышеперечисленными компо нентами. Примерно треть из них описана в DDK, поскольку драйверы тоже используют их. Вот что представляют собой четыре категории функций под держки. 쐽 Диспетчер объектов — создает, управляет и удаляет объекты и абстракт ные типы данных исполнительной системы, используемые для представ ления таких ресурсов операционной системы, как процессы, потоки и различные синхронизирующие объекты. Подробнее о диспетчере объек тов см. главу 3. 쐽 Механизм LPC (см. главу 3) — передает сообщения между клиентским и серверным процессами на одном компьютере. LPC является гибкой, оп тимизированной версией RPC (remote procedure call), стандартного ме ханизма взаимодействия между клиентскими и серверными процессами через сеть. 쐽 Большой набор стандартных библиотечных функций для обработки строк, арифметических операций, преобразования типов данных и обра ботки структур безопасности. 쐽 Подпрограммы поддержки исполнительной системы, например для вы деления системной памяти (пулов подкачиваемых и неподкачиваемых страниц), доступа к памяти со взаимоблокировкой, а также два специаль ных типа синхронизирующих объектов: ресурс (resource) и быстродей ствующий мьютекс (fast mutex).
ГЛАВА 9 Архитектура системы 71 Ядро Ядро состоит из набора функций в Ntoskrnl.exe, предоставляющих фунда ментальные механизмы (в том числе планирования потоков и синхрониза ции), которые используются компонентами исполнительной системы и низ коуровневыми аппаратнозависимыми средствами поддержки (диспетчери зации прерываний и исключений), различными в каждой процессорной архитектуре. Код ядра написан в основном на С, а ассемблер использовали лишь для решения специфических задач, трудно реализуемых на С. Как и функции поддержки исполнительной системы, упоминавшиеся в предыдущем разделе, часть функций ядра описана в DDK (см. функции, чьи имена начинаются с Ke), поскольку они необходимы для реализации драй веров устройств. Объекты ядра Ядро состоит из низкоуровневых, четко определенных и хорошо предска зуемых примитивов и механизмов операционной системы, позволяющих компонентам исполнительной системы более высокого уровня выполнять свои функции. Ядро отделено от остальной части исполнительной системы; оно реализует системные механизмы и не участвует в принятии решений, связанных с системной политикой. Практически все такие решения, кроме планирования и диспетчеризации потоков, принимаются исполнительной системой. Вне ядра исполнительная система представляет потоки и другие разде ляемые ресурсы в виде объектов. Управление этими объектами требует оп ределенных издержек, так как нужны описатели, позволяющие манипулиро вать объектами, средства защиты и квоты ресурсов, резервируемых при их создании. В ядре можно избежать таких издержек, поскольку оно реализует набор более простых объектов, называемых объектами ядра (kernel objects). Эти объекты позволяют ядру контролировать обработку данных процессо ром и поддерживают объекты исполнительной системы. Большинство объектов уровня исполнительной системы инкапсулирует один или более объектов ядра, включая в себя их атрибуты, определенные ядром. Одна из групп объектов ядра, называемых управляющими (control objects), определяет семантику управления различными функциями операционной системы. В эту группу входят объекты APC, DPC (deferred procedure call) и несколько объектов, используемых диспетчером вводавывода (например, объект прерывания). Другая группа объектов под названием объекты диспетчера (dispatcher objects) реализует средства синхронизации, позволяющие изменять плани рование потоков. В группу таких объектов входят поток ядра (kernel thread), мьютекс (mutex), событие (event), семафор (semaphore), таймер (timer), ожи даемый таймер (waitable timer) и некоторые другие. С помощью функций ядра исполнительная система создает объекты ядра, манипулирует ими и конструирует более сложные объекты, предоставляемые в пользовательском
72 ГЛ А В А 2 БЕЗОПАСНОСТЬ режиме. Объекты подробно рассматриваются в главе 3, а процессы и пото ки — в главе 6. Поддержка оборудования Другая важная задача ядра — абстрагирование или изоляция исполнитель ной системы и драйверов устройств от различий между аппаратными архи тектурами, поддерживаемыми Windows (т. е. различий в обработке преры ваний, диспетчеризации исключений и синхронизации между несколькими процессорами). Архитектура ядра нацелена на максимальное обобщение кода — даже в случае аппаратнозависимых функций. Ядро поддерживает набор семанти чески идентичных и переносимых между архитектурами интерфейсов. Боль шая часть кода, реализующего переносимые интерфейсы, также идентична для разных архитектур. Но одна часть этих интерфейсов поразному реализуется на разных ар хитектурах, а другая включает код, специфичный для конкретной архитек туры. Архитектурнонезависимые интерфейсы могут быть вызваны на лю бой машине, причем семантика интерфейса будет одинаковой — независи мо от специфического кода для той или иной архитектуры. Некоторые ин терфейсы ядра (например, процедуры спинблокировки, описанные в гла ве 3) на самом деле реализуются в HAL (см. следующий раздел), поскольку их реализация может отличаться даже в пределах семейства процессоров с одинаковой архитектурой. В ядре также содержится небольшая порция кода с х86специфичными интерфейсами, необходимыми для поддержки старых программ MSDOS. Эти интерфейсы не являются переносимыми в том смысле, что их нельзя вызывать на машине с другой архитектурой, где они попросту отсутствуют. Этот х86специфичный код, например, поддерживает манипуляции с GDT (global descriptor tables) и LDT (local descriptor tables) — аппаратными сред ствами x86. Другим примером архитектурноспецифичного кода ядра может служить интерфейс, предоставляющий поддержку буфера трансляции и процес сорного кэша. Эта поддержка требует разного кода на разных архитектурах, поскольку кэш в них реализуется различным образом. Еще один пример — переключение контекста. Хотя на высоком уровне для выбора потоков и переключения контекста применяется один и тот же алгоритм (сохраняется контекст предыдущего потока, загружается контекст нового и запускается новый поток), существуют архитектурные различия между его реализациями для разных процессоров. Поскольку контекст опи сывается состоянием процессора (его регистров и т. д.), сохраняемая и заг ружаемая информация зависит от архитектуры. Уровень абстрагирования от оборудования Как отмечалось в начале этой главы, одной из важнейших особенностей архи тектуры Windows является переносимость между различными аппаратными
ГЛАВА 9 Архитектура системы 73 платформами. Ключевой компонент, обеспечивающий такую переносимость, — уровень абстрагирования от оборудования (hardware abstraction layer, HAL). HAL — это загружаемый модуль режима ядра (Hal.dll), предоставляющий низ коуровневый интерфейс с аппаратной платформой, на которой выполняется Windows. Он скрывает от операционной системы специфику конкретной ап паратной платформы, в том числе ее интерфейсов вводавывода, контроллеров прерываний и механизмов взаимодействия между процессорами, т. е. все функ ции, зависимые от архитектуры и от конкретной машины. Когда внутренним компонентам Windows и драйверам устройств нужна платформеннозависимая информация, они обращаются не к самому обо рудованию, а к подпрограммам HAL, что и обеспечивает переносимость этой операционной системы. По этой причине подпрограммы HAL документиро ваны в Windows DDK, где вы найдете более подробные сведения о HAL и о его использовании драйверами. Хотя в Windows имеется несколько модулей HAL (см. таблицу 26), при ус тановке на жесткий диск компьютера копируется только один из них — Hal.dll. (В других операционных системах, например в VMS, нужный модуль HAL вы бирается при загрузке системы.) Поскольку для поддержки разных процессо ров требуются разные модули HAL, системный диск от одной х86установки скорее всего не подойдет для загрузки системы с другим процессором. Таблица 2-6. Список модулей HAL для x86 в \Windows\Driver\Cache\i386\Driver.cab Имя файла HAL Поддерживаемые системы Hal.dll Стандартные персональные компьютеры (ПК) Halacpi.dll ПК с ACPI (Advanced Configuration and Power Interface) Halapic.dll ПК с APIC (Advanced Programmable Interrupt Controller) Halaacpi.dll ПК с APIC и ACPI Halmps.dll Многопроцессорные ПК Halmacpi.dll Многопроцессорные ПК с ACPI Halborg.dll Рабочие станции Silicon Graphics (только для Windows 2000; больше не продаются) Halsp.dll Compaq SystemPro (только для Windows XP) ПРИМЕЧАНИЕ В базовой системе Windows Server 2003 нет HAL, специ фических для конкретных вендоров. ЭКСПЕРИМЕНТ: просмотр базовых HAL, включенных в Windows Для просмотра HAL, включенных в Windows, откройте файл Driver.cab в соответствующем подкаталоге, специфичном для конкретной архи тектуры, в каталоге \Windows\Driver Cache. (Например, для систем x86 имя этого файла — \Windows\Driver Cache\i386\Driver.cab.) Прокрути те список до файлов, начинающихся с «Hal», и вы увидите файлы, пе речисленные в таблице 26.
74 ГЛ А В А 2 БЕЗОПАСНОСТЬ ЭКСПЕРИМЕНТ: определяем используемый модуль HAL Определить, какой модуль HAL используется на вашей машине, мож но двумя способами. 1. Откройте файл \Windows\Repair\Setup.log, найдите строку с Hal.dll. Имя файла, стоящее в этой строке после знака равенства, соответ ствует имени модуля HAL, извлеченного из Driver.cab с дистрибу тивного носителя. 2. Откройте Device Manager (Диспетчер устройств): щелкните правой кнопкой мыши значок My Computer (Мой компьютер) на рабочем столе, выберите команду Properties (Свойства), откройте вкладку Hardware (Оборудование) и щелкните кнопку Device Manager (Дис петчер устройств). Проверьте имя «драйвера» для устройства Com puter (Компьютер). ЭКСПЕРИМЕНТ: просмотр зависимостей NTOSKRNL и HAL Вы можете просмотреть взаимосвязи образов ядра и HAL, изучив их таблицы импорта и экспорта с помощью утилиты Dependency Walker (Depends.exe), которая содержится в Windows Support Tools и Platform SDK. Для исследования файла в Dependency Walker откройте его ко мандой Open из меню File. Вот пример вывода этой утилиты при просмотре зависимостей в Ntoskrnl. Обратите внимание, что Ntoskrnl связан с HAL, который в свою оче редь связан с Ntoskrnl (оба используют функции друг у друга). Ntoskrnl также связан с Bootvid.dll, видеодрайвером, используемым для вывода заставки при запуске Windows. В Windows XP и выше вы увидите в списке дополнительную DLL, Kdcom.dll. Она содержит код инфра структуры отладчика ядра, который раньше был частью Ntoskrnl.exe. Подробное описание информации, выводимой Dependency Walker, см. в справочном файле этой утилиты (Depends.hlp).
ГЛАВА 9 Архитектура системы 75 Драйверы устройств Драйверы устройств подробно описываются в главе 9, а здесь мы даем крат кий обзор их типов и поясняем, как перечислить установленные драйверы, загруженные в системе. Драйверы устройств являются загружаемыми модулями режима ядра (как правило, это файлы с расширением .sys); они образуют интерфейс между диспетчером вводавывода и соответствующим оборудованием. Эти драйве ры выполняются в режиме ядра в одном из трех контекстов: 쐽 в контексте пользовательского потока, инициировавшего функцию вво давывода; 쐽 в контексте системного потока режима ядра; 쐽 как результат прерывания (а значит, не в контексте какоголибо процес са или потока, который был текущим на момент прерывания). Как было сказано в предыдущем разделе, в Windows драйверы устройств не управляют оборудованием напрямую — вместо этого они вызывают функ ции HAL. Драйверы, как правило, пишутся на С (иногда на С++), поэтому при правильном использовании процедур HAL они являются переносимыми между поддерживаемыми Windows архитектурами на уровне исходного кода, а на уровне двоичных файлов — внутри семейства с одинаковой архи тектурой. Существует несколько типов драйверов устройств. 쐽 Драйверы аппаратных устройств, которые управляют (через HAL) обо рудованием, записывают на них выводимые данные и получают вводимые данные от физического устройства или из сети. Есть множество типов таких драйверов — драйверы шин, интерфейсов, устройств массовой па мяти и т. д. 쐽 Драйверы файловой системы — это драйверы Windows, принимающие запросы на файловый вводвывод и транслирующие их в запросы ввода вывода для конкретного устройства. 쐽 Драйверы фильтра файловой системы, которые обеспечивают зеркали рование и шифрование дисков, перехват вводавывода и некоторую до полнительную обработку информации перед передачей ее на следующий уровень. 쐽 Сетевые редиректоры и серверы, являющиеся драйверами файловых си стем, которые передают запросы файловой системы на вводвывод дру гим компьютерам в сети и принимают от них аналогичные запросы. 쐽 Драйверы протоколов, реализующие сетевые протоколы вроде TCP/IP, NetBEUI и IPX/SPX. 쐽 Драйверы потоковых фильтров ядра, действующие по цепочке для об работки потоковых данных, например при записи и воспроизведении аудио и видеоинформации. Поскольку установка драйвера устройства — единственный способ добав ления в систему стороннего кода режима ядра, некоторые программисты
76 ГЛ А В А 2 БЕЗОПАСНОСТЬ пишут драйверы просто для того, чтобы получить доступ к внутренним функ циям или структурам данных операционной системы, недоступным из поль зовательского режима (но документированным и поддерживаемым в DDK). Например, многие утилиты с www.sysinternals.com представляют собой ком бинацию GUIприложений Windows с драйверами устройств, используемы ми для сбора сведений о состоянии внутрисистемных структур и вызова функций, доступных только в режиме ядра. Усовершенствования в модели драйверов Windows В Windows 2000 была введена поддержка Plug and Play и энергосберегающих технологий, а также расширена модель драйверов Windows NT, называемая Windows Driver Model (WDM). Windows 2000 и более поздние версии могут работать с унаследованными драйверами Windows NT 4, но, поскольку они не поддерживают Plug and Play и энергосберегающие технологии, функци ональность системы в этом случае будет ограничена. С точки зрения WDM, существует три типа драйверов. 쐽 Драйвер шины (bus driver), обслуживающий контроллер шины, адаптер, мост или любые другие устройства, имеющие дочерние устройства. Драй веры шин нужны для работы системы и в общем случае поставляются Microsoft. Для каждого типа шины (PCI, PCMCIA и USB) в системе имеет ся свой драйвер. Сторонние разработчики создают драйверы для поддерж ки новых шин вроде VMEbus, Multibus и Futurebus. 쐽 Функциональный драйвер (function driver) — основной драйвер устрой ства, предоставляющий его функциональный интерфейс. Обязателен, кроме тех случаев, когда устройство используется без драйверов (т. е. вводвывод осуществляется драйвером шины или драйверами фильтров шины, как в случае SCSI PassThru). Функциональный драйвер по опреде лению обладает наиболее полной информацией о своем устройстве. Обычно только этот драйвер имеет доступ к специфическим регистрам устройства. 쐽 Драйвер фильтра (filter driver), поддерживающий дополнительную функ циональность устройства (или существующего драйвера) или изменяю щий запросы на вводвывод и ответы на них от других драйверов (это часто используется для коррекции устройств, предоставляющих невер ную информацию о своих требованиях к аппаратным ресурсам). Такие драйверы не обязательны, и их может быть несколько. Они могут рабо тать как на более высоком уровне, чем функциональный драйвер или драйвер шины, так и на более низком. Обычно эти драйверы предостав ляются OEMпроизводителями или независимыми поставщиками обору дования (IHV). В среде WDM один драйвер не может контролировать все аспекты уст ройства: драйвер шины информирует диспетчер PnP об устройствах, под ключенных к шине, в то время как функциональный драйвер управляет уст ройством.
ГЛАВА 9 Архитектура системы 77 В большинстве случаев драйвер фильтра более низкого уровня модифи цирует поведение устройства. Например, если устройство сообщает драйве ру своей шины о том, что ему нужно 4 порта вводавывода, тогда как на са мом деле ему требуется 16, драйвер фильтра может перехватить список ап паратных ресурсов, направляемый драйвером шины диспетчеру PnP и ис править число портов. Драйвер фильтра более высокого уровня обычно придает устройству до полнительную функциональность. Так, высокоуровневый драйвер фильтра для клавиатуры может обеспечивать дополнительную защиту. Обработка прерываний описывается в главе 3. Подробнее о диспетчере вво давывода, WDM, Plug and Play и энергосберегающих технологиях см. главу 9. ЭКСПЕРИМЕНТ: просмотр установленных драйверов устройств Чтобы вывести список установленных драйверов, запустите оснастку Computer Management (Управление компьютером). Для этого выбери те из меню Start (Пуск) команду Programs (Программы), затем Admi nistrative Tools (Администрирование) и Computer Management (Управ ление компьютером) или откройте Control Panel (Панель управления) и дважды щелкните значок Computer Management. В окне Computer Management раскройте System Information (Сведения о системе), затем Software Environment (Программная среда) и Drivers (Драйверы). Ниже приведен пример списка драйверов. В этом окне выводится список драйверов, определенных в реест ре, а также их тип и состояние — Running (Работает) или Stopped (Ос тановлена). Драйверы устройств и процессы Windowsсервисов опре деляются в разделе реестра HKLM\SYSTEM\CurrentControlSet\Services. Однако они отличаются по коду типа, например 1 соответствует драй веру режима ядра. (Полный список хранящихся в реестре сведений, которые относятся к драйверам, см. в таблице 47.) Список загруженных в текущий момент драйверов можно просмот реть и с помощью утилиты Drivers (Drivers.exe в ресурсах Windows 2000) или Pstat (Pstat.exe в Windows XP Support Tools, Windows Server 2003 Support Tools, ресурсах Windows 2000 и Platform SDK). Ниже при веден листинг части выходной информации утилиты Drivers. см. след. стр.
78 ГЛ А В А 2 БЕЗОПАСНОСТЬ C:\>drivers ModuleName Code Data Bss Paged Init LinkDate ———————————————————————————————— ntoskrnl.exe 429184 96896 0 775360 138880 Tue Dec 07 18:41:11 1999 hal.dll 25856 6016 0 16160 10240 Tue Nov 02 20:14:22 1999 BOOTVID.DLL 5664 2464 0 0 320 Wed Nov 03 20:24:33 1999 ACPI.sys 92096 8960 0 43488 4448 Wed Nov 10 20:06:04 1999 WMILIB.SYS 512 0 0 1152 192 Sat Sep 25 14:36:47 1999 pci.sys 12704 1536 0 31264 4608 Wed Oct 27 19:11:08 1999 isapnp.sys 14368 832 0 22944 2048 Sat Oct 02 16:00:35 1999 compbatt.sys 2496 0 0 2880 1216 Fri Oct 22 18:32:49 1999 BATTC.SYS 800 0 0 2976 704 Sun Oct 10 19:45:37 1999 intelide.sys 1760 32 0 0 128 Thu Oct 28 19:20:03 1999 PCIIDEX.SYS 4544 480 0 10944 1632 Wed Oct 27 19:02:19 1999 pcmcia.sys 32800 8864 0 23680 6240 Fri Oct 29 19:20:08 1999 ftdisk.sys 4640 32 0 95072 3392 Mon Nov 22 14:36:23 1999 ———————————————————————————————— Total 4363360 580320 0 3251424 432992 Утилита перечисляет все загруженные компоненты режима ядра (Ntoskrnl, HAL и драйверы устройств) и сообщает размеры разделов в каждом образе. Pstat также выводит список загруженных драйверов, но только пос ле списка процессов и потоков в каждом процессе. Она показывает один вид очень важной информации, не сообщаемой утилитой Drivers: адрес загрузки модуля в системном пространстве. Как вы еще увиди те, этот адрес нужен для увязки выполняемых системных потоков с драйвером, в котором они существуют. Недокументированные интерфейсы Просмотр имен экспортируемых или глобальных символов в ключе вых системных файлах (Ntoskrnl.exe, Hal.dll или Ntdll.dll) может ока заться полезным: вы получите представление о том, что умеет делать Windows в сравнении с документированной и поддерживаемой час тью. Конечно, знание имен этих функций еще не означает, что вы смо жете или должны их вызывать. Эти интерфейсы не документированы и могут быть изменены. Мы предлагаем рассмотреть эти функции только для лучшего понимания внутренних функций Windows, а не для обхода поддерживаемых интерфейсов. Например, просмотрев список функций в Ntdll.dll, вы сможете срав нить список всех системных сервисов, которые Windows предостав ляет DLLмодулям подсистем пользовательского режима, с их подмно жеством, предоставляемым каждой подсистемой. Хотя многие из этих функций точно соответствуют документированным и поддерживае мым Windowsфункциям, некоторые из них недоступны через Win dows API (см. статью «Inside the Native API» на www.sysinternals.com).
ГЛАВА 9 Архитектура системы 79 С другой стороны, было бы интересно выяснить, что импортиру ют DLLмодули подсистемы Windows (скажем, Kernel32.dll или Adva pi32.dll) и какие функции они вызывают в Ntdll. Также представляет интерес содержимое Ntoskrnl.exe: хотя в Windows DDK документированы многие экспортируемые подпрограммы, исполь зуемые драйверами режима ядра, немалая их часть не описана. Возмож но, вас заинтересует содержимое таблицы импорта для Ntoskrnl и HAL, где перечислены функции HAL, используемые Ntoskrnl, и наоборот. В таблице 27 приведено большинство общеупотребительных пре фиксов имен функций в компонентах исполнительной системы. В каж дом из таких компонентов также используются слегка модифицирован ные префиксы, обозначающие внутренние функции: либо за первой буквой префикса указывается i (от internal), либо префикс заканчива ется на букву p (от private). Так, Ki относится к внутренним функциям ядра, а Psp — к внутренним функциям поддержки процессов. Таблица 2-7. Общеупотребительные префиксы Префикс Компонент Cc Диспетчер кэша Cm Диспетчер конфигурации Ex Подпрограммы поддержки исполнительной системы FsRtl Библиотека (периода выполнения) драйвера файловой системы Hal HAL Io Диспетчер вводавывода Ke Ядро Lpc LPC Lsa Локальная аутентификация Mm Диспетчер памяти Nt Системные сервисы Windows (большинство из них экспортируется как Windowsфункции) Ob Диспетчер объектов Po Диспетчер электропитания Pp Диспетчер PnP Ps Поддержка процессов Rtl Стандартная библиотека (периода выполнения) Se Защита Wmi Windows Management Instrumentation (Инструментарий управления Windows) Zw Зеркальная точка входа для системных сервисов (имена которых начинаются с Nt), устанавливающих предыдущий режим доступа к ядру. При этом параметры не контролиру ются, так как Ntсервисы проверяют параметры только при переключении из пользовательского режима см. след. стр.
80 ГЛ А В А 2 БЕЗОПАСНОСТЬ Понимая схему именования системных процедур Windows, рас шифровывать имена экспортируемых функций гораздо легче. Общий формат выглядит так: <префикс><операция><объект> где префикс — внутренний компонент, экспортирующий процедуру, операция — название операции, выполняемой над объектом или ре сурсом, а объект — объект, над которым проводится эта операция. Например, ExAllocatePoolWithTag является процедурой поддержки исполнительной системы, которая выделяет память из пула подкачива емых или неподкачиваемых страниц. KeInitializeThread представляет собой процедуру для создания и инициализации объекта ядра «поток». Системные процессы В каждой системе Windows выполняются перечисленные ниже процессы. (Два из них, Idle и System, не являются процессами в строгом смысле этого слова, поскольку они не выполняют какойлибо код пользовательского ре жима.) 쐽 Процесс Idle (включает по одному потоку на процессор для учета време ни простоя процессора). 쐽 Процесс System (содержит большинство системных потоков режима ядра). 쐽 Диспетчер сеансов (Smss.exe). 쐽 Подсистема Windows (Csrss.exe). 쐽 Процесс входа в систему (Winlogon.exe). 쐽 Диспетчер управления сервисами (Services.exe) и создаваемые им дочер ние процессы сервисов (например, универсальный процесс для хостин га сервисов, Svchost.exe). 쐽 Серверный процесс локальной аутентификации (Lsass.exe). Чтобы понять взаимоотношения этих процессов, полезно просмотреть «дерево» процессов, отражающее связи между родительскими и дочерними процессами. Увидев, кем создается тот или иной процесс, вам будет легче понять, откуда берется каждый процесс. На рис. 26 показана часть экранно го снимка дерева процессов с комментариями по нескольким первым про цессам. (Process Explorer позволяет добавлять комментарии для индивидуаль ных процессов и выводить их как дополнительную колонку в окне.) В следующих разделах поясняются основные системные процессы, пере численные на рис. 26. Хотя в этих разделах дается краткое описание по следовательности запуска данных процессов, подробно все этапы загрузки Windows рассматриваются в главе 5.
ГЛАВА 9 Рис. 2-6. Архитектура системы 81 Начальное дерево системных процессов Процесс Idle Первый процесс, показанный на рис. 26, является процессом простоя сис темы (system idle process). Как будет показано в главе 6, процессы идентифи цируются по именам их образов. Однако этот процесс (как и процесс Sys tem) не выполняет реальный код пользовательского режима (в том смысле, что в каталоге \Windows нет «System Idle Process.exe»). Кроме того, разные утилиты изза особенностей реализации поразному именуют его. В табли це 28 приводится несколько имен процесса Idle (с идентификатором 0); подробнее о нем рассказывается в главе 6. Таблица 2-8. Имена процесса с идентификатором 0, сообщаемые различными утилитами Утилита Имя процесса с идентификатором 0 Task Manager System Idle Process Process Viewer (Pviewer.exe) Idle Process Status (Pstat.exe) Idle Process Process Explode (Pview.exe) System Process Task List (Tlist.exe) System Process QuickSlice (Qslice.exe) Systemprocess А теперь рассмотрим системные потоки и предназначение каждого сис темного процесса, выполняющего реальный код. Прерывания и DPC Две строки, помеченные как Interrupts и DPCs, отражают время, затраченное на обслуживание прерываний и обработку отложенных вызовов процедур (deferred procedure calls, DPC). Эти механизмы объясняются в главе 3. Заметь те: хотя Process Explorer показывает эти строки в списке процессов, они не имеют отношения к процессам. Они выводятся потому, что ведут учет про цессорного времени, не выделенного какомулибо процессу. Но Task Manager (Диспетчер задач) рассматривает время, затраченное на обработку преры
82 ГЛ А В А 2 БЕЗОПАСНОСТЬ ваний и DPC, как время простоя системы. Поэтому система, занятая интен сивной обработкой прерываний, будет выглядеть в Task Manager так, будто она ничем не занимается. Процесс System и его потоки Процесс System (с идентификатором 8 в Windows 2000 и идентификатором 4 в Windows XP и Windows Server 2003) служит носителем особых потоков, работающих только в режиме ядра, — системных потоков режима ядра (kernelmode system threads). У системных потоков имеются все атрибуты и контексты обычных потоков пользовательского режима (например, кон текст оборудования, приоритет и т. д.), но они отличаются тем, что выпол няются только в режиме ядра внутри системного кода, загруженного в сис темное пространство, — будь то Ntoskrnl.exe или какойлибо драйвер уст ройства. Кроме того, у системных потоков нет адресного пространства поль зовательского процесса, и поэтому нужная им динамическая память выделя ется из куч памяти операционной системы, например из пула подкачивае мых или неподкачиваемых страниц. Системные потоки создаются функцией PsCreateSystemThread (докумен тирована в DDK), вызываемой только в режиме ядра. Windows, как и драй веры устройств, создает системные потоки при инициализации системы для выполнения действий, требующих получения контекста потока, например для выдачи и ожидания запросов на вводвывод или опроса устройства. Ска жем, диспетчер памяти использует системные потоки для реализации таких функций, как запись измененных страниц в страничный файл (page file) или в спроецированные файлы, загрузки процессов в память или выгрузки из нее и т. д. Ядро создает системный поток под названием «диспетчер настройки баланса» (balance set manager), активизируемый раз в секунду для инициа ции при необходимости различных событий, связанных с планированием и управлением памятью. Диспетчер кэша также использует системные пото ки для реализации как опережающего чтения, так и отложенной записи. Драйвер файлсервера (Srv.sys) с помощью системных потоков отвечает на сетевые запросы вводавывода применительно к файлам на общих дисковых разделах, доступных в сети. Даже драйвер дисковода гибких дисков создает свой системный поток для опроса этого устройства (это повышает эффек тивность опроса, потому что драйвер дисковода гибких дисков, управляемый прерываниями, расходует много системных ресурсов). Подробнее о конк ретных системных потоках см. главы, где рассматриваются соответствующие компоненты. По умолчанию владельцем системных потоков является процесс System, но драйверы могут создавать системные потоки в любом процессе. Напри мер, драйвер подсистемы Windows (Win32k.sys) создает системные потоки в процессе подсистемы Windows (Csrss.exe), чтобы облегчить доступ к дан ным в адресном пространстве этого процесса в пользовательском режиме. Если вы занимаетесь поиском причин неполадок или системным анали зом, полезно сопоставить выполнение индивидуальных системных потоков
ГЛАВА 9 Архитектура системы 83 с создавшими их драйверами или даже с подпрограммой, содержащей соот ветствующий код. Так, на сильно загруженном файлсервере процесс System скорее всего потребляет значительную часть процессорного времени. Но для определения того, какой именно драйвер или компонент операционной системы выполняется, просто знать, что процесс System в данный момент выполняет «какойто системный поток», недостаточно. Так что, если в процессе System выполняются потоки, сначала определи те, какие это потоки (например, с помощью оснастки Performance). Найдя такой поток (или потоки), посмотрите, в каком драйвере началось выпол нение системного потока (это по крайней мере укажет на наиболее веро ятного создателя потока), либо проанализируйте стек вызовов (или хотя бы текущий адрес) интересующего вас потока, что позволит определить, в ка ком месте он сейчас выполняется. Оба этих метода демонстрируются следующими экспериментами. ЭКСПЕРИМЕНТ: идентификация системных потоков в процессе System Вы можете убедиться, что потоки внутри процесса System должны быть потоками режима ядра, поскольку стартовый адрес каждого из них больше адреса начала системного пространства (которое по умол чанию начинается с 0x80000000, если система загружена без парамет ра /3GB в Boot.ini). Кроме того, обратив внимание на процессорное время, выделяемое этим потокам, вы увидите, что они занимают про цессорное время только при выполнении в режиме ядра. Чтобы опре делить драйвер, создавший системный поток, найдите стартовый ад рес потока (с помощью Pviewer.exe) и ищите драйвер с базовым адре сом, ближайшим (с меньшей стороны) к этому стартовому адресу. Ути лита Pstat в конце своих выходных данных, как и команда !drivers от ладчика ядра, сообщает базовые адреса каждого загруженного драйве ра устройства. Чтобы быстро найти текущий адрес потока, воспользуйтесь коман дой !stacks 0 отладчика ядра. Ниже приводится образец вывода, полу ченный на работающей системе с помощью LiveKd. kd> !stacks 0 Proc.Thread Thread ThreadState Blocker [System] 8.000004 8146edb0 BLOCKED ntoskrnl!MmZeroPageThread+0x5f 8.00000c 8146e730 BLOCKED ?? Kernel stack not resident ?? 8.000010 8146e4b0 BLOCKED ntoskrnl!ExpWorkerThread+0x73 8.000014 8146d030 BLOCKED ?? Kernel stack not resident ?? 8.000018 8146ddb0 BLOCKED ntoskrnl!ExpWorkerThread+0x73 8.00001c 8146db30 BLOCKED ntoskrnl!ExpWorkerThread+0x73 8.000020 8146d8b0 BLOCKED ntoskrnl!ExpWorkerThread+0x73 8.000024 8146d630 BLOCKED ntoskrnl!ExpWorkerThread+0x73 8.000028 8146d3b0 BLOCKED ntoskrnl!ExpWorkerThread+0x73 8.00002c 8146c030 BLOCKED ntoskrnl!ExpWorkerThread+0x73 см. след. стр.
84 ГЛ А В А 2 8.000030 8.000034 8.000038 8.00003c 8.000040 8.000044 8.000048 8.00004c 8.000050 8.000054 8.000058 8.00005c 8.000060 8.000070 8.000074 8.00006c 8.000080 8.000084 8.00008c 8.00015c 8.000160 8.000178 8.0002d0 8.0002d4 8.000404 8.000430 8.00069c БЕЗОПАСНОСТЬ 8146cdb0 8146b470 8146b1f0 8146a030 8146adb0 8146a5b0 8146a330 81461030 8143a770 81439730 81436c90 813d9170 813d8030 8139c850 8139c5d0 81384030 81333330 813330b0 81321db0 81205570 81204570 811fcdb0 811694f0 81168030 811002b0 810f4990 80993030 BLOCKED BLOCKED BLOCKED BLOCKED BLOCKED BLOCKED BLOCKED BLOCKED BLOCKED BLOCKED BLOCKED BLOCKED BLOCKED BLOCKED BLOCKED BLOCKED BLOCKED BLOCKED BLOCKED BLOCKED BLOCKED BLOCKED BLOCKED BLOCKED BLOCKED READY READY ntoskrnl!ExpWorkerThreadBalanceManager+0x55 ntoskrnl!MiDereferenceSegmentThread+0x44 ntoskrnl!MiModifiedPageWriterWorker+0x31 ntoskrnl!KeBalanceSetManager+0x7e ntoskrnl!KeSwapProcessOrStack+0x24 ntoskrnl!FsRtlWorkerThread+0x33 ntoskrnl!FsRtlWorkerThread+0x33 ACPI!ACPIWorker+0x46 ntoskrnl!MiMappedPageWriter+0x4d dmio!voliod_loop+0x399 NDIS!ndisWorkerThread+0x22 ltmdmntt!WakeupTimerThread+0x27 ltmdmntt!WriteRegistryThread+0x1c raspptp!MainPassiveLevelThread+0x78 raspptp!PacketWorkingThread+0xc0 rasacd!AcdNotificationRequestThread+0xd8 rdbss!RxpWorkerThreadDispatcher+0x6f rdbss!RxSpinUpRequestsDispatcher+0x58 ?? Kernel stack not resident ?? INO_FLTR+0x68bd INO_FLTR+0x80e9 irda!RxThread+0xfa ?? Kernel stack not resident ?? ?? Kernel stack not resident ?? rdbss!RxpWorkerThreadDispatcher+0x6f parallel!ParallelThread+0x3e rdbss!RxpWorkerThreadDispatcher+0x6f В первом столбце выводятся идентификаторы процесса и потока (в виде «Идентификатор процесса. Идентификатор потока»). Во вто ром сообщается текущий адрес потока, в третьем — состояние пото ка: ожидает, готов или выполняется (о состояниях потоков см. главу 6). В последнем столбце показывается адрес вершины стека потока. Эта информация помогает определить драйвер, в котором началось вы полнение того или иного потока. Имя функции потока в Ntoskrnl дает дополнительную подсказку о том, что именно делает поток. Однако, если выполняемый поток является одним из рабочих по токов системы (ExpWorkerThread), вы не сможете точно сказать, что он делает, поскольку любой драйвер может давать задания рабочему потоку системы. В этом случае единственный выход — поставить точку прерывания в ExQueueWorkItem. По достижении этой точки введите !dso work_queue_item esp+4. Эта команда даст вам первый аргумент функции ExQueueWorkItem, представляющий собой указатель на струк туру рабочего элемента, которая в свою очередь содержит адрес про цедуры рабочего потока, вызываемой в его контексте. В качестве аль тернативы можно использовать команду k отладчика ядра, которая сообщает текущее содержимое стека вызовов. А это подскажет, какой драйвер отправил задание рабочему потоку.
ГЛАВА 9 Архитектура системы 85 ЭКСПЕРИМЕНТ: увязка системного потока с драйвером устройства В этом эксперименте мы посмотрим, как увязать активность процес сора в процессе System с системным потоком (и драйвером, к которо му он относится), вызывающим эту активность. Это важно: чтобы по настоящему понять, что происходит, нужно перейти на уровень пото ков процесса System. В данном случае мы вызовем активность систем ного потока, создав нагрузку файлового сервера на компьютере. (Драйвер файлсервера Srv.sys создает системные потоки для обработ ки входящих запросов на файловый вводвывод. Подробнее об этом компоненте см. главу 13.) 1. Откройте окно командной строки. 2. Создайте список всех каталогов на диске C, используя сетевой путь для доступа к этому диску. Например, если имя вашего компьюте ра — COMPUTER1, введите dir \\computer1\c$ /s. (Ключ /s застав ляет перечислять все подкаталоги.) 3. Запустите Process Explorer и дважды щелкните процесс System. 4. Откройте вкладку Threads. 5. Отсортируйте список по столбцу CSwitch Delta (разница по числу переключений контекста). Вы должны увидеть один или более по токов в Srv.sys, как показано на следующей иллюстрации. Если вы видите работающий системный поток и не уверены, какой это драйвер, нажмите кнопку Module, которая открывает окно свойств для файла. Например, нажатие кнопки Module при выбранном, как на предыдущей иллюстрации, потоке в Srv.sys выводит результаты в сле дующем окне. см. след. стр.
86 ГЛ А В А 2 БЕЗОПАСНОСТЬ Диспетчер сеансов (Smss) Диспетчер сеансов (Session Manager) (\Windows\System32\Smss.exe) являет ся первым процессом пользовательского режима, создаваемым в системе. Он порождается системным потоком режима ядра, отвечающим за последний этап инициализации исполнительной системы и ядра. Диспетчер сеансов отвечает за некоторые важные этапы запуска Win dows, такие как создание дополнительных страничных файлов, выполнение отложенных операций по копированию, переименованию и удалению фай лов, а также создание системных переменных окружения. Он также запус кает процессы подсистем (обычно только Csrss.exe) и Winlogon, который в свою очередь создает остальные системные процессы. Значительная часть сведений о конфигурации, хранящихся в реестре и используемых при инициализации Smss, находится в HKLM\SYSTEM\Current ControlSet\Control\Session Manager. Некоторые из этих данных поясняются в главе 5 в разделе по Smss. (Более подробное описание разделов и парамет ров см. в справочном файле Regentry.chm из ресурсов Windows 2000). После выполнения этих этапов инициализации главный поток Smss пе реходит к бесконечному ожиданию описателей процессов Csrss и Winlogon. Так как от них зависит функционирование Windows, при неожиданном за вершении любого из них Smss вызывает крах системы (с кодом STATUS_SYS TEM_ PROCESS_TERMINATED, или 0xC000021A). Smss также ожидает запро сы на загрузку, события отладки и запросы на запуск новых сеансов серве ра терминала. (Описание служб терминала см. в главе 1.) Сеанс Terminal Services создается Smss. Когда Smss получает запрос на со здание сеанса, он сначала вызывает NtSetSystemInformation с запросом на настройку сеансовых структур данных режима ядра. Это приводит к вызову внутренней функции диспетчера памяти MmSessionCreate, настраивающей виртуальное адресное пространство сеанса, которое будет содержать пул подкачиваемой памяти для сеанса и сеансовые структуры данных, создава емые подсистемой Windows (а точнее, ее частью, работающей в режиме
ГЛАВА 9 Архитектура системы 87 ядра), а также другими драйверами устройств. (Детали см. в главе 7). Затем Smss создает экземпляр Winlogon и Csrss для данного сеанса. Winlogon, LSASS и Userinit Процесс входа в Windows (\Windows\System32\Winlogon.exe) обрабатывает интерактивный вход пользователя в систему и выход из нее. При нажатии комбинации клавиш SAS (secure attention sequence) Winlogon получает уве домление о запросе пользователя на вход в систему. По умолчанию SAS в Windows представляет собой комбинацию клавиш Ctrl+Alt+Del. Назначение SAS — защита пользователя от программ перехвата паролей, имитирующих процесс входа в систему, так как эту комбинацию клавиш нельзя перехватить в приложении пользовательского режима. Идентификация и аутентификация при входе в систему реализованы в заменяемой DLL под названием GINA (Graphical Identification and Authen tication). Стандартная GINA Windows, Msgina.dll, реализует интерфейс для входа в систему по умолчанию. Однако разработчики могут включать свои GINA DLL, реализующие другие механизмы аутентификации и идентифика ции вместо стандартного метода Windows на основе проверки имени и па роля пользователя — например, на основе распознавания образцов голоса. Кроме того, Winlogon может загружать дополнительные DLL компонентов сетевого доступа для дальнейшей аутентификации. Эта функция позволяет нескольким компонентам доступа к сетям единовременно собирать все не обходимые регистрационные данные в процессе обычного входа в систему. После ввода имя и пароль пользователя посылаются для проверки сервер ному процессу локальной аутентификации (local security authentication server process, LSASS) (\Windows\System32\Lsass.exe, описываемому в главе 8). LSASS вызывает соответствующую функциональность (реализованную в виде DLL) для проверки соответствия введенного пароля с тем, что хранится в актив ном каталоге или SAM (части реестра, содержащей определения пользова телей и групп). После успешной аутентификации LSASS вызывает какуюлибо функцию в мониторе состояния защиты (например, NtCreateToken), чтобы сгенерировать объект «маркер доступа» (access token object), содержащий профиль безопас ности пользователя. Впоследствии Winlogon использует его для создания на чального процесса оболочки. Информация о начальном процессе (или процес сах) хранится в параметре Userinit в разделе реестра HKLM\ SOFTWARE\ Micro soft\Windows NT\CurrentVersion\Winlogon. (По умолчанию начальным процес сом считается Userinit.exe, но в списке может быть более одного образа.) Userinit выполняет некоторые действия по инициализации пользователь ской среды (например, запускает сценарии регистрации и активизирует групповые политики), а затем ищет в реестре параметр Shell (в указанном выше разделе Winlogon) и создает процесс для запуска определенной сис темной оболочки (по умолчанию — Explorer.exe). После этого процесс Useri nit завершается. Вот почему для Explorer.exe не показывается родительский процесс — он уже завершился. Иначе говоря, Explorer является «внучатым»
88 ГЛ А В А 2 БЕЗОПАСНОСТЬ процессом Winlogon. (Имена процессов, чьи родительские процессы уже завершены, в списке Tlist выравниваются по левому краю.) Winlogon активен не только при входе и выходе пользователя, но и при перехвате ввода SAS с клавиатуры. Например, когда вы нажимаете Ctrl+Alt+ Del после входа в систему, Winlogon открывает диалоговое окно Windows Security (Безопасность Windows), предлагающее на выбор выход из системы, запуск Task Manager, блокировку рабочей станции, завершение работы сис темы и т. д. Полное описание этапов процесса входа см. в разделе «Smss, Csrss и Win logon» главы 5. Подробнее об аутентификации см. главу 8. Подробнее о вы зываемых функциях интерфейса LSASS (чьи имена начинаются с Lsa) см. до кументацию Platform SDK. Диспетчер управления сервисами (SCM) Вспомните, что термин «сервисы» в Windows обозначает как серверные про цессы, так и драйверы устройств. В этом разделе обсуждаются сервисы, яв ляющиеся процессами пользовательского режима. Они похожи на демоны UNIX или обособленные процессы VMS в том смысле, что могут быть скон фигурированы на автоматический запуск при загрузке системы, не требуя интерактивного входа. Их также можно запустить вручную, например, с по мощью оснастки Services (Службы) или вызовом Windowsфункции StartSer! vice. Как правило, сервисы не взаимодействуют с вошедшим в систему поль зователем, хотя при особых условиях это возможно (см. главу 4). Этими сервисами управляет специальный системный процесс, диспетчер управления сервисами (service control manager) (\Windows\System32\Servi ces.exe), отвечающий за запуск, остановку процессов сервисов и взаимодей ствие с ними. Сервисы представляют собой просто Windowsобразы испол няемых программ, вызывающие особые Windowsфункции для взаимодей ствия с диспетчером управления сервисами и с его помощью выполняющие такие операции, как регистрация успешного запуска сервиса, ответы на зап росы о состоянии, приостановку или завершение работы сервиса. Сервисы определяются в разделе реестра HKLM\SYSTEM\CurrentControlSet\Services. Сведения о подразделах и параметрах, относящихся к сервисам, см. в спра вочном файле Regentry.chm в ресурсах Windows. Учтите, что у сервисов есть три имени: имя процесса, выполняемого в си стеме, внутреннее имя в реестре и так называемое отображаемое имя (display name), которое можно увидеть в оснастке Services (Службы). (Не у каждого сервиса есть отображаемое имя, и в случае его отсутствия используется внут реннее имя.) Сервисы Windows также содержат поле описания, где находит ся более подробная информация о том, что делает конкретный сервис. Чтобы выяснить, какие именно сервисы содержатся в том или ином про цессе, введите команду tlist /s. Но заметьте, что иногда один процесс совме стно используется несколькими сервисами. Код типа в реестре позволяет узнать, какие сервисы имеют собственные процессы и какие из них делят процессы с другими сервисами данного образа файла.
ГЛАВА 9 Архитектура системы 89 В виде сервисов реализуются некоторые компоненты Windows, например диспетчер очереди печати (спулер), журнал системных событий, планиров щик задач, а также ряд сетевых компонентов. ЭКСПЕРИМЕНТ: вывод списка установленных сервисов Чтобы вывести список установленных сервисов (служб), дважды щел кните значок Administrative Tools (Администрирование) в окне Control Panel (Панель управления) и выберите Services (Службы). Вы должны увидеть чтонибудь в таком роде: Для просмотра детальных сведений о сервисе щелкните правой кнопкой мыши имя сервиса и выберите команду Properties (Свойства). Ниже показан пример окна свойств для службы Print Spooler (Диспет чер очереди печати). см. след. стр.
90 ГЛ А В А 2 БЕЗОПАСНОСТЬ Обратите внимание, что поле Path To Executable (Исполняемый файл) указывает на программу, включающую данный сервис. Помни те, что некоторые сервисы разделяют процессы с другими сервисами, поэтому число сервисов и используемых ими процессов не всегда на ходится в соотношении «один к одному». ЭКСПЕРИМЕНТ: просмотр сервисов внутри сервисных процессов Process Explorer выделяет процессы, которые являются хостами одного и более сервисов. (Для настройки поведения Process Explorer выберите Con figure Highlighting в меню Options.) Дважды щелкнув процесс — хост сер висов, вы откроете вкладку Services, где перечисляются сервисы внутри этого процесса. При этом по каждому сервису выводится имя раздела ре естра, где определен данный сервис, отображаемое имя, видимое админи стратору, и текст описания для этого сервиса (если такой текст есть). На пример, в Windows XP список сервисов в процессе Svchost.exe, выполняе мом под учетной записью System, выглядит следующим образом. Подробнее о сервисах рассказывается в главе 4. Резюме В этой главе мы познакомились с общими аспектами системной архитекту ры Windows. Мы также рассмотрели ключевые компоненты Windows и принципы их взаимодействия. В следующей главе будет подробнее расска зано о базовых системных механизмах, на которые опираются эти компо ненты, в том числе о синхронизации и диспетчере объектов.
Г Л А В А 3 Системные механизмы В Microsoft Windows существует несколько базовых механизмов, которыми пользуются компоненты режима ядра: исполнительная система (executive), ядро и драйверы устройств. В этой главе описываются следующие систем ные механизмы (а также способы их использования): 쐽 диспетчеризация ловушек (trap dispatching), в том числе прерываний, DPC (deferred procedure call), APC (asynchronous procedure call), исключе ний и системных сервисов; 쐽 диспетчер объектов исполнительной системы; 쐽 синхронизация, в том числе спинблокировки, объекты диспетчера ядра (kernel dispatcher objects) и реализация механизмов ожидания; 쐽 системные рабочие потоки; 쐽 различные механизмы вроде поддержки глобальных флагов Windows; 쐽 LPC (local procedure call); 쐽 Kernel Event Tracing; 쐽 Wow64. Диспетчеризация ловушек Прерывания и исключения — такие ситуации в операционной системе, в которых нормальный поток выполнения кода процессором прерывается. Эти ситуации обнаруживаются как программным, так и аппаратным обес печением. Термин ловушка (trap) относится к механизму, благодаря которо му при прерывании или исключении процессор перехватывает контроль над выполняемым потоком и передает управление определенной части опе рационной системы. В Windows процессор передает управление обработ чику ловушек (trap handler) — функции, специфичной для конкретного пре рывания или исключения. Рис. 31 иллюстрирует некоторые ситуации, в ко торых активизируются обработчики ловушек.
92 Рис. 3-1. ГЛ А В А 3 БЕЗОПАСНОСТЬ Диспетчеризация ловушек Ядро различает прерывания и исключения: прерывание (interrupt) явля ется асинхронным событием (т. е. оно может произойти в любой момент независимо от текущих команд, выполняемых процессором). Прерывания в основном генерируются устройствами вводавывода и таймерами. Их мож но включать и отключать. Исключение (exception), напротив, представляет собой синхронное событие, являющееся результатом выполнения конкрет ной команды. Повторный запуск программы в аналогичных условиях с теми же данными позволит воспроизвести исключение. Примерами исключений могут служить нарушения доступа (ошибки защиты памяти), выполнение некоторых команд отладчика, а также попытки деления на нуль. Ядро также считает исключениями вызовы системных сервисов (хотя с точки зрения технической реализации это системные ловушки). Прерывания и исключения можно генерировать как программно, так и аппаратно. Например, исключение «bus error» (ошибка шины) возникает из за аппаратной ошибки, а причиной исключения «dividebyzero» (деление на нуль) является ошибка в программе. Аналогичным образом прерывания мо гут генерироваться устройствами вводавывода или самим ядром (такие про граммные прерывания, как, например, APC или DPC). При аппаратном прерывании или исключении процессор записывает статусную информацию в стек ядра для прерванного потока, чтобы впослед ствии можно было вернуться к исходной точке в потоке управления и про должить выполнение команд так, будто ничего не произошло. Если поток выполнялся в пользовательском режиме, Windows переключается на стек режима ядра для потока. Затем создает в стеке ядра прерванного потока
ГЛАВА 9 Системные механизмы 93 фрейм ловушки (trap frame), в котором сохраняет информацию о состоянии потока. Фрейм ловушки является подмножеством полного контекста пото ка (см. главу 6), и вы можете просмотреть его определение, введя в отладчи ке ядра команду dt nt!_ktrap_frame. Программное прерывание ядро обслу живает либо при обработке аппаратного прерывания, либо синхронно — при вызове потоком функции ядра, относящейся к данному программному прерыванию. В большинстве случаев ядро устанавливает функции, выполняющие об щую обработку ловушек до и после передачи управления другим функциям, которые ставят ловушки. Например, когда устройство генерирует прерыва ние, обработчик ловушек аппаратных прерываний (принадлежащий ядру) передает управление процедуре обслуживания прерывания (interrupt service routine, ISR), предоставленной драйвером соответствующего устройства. Если прерывание возникло в результате вызова системного сервиса, обра ботчик ловушек общесистемных сервисов передает управление функции указанного системного сервиса в исполнительной системе. Ядро также ус танавливает обработчики для ловушек, которые оно не ожидает или не об рабатывает. Эти обработчики, как правило, выполняют системную функцию KeBugCheckEx. Она останавливает компьютер, если ядро обнаруживает в ра боте системы отклонения, способные привести к повреждению данных (подробнее об этом см. главу 14). Диспетчеризация прерываний, исключе ний и системных сервисов детальнее описывается в следующих разделах. Диспетчеризация прерываний Аппаратные прерывания обычно генерируются устройствами вводавывода, которые таким образом уведомляют процессор о необходимости уделить им внимание. Устройства, управляемые на основе прерываний, позволяют опе рационной системе максимально полно использовать процессор, совмещая основную обработку с обслуживанием вводавывода. Выдав запрос на ввод вывод, поток может заняться другой работой, пока устройство выполняет запрошенную операцию. Закончив, устройство генерирует прерывание, и процессор переключается на обслуживание этого устройства. Прерывания ми управляются, как правило, координатные устройства, принтеры, клавиа туры, дисковые устройства и сетевые платы. Системное программное обеспечение также может генерировать преры вания. Ядро способно отключать прерывания, чтобы не прерывать работу процессора, однако это делается нечасто — только в критические моменты, например при обработке прерываний или диспетчеризации исключения. Для обработки аппаратных прерываний ядро устанавливает обработчи ки ловушек прерываний, которые передают управление внешней процеду ре (ISR), обрабатывающей прерывание, или внутренней процедуре ядра, реагирующей на прерывание. Драйверы устройств предоставляют ISR для об служивания прерываний от своих устройств, а ядро — внутренние процеду ры для обработки других типов прерываний.
94 ГЛ А В А 3 БЕЗОПАСНОСТЬ Далее мы рассмотрим, как процессор уведомляется об аппаратных пре рываниях, какие типы прерываний поддерживаются ядром и как драйверы устройств взаимодействуют с ядром (в процессе обработки прерываний). Кроме того, мы поговорим о распознавании ядром программных прерыва ний и об объектах, используемых для реализации таких прерываний. Обработка аппаратных прерываний На аппаратных платформах, поддерживаемых Windows, прерывания, связан ные с внешним вводомвыводом, поступают по одной из линий контролле ра прерываний. Контроллер в свою очередь связан с процессором един ственной линией, по которой и уведомляет о прерывании. Как только про цессор прерывается, он требует от контроллера запрос прерывания (inter rupt request, IRQ). Контроллер транслирует IRQ в номер прерывания, исполь зуемый как индекс в структуре, называемой таблицей диспетчеризации прерываний (interrupt dispatch table, IDT), и передает управление соответ ствующей процедуре. При загрузке Windows заносит в IDT указатели на процедуры ядра, обрабатывающие каждое прерывание и исключение. ЭКСПЕРИМЕНТ: просмотр IDT Просмотреть содержимое IDT, включая сведения об обработчиках ло вушек, которые Windows назначила прерываниям, можно с помощью команды !idt отладчика ядра. Команда !idt без флагов показывает век торы, которые сопоставлены с адресами в модулях, отличных от Ntoskrnl.exe. Ниже показано, что выводит команда !idt. kd> !idt Dumping IDT: 30: 31: 34: 35: 38: 39: 3b: 806b14c0 hal!HalpClockInterrupt 8a39dc3c i8042prt!I8042KeyboardInterruptService (KINTERRUPT 8a39dc00) 8a436dd4 serial!SerialCIsrSw (KINTERRUPT 8a436d98) 8a44ed74 NDIS!ndisMIsr (KINTERRUPT 8a44ed38) portcls!CInterruptSync::Release+0x10 (KINTERRUPT 899c44a0) 806abe80 hal!HalpProfileInterrupt 8a4a8abc ACPI!ACPIInterruptServiceRoutine (KINTERRUPT 8a4a8a80) 8a48d8c4 pcmcia!PcmciaInterrupt (KINTERRUPT 8a48d888) ohci1394!OhciIsr (KINTERRUPT 8a41da18) VIDEOPRT!pVideoPortInterrupt (KINTERRUPT 8a1bc2c0) USBPORT!USBPORT_InterruptService (KINTERRUPT 8a2302b8) USBPORT!USBPORT_InterruptService (KINTERRUPT
ГЛАВА 9 3c: 3e: 3f: Системные механизмы 95 8a0b8008) USBPORT!USBPORT_InterruptService (KINTERRUPT 8a170008) USBPORT!USBPORT_InterruptService (KINTERRUPT 8a258380) NDIS!ndisMIsr (KINTERRUPT 8a0e0430) 8a39d3ec i8042prt!I8042MouseInterruptService (KINTERRUPT 8a39d3b0) 8a47264c atapi!IdePortInterrupt (KINTERRUPT 8a472610) 8a489b3c atapi!IdePortInterrupt (KINTERRUPT 8a489b00) В системе, задействованной в этом эксперименте, номер прерыва ния 0x3C — с ISR драйвера клавиатуры (I8042prt.sys), а прерывание 0x3B совместно используется несколькими устройствами, в том чис ле видеоадаптером, шиной PCMCIA, портами USB и IEEE 1394, а также сетевым адаптером. Windows увязывает аппаратные IRQ с номерами прерываний в IDT. Эта таблица используется системой и при конфигурировании обработчиков ловушек для исключений. Так, номер исключения для ошибки страницы на x86 и x64 (это исключение возникает, когда поток пытается получить дос туп к отсутствующей или не определенной в виртуальной памяти странице) равен 0xe. Следовательно, запись 0xe в IDT указывает на системный обработ чик ошибок страниц. Хотя архитектуры, поддерживаемые Windows, допус кают до 256 элементов в IDT, число IRQ на конкретной машине определяет ся архитектурой используемого в ней контроллера прерываний. У каждого процессора имеется своя IDT, так что разные процессоры мо гут при необходимости выполнять разные ISR. Например, в многопроцес сорной системе каждый процессор получает прерывания системного тай мера, но обновление значения системного таймера в результате обработки этого прерывания осуществляется только одним процессором. Однако все процессоры используют это прерывание для измерения кванта времени, выделенного потоку, и для инициации новой процедуры планирования по истечении этого кванта. Аналогичным образом в некоторых конфигураци ях может понадобиться, чтобы определенные аппаратные прерывания об рабатывал конкретный процессор. Контроллеры прерываний на платформе x86 В большинстве систем x86 применяется либо программируемый контрол лер прерываний (Programmable Interrupt Controller, PIC) i8259A, либо его разновидность, усовершенствованный программируемый контроллер пре рываний (Advanced Programmable Interrupt Controller, APIC) i82489. Новые компьютеры, как правило, оснащаются APIC. Стандарт PIC был разработан для оригинальных IBM PC. PIC работает только в однопроцессорных систе мах и имеет 15 линий прерываний. АPIC и SAPIC (о нем чуть позже) спосо бен работать в многопроцессорных системах и предлагает 256 линий пре
96 ГЛ А В А 3 БЕЗОПАСНОСТЬ рываний. Intel совместно с другими компаниями создали спецификацию Multiprocessor (MP) Specification, стандарт для многопроцессорных систем x86, основанный на использовании APIC. Для совместимости с однопроцес сорными операционными системами и загрузочным кодом, запускающим многопроцессорную систему в однопроцессорном режиме, APIC поддержи вает PICсовместимый режим с 15 линиями прерываний и передачей преры ваний лишь главному процессору. Архитектура APIC показана на рис. 32. На самом деле APIC состоит из нескольких компонентов: APIC вводавывода, принимающего прерывания от устройств, локальных APIC, принимающих прерывания от APIC вводавывода по выделенной шине и прерывающих ра боту того процессора, с которым они связаны, а также i8259Aсовместимо го контроллера прерываний, транслирующего входные сигналы APIC в со ответствующие PICэквиваленты. APIC вводавывода отвечает за реализацию алгоритмов перенаправления прерываний, и операционная система выби рает нужный ей алгоритм (в Windows выбор возлагается на HAL). Эти алго ритмы равномерно распределяют между процессорами нагрузку, связанную с обработкой прерываний от устройств, и в максимальной мере использу ют все преимущества локальности, направляя такие прерывания процессо ру, который только что обрабатывал прерывания аналогичного типа. Рис. 3-2. Архитектура x86 APIC Контроллеры прерываний на платформе x64 Поскольку архитектура x64 совместима с операционными системами для x86, системы на базе x64 должны предоставлять те же контроллеры преры ваний, что и на базе x86. Однако x64версии Windows не будут работать на системах без APIC (т. е. они не поддерживают PIC).
ГЛАВА 9 Системные механизмы 97 Контроллеры прерываний на платформе IA64 В архитектуре IA64 используется контроллер прерываний Streamlined Advanced Programmable Interrupt Controller (SAPIC) — результат эволюционного развития APIC. Главное различие между архитектурами APIC и SAPIC в том, что APIC вво давывода в APICсистеме направляет прерывания локальным APIC по выделен ной шине APIC, тогда как в системе SAPIC прерывания передаются по шине вво давывода и системы (I/O and system bus) для большего быстродействия. Еще одно различие — перенаправление прерываний и балансировка нагрузки в APICсистеме обрабатывается самой шиной APIC, а в SAPICсистеме, где нет выделенной шины APIC, требуется, чтобы соответствующая поддержка была запрограммирована в микрокоде (прошивке). Но, даже если эта поддержка имеется в микрокоде, Windows не использует ее — вместо этого она статичес ки назначает прерывания процессорам по принципу карусели. ЭКСПЕРИМЕНТ: просмотр конфигурации PIC и APIC Конфигурацию PIC в однопроцессорной системе и АPIC в многопро цессорной системе можно просмотреть с помощью команд !pic или !apic отладчика ядра. (Для этого эксперимента LiveKd не годится, так как она не может напрямую обращаться к оборудованию.) Ниже по казан образец вывода команды !pic в однопроцессорной системе (уч тите, что команда !pic не работает в системе, использующей APIC HAL). lkd> !pic —— IRQ Number —— 00 01 Physically in service: Physically masked: Physically requested: Level triggered: 02 . . . . 03 . . . . 04 . . . . 05 . Y . . 06 . . . . 07 . . . Y 08 . Y . . 09 . Y . . 0A . . . . 0B . . . Y 0C . Y . . 0D . . . Y 0E . . . . 0F . Y . . . . . . . . . . На следующем листинге приводится выходная информация коман ды !apic в системе, использующей MPS HAL. Префикс «0:» в командной строке отладчика говорит о том, что текущие команды выполняются на процессоре 0, поэтому данный листинг относится к APIC ввода вывода процессора 0. lkd> !apic Apic @ fffe0000 ID:0 (40010) LogDesc:01000000 DestFmt:ffffffff TPR 20 TimeCnt: 0bebc200clk SpurVec:3f FaultVec:e3 error:0 Ipi Cmd: 0004001f Vec:1F FixedDel Dest=Self edg high Timer..: 000300fd Vec:FD FixedDel Dest=Self edg high masked Linti0.: 0001003f Vec:3F FixedDel Dest=Self edg high masked Linti1.: 000184ff Vec:FF NMI Dest=Self lvl high masked TMR: 61, 82, 9192, B1 IRR: ISR: см. след. стр.
98 ГЛ А В А 3 БЕЗОПАСНОСТЬ Теперь взгляните на образец вывода команды !ioapic, показываю щей конфигурацию APIC вводавывода: 0: kd> !ioapic IoApic @ ffd02000 Inti00.: 000100ff Inti01.: 00000962 Inti02.: 000100ff Inti03.: 00000971 Inti04.: 000100ff Inti05.: 00000961 Inti06.: 00010982 Inti07.: 000100ff Inti08.: 000008d1 Inti09.: 000100ff Inti0A.: 000100ff Inti0B.: 000100ff Inti0C.: 00000972 Inti0D.: 000100ff Inti0E.: 00000992 Inti0F.: 000100ff Inti10.: 000100ff Inti11.: 000100ff Inti12.: 000100ff Inti13.: 000100ff Inti14.: 0000a9a3 Inti15.: 0000a993 Inti16.: 000100ff Inti17.: 000100ff ID:8 (11) Arb:0 Vec:FF FixedDel Vec:62 LowestDl Vec:FF FixedDel Vec:71 LowestDl Vec:FF FixedDel Vec:61 LowestDl Vec:82 LowestDl Vec:FF FixedDel Vec:D1 FixedDel Vec:FF FixedDel Vec:FF FixedDel Vec:FF FixedDel Vec:72 LowestDl Vec:FF FixedDel Vec:92 LowestDl Vec:FF FixedDel Vec:FF FixedDel Vec:FF FixedDel Vec:FF FixedDel Vec:FF FixedDel Vec:A3 LowestDl Vec:93 LowestDl Vec:FF FixedDel Vec:FF FixedDel PhysDest:00 Lg:03000000 PhysDest:00 Lg:03000000 PhysDest:00 Lg:03000000 Lg:02000000 PhysDest:00 Lg:01000000 PhysDest:00 PhysDest:00 PhysDest:00 Lg:03000000 PhysDest:00 Lg:03000000 PhysDest:00 PhysDest:00 PhysDest:00 PhysDest:00 PhysDest:00 Lg:03000000 Lg:03000000 PhysDest:00 PhysDest:00 edg edg edg edg edg edg edg edg edg edg edg edg edg edg edg edg edg edg edg edg lvl lvl edg edg masked masked masked masked masked masked masked masked masked masked masked masked masked masked masked masked Уровни запросов программных прерываний Хотя контроллеры прерываний различают уровни приоритетов прерыва ний, Windows использует свою схему приоритетов прерываний, известную под названием уровни запросов прерываний (interrupt request levels, IRQL). Внутри ядра IRQL представляются в виде номеров 0–31 в системах x86 и 0–15 в системах x64 и IA64, причем больший номер соответствует преры ванию с более высоким приоритетом. Ядро определяет стандартный набор IRQL для программных прерываний, а HAL увязывает IRQL с номерами ап паратных прерываний. IRQL, определенные для архитектуры x86, показаны на рис. 33, а аналогичные сведения для архитектур x64 и IA64 — на рис. 34. ПРИМЕЧАНИЕ Уровень SYNCH_LEVEL, используемый многопроцес сорными версиями ядра для защиты доступа к индивидуальным для каждого процессора блокам PRCB (processor control blocks), не пока зан на этих схемах, так как его значение варьируется в разных верси ях Windows. Описание SYNCH_LEVEL и его возможных значений см. в главе 6.
ГЛАВА 9 Системные механизмы Рис. 3-3. Уровни запросов прерываний (IRQL) в x86-системах Рис. 3-4. Уровни запросов прерываний (IRQL) в системах x64 и IA64 99 Прерывания обслуживаются в порядке их приоритета, и прерывания с более высоким приоритетом вытесняют обработку прерываний с меньшим приоритетом. При возникновении прерывания с высоким приоритетом процессор сохраняет информацию о состоянии прерванного потока и ак тивизирует сопоставленный с данным прерыванием диспетчер ловушки. Последний повышает IRQL и вызывает процедуру обслуживания прерывания (ISR). После выполнения ISR диспетчер прерывания понижает IRQL процес сора до исходного уровня и загружает сохраненные ранее данные о состо янии машины. Прерванный поток возобновляется с той точки, где он был прерван. Когда ядро понижает IRQL, могут «материализоваться» ранее замас кированные прерывания с более низким приоритетом. Тогда вышеописан ный процесс повторяется ядром для обработки и этих прерываний.
100 ГЛ А В А 3 БЕЗОПАСНОСТЬ Уровни приоритетов IRQL имеют совершенно иной смысл, чем приори теты в схеме планирования потоков (см. главу 6). Приоритет в этой схеме является атрибутом потока, тогда как IRQL — атрибутом источника преры вания, например клавиатуры или мыши. Кроме того, IRQL каждого процес сора меняется во время выполнения команд операционной системы. Значение IRQL определяет, какие прерывания может получать данный процессор. IRQL также используется для синхронизации доступа к структу рам данных режима ядра (о синхронизации мы поговорим позже). При вы полнении поток режима ядра повышает или понижает IRQL процессора либо напрямую (вызовом соответственно KeRaiseIrql или KeLowerIrql), ли бо — что бывает гораздо чаще — опосредованно (через функции, которые обращаются к синхронизирующим объектам ядра). Как показано на рис. 35, прерывания от источника с IRQL, превышающим текущий уровень, преры вают работу процессора, а прерывания от источников, IRQL которых мень ше или равен текущему уровню, маскируются до тех пор, пока выполняемый поток не понизит IRQL. Рис. 3-5. Маскирование прерываний Поскольку доступ к PIC — операция довольно медленная, в HAL, исполь зующих PIC, реализован механизм оптимизации «отложенный IRQL» (lazy IRQL), который избегает обращений к PIC. Когда IRQL повышается, HAL — вместо того чтобы изменять маску прерывания — просто отмечает новый IRQL. Если вслед за этим возникает прерывание с более низким приорите том, HAL устанавливает маску прерывания в соответствии с первым и откла дывает обработку прерывания с более низким приоритетом до понижения IRQL. Таким образом, если при повышенном IRQL не возникнет прерываний с более низким приоритетом, HAL не потребуется обращаться к PIC.
ГЛАВА 9 Системные механизмы 101 Поток режима ядра повышает и понижает IRQL процессора, на котором он выполняется, в зависимости от того, что именно делает этот поток. На пример, обработчик ловушки (или сам процессор) при прерывании повы шает IRQL процессора до IRQL источника прерывания. В результате все пре рывания с более низким или равным IRQL маскируются (только на этом про цессоре), что не дает прерыванию с таким же или более низким IRQL поме шать процессору обработать текущее прерывание. Замаскированные преры вания либо обрабатываются другим процессором, либо откладываются до понижения IRQL. Поэтому все системные компоненты, в том числе ядро и драйверы устройств, пытаются удерживать IRQL на уровне passive («пассив ный»), иногда называемом низким уровнем. Если бы IRQL долго оставался неоправданно высоким, драйверы устройств не смогли бы оперативно реа гировать на аппаратные прерывания. ПРИМЕЧАНИЕ Прерывания APC_LEVEL являются исключением из правила, которое гласит, что повышение IRQL блокирует прерывания такого же уровня и ниже. Если поток повышает IRQL до уровня APC_ LEVEL, а затем отключается от процессора изза появления прерыва ния DISPATCH_LEVEL, то система может доставить ему прерывание APC_LEVEL, как только он вновь получит процессорное время. Таким образом, APC_LEVEL можно считать IRQL, локальным для потока. ЭКСПЕРИМЕНТ: определяем IRQL Если вы работаете с отладчиком ядра в Windows Server 2003, то може те определить IRQL процессора командой !irql: kd> !irql Debugger saved IRQL for processor 0x0 — 0 (LOW_LEVEL) Заметьте, что в структуре данных, называемой PCR (processor control region), и ее расширении — PRCB (processor control block) име ется поле с именем Irql. Эти структуры содержат информацию о состо янии каждого процессора в системе, в том числе текущий IRQL, ука затель на аппаратную IDT, сведения о текущем потоке и потоке, кото рый будет выполняться следующим. Ядро и HAL используют эту ин формацию для выполнения операций, специфичных для данной ма шины и ее архитектуры. Отдельные части структур PCR и PRCB откры то определены в заголовочном файле Ntddk.h (в Windows DDK). Заг ляните в него, чтобы получить представление об этих структурах. Для просмотра содержимого PCR воспользуемся командой !pcr от ладчика ядра. kd> !pcr PCR Processor 0 @ffdff000 NtTib.ExceptionList: f8effc68 NtTib.StackBase: f8effdf0 NtTib.StackLimit: f8efd000 см. след. стр.
102 ГЛ А В А 3 БЕЗОПАСНОСТЬ NtTib.SubSystemTib: NtTib.Version: NtTib.UserPointer: NtTib.SelfTib: 00000000 00000000 00000000 7ffde000 SelfPcr: Prcb: Irql: IRR: IDR: InterruptMode: IDT: GDT: TSS: ffdff000 ffdff120 00000000 00000000 ffff28e8 00000000 80036400 80036000 802b5000 CurrentThread: 81638020 NextThread: 00000000 IdleThread: 8046bdf0 К сожалению, Windows не поддерживает поле Irql на платформах, не использующих отложенные IRQL, поэтому в большинстве систем это поле всегда содержит 0. Так как изменения IRQL процессора существенно влияют на функциони рование системы, они возможны только в режиме ядра. Потоки пользова тельского режима не могут изменять IRQL процессора. Это значит, что при выполнении потоков пользовательского режима значение IRQL процессо ра всегда равно passive. Только при выполнении кода режима ядра IRQL мо жет быть выше этого уровня. Каждый уровень прерывания имеет определенное назначение. Так, ядро генерирует межпроцессорное прерывание (interprocessor interrupt, IPI), что бы потребовать выполнения какойлибо операции от другого процессора, например, при диспетчеризации некоего потока или обновлении кэша ас социативного буфера трансляции [translation lookaside buffer (TLB) cache]. Системный таймер через регулярные промежутки генерирует прерывания, на которые ядро реагирует обновлением системного времени, и это исполь зуется для измерения продолжительности выполнения потока. Если аппарат ная платформа поддерживает два таймера, то для измерения производитель ности ядро добавляет еще один уровень прерываний от таймера. HAL под держивает несколько уровней запросов прерываний для устройств, управля емых прерываниями; конкретное число таких уровней зависит от процес сора и конфигурации системы. Ядро использует программные прерывания для инициации планирования потоков и асинхронного вмешательства в выполнение потока. Увязка прерываний с IRQL Уровни IRQL и запросы прерываний (IRQ) — вещи разные. Концепция IRQL в архитектурах, на которых работает Win dows, не реализована аппаратно. Тогда возникает вопрос: как Windows оп
ГЛАВА 9 Системные механизмы 103 ределяет, какой IRQL следует присвоить прерыванию? Ответ нужно искать в HAL. В Windows за определение устройств на конкретной шине (PCI, USB и т. д.) и назначение им прерываний отвечают драйверы устройств особого типа — драйверы шин. Драйвер шины сообщает эту информацию диспет черу Plug and Play, и тот, учитывая приемлемые для других устройств преры вания, принимает решение о конкретных прерываниях, выделяемых каждо му устройству. Далее он вызывает HALфункцию HalpGetSystemInterruptVector, которая увязывает прерывания со значениями IRQL. Этот алгоритм неодинаков в различных версиях HAL. В однопроцессор ных x86системах HAL выполняет прямую трансляцию: IRQL данного векто ра прерывания вычисляется путем вычитания значения вектора из 27. Таким образом, если устройство использует 5й вектор прерывания, его ISR выпол няется при IRQL, равном 22. В многопроцессорной x86системе преобразо вания более сложны. APIC поддерживает более 200 векторов прерываний, поэтому при трансляции «один в один» имеющихся IRQL окажется недоста точно. Многопроцессорная версия HAL присваивает IRQL векторам преры ваний, циклически перебирая значения из диапазона IRQL устройств (device IRQL, DIRQL). В итоге на многопроцессорной x86системе не такто просто предсказать или выяснить IRQL, назначаемый IRQ. Наконец, в x64 и IA64 системах HAL вычисляет IRQL для IRQ путем деления вектора прерывания, назначенного данному IRQ, на 16. Предопределенные IRQL Давайте повнимательнее приглядимся к предопределенным IRQL, начиная с самого верхнего уровня схемы, пред ставленной на рис. 35. 쐽 Уровень «high» (высокий) используется ядром, только если оно останав ливает систему в функции KeBugCheckEx и маскирует все прерывания. 쐽 Уровень «power fail» (отказ электропитания) был заложен еще в самый первый проект Microsoft Windows NT. Он определяет поведение системы при отказе электропитания, но никогда не применялся. 쐽 Уровень «interprocessor interrupt» (межпроцессорное прерывание) исполь зуется для того, чтобы запрашивать от другого процессора выполнение какойлибо операции, например, при постановке в очередь прерывания DISPATCH_LEVEL для планирования конкретного потока к выполнению, при обновлении кэша TLB, завершении работы или крахе системы. 쐽 Уровень «clock» (часы) используется для системных часов, с помощью которых ядро отслеживает время суток, измеряет и распределяет процес сорное время между потоками. 쐽 Уровень «profile» (профиль) используется системным таймером реально го времени, если активизирован механизм профилирования ядра (kernel profiling), т. е. измерения его производительности. Когда он активен, об работчик ловушки профилирования регистрирует адрес команды, выпол нявшейся на момент прерывания. Со временем создается таблица адре сов, которую можно извлечь и проанализировать с помощью соответству ющих утилит. Вы можете скачать утилиту Kernrate (http://www.microsoft.
104 ГЛ А В А 3 БЕЗОПАСНОСТЬ com/whdc/system/sysperf/krview.mspx), позволяющую просматривать ста тистику, полученную при использовании механизма профилирования ядра. Подробнее об этой утилите см. описание эксперимента с Kernrate. 쐽 Уровень «device» (устройство) применяется для задания приоритетов прерываний от устройств (о принципах увязки аппаратных прерываний с IRQL см. предыдущий раздел). 쐽 Прерывания уровней «DPC/dispatch» и «APC» являются программными; они генерируются ядром и драйверами устройств (о DPC и APC будет рассказано позже). 쐽 Самый низкий уровень IRQL, «passive» (пассивный), на самом деле вооб ще не является уровнем прерывания. При этом значении IRQL потоки выполняются обычным образом и могут возникать любые прерывания. ЭКСПЕРИМЕНТ: применение утилиты Kernrate Утилита профилирования ядра (Kernrate) позволяет включать таймер профилирования системы, собирать образцы кода, выполняемого при срабатывании таймера, и выводить сводную информацию, отражаю щую распределение процессорного времени по образам файлов и функциям. Ее можно использовать для отслеживания процессорного времени, потребляемого индивидуальными процессами, и/или време ни, проведенного в режиме ядра независимо от процессов (например, для выполнения процедур обслуживания прерываний). Профилирова ние ядра полезно, когда вы хотите выявить точки, в которых на выпол нение кода тратится больше всего процессорного времени. В своей простейшей форме Kernrate сообщает, сколько процессор ного времени было использовано каждым модулем ядра (Ntoskrnl, драйверами и т. д.). Попробуйте, к примеру, выполнить следующие операции. 1. Откройте окно командной строки. 2. Введите cd c:\program files\krview\kernrates. 3. Введите dir. (Вы увидите образы kernrate для каждой платформы.) 4. Запустите образ, который подходит для вашей платформы (без ар гументов или ключей). Например, Kernrate_i386_XP.exe — это образ для Windows XP на платформе x86. 5. Пока Kernrate выполняется, поделайте чтонибудь в системе. Ска жем, запустите Windows Media Player и проиграйте музыку, запус тите игру, интенсивно работающую с графикой, или перечислите содержимое каталога на удаленном сетевом ресурсе. 6. Нажмите Ctrl+C, чтобы остановить Kernrate. Это заставит Kernrate вывести статистику за прошедший период. Ниже приведена часть вывода Kernrate, когда выполнялся Windows Media Player, воспроизводивший дорожку с компактдиска.
ГЛАВА 9 Системные механизмы 105 C:\Program Files\KrView\Kernrates>Kernrate_i386_XP.exe /==============================\ < KERNRATE LOG > \==============================/ Date: 2004/05/13 Time: 9:48:28 Machine Name: BIGDAVID Number of Processors: 1 PROCESSOR_ARCHITECTURE: x86 PROCESSOR_LEVEL: 6 Kernrate UserSpecified Command Line: Kernrate_i386_XP.exe ***> Press ctrlc to finish collecting profile data ===> Finished Collecting Data, Starting to Process Results ——————Overall Summary:——————— P0 K 0:00:03.234 (11.7%) U 0:00:08.352 (30.2%) I 0:00:16.093 (58.1%) DPC 0:00:01.772 ( 6.4%) Interrupt 0:00:00.350 ( 1.3%) Interrupts= 52899, Interrupt Rate= 1911/sec. Time 7315 hits, 19531 events per hit ———— Module Hits msec %Total Events/Sec gv3 4735 27679 64 % 3341135 smwdm 872 27679 11 % 615305 win32k 764 27679 10 % 539097 ntoskrnl 739 27679 10 % 521457 hal 124 27679 1 % 87497 Сводные данные показывают, что система провела 11,7% времени в режиме ядра, 30,2% в пользовательском режиме, 58,1% в простое, 6,4% на уровне DPC и 1,3% на уровне прерываний (interrupt level). Модуль, чаще всего требовавший к себе внимания, был GV3.SYS, драйвер про цессора для Pentium M (семейства Geyserville). Он используется для сбора информации о производительности, поэтому и оказался на пер вом месте. Модуль, занявший второе место, — Smwdm.sys, драйвер зву ковой платы на компьютере, где проводился тест. Это вполне объяс нимо, учитывая, что основную нагрузку в системе создавал Windows Media Player, посылавший звуковой вводвывод этому драйверу. Если у вас есть файлы символов, вы можете исследовать индивиду альные модули и посмотреть, сколько времени было затрачено каждой из их функций. Например, профилирование системы в процессе бы строго перемещения окна по экрану давало такой вывод (здесь при ведена лишь его часть): C:\Program Files\KrView\Kernrates>Kernrate_i386_XP.exe –z ntoskrnl z win32k см. след. стр.
106 ГЛ А В А 3 БЕЗОПАСНОСТЬ /==============================\ KERNRATE LOG > \==============================/ Date: 2004/05/13 Time: 10:26:55 < Time 4087 hits, 19531 events per hit ———— Module Hits win32k 1649 ati2dvag 1269 ntoskrnl 794 gv3 162 msec %Total 10424 40 % 10424 31 % 10424 19 % 10424 3 % Events/Sec 3089660 2377670 1487683 303532 —— Zoomed module win32k.sys (Bucket size = 16 bytes, Rounding Down) ——— Module Hits msec %Total Events/Sec EngPaint 328 10424 19 % 614559 EngLpkInstalled 302 10424 18 % 565844 —— Zoomed module ntoskrnl.exe (Bucket size = 16 bytes, Rounding Down) —— Module Hits msec %Total Events/Sec KiDispatchInterrupt 243 10424 26 % 455298 ZwYieldExecution 50 10424 5 % 93682 InterlockedDecrement 39 10424 4 % 73072 В данном случае самым «прожорливым» был модуль Win32k.sys, драйвер системы, отвечающей за работу с окнами. Второй в списке — видеодрайвер. И действительно, основная нагрузка в системе была свя зана с рисованием окна на экране. В детальном выводе для Win32k.sys видно, что наиболее активна была его функция EngPaint, основная GDIфункция для рисования на экране. На код, выполняемый на уровне «DPC/dispatch» и выше, накладывается важное ограничение: он не может ждать освобождения объекта, если такое ожидание заставило бы планировщик подключить к процессору другой по ток (а это недопустимая операция, так как планировщик синхронизирует свои структуры данных на уровне «DPC/dispatch» и, следовательно, не может быть активизирован для выполнения перераспределения процессорного времени). Другое ограничение заключается в том, что при уровне IRQL «DPC/ dispatch» или выше доступна только неподкачиваемая память. На самом деле второе ограничение является следствием первого, так как обращение к от сутствующей в оперативной памяти странице вызывает ошибку страницы. Тогда диспетчер памяти должен был бы инициировать операцию дисково го вводавывода, после чего ждать, когда драйвер файловой системы загру зит эту страницу с диска. Это в свою очередь вынудило бы планировщик переключить контекст (возможно, на поток простоя, если нет ни одного пользовательского потока, ждущего выполнения). В результате было бы на рушено правило, запрещающее вызов планировщика в таких ситуациях (по скольку при чтении с диска IRQL все еще остается на уровне «DPC/dispatch»
ГЛАВА 9 Системные механизмы 107 или выше). При нарушении любого из этих двух ограничений происходит крах системы с кодом завершения IRQL_NOT_LESS_OR_EQUAL (подробнее о кодах завершения при крахе системы см. главу 4). Кстати, нарушение этих ограничений является довольно распространенной ошибкой в драйверах устройств. Локализовать причину ошибок такого типа помогает утилита Driver Verifier, о которой будет подробно рассказано в разделе «Утилита Driver Verifier» главы 7. Объекты «прерывание» (interrupt objects) Ядро предоставляет пе реносимый (портируемый) механизм — объект прерывания, позволяющий драйверам устройств регистрировать ISR для своих устройств. Этот объект содержит всю информацию, необходимую ядру для назначения конкретно го уровня прерывания для ISR устройства, включая адрес ISR, IRQL устрой ства и запись в IDT ядра, с которой должна быть сопоставлена ISR. При ини циализации в объект прерывания из шаблона обработки прерываний, KiIn terruptTemplate, копируется несколько ассемблерных инструкций — код дис петчеризации. Этот код выполняется при возникновении прерывания. Код, хранящийся в объекте прерывания, вызывает реальный диспетчер прерываний, которым обычно является процедура ядра KiInterruptDispatch или KiChainedDispatch, и передает ему указатель на объект прерывания. KiIn terruptDispatch обслуживает векторы прерываний, для которых зарегистри рован только один объект прерывания, а KiChainedDispatch — векторы, раз деляемые несколькими объектами прерываний. В объекте прерывания со держится информация, необходимая процедуре KiChainedDispatch для поис ка и корректного вызова ISR драйвера. Объект прерывания также хранит значение IRQL, сопоставленное с данным прерыванием, так что KiDispatch Interrupt или KiChainedDispatch может перед вызовом ISR повысить IRQL до нужного уровня и вернуть его к исходному после завершения ISR. Этот двух этапный процесс необходим изза того, что при начальной диспетчериза ции нельзя передать указатель (или какойлибо иной аргумент) объекту пре рывания, так как она выполняется не программно, а аппаратно. В многопро цессорных системах ядро создает и инициализирует объект прерывания для каждого процессора, позволяя их локальным APIC принимать конкретные прерывания. На рис. 36 показана типичная схема обслуживания прерыва ний, сопоставленных с объектами прерываний.
108 Рис. 3-6. ГЛ А В А 3 БЕЗОПАСНОСТЬ Типичная схема обслуживания прерываний ЭКСПЕРИМЕНТ: изучение внутреннего устройства прерываний С помощью отладчика ядра вы можете просмотреть детальные сведе ния об объекте прерывания, в том числе его IRQL, адрес ISR и собствен ный код диспетчеризации прерывания (custom interrupt dispatching code). Вопервых, введите команду !idt и найдите запись со ссылкой на I8042KeyboardInterruptService — процедуру ISR для устройства «PS2 клавиатура»: 31: 8a39dc3c i8042prt!I8042KeyboardInterruptService (KINTERRUPT 8a39dc00) Для просмотра содержимого объекта, сопоставленного с прерыва нием, введите dt nt!_kinterrupt, указав адрес, следующий за KINTER RUPT: kd> dt nt!_kinterrupt 8a39dc00 nt!_KINTERRUPT +0x000 Type : 22 +0x002 Size : 484 +0x004 InterruptListEntry : _LIST_ENTRY [ 0x8a39dc04  0x8a39dc04 ] +0x00c ServiceRoutine : 0xba7e74a2 i8042prt!I8042KeyboardInterruptService+0 +0x010 ServiceContext : 0x8a067898 +0x014 SpinLock : 0 +0x018 TickCount : 0xffffffff +0x01c ActualLock : 0x8a067958 > 0 +0x020 DispatchAddress : 0x80531140 nt!KiInterruptDispatch+0
ГЛАВА 9 +0x024 +0x028 +0x029 +0x02a +0x02b +0x02c +0x02d +0x030 +0x034 +0x038 +0x03c Vector Irql SynchronizeIrql FloatingSave Connected Number ShareVector Mode ServiceCount DispatchCount DispatchCode : : : : : : : : : : : Системные механизмы 109 0x31 0x1a '' 0x1a '' 0 '' 0x1 '' 0 '' 0 '' 1 ( Latched ) 0 0xffffffff [106] 0x56535554 В этом примере IRQL, назначенный Windows прерыванию, — 0x1a (или 26 в десятичной системе). Поскольку вывод получен на однопро цессорной x86системе, IRQ равно 1 (IRQL в таких системах вычисля ются путем вычитания IRQ из 27). Это можно проверить, открыв De vice Manager (Диспетчер устройств) [на вкладке Hardware (Оборудова ние) в окне свойств системы)], найдя PS/2клавиатуру и посмотрев назначенные ей ресурсы, как показано на следующей иллюстрации. В многопроцессорных x86системах IRQ назначается в основном случайным образом, а в x64 или IA64системе вы увидите, что IRQ — это номер вектора прерываний [0x31 (49 в десятичной системе)], де ленный на 16. Адрес ISR для объекта прерывания хранится в поле ServiceRoutine (его и показывает !idt в своем выводе), а код прерывания, срабатыва см. след. стр.
110 ГЛ А В А 3 БЕЗОПАСНОСТЬ ющий при появлении этого прерывания, — в массиве DispatchCode в конце объекта прерывания. Этот код программируется так, чтобы со здавать фрейм ловушки в стеке и потом вызывать функцию, хранящу юся в поле DispatchAddress (в нашем примере это KiInterruptDispatch), с передачей ей указателя на объект прерывания. Windows и обработка данных в реальном времени К средам, предназначенным для работы в реальном времени, предъяв ляются либо жесткие, либо очень жесткие требования к максимально му времени реакции. Реакция системы реального времени, к которой предъявляются очень жесткие требования (например, системы управ ления атомной электростанцией), должна быть исключительно быст рой, иначе неизбежны катастрофы, опасные не только для оборудова ния, но и для жизни людей. Менее ответственные системы реального времени (например, система экономичного расхода топлива автомо биля) могут в какойто мере отклоняться от этих требований, но их соблюдение все же желательно. В системах реального времени устрой ствами ввода служат датчики, а устройствами вывода — управляющие устройства. Проектировщик компьютерных систем реального време ни должен знать величину максимально допустимого запаздывания между моментом генерации прерывания устройством ввода и ответом управляющего устройства, контролируемого драйвером. Анализ самых неблагоприятных вариантов должен учитывать как запаздывание опе рационной системы, так и запаздывание драйверов и приложений. Поскольку проконтролировать расстановку приоритетов IRQ уст ройств операционной системой Windows нельзя, а пользовательские приложения выполняются лишь при IRQL уровня «passive», Windows не всегда подходит для обработки данных в реальном времени. Макси мальное запаздывание определяется в конечном счете устройствами и драйверами системы, а не самой Windows. Этот фактор становится проблемой при использовании готового оборудования, имеющегося в продаже. Проектировщик может столкнуться с трудностями при оп ределении максимального времени выполнения ISR или DPC драйве ра готового устройства. Даже после тестирования он не сможет гаран тировать, что запаздывание ни при каких обстоятельствах не превы сит заданного предела. Более того, суммарное запаздывание систем ных DPC и ISR, как правило, существенно превосходит значения, при емлемые для чувствительных к задержкам систем. Хотя ко многим типам встраиваемых систем (например, к принте рам и автомобильным компьютерам) предъявляются требования, как к системам реального времени, Windows XP Embedded не обладает соответствующими характеристиками. Это просто версия Windows XP, которая создана с использованием технологии, лицензированной Mic rosoft у компании VenturCom, и способна работать в системах с огра
ГЛАВА 9 Системные механизмы 111 ниченными ресурсами. Так, для устройства без сетевых функций ис ключается вся функциональность Windows XP, связанная с поддерж кой работы в сетях, включая средства управления сетью, драйверы сте ка протокола и сетевого адаптера. Тем не менее третьи фирмы поставляют версии ядра реального вре мени для Windows. Их подход заключается в том, что они встраивают ядро реального времени в собственный HAL и выполняют Windows как задачу в операционной системе реального времени. Windows, выпол няемая в таком виде, служит в качестве пользовательского интерфей са системы и имеет меньший приоритет по сравнению с задачами, ответственными за управление нужным устройством. Пример расши рения ядра Windows реального времени можно увидеть на Webсайте VenturCom www.venturcom.com. Сопоставление ISR с конкретным уровнем прерывания называется под ключением объекта прерывания, а разрыв связи между ISR и записью в IDT — отключением. Эти операции, выполняемые функциями ядра IoCon nectInterrupt и IoDisconnectInterrupt, позволяют драйверу устройства «вклю чать» ISR после своей загрузки и «отключать» ISR, если он не загружен. Применение объекта прерывания для регистрации ISR позволяет драйве рам устройств избегать прямого взаимодействия с контроллером прерыва ний (разным на разных процессорных архитектурах) и исключает необхо димость детального знания IDT. Это дает возможность создавать переноси мые драйверы устройств, поскольку благодаря такой функциональности ядра программировать драйверы устройств на ассемблере и учитывать в них особенности конкретных процессоров больше не нужно. Использование объекта прерывания дает и другие преимущества: ядро может синхронизировать выполнение ISR с другими частями драйвера уст ройства, которые могут разделять данные с ISR. (Подробнее о том, как драй веры устройств реагируют на прерывания, см. главу 9.) Более того, объекты прерывания позволяют ядру легко вызывать более одной ISR для любого уровня прерывания. Если несколько драйверов созда ют объекты прерывания и сопоставляют их с одной записью в IDT, то при прерывании на определенной линии диспетчер вызывает каждую из этих процедур (ISR). Такая функциональность позволяет ядру поддерживать кон фигурации в виде цепочек, когда несколько устройств совместно использу ют одну линию прерывания. Когда одна из ISR объявляет диспетчеру о зах вате прерывания, происходит разрыв цепочки. Если несколько устройств, разделяющих одну линию прерывания, одновременно запрашивают обслу живание, то устройства, не получившие подтверждения от своих ISR, будут вновь генерировать прерывания, как только диспетчер понизит IRQL. Свя зывание устройств в цепочку разрешается, только если все драйверы уст ройств, стремящиеся использовать одно и то же прерывание, сообщат ядру о своей способности разделять данное прерывание. Если они не в состоя нии совместно использовать это прерывание, диспетчер Plug and Play пере
112 ГЛ А В А 3 БЕЗОПАСНОСТЬ назначит IRQ с учетом запросов каждого устройства. Если разделяемым яв ляется вектор прерываний, объект прерывания вызывает KiChainedDispatch, которая поочередно обращается к ISR каждого зарегистрированного объек та прерывания, пока один из них не сообщит, что прерывание вызвано им, или пока все они не будут выполнены. В одном из предыдущих примеров вывода !idt вектор 0x3b был подключен к нескольким объектам прерываний, связанным в цепочку (chained interrupt objects). Программные прерывания Хотя большинство прерываний генерируется аппаратно, ядро Windows тоже может генерировать прерывания — только они являются программными. Этот вид прерываний служит для решения многих задач, в том числе: 쐽 инициации диспетчеризации потоков; 쐽 обработки прерываний, не критичных по времени; 쐽 обработки событий таймеров; 쐽 асинхронного выполнения какойлибо процедуры в контексте конкрет ного потока; 쐽 поддержки асинхронного вводавывода. Эти задачи подробно рассматриваются ниже. Прерывания DPC или диспетчеризации Когда дальнейшее выпол нение потока невозможно, например изза его завершения или перехода в ждущее состояние, ядро напрямую обращается к диспетчеру, чтобы вызвать немедленное переключение контекста. Однако иногда ядро обнаруживает, что перераспределение процессорного времени (rescheduling) должно про изойти при выполнении глубоко вложенных уровней кода. В этой ситуации ядро запрашивает диспетчеризацию, но саму операцию откладывает до вы полнения текущих действий. Такую задержку удобно организовать с помо щью программного прерывания DPC (deferred procedure call). При необходимости синхронизации доступа к разделяемым структурам ядра последнее всегда повышает IRQL процессора до уровня «DPC/dispatch» или выше. При этом дополнительные программные прерывания и диспет черизация потоков запрещаются. Обнаружив необходимость в диспетчери зации, ядро генерирует прерывание уровня «DPC/dispatch». Но поскольку IRQL уже находится на этом уровне или выше, процессор откладывает об работку этого прерывания. Когда ядро завершает свои операции, оно опре деляет, что должно последовать снижение IRQL ниже уровня «DPC/dispatch», и проверяет, не ожидают ли выполнения отложенные прерывания диспет черизации. Если да, IRQL понижается до уровня «DPC/dispatch», и эти отло женные прерывания обрабатываются. Активизация диспетчера потоков че рез программное прерывание — способ отложить диспетчеризацию до под ходящего момента. Однако Windows использует программные прерывания для отложенного выполнения и других операций.
ГЛАВА 9 Системные механизмы 113 При этом IRQL ядро обрабатывает не только диспетчеризацию потоков, но и DPC. DPC — это функция, выполняющая системную задачу, менее кри тичную по времени в сравнении с текущей. Эти функции называются отло женными (deferred), так как не требуют немедленного выполнения. DPC позволяют операционной системе генерировать прерывания и вы полнять системные функции в режиме ядра. Ядро использует DPC для обра ботки прерываний по таймеру (и освобождения потоков, ждущих на тайме рах), а также для перераспределения процессорного времени по истечении кванта времени, отведенного текущему потоку. Драйверы устройств исполь зуют DPC для выполнения запросов вводавывода. Для своевременного об служивания аппаратных прерываний Windows — во взаимодействии с драй верами устройств — пытается удерживать текущий IRQL ниже IRQL уст ройств. Один из способов достижения этой цели заключается в следующем. ISR должна выполнять минимум действий по обслуживанию своего устрой ства, сохранять переменные данные о состоянии прерывания и откладывать передачу данных или выполнение других не столь критичных по времени операций, как DPC, до снижения IRQL к уровню «DPC/dispatch» (подробнее о DPC и системе вводавывода см. главу 9). DPC представляется DPC объектом, управляющим объектом ядра, неви димым программам пользовательского режима, но видимым драйверам и системному коду. Наиболее важной частью информации DPCобъекта явля ется адрес системной функции, которую ядро должно вызвать для обработ ки прерывания DPC. DPCпроцедуры, ожидающие выполнения, хранятся в управляемых ядром очередях (по одной на каждый процессор). Эти очере ди называются очередями DPC. Запрашивая DPC, системный код вызывает ядро для инициализации DPCобъекта и помещает его в очередь DPC. По умолчанию ядро помещает DPCобъекты в конец очереди DPC про цессора, на котором был запрошен DPC (как правило, это процессор, на ко тором выполняется ISR). Однако драйвер устройства может изменить это, указав приоритет DPC (низкий, средний или высокий; по умолчанию — сред ний) или направив DPC конкретному процессору. DPC, направленный кон кретному процессору, называется целевым DPC (targeted DPC). Если у DPC низкий или средний приоритет, ядро помещает DPCобъект в конец очере ди, а если у DPC высокий приоритет, то — в начало. Когда IRQL процессора вотвот понизится с уровня «DPC/dispatch» или более высокого до уровня «APC» или «passive», ядро переходит к обработке всех DPC. Windows оставляет IRQL на уровне «DPC/dispatch» и извлекает все DPCобъекты из очереди данного процессора (т. е. ядро опустошает оче редь), поочередно вызывая каждую DPCфункцию. Ядро разрешает умень шить IRQL ниже уровня «DPC/dispatch» для продолжения выполнения обыч ных потоков только после опустошения очереди. Схема обработки DPC по казана на рис. 37.
114 ГЛ А В А 3 Рис. 3-7. БЕЗОПАСНОСТЬ Обработка DPC Приоритеты DPC могут влиять на поведение системы и иным способом. Обычно ядро начинает опустошение очереди DPC с прерывания уровня «DPC/dispatch». Такое прерывание генерируется ядром, только если DPC на правлен на процессор, на котором выполняется ISR, и DPC имеет средний или высокий приоритет. Если у DPC низкий приоритет, ядро генерирует прерывание, только если число незавершенных запросов DPC превышает пороговое значение или если число DPC, запрошенных на процессоре за установленный период, невелико. Если DPC направлен другому процессору (не тому, на котором выполняется ISR) и его приоритет высокий, ядро не медленно посылает ему диспетчерское IPI, сигнализируя целевому процес сору о необходимости опустошения его очереди DPC. Если приоритет DPC средний или низкий, для появления прерывания «DPC/dispatch» число DPC в очереди целевого процессора должно превышать пороговое значение. Системный поток простоя также опустошает очередь DPC процессора, на котором он выполняется. Хотя уровни приоритета и направление DPC яв ляются довольно гибкими средствами, у драйверов устройств редко возни кает необходимость в изменении заданного по умолчанию поведения сво их DPCобъектов. В таблице 31 даются сведения о ситуациях, в которых начинается опустошение очереди DPC. Таблица 3-1. Правила генерации прерываний DPC Приоритет DPC DPC, направленный на процессор ISR DPC, направленный на другой процессор Низкий Длина очереди DPC превышает по Длина очереди DPC превышает роговое значение, или частота зап пороговое значение, или систе росов DPC ниже минимальной ма не занята Средний Всегда Длина очереди DPC превышает пороговое значение, или систе ма не занята Высокий Всегда Всегда
ГЛАВА 9 Системные механизмы 115 Поскольку потоки пользовательского режима выполняются при низком IRQL, вероятность того, что DPC прервет выполнение обычного пользова тельского потока, довольно велика. DPCпроцедуры выполняются независи мо от того, какой поток работает в настоящий момент. Это означает, что выполняемая DPCпроцедура не в состоянии предугадать текущий размер спроецированного адресного пространства процесса. DPCпроцедуры мо гут вызывать функции ядра, но не могут обращаться к системным сервисам, генерировать ошибки страницы, создавать или ждать объекты диспетчера. Однако они способны получать доступ к неподкачиваемым областям сис темной памяти, поскольку системное адресное пространство всегда спрое цировано независимо от того, что представляет собой текущий процесс. DPC используются не только драйверами, но и ядром. Ядро чаще всего применяет DPC для обработки ситуации, когда истекает выделенный квант времени. При каждом такте системного таймера генерируется прерывание с IRQLуровнем «clock». Обработчик прерываний таймера (выполняемый при IRQL, равном «clock») обновляет системное время и уменьшает значение счетчика, отслеживающего время выполнения текущего потока. Когда зна чение счетчика обнуляется, квант времени, отведенный потоку, заканчива ется, и ядру может понадобиться перераспределить процессорное время — эта задача имеет более низкий приоритет и должна выполняться при IRQL, равном «DPC/dispatch». Обработчик прерываний таймера ставит DPC в оче редь, чтобы инициировать диспетчеризацию потоков, после чего заверша ет свою работу и понижает IRQL процессора. Поскольку приоритет преры ваний DPC ниже, чем аппаратных, перед генерацией прерывания DPC сна чала обрабатываются все аппаратные прерывания, возникающие до завер шения обработки прерывания таймера. ЭКСПЕРИМЕНТ: мониторинг активности прерываний и DPC Process Explorer позволяет вести мониторинг активности прерываний и DPC, добавив столбец Context Switch Delta и наблюдая за процесса ми Interrupt и DPC. Это не настоящие процессы, они показываются как процессы просто для удобства и не вызывают переключений контек ста. Счетчик переключений контекста в Process Explorer для этих псев допроцессов отражает число возникновений каждого из них в тече ние предыдущего интервала обновления (refresh interval). Вы можете имитировать активность прерываний и DPC, быстро перемещая кур сор мыши по экрану. см. след. стр.
116 ГЛ А В А 3 БЕЗОПАСНОСТЬ Вы также можете проследить выполнение конкретных процедур обслуживания прерываний (ISR) и отложенных вызовов процедур (DPC), используя встроенную поддержку трассировки событий (под робнее об этом будет рассказано позже) в Windows XP Service Pack 2 или Windows Server 2003 Service Pack 1 (и выше). 1. Инициируйте захват событий, введя команду: tracelog start f kernel.etl b 64 –UsePerfCounter eflag 8 0x307 0x4084 0 0 0 0 0 0 2. Остановите захват событий, введя: tracelog stop 3. Создайте отчеты по захваченным событиям, набрав команду: tracerpt kernel.etl df o report Это приведет к генерации двух файлов: workload.txt и dumpfile.csv. 4. Откройте workload.txt и вы увидите сводные сведения о времени, проведенном драйверами каждого типа в ISR и DPCпроцедурах. 5. Откройте файл dumpfile.csv, созданный на этапе 3; найдите строки, где во втором значении встречается «DPC» или «ISR». Например, следующие три строки из dumpfile.csv показывают DPC таймера, DPC и ISR: PerfInfo, 0, PerfInfo, 0, PerfInfo, 0, TimerDPC, 0xFFFFFFFF, 127383953645422825, 0, 127383953645421500, 0xFB03A385, 0, 0 DPC, 0xFFFFFFFF, 127383953645424040, 0, 127383953645421394, 0x804DC87D, 0, 0 ISR, 0xFFFFFFFF, 127383953645470903, 0, 127383953645468696, 0xFB48D5E0, 0, 0, 0 Введя команду ln в отладчике ядра и указав начальный адрес из каж дой записи события (восьмое значение в каждой строке), вы увидите имя функции, выполнявшей DPC или ISR: lkd> ln 0xFB03A385 (fb03a385) rdbss!RxTimerDispatch | (fb03a41e) rdbss!RxpWorkerThreadDispatcher lkd> ln 0x804DC87D (804dc87d) nt!KiTimerExpiration | (804dc93b) nt!KeSetTimerEx lkd> ln 0xFB48D5E0 (fb48d5e0) atapi!IdePortInterrupt | (fb48d622) atapi!IdeCheckEmptyChannel Первый адрес относится к DPC, вызванному срабатыванием тайме ра, который был поставлен в очередь клиентским драйвером редирек тора файловой системы (file system redirector client driver). Второй от носится к DPC, вызванному срабатыванием универсального таймера
ГЛАВА 9 Системные механизмы 117 (generic timer). Наконец, третий — это адрес ISR для портдрайвера ATAPI. Более подробные сведения см. по ссылке http://www.microsoft. com/whdc/driver/perform/mmdrv.mspx. Прерывания APC APC (asynchronous procedure call) позволяет выпол нять пользовательские программы и системный код в контексте конкретно го пользовательского потока (а значит, и в адресном пространстве конкрет ного процесса). Поскольку для выполнения в контексте конкретного пото ка APC ставятся в очередь и выполняются при IRQL ниже «DPC/dispatch», на их работу не налагаются ограничения, свойственные DPC. APCпроцедура может обращаться к ресурсам (объектам), ждать освобождения описателей объектов, генерировать ошибки страниц и вызывать системные сервисы. APC описывается управляющим объектом ядра — APC объектом. APC, ждущие выполнения, находятся в очереди APC (APC queue), управляемой яд ром. Очереди APC — в отличие от общесистемной очереди DPC — специ фичны для конкретного потока, так как у каждого потока своя очередь APC. При запросе на постановку APC в очередь ядро помещает его (APC) в оче редь того потока, который будет выполнять APCпроцедуру. Далее ядро ге нерирует программное прерывание с уровнем APC, и поток, когда он в ко нечном счете начинает выполняться, обрабатывает APC. APC бывают двух видов: режима ядра и пользовательского режима. APC режима ядра для выполнения в контексте целевого потока не нужно «разре шение» со стороны этого потока, тогда как для APC пользовательского ре жима это обязательно. APC режима ядра прерывает поток и выполняет про цедуру без вмешательства или согласия потока. APC режима ядра тоже бы вают двух типов: обычные (normal) и специальные (special). Поток может отключить все APC режима ядра, повысив IRQL до уровня APC_LEVEL или вызвав KeEnterGuardedRegion, которая впервые появилась в Windows Server 2003. KeEnterGuardedRegion отключает доставку APC, устанавливая поле Spe cialApcDisable в структуре KTHREAD вызвавшего потока (об этой структуре см. главу 6). Поток также может отключить только обычные APC режима ядра вызовом KeEnterCriticalRegion, которая устанавливает поле KernelApcDisable в структуре KTHREAD потока. Исполнительная система использует APC режима ядра для тех задач опе рационной системы, которые нужно выполнить в адресном пространстве (контексте) конкретного потока. Так, через специальные APC режима ядра она может указать потоку прекратить выполнение системного сервиса, до пускающего прерывание, или записать результаты операции асинхронного вводавывода в адресное пространство этого потока. Подсистемы окружения используют такие APC, чтобы приостановить поток или завершить себя, а также чтобы получить или установить контекст пользовательского потока. Подсистема POSIX эмулирует через APC режима ядра передачу POSIXсигна лов процессам POSIX. Драйверы устройств также применяют APC режима ядра. Например, если инициирована операция вводавывода и поток переходит в состояние ожи
118 ГЛ А В А 3 БЕЗОПАСНОСТЬ дания, к процессору может быть подключен другой поток из другого про цесса. По завершении передачи данных устройством система вводавывода должна както вернуться в контекст потока, инициировавшего эту операцию вводавывода, чтобы он мог скопировать ее результаты в буфер в адресном пространстве своего процесса. Система вводавывода использует для выпол нения подобных действий специальные APC режима ядра (применение APC в системе вводавывода подробно рассматривается в главе 9). Некоторые Windowsфункции вроде ReadFileEx, WriteFileEx и QueueUser APC вызывают APC пользовательского режима. Так, функции ReadFileEx и WriteFileEx позволяют вызывающей программе указать процедуру заверше ния вводавывода (completion procedure), которая будет вызвана по оконча нии операции вводавывода. Процедура завершения вводавывода реализу ется помещением APC в очередь потока, выдавшего запрос на вводвывод. Однако обратный вызов процедуры завершения не обязательно происходит в момент постановки APC в очередь, поскольку APC пользовательского ре жима передаются потоку, только если он находится в состоянии тревожно го ожидания (alertable wait state). Поток может перейти в такое состояние, вызвав одну из Windowsфункций: либо WaitForMultipleObjectsEx, либо Sleep Ex. В обоих случаях, как только в очереди появится APC пользовательского режима, ядро прервет поток, передаст управление APCпроцедуре и возоб новит его выполнение лишь после завершения APCпроцедуры. В отличие от APC режима ядра, которые выполняются на уровне «APC», APC пользователь ского режима выполняются на уровне «passive». Появление APC может переупорядочить очереди ожидания — списки, определяющие, какие потоки ждут, в каком порядке и на каких объектах (см. раздел по синхронизации далее в этой главе). Если в момент появления APC поток находится в состоянии ожидания, то после обработки APCпроцеду ры поток возвращается в состояние ожидания, но перемещается в конец списка потоков, ждущих те же объекты. Диспетчеризация исключений В отличие от прерываний, которые могут возникать в любой момент, исклю чения являются прямым следствием действий выполняемой программы. Windows вводит понятие структурной обработки исключений (structured exception handling, SEH), позволяющей приложениям получать управление при возникновении исключений. При этом приложение может исправить ситуацию, которая привела к исключению, провести раскрутку стека (завер шив таким образом выполнение подпрограммы, вызвавшей исключение) или уведомить систему о том, что данное исключение ему не известно, и тогда система продолжит поиск подходящего обработчика для данного ис ключения. В этом разделе мы исходим из того, что вы знакомы с базовыми концепциями структурной обработки исключений Windows; в ином случае сначала прочитайте соответствующую часть справочной документации Win dows API из Platform SDK или главы 23–25 из четвертого издания книги Джеффри Рихтера «Windows для профессионалов». Учтите: хотя обработка
ГЛАВА 9 Системные механизмы 119 исключений возможна через расширения языка программирования (напри мер, с помощью конструкции __try в Microsoft Visual C++), она является сис темным механизмом и поэтому не зависит от конкретного языка. В системах типа x86 все исключения имеют предопределенные номера прерываний, прямо соответствующие записям в IDT, ссылающимся на обра ботчики ловушек конкретных исключений. В таблице 32 перечислены ис ключения, определенные для систем типа x86, с указанием номеров преры ваний. Как уже говорилось, первая часть IDT используется для исключений, а аппаратные прерывания располагаются за ней. Таблица 3-2. Исключения в системах типа x86 и соответствующие им номера прерываний Номер прерывания Исключение 0 Divide Error (ошибка деления) 1 DEBUG TRAP (ловушка отладки) 2 NMI/NPX Error (ошибка NMI/NPX) 3 Breakpoint (точка прерывания) 4 Overflow (переполнение) 5 BOUND/Print Screen 6 Invalid Opcode (неправильный код операции) 7 NPX Not Available (NPX недоступен) 8 Double Exception (двойное исключение) 9 NPX Segment Overrun (выход за пределы сегмента NPX) A Invalid Task State Segment (TSS) (неправильный TSS) B Segment Not Present (сегмент отсутствует) C Stack Fault (ошибка стека) D General Protection (ошибка общей защиты) E Page Fault (ошибка страницы) F Зарезервировано Intel 10 Floating Point (ошибка в операции с плавающей точкой) 11 Alignment Check (ошибка контроля выравнивания) Все исключения, кроме достаточно простых, которые могут быть разре шены обработчиком ловушек, обслуживаются модулем ядра — диспетчером исключений (exception dispatcher). Его задача заключается в поиске обработ чика, способного «справиться» с данным исключением. Примерами незави симых от архитектуры исключений могут служить нарушения доступа к па мяти, целочисленное деление на нуль, переполнение целых чисел, исключе ния при операциях с плавающей точкой и точки прерывания отладчика. Полный список независимых от архитектуры исключений см. в справочной документации Windows API. Ядро перехватывает и обрабатывает некоторые из этих исключений про зрачно для пользовательских программ. Так, если при выполнении отлажи ваемой программы встретилась точка прерывания, генерируется исключе
120 ГЛ А В А 3 БЕЗОПАСНОСТЬ ние, обрабатываемое ядром за счет вызова отладчика. Ряд исключений ядро обрабатывает, просто возвращая код неудачной операции. Определенные исключения могут передаваться в неизменном виде поль зовательским процессам. Например, при ошибке доступа к памяти или при переполнении в ходе арифметической операции генерируется исключение, не обрабатываемое операционной системой. Для обработки этих исключений подсистема окружения может устанавливать обработчики исключений на основе SEH фрейма (далее для краткости — обработчик SEHфрейма). Этим термином обозначается обработчик исключения, сопоставленный с вызовом конкретной процедуры. При активизации такой процедуры в стек заталкива ется стековый фрейм, представляющий вызов этой процедуры. Со стековым фреймом можно сопоставить один или несколько обработчиков исключений, каждый из которых защищает определенный блок кода исходной програм мы. При возникновении исключения ядро ищет обработчик, сопоставленный с текущим стековым фреймом. Если его нет, ядро ищет обработчик, сопостав ленный с предыдущим стековым фреймом, — и так до тех пор, пока не будет найден подходящий обработчик. Если найти обработчик исключения не уда лось, ядро вызывает собственные обработчики по умолчанию. Когда происходит исключение (аппаратное или программное), цепочка событий начинается в ядре. Процессор передает управление обработчику ловушки в ядре, который создает фрейм ловушки по аналогии с тем, как это происходит при прерывании. Фрейм ловушки позволяет системе после об работки исключения возобновить работу с той точки, где она была прерва на. Обработчик ловушки также создает запись исключения, содержащую све дения о ее причине и другую сопутствующую информацию. Если исключение возникает в режиме ядра, то для его обработки диспет чер исключений просто вызывает процедуру поиска подходящего обработ чика SEHфрейма. Поскольку необработанные исключения режима ядра были бы фатальными ошибками операционной системы, диспетчер всегда находит какойнибудь обработчик. Если исключение возникает в пользовательском режиме, диспетчер исклю чений предпринимает более сложные действия. Как поясняется в главе 6, под система Windows предусматривает порт отладчика (debugger port) и порт исключений (exception port) для приема уведомлений об исключениях поль зовательского режима в Windowsпроцессах. Они применяются ядром при обработке исключений по умолчанию, как показано на рис. 38. Точки прерывания в отлаживаемой программе являются распространен ной причиной исключений. Поэтому диспетчер исключений первым делом проверяет, подключен ли к процессу, вызвавшему исключение, отладчик. Если подключен и системой является Windows 2000, диспетчер исключений посылает отладчику через LPC первое предупреждение. (Это уведомление на самом деле сначала поступает диспетчеру сеансов, а тот пересылает его со ответствующему отладчику.) В Windows XP и Windows Server 2003 диспетчер исключений посылает сообщение объекта отладчика (debugger object mes
ГЛАВА 9 Системные механизмы 121 sage) объекту отладки (debug object), сопоставленному с процессом (кото рый внутри системы рассматривается как порт). Рис. 3-8. Диспетчеризация исключений Если к процессу не подключен отладчик или если отладчик не в состоя нии обработать данное исключение, диспетчер исключений переключает ся в пользовательский режим, копирует фрейм ловушки в пользовательский стек, имеющий формат структуры данных CONTEXT (документирована в Platform SDK), и вызывает процедуру поиска обработчика SEHфрейма. Если поиск не дал результатов, диспетчер возвращается в режим ядра и снова вы зывает отладчик, чтобы пользователь мог продолжить отладку. При этом посылается второе (и последнее) предупреждение. Если отладчик не запущен и обработчики SEHфреймов не найдены, ядро посылает сообщение в порт исключений, сопоставленный с процессом по тока. Этот порт (если таковой есть) регистрируется подсистемой окружения, контролирующей данный поток. Порт исключений дает возможность под системе окружения (прослушивающей этот порт) транслировать исходное исключение в уведомление или исключение, специфичное для ее окружения. CSRSS (Client/Server RunTime Subsystem) просто выводит окно сообщения, уведомляющее пользователя о сбое, и завершает процесс. Когда подсистема POSIX получает от ядра сообщение о том, что один из потоков вызвал исклю чение, эта подсистема посылает вызвавшему исключение потоку сигнал в стиле POSIX. Но, если ядро уже дошло до этого этапа в обработке исключе ния, а подсистема не способна обработать данное исключение, выполняет ся обработчик ядра по умолчанию, просто завершающий процесс, поток которого вызвал исключение. Необработанные исключения На вершине стека любого Windowsпотока объявляется обработчик, имею щий дело с необработанными исключениями. За объявление отвечает внут
122 ГЛ А В А 3 БЕЗОПАСНОСТЬ ренняя Windowsфункция start of process или start of thread. Функция start of process срабатывает в момент начала выполнения первого потока процес са. Она вызывает главную точку входа в образе. Функция start of thread вы полняется при создании дополнительных потоков в процессе и вызывает стартовую процедуру, указанную в вызове CreateThread. ЭКСПЕРИМЕНТ: определение истинного стартового адреса Windows-потоков Тот факт, что выполнение каждого Windowsпотока начинается с сис темной (а не пользовательской) функции, объясняет, почему у каждо го Windowsпроцесса стартовый адрес нулевого потока одинаков (как и стартовые адреса вторичных потоков). Стартовый адрес нулевого потока Windowsпроцессов соответствует Windowsфункции start of process, а стартовые адреса остальных потоков являются адресом Win dowsфункции start of thread. Для определения адреса пользовательс кой функции применим утилиту Tlist из Windows Support Tools. Для по лучения детальной информации о процессе наберите tlist имя_про цесса или tlist идентификатор_процесса. Например, сравним стартовый адрес процесса Windows Explorer, сообщаемый утилитой Pstat (из Platform SDK), и стартовый адрес Tlist. C:\> pstat ... pid:3f8 pri: 8 Hnd: 329 Pf: 80043 Ws: tid pri Ctx Swtch StrtAddr User Time 7c 9 16442 77E878C1 0:00:01.241 42c 11 157888 77E92C50 0:00:07.110 44c 8 6357 77E92C50 0:00:00.070 1cc 8 3318 77E92C50 0:00:00.030 ... 4620K explorer.exe Kernel Time State 0:00:01.251 Wait:UserRequest 0:00:34.309 Wait:UserRequest 0:00:00.140 Wait:UserRequest 0:00:00.070 Wait:DelayExecution C:\> tlist explorer 1016 explorer.exe Program Manager CWD: C:\ CmdLine: Explorer.exe VirtualSize: 25348 KB PeakVirtualSize: 31052 KB WorkingSetSize: 1804 KB PeakWorkingSetSize: 3276 KB NumberOfThreads: 4 149 Win32StartAddr:0x01009dbd LastErr:0x0000007e State:Waiting 86 Win32StartAddr:0x77c5d4a5 LastErr:0x00000000 State:Waiting 62 Win32StartAddr:0x00000977 LastErr:0x00000000 State:Waiting 179 Win32StartAddr:0x0100d8d4 LastErr:0x00000002 State:Waiting ... Стартовый адрес нулевого потока, сообщаемый Pstat, соответству ет внутренней Windowsфункции start of process, а стартовые адреса потоков 1–3 указывают адреса внутренних Windowsфункций start of thread. С другой стороны, Tlist показывает стартовый адрес пользова
ГЛАВА 9 Системные механизмы 123 тельской функции, вызываемой внутренней стартовой Windowsфунк цией. Поскольку большинство потоков в Windowsпроцессах начинает ся в одной из системных функцийоболочек, Process Explorer, показы вая стартовые адреса потоков в процессе, пропускает фрейм началь ного вызова, представляющий функциюоболочку, и вместо этого ото бражает второй фрейм в стеке. Например, обратите внимание на стар товый адрес потока в процессе, выполняющем Notepad.exe. Process Explorer не выводит всю иерархию вызовов при отображе нии стека вызовов. Вот что вы получите, щелкнув кнопку Stack. В строке 12 на этой иллюстрации показан первый фрейм в сте ке — начало процессаоболочки. Второй фрейм (строка 11) является основной точкой входа в Notepad.exe. Базовый код внутренних стартовых функций выглядит так: void Win32StartOfProcess( LPTHREAD_START_ROUTINE lpStartAddr, LPVOID lpvThreadParm){ __try {
124 ГЛ А В А 3 БЕЗОПАСНОСТЬ DWORD dwThreadExitCode = lpStartAddr(lpvThreadParm); ExitThread(dwThreadExitCode); } __except(UnhandledExceptionFilter( GetExceptionInformation())) { ExitProcess(GetExceptionCode()); } } Заметьте: если при выполнении потока возникает исключение, не обра батываемое этим потоком, вызывается Windowsфильтр необработанных исключений. Эта функция реализует поведение системы, когда та обнаружи вает необработанное исключение. Поведение зависит от содержимого раз дела реестра HKLM\Software\Microsoft\Windows NT\CurrentVersion\AeDebug. В нем есть два важных параметра: Auto и Debugger. Auto сообщает фильтру необработанных исключений, надо ли автоматически запускать отладчик или спросить у пользователя, что делать. По умолчанию этому параметру присваивается 1, что подразумевает автоматический запуск отладчика. Од нако после установки средств разработки вроде Visual Studio его значение меняется на 0. Параметр Debugger является строкой, которая указывает путь к исполняемому файлу отладчика, который следует запускать при появлении необработанного исключения. Отладчик по умолчанию — \Windows\System32\Drwtsn32.exe (Dr. Wat son), который на самом деле является не отладчиком, а утилитой, сохраня ющей сведения о рухнувшем приложении в файле журнала (Drwtsn32.log) и обрабатывающей файл аварийного дампа (User.dmp). Оба этих файла по умолчанию помещаются в папку \Documents And Settings\All Users\ Docu ments\DrWatson. Для просмотра или изменения конфигурации утилиту Dr. Watson можно запустить в интерактивном режиме; при этом выводится окно с текущими параметрами (пример для Windows 2000 показан на рис. 39). Рис. 3-9. Параметры Dr. Watson (Доктор Ватсон) по умолчанию
ГЛАВА 9 Системные механизмы 125 Файл журнала содержит такую базовую информацию, как код исключе ния, имя рухнувшего образа, список загруженных DLL, а также содержимое стека и последовательность команд потока, вызвавшая исключение. Более подробные сведения о содержимом этого файла можно получить, запустив Dr. Watson и щелкнув кнопку Help (Справка) в его окне. В файл аварийного дампа записывается содержимое закрытых страниц процесса на момент возникновения исключения (но страницы кода из EXE и DLLмодулей не включаются). Этот файл можно открыть с помощью Win Dbg — Windowsотладчика, поставляемого с пакетом Debugging Tools или с Visual Studio 2003 и выше). Файл аварийного дампа перезаписывается при каждом крахе процесса. Поэтому, если его предварительно не скопировать или не переименовать, в нем будет содержаться информация лишь о послед нем крахе процесса. В Windows 2000 Professional визуальное уведомление включено по умол чанию. Окно сообщения, представленное на рис. 310, выводится Dr. Watson после того, как он сгенерирует аварийный дамп и запишет информацию в свой файл журнала. Рис. 3-10. Сообщение об ошибке от Dr. Watson (Windows 2000) Процесс Dr. Watson остается до тех пор, пока не будет закрыто это окно, и именно поэтому в Windows 2000 Server визуальное уведомление по умол чанию отключено. Дело вот в чем. Обычно сервер находится в отдельной комнате и возле него никто не сидит. Если на сервере рушится какоето при ложение, то подобное окно просто некому закрыть. По этой причине сер верные приложения должны регистрировать ошибки в журнале событий Windows. В Windows 2000, если параметр Auto установлен в 0, отображается окно, приведенное на рис. 311. Рис. 3-11. Сообщение о необработанном исключении (Windows 2000) После щелчка кнопки OK процесс завершается. А если вы нажимаете кнопку Cancel, запускается системный отладчик (заданный параметром De bugger в реестре).
126 ГЛ А В А 3 БЕЗОПАСНОСТЬ ЭКСПЕРИМЕНТ: необработанные исключения Чтобы увидеть образец файла журнала Dr. Watson, запустите программу Accvio.exe, которую можно скачать по ссылке www.sysinternals.com/win dowsinternals.shtml. Эта программа вызовет нарушение доступа (ошибку защиты памяти) при попытке записи по нулевому адресу, всегда недей ствительному для Windowsпроцессов (см. таблицу 76 в главе 7). 1. Запустите Registry Editor (Редактор реестра) и найдите раздел HKLM\ SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug. 2. Если значение параметра Debugger равно «drwtsn32 p %ld e %ld  g», ваша система настроена на использование Dr. Watson в качестве отладчика по умолчанию. Переходите в п. 4. 3. Если в параметре Debugger не указан Drwtsn32.exe, вы все равно можете протестировать Dr. Watson, временно установив его, а затем восстановив исходные параметры своего отладчика: 쐽 сохраните гденибудь текущее значение параметра (например, в файле Notepad или в буфере обмена); 쐽 выберите из меню Start (Пуск) команду Run (Выполнить) и вве дите команду drwtsn32 i (чтобы инициализировать параметр Debugger для запуска Dr. Watson). 4. Запустите тестовую программу Accvio.exe. 5. Вы должны увидеть одно из окон, описанных ранее (в зависимос ти от версии Windows, в которой вы работаете). 6. Если вы используете параметры Dr. Watson по умолчанию, то те перь сможете изучить файл журнала и файл дампа в каталоге фай лов дампов. Для просмотра параметров Dr. Watson, запустите drwt sn32 без аргументов. (Выберите из меню Start команду Run и введи те drwtsn32.) 7. В качестве альтернативы щелкните последнюю запись в списке Application Errors (Ошибки приложения) и нажмите кнопку View (Показать) — будет выведена часть файла журнала Dr. Watson, со держащая сведения о нарушении доступа, вызванном Accvio.exe. Если вас интересуют детали формата файла журнала, щелкните кнопку Help (Справка) и выберите раздел Dr. Watson Log File Over view (Обзор файла журнала доктора Ватсона). 8. Если Dr. Watson не был отладчиком по умолчанию, восстановите исходное значение, сохраненное в п. 1. Проведите еще один эксперимент: попробуйте перенастроить пара метр Debugger на другую программу, например Notepad.exe (Блокнот) или Sol.exe (Solitaire). Снова запустите Accvio.exe. Обратите внимание, что запускается любая программа, указанная в параметре Debugger. То есть система не проверяет, действительно ли указанная в этом парамет ре программа является отладчиком. Обязательно восстановите исход ные значения параметров реестра (введите drwtsn32 i).
ГЛАВА 9 Системные механизмы 127 Windows-поддержка отчетов об ошибках В Windows XP и Windows Server 2003 появился новый, более изощренный механизм отчетов об ошибках, называемый Windows Error Reporting. Он ав томатизирует передачу информации о крахе как в пользовательском режи ме, так и в режиме ядра. (Как применить этот механизм для получения све дений о крахе системы, см. главу 14.) Windows Error Reporting можно настроить, последовательно выбрав My Computer (Мой компьютер), Properties (Свойства), Advanced (Дополнитель но) и Error Reporting (Отчет об ошибках) (на экране появится диалоговое окно, показанное на рис. 312); то же самое можно сделать через парамет ры локальной или доменной политики группы, которые хранятся в разделе реестра HKLM\Software\Microsoft\PCHealth\ErrorReporting. Рис. 3-12. Диалоговое окно настройки отчетов об ошибках Перехватив необработанное исключение (об этом шла речь в предыду щем разделе), фильтр необработанных исключений выполняет начальную проверку, чтобы решить, надо ли запустить механизм Windows Error Repor ting. Если параметр реестра HKLM\SOFTWARE\Microsoft\Windows NT\Current Version\AeDebug\Auto установлен в 0 или строка Debugger содержит текст «Drwtsn32», фильтр необработанных исключений загружает в аварийный процесс библиотеку \Windows\System32\Faultrep.dll и вызывает ее функцию ReportFault. Эта функция проверяет конфигурацию механизма отчетов об ошибках, которая хранится в разделе HKLM\Software\Microsoft\PCHealth\ ErrorReporting, и определяет, следует ли формировать отчет для данного процесса и, если да, то как. В обычном случае ReportFault создает процесс, выполняющий \Windows\System32\Dwwin.exe, который выводит окно, где пользователь уведомляется о крахе процесса и где ему предоставляется воз можность передать отчет об ошибках в Microsoft (рис. 313).
128 ГЛ А В А 3 Рис. 3-13. БЕЗОПАСНОСТЬ Диалоговое окно, выводимое Windows Error Reporting При щелчке кнопки Send Error Report (Послать отчет), отчет об ошибках (минидамп и текстовый файл с детальными сведениями о номерах версий DLL, загруженных в рухнувший процесс) передается на онлайновый сервер анализа аварийных ситуаций, Watson.Microsoft.com. (В отличие от краха сис темы в режиме ядра здесь нет возможности найти какоелибо решение на момент отправки отчета.) Затем фильтр необработанных исключений созда ет процесс для запуска отладчика (обычно Drwtsn32.exe), который по умол чанию создает свой файл дампа и запись в журнале. В отличие от Windows 2000 этот файл содержит не полный дамп, а минидамп. Поэтому в ситуации, где для отладки рухнувшего приложения нужен полный дамп памяти процес са, вы можете изменить конфигурацию Dr. Watson, запустив его без аргумен тов командной строки, как было описано в предыдущем разделе. В средах, где системы не подключены к Интернету или где администра тор хочет контролировать, какие именно отчеты об ошибках посылаются в Microsoft, эти отчеты можно передавать на внутренний файлсервер. Micro soft предоставляет опытным заказчикам утилиту Corporate Error Reporting, которая понимает структуру каталогов, создаваемую Windows Error Repor ting, и позволяет администратору задавать условия, при которых отчеты формируются и передаются в Microsoft. (Подробности см. по ссылке http:// www.microsoft.com/resources/satech/cer.) Диспетчеризация системных сервисов Как показано на рис. 31, обработчики ловушек ядра обслуживают прерывания, исключения и вызовы системных сервисов. Из предыдущих разделов вы знае те, как проводится обработка прерываний и исключений. Здесь будет расска зано о вызовах системных сервисов. Диспетчеризация системных сервисов начинается с выполнения инструкции, закрепленной за такой диспетчериза цией. Эта инструкция зависит от процессора, на котором работает Windows. Диспетчеризация 32-разрядных системных сервисов На процессорах x86 до Pentium II использовалась инструкция int 0x2e (де сятичное значение 46). В результате выполнения этой инструкции срабаты вает ловушка, и Windows заносит в запись IDT под номером 46 указатель на
ГЛАВА 9 Системные механизмы 129 диспетчер системных сервисов (см. таблицу 31). Эта ловушка заставляет выполняемый поток переключиться в режим ядра и войти в диспетчер сис темных сервисов. Номер запрошенного системного сервиса указывается числовым аргументом, переданным в регистр процессора EAX. Содержимое регистра EBX указывает на список параметров, передаваемый системному сервису вызывающей программой. На x86процессорах Pentium II и выше Windows использует инструкцию sysenter, которую Intel специально определил для быстрой диспетчеризации системных сервисов. Для поддержки этой инструкции Windows сохраняет на этапе загрузки адрес процедуры ядра — диспетчера системных сервисов в регистре, сопоставленном с данной инструкцией. Выполнение инструкции приводит к переключению в режим ядра и запуску диспетчера системных сервисов. Номер системного сервиса передается в регистре процессора EAX, а регистр EDX указывает на список аргументов, предоставленных вызвавшим кодом. Для возврата в пользовательский режим диспетчер системных серви сов обычно выполняет инструкцию sysexit. (В некоторых случаях, например, когда в процессоре включен флаг single step, диспетчер системных сервисов использует вместо sysexit инструкцию iretd.) На 32разрядных процессорах AMD K6 и выше Windows применяет спе циальную инструкцию syscall, которая функционирует аналогично x86ин струкции sysenter; Windows записывает в регистр процессора, связанный с инструкцией syscall, адрес диспетчера системных сервисов ядра. Номер сис темного вызова передается в регистре EAX, а в стеке хранятся аргументы, предоставленные вызвавшим кодом. После диспетчеризации ядро выполня ет инструкцию sysret. При загрузке Windows распознает тип процессора, на котором она рабо тает, и выбирает подходящий системный код. Этот код для NtReadFile в поль зовательском режиме выглядит так: ntdll!NtReadFile: 77f5bfa8 b8b7000000 77f5bfad ba0003fe7f 77f5bfb2 ffd2 77f5bfb4 c22400 mov mov call ret eax,0xb7 edx,0x7ffe0300 edx 0x24 Номер системного сервиса — 0xb7 (183 в десятичной форме), инструк ция вызова выполняет код диспетчеризации системного сервиса, установ ленный ядром, который в данном примере находится по адресу 0x7ffe0300. Поскольку пример взят для Pentium M, используется sysenter: SharedUserData!SystemCallStub: 7ffe0300 8bd4 mov edx,esp 7ffe0302 0f34 sysenter 7ffe0304 c3 ret
130 ГЛ А В А 3 БЕЗОПАСНОСТЬ Диспетчеризация 64-разрядных системных сервисов В архитектуре x64 операционная система Windows использует инструкцию syscall, которая работает аналогично инструкции syscall на процессорах AMD K6. Windows передает номер системного вызова в регистре EAX, первые че тыре параметра в других регистрах, а остальные параметры (если они есть) в стеке: ntdll!NtReadFile: 00000000'77f9fc60 00000000'77f9fc63 00000000'77f9fc68 00000000'77f9fc6a 4c8bd1 b8bf000000 0f05 c3 mov r10,rcx mov eax,0xbf syscall ret В архитектуре IA64 для тех же целей применяется инструкция epc (Enter Privileged Mode). Первые восемь аргументов системного вызова передаются в регистрах, а остальное в стеке. Диспетчеризация системных сервисов режима ядра Как показано на рис. 314, ядро использует номер системного сервиса для поиска информации о нем в таблице диспетчеризации системных серви сов (system service dispatch table). Эта таблица похожа на описанную ранее таблицу IDT и отличается от нее тем, что каждый ее элемент содержит ука затель на системный сервис, а не на процедуру обработки прерывания. ПРИМЕЧАНИЕ Номера системных сервисов могут различаться в раз ных сервисных пакетах (service packs) — Microsoft время от времени добавляет или удаляет некоторые системные сервисы, а их номера ге нерируются автоматически при компиляции ядра. Рис. 3-14. Исключения системных сервисов Диспетчер системных сервисов, KiSystemService, копирует аргументы выз вавшего кода из стека потока пользовательского режима в свой стек режи ма ядра (поэтому вызвавший код не может изменить значения аргументов после того, как они переданы ядру) и выполняет системный сервис. Если
ГЛАВА 9 Системные механизмы 131 переданные системному сервису аргументы содержат ссылки на буферы в пользовательском пространстве, код режима ядра проверяет возможность доступа к этим буферам, прежде чем копировать в них (или из них) данные. Как будет показано в главе 6, у каждого потока есть указатель на таблицу системных сервисов. Windows располагает двумя встроенными таблицами системных сервисов, но поддерживает до четырех. Диспетчер системных сервисов определяет, в какой таблице содержится запрошенный сервис, интерпретируя 2битное поле 32битного номера системного сервиса как указатель на таблицу. Младшие 12 битов номера системного сервиса служат индексом внутри указанной таблицы. Эти поля показаны на рис. 315. Рис. 3-15. Трансляция номера системного сервиса Таблицы дескрипторов сервисов Главная таблица по умолчанию, KeServiceDescriptorTable, определяет базовые сервисы исполнительной системы, реализованные в Ntoskrnl.exe. Другая таб лица, KeServiceDescriptorTableShadow, включает в себя сервисы USER и GDI, реализованные в Win32k.sys — той части подсистемы Windows, которая ра ботает в режиме ядра. Когда Windowsпоток впервые вызывает сервис USER или GDI, адрес таблицы системных сервисов потока меняется на адрес таб лицы, содержащей сервисы USER и GDI. Функция KeAddSystemServiceTable позволяет Win32k.sys и другим драйверам добавлять новые таблицы систем ных сервисов. Если в Windows 2000 установлены службы Internet Information Services (IIS), их драйвер поддержки (Spud.sys) после загрузки определяет
132 ГЛ А В А 3 БЕЗОПАСНОСТЬ дополнительную таблицу сервисов. Так что после этого стороннее про граммное обеспечение может определить только одну дополнительную таб лицу. Таблица сервисов, добавляемая KeAddSystemServiceTable (кроме табли цы Win32k.sys), копируется в таблицы KeServiceDescriptorTable и KeService DescriptorTableShadow. Windows поддерживает добавление лишь двух таблиц системных сервисов помимо главной и таблиц Win32. ПРИМЕЧАНИЕ Windows Server 2003 Service Pack 1 и выше не поддер живает добавление таблиц системных сервисов, если не считать те, которые включаются Win32k.sys, так что этот способ не годится для расширения функциональности этой системы. Инструкции для диспетчеризации сервисов исполнительной системы Windows содержатся в системной библиотеке Ntdll.dll. DLLмодули подсис тем окружения вызывают функции из Ntdll.dll для реализации своих доку ментированных функций. Исключением являются функции USER и GDI — здесь инструкции для диспетчеризации системных сервисов реализованы непосредственно в User32.dll и Gdi32.dll, а не в Ntdll.dll. Эти два случая иллю стрирует рис. 316. Рис. 3-16. Диспетчеризация системных сервисов
ГЛАВА 9 Системные механизмы 133 Как показано на рис. 316, Windowsфункция WriteFile в Kernel32.dll вы зывает функцию NtWriteFile из Ntdll.dll. Она в свою очередь выполняет соот ветствующую инструкцию, вызывающую срабатывание ловушки системно го сервиса и передающую номер системного сервиса NtWriteFile. Далее дис петчер системных сервисов (функция KiSystemService в Ntoskrnl.exe) вызы вает истинную NtWriteFile для обработки запроса на вводвывод. Для функ ций USER и GDI диспетчер системных сервисов вызывает функции из Win32k.sys, той части подсистемы Windows, которая работает в режиме ядра. ЭКСПЕРИМЕНТ: наблюдение за частотой вызова системных сервисов Вы можете наблюдать за частотой вызова системных сервисов с помо щью счетчика System Calls/Sec (Системных вызовов/сек) объекта Sys tem (Система). Откройте оснастку Performance (Производительность) и щелкните кнопку Add (Добавить), чтобы добавить на график счет чик. Выберите объект System и счетчик System Calls/Sec, затем щелк ните кнопки Add и Close (Закрыть). Диспетчер объектов Как говорилось в главе 2, реализованная в Windows модель объектов позво ляет получать согласованный и безопасный доступ к различным внутренним сервисам исполнительной системы. В этом разделе описывается диспетчер объектов (object manager) — компонент исполнительной системы, отвеча ющий за создание, удаление, защиту и отслеживание объектов. ЭКСПЕРИМЕНТ: исследование диспетчера объектов В этом разделе будут предлагаться эксперименты, которые покажут вам, как просмотреть базу данных диспетчера объектов. В них будут использоваться перечисленные ниже инструменты, которые вам нуж но освоить (если вы их еще не освоили). 쐽 Winobj можно скачать с сайта www.sysinternals.com. Она показывает пространство имен диспетчера объектов. Другая версия этой утили ты есть в Platform SDK (\Program Files\Microsoft Platform SDK\Bin\ Winnt\Winobj.exe). Однако версия с www.sysinternals.com сообщает более детальную информацию об объектах (например, счетчик ссы лок, число открытых описателей, дескрипторы защиты и т. д.). 쐽 Process Explorer и Handle с сайта www.sysinternals.com. Отображают открытые описатели для процесса. 쐽 Oh.exe (имеется в ресурсах Windows) выводит открытые описате ли для процесса, но требует предварительной установки специаль ного глобального флага. 쐽 Команда Openfiles /query (в Windows XP и Windows Server 2003) ото бражает открытые описатели для процесса, но требует предвари тельной установки специального глобального флага. см. след. стр.
134 ГЛ А В А 3 БЕЗОПАСНОСТЬ 쐽 Команда !handle отладчика ядра отображает открытые описатели для процесса. Средство просмотра объектов позволяет изучить пространство имен, поддерживаемое диспетчером объектов (имена есть не у всех объектов). Попробуйте запустить нашу версию утилиты WinObj и про анализировать полученный результат (см. иллюстрацию ниже). Как уже отмечалось, утилита OH и команда Openfiles /query требу ют установки глобального флага «поддержка списка объектов» (main tain objects list). (О глобальных флагах см. соответствующий раздел далее в этой главе.) OH установит этот флаг, если он еще не задан. Что бы узнать, включен ли данный флаг, введите Openfiles /Local. Вы мо жете включить его командой Openfiles /Local ON. В любом случае нуж но перезагрузить систему, чтобы новый параметр вступил в силу. Ни Process Explorer, ни Handle с сайта www.sysinternals.com не требуют включения слежения за объектами, потому что для получения соответ ствующей информации они используют драйвер устройства. При разработке диспетчера объекта был выдвинут ряд требований, в со ответствии с которыми он должен: 쐽 реализовать общий, унифицированный механизм использования систем ных ресурсов; 쐽 изолировать защиту объектов в одном участке операционной системы для соответствия требованиям безопасности класса С2; 쐽 предоставлять механизм учета использования объектов процессами, поз воляющий устанавливать лимиты на выделение процессам системных ресурсов;
ГЛАВА 9 Системные механизмы 135 쐽 поддерживать такую схему именования объектов, которая позволяла бы легко включать как существующие объекты (устройства, файлы и катало ги файловой системы), так и независимые наборы объектов; 쐽 соответствовать требованиям различных подсистем окружения операци онной системы — например, поддерживать наследование ресурсов роди тельских процессов дочерними (необходимо в Windows и POSIX) и име на файлов, чувствительные к регистру букв (требуется в POSIX); 쐽 устанавливать единообразные правила сохранения объектов в памяти (т. е. объект должен быть доступен, пока используется какимилибо процессами). В Windows существует два вида внутренних объектов: объекты исполни тельной системы (executive objects) и объекты ядра (kernel objects). Первые реализуются различными компонентами исполнительной системы (диспет чером процессов, диспетчером памяти, подсистемой вводавывода и т. д.). Вторые являются более примитивными объектами, которые реализуются ядром Windows. Эти объекты, невидимые коду пользовательского режима, создаются и используются только в исполнительной системе. Объекты ядра поддерживают фундаментальную функциональность (например, синхрони зацию), на которую опираются объекты исполнительной системы. Так, мно гие объекты исполнительной системы содержат (инкапсулируют) один или несколько объектов ядра, как показано на рис. 317. Рис. 3-17. Объекты исполнительной системы, включающие объекты ядра Структура объектов ядра и способы их применения для синхронизации других объектов будут рассмотрены в этой главе несколько позже. А сейчас мы сосредоточимся на принципах работы диспетчера объектов, а также на структуре объектов исполнительной системы, описателях и таблицах опи сателей. Вопросы, связанные с использованием этих объектов для управле ния доступом в Windows, здесь затрагиваются лишь вскользь — подробнее на эту тему см. главу 8.
136 ГЛ А В А 3 БЕЗОПАСНОСТЬ Объекты исполнительной системы Каждая подсистема окружения проецирует на свои приложения разные об разы операционной системы. Объекты исполнительной системы и сервисы объектов — именно те примитивы, из которых подсистемы окружения кон струируют собственные версии объектов и других ресурсов. Как правило, объекты исполнительной системы создаются подсистемой окружения в интересах пользовательских приложений или компонентов операционной системы в процессе обычной работы. Так, для создания фай ла Windowsприложение вызывает Windowsфункцию CreateFile, реализо ванную в DLL подсистемы Windows, Kernel32.dll. После проверки и инициа лизации CreateFile в свою очередь вызывает NtCreateFile, встроенный сервис Windows, для создания объекта «файл» исполнительной системы. Набор объектов, предоставляемый приложениям подсистемой окруже ния, может быть больше или меньше того набора, который предоставляет ся исполнительной системой. Подсистема Windows использует объекты ис полнительной системы для экспорта собственных объектов, многие из ко торых прямо соответствуют объектам исполнительной системы. Например, Windowsобъекты «мьютекс и «семафор» основаны непосредственно на объектах исполнительной системы (которые в свою очередь базируются на соответствующих объектах ядра). Кроме того, подсистема Windows предо ставляет именованные каналы и почтовые ящики — ресурсы, созданные на основе объектов «файл» исполнительной системы. Некоторые подсистемы вроде POSIX вообще не поддерживают объекты как таковые. Подсистема POSIX использует объекты и сервисы исполнительной системы просто как основу для POSIXпроцессов, каналов и других ресурсов, которые она пре доставляет своим приложениям. В таблице 33 кратко описываются основные объекты, предоставляемые исполнительной системой. Подробнее об объектах исполнительной систе мы см. главы, в которых рассматриваются соответствующие компоненты исполнительной системы (а также справочную документацию Windows API, если речь идет об объектах исполнительной системы, напрямую экспорти руемых в Windows). ПРИМЕЧАНИЕ В Windows 2000 исполнительная система реализует в общей сложности 27 типов объектов, а в Windows XP и Windows Server 2003 — 29. (В эти более новые версии Windows добавлены объекты DebugObject и KeyedEvent.) Многие из таких объектов предназначены только для использования компонентами исполнительной системы, которая и определяет их. Эти объекты недоступны Windows API напря мую. Пример таких объектов — Driver, Device и EventPair.
ГЛАВА 9 Системные механизмы 137 Таблица 3-3. Объекты исполнительной системы, доступные Windows API Тип объектов Представляет: Символьная ссылка (symbolic link) Механизм косвенной ссылки на имя объекта Процесс (process) Виртуальное адресное пространство и управляющую информацию, необходимую для выполнения набора объектов «поток» Поток (thread) Исполняемую часть процесса Задание (job) Совокупность процессов, управляемую как единая группа Раздел (section) Область разделяемой памяти (называемую объектом «проекция файла») Файл (file) Экземпляр открытого файла или устройства вводавывода Маркер доступа (access token) Профиль защиты (SID, права пользователя и т. д.) процесса или потока Событие (event) Объект, который может пребывать либо в занятом, либо в свободном состоянии; используется для синхрониза ции или уведомления Семафор (semaphore) Счетчик, действующий как шлюз к ресурсам; позволяет указывать максимальное число потоков, которым разре шен доступ к защищенным этим объектом ресурсам Мьютекс (mutex) Механизм синхронизации, используемый для упорядоче ния доступа к ресурсам Таймер (timer) Механизм уведомления потока об истечении фиксиро ванного периода времени IoCompletion Метод постановки в очередь и извлечения из нее уведом лений о завершении операций вводавывода (в Windows API называется портом завершения вводавывода) Раздел реестра (key) Механизм ссылки на данные в реестре; хотя разделы реестра появляются в пространстве имен диспетчера объектов, они управляются диспетчером конфигурации по аналогии с тем, как объекты «файл» управляются драйверами файловой системы; с объектом «раздел реестра» может быть сопоставлено произвольное коли чество параметров (от 0 и более) WindowStation Объект, содержащий буфер обмена, набор глобальных атомов и группу объектов «рабочий стол» Рабочий стол (desktop) Объект, содержащийся в объекте типа WindowStation; он описывает логическую поверхность экрана и содер жит окна, меню и ловушки ПРИМЕЧАНИЕ Мьютекс — это название объектов «мутант» (mutants) в Windows API; объект ядра, на котором основан мьютекс, имеет внут реннее имя мутант.
138 ГЛ А В А 3 БЕЗОПАСНОСТЬ Структура объектов Как показано на рис. 318, у каждого объекта есть заголовок и тело. Диспет чер объектов управляет заголовками объектов, а телами объектов управля ют владеющие ими компоненты исполнительной системы. Кроме того, каж дый заголовок объекта указывает на список процессов, которые открыли этот объект, и на специальный объект, называемый объектом типа (type object), — он содержит общую для всех экземпляров информацию. Рис. 3-18. Структура объекта Заголовки и тела объектов Диспетчер объектов использует данные, хранящиеся в заголовке, для управ ления объектами независимо от их типа. Стандартные атрибуты заголовка кратко описываются в таблице 34. Таблица 3-4. Стандартные атрибуты заголовка объекта Атрибут Описание Имя объекта (object name) Позволяет совместно использовать объект, делая его видимым для других процессов Каталог объектов (object directory) Предоставляет иерархическую структуру для хранения имен объектов Дескриптор защиты (security descriptor) Определяет, кто и как может использовать данный объект (должен быть null для безымянных объектов) Квота (quota charges) Устанавливает ограничения на объемы ресурсов при открытии процессом описателя данного объекта Счетчик открытых описателей (open handle count) Подсчитывает, сколько раз был открыт описатель объекта
ГЛАВА 9 Системные механизмы 139 Таблица 3-4. (окончание) Атрибут Описание Список открытых описателей (open handles list) Указывает на список процессов, открывших описатели данного объекта Тип объекта (object type) Указывает на объект типа, содержащий атрибуты, общие для объектов данного типа Счетчик ссылок (reference count) Подсчитывает, сколько раз компоненты режима ядра ссылались на адрес данного объекта Кроме заголовка у каждого объекта имеется тело, чей формат и содержи мое уникальны для данного типа объектов; все объекты одного типа имеют одинаковый формат тела. Создавая тип объектов и предоставляя для него сервисы, компонент исполнительной системы может контролировать мани пуляции с данными в телах всех объектов этого типа. Диспетчер объектов предоставляет небольшой набор базовых сервисов, которые работают с атрибутами заголовка объекта и применимы к объек там любого типа (хотя некоторые базовые сервисы не имеют смысла для отдельных объектов). Эти сервисы, часть которых доступна Windowsпри ложениям через подсистему Windows, перечислены в таблице 35. Базовые сервисы поддерживаются для всех типов объектов, но у каждого объекта есть свои сервисы для создания, открытия и запроса. Так, подсисте ма вводавывода реализует сервис создания файлов для объектов «файл», а диспетчер процессов — сервис создания процессов для объектов «процесс». Конечно, можно было бы реализовать единый сервис создания объектов, но подобная процедура оказалась бы весьма сложной, так как набор парамет ров, необходимых для инициализации объекта «файл», значительно отлича ется, скажем, от параметров инициализации объекта «процесс». А при вызове потоком сервиса объекта для определения его типа и обращении к соответ ствующей версии сервиса диспетчер объектов каждый раз сталкивался бы с необходимостью обработки дополнительных данных. В силу этих и иных причин сервисы, обеспечивающие создание, открытие и запросы, для каж дого типа объектов реализованы отдельно. Таблица 3-5. Базовые сервисы объектов Сервис Описание Закрытие (close) Закрывает описатель объекта Дублирование (duplicate) Позволяет совместно использовать объект за счет дубли рования его описателя и передачи его другому процессу Запрос объекта (query object) Сообщает информацию о стандартных атрибутах объекта Запрос защиты (query security) Сообщает дескриптор защиты объекта Установка защиты (set security) Изменяет защиту объекта см. след. стр.
140 ГЛ А В А 3 БЕЗОПАСНОСТЬ Таблица 3-5. (окончание) Сервис Описание Ожидание одного объекта (wait for a single object) Синхронизирует выполнение потока с одним объектом Ожидание нескольких объектов (wait for multiple objects) Синхронизирует выполнение потока с несколькими объектами Объекты типа В заголовках объектов содержатся общие для всех объектов атрибуты, но их значения могут меняться у конкретных экземпляров данного объекта. Так, у каждого объекта есть уникальное имя и может быть уникальный дескриптор защиты. Однако некоторые атрибуты объектов остаются неизменными для всех объектов данного типа. Например, при открытии описателя объекта можно выбрать права доступа из набора, специфичного для объектов данно го типа. Исполнительная система предоставляет в том числе атрибуты досту па «завершение» (terminate) и «приостановка» (suspend) для объектов «поток», а также «чтение» (read), «запись» (write), «дозапись» (append) и «удаление» (delete) для объектов «файл». Другой пример атрибута, специфичного для типа объектов, — синхронизация, о которой мы кратко расскажем ниже. Чтобы сэкономить память, диспетчер объектов сохраняет статические атрибуты, специфичные для конкретного типа объектов, только при созда нии нового типа объектов. Для записи этих данных он использует собствен ный объект типа. Как показано на рис. 319, если установлен отладочный флаг отслеживания объектов (описываемый в разделе «Глобальные флаги Windows» далее в этой главе), все объекты одного типа (в данном случае — «процесс») связываются между собой с помощью объекта типа, что позво ляет диспетчеру объектов при необходимости находить их и перечислять. Рис. 3-19. Объекты «процесс» и объект типа «процесс»
ГЛАВА 9 Системные механизмы 141 ЭКСПЕРИМЕНТ: просмотр заголовков объектов и объектов типа Вы можете увидеть список объектов типа, объявленных диспетчеру объектов, с помощью утилиты Winobj с сайта www.sysinternals.com. Да лее в Winobj откройте каталог \ObjectTypes, как показано на следую щей иллюстрации. Чтобы просмотреть структуру данных типа объектов «процесс» в отладчике ядра, сначала идентифицируйте этот объект командой !process: kd> !process 0 0 **** NT ACTIVE PROCESS DUMP **** PROCESS 8a4ce668 SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000 DirBase: 00039000 ObjectTable: e1001c88 HandleCount: 474. Image: System Затем выполните команду !object, указав адрес объекта «процесс» в качестве аргумента: kd> !object 8a4ce668 Object: 8a4ce668 Type: (8a4ceca0) Process ObjectHeader: 8a4ce650 HandleCount: 2 PointerCount: 89 Заметьте, что заголовок объекта начинается с 0x18 (24) байтов до нижней границы тела объекта. Увидеть заголовок объекта позволяет следующая команда: kd> dt _object_header 8a4ce650 nt!_OBJECT_HEADER +0x000 PointerCount : 79 +0x004 HandleCount : 2 +0x004 NextToFree : 0x00000002 см. след. стр.
142 ГЛ А В А 3 +0x008 +0x00c +0x00d +0x00e +0x00f +0x010 +0x010 +0x014 +0x018 БЕЗОПАСНОСТЬ Type : 0x8a4ceca0 NameInfoOffset : 0 '' HandleInfoOffset : 0 '' QuotaInfoOffset : 0 '' Flags : 0x22 '''' ObjectCreateInfo : 0x80545620 QuotaBlockCharged : 0x80545620 SecurityDescriptor : 0xe10001dc Body : _QUAD Теперь посмотрите на структуру данных типа этих объектов, полу чив ее адрес из поля Type в структуре данных заголовка объекта: kd> dt _object_type 8a4ceca0 ntdll!_OBJECT_TYPE +0x000 Mutex : _ERESOURCE +0x038 TypeList : _LIST_ENTRY [ 0x8a4cecd8  0x8a4cecd8 ] +0x040 Name : _UNICODE_STRING "Process" +0x048 DefaultObject : (null) +0x04c Index : 5 +0x050 TotalNumberOfObjects : 0x30 +0x054 TotalNumberOfHandles : 0x1b4 +0x058 HighWaterNumberOfObjects : 0x3f +0x05c HighWaterNumberOfHandles : 0x1b8 +0x060 TypeInfo : _OBJECT_TYPE_INITIALIZER +0x0ac Key : 0x636f7250 +0x0b0 ObjectLocks : [4] _ERESOURCE Этот вывод показывает, что структура типа включает имя типа объек та, счетчики активных объектов этого типа, а также счетчики пиково го числа описателей и объектов данного типа. В поле TypeInfo хранит ся указатель на структуру данных, в которой содержатся атрибуты, об щие для всех объектов этого типа, а также указатели на методы типа: kd> dt _object_type_initializer 8a4ceca0+60 ntdll!_OBJECT_TYPE_INITIALIZER +0x000 Length : 0x4c +0x002 UseDefaultObject : 0 '' +0x003 CaseInsensitive : 0 '' +0x004 InvalidAttributes : 0xb0 +0x008 GenericMapping : _GENERIC_MAPPING +0x018 ValidAccessMask : 0x1f0fff +0x01c SecurityRequired : 0x1 '' +0x01d MaintainHandleCount : 0 '' +0x01e MaintainTypeList : 0 '' +0x020 PoolType : 0 ( NonPagedPool ) +0x024 DefaultPagedPoolCharge : 0x1000 +0x028 DefaultNonPagedPoolCharge : 0x288 +0x02c DumpProcedure : (null)
ГЛАВА 9 Системные механизмы 143 +0x030 OpenProcedure : (null) +0x034 CloseProcedure : (null) +0x038 DeleteProcedure : 0x805abe6e nt!PspProcessDelete+0 +0x03c ParseProcedure : (null) +0x040 SecurityProcedure : 0x805cf682 nt!SeDefaultObjectMethod+0 +0x044 QueryNameProcedure : (null) +0x048 OkayToCloseProcedure : (null) Объектами типов нельзя управлять из пользовательского режима изза отсутствия соответствующих сервисов диспетчера объектов. Но некоторые из определяемых ими атрибутов видимы через отдельные системные серви сы и функции Windows API. Атрибуты, хранящиеся в объектах типа, описы ваются в таблице 36. Таблица 3-6. Атрибуты объекта типа Атрибут Описание Имя типа (type name) Название объектов этого типа («процесс», «событие», «порт» и т. д.) Тип пула (pool type) Определяет тип памяти, выделяемый для объектов этого типа (подкачиваемая или неподкачиваемая) Квота по умолчанию (default quota charges) Ограничение по умолчанию на объемы подкачиваемой и неподкачиваемой памяти при открытии процессом описателя данного объекта Виды доступа (access types) Виды доступа, который поток может запрашивать при открытии описателя объекта этого типа («чтение», «за пись», «завершение», «приостановка» и т. д.) Базовые права доступа (generic access rights mapping) Сопоставление четырех базовых прав доступа («чтение», «запись», «выполнение» и «все») с правами доступа, спе цифичными для данного типа Синхронизация (synchronization) Определяет, может ли поток ждать на объектах данного типа Методы (methods) Одна или несколько процедур, автоматически вызывае мых диспетчером объектов на определенных этапах жизненного цикла объекта Синхронизация, один из атрибутов, видимых Windowsприложениям, относится к способности потока синхронизировать свое выполнение, ожи дая изменения состояния определенного объекта. Поток можно синхрони зировать по таким объектам исполнительной системы, как задание, процесс, поток, файл, событие, семафор, мьютекс и таймер. Другие объекты исполни тельной системы не поддерживают синхронизацию. Способность объекта к синхронизации зависит от того, содержит ли он встроенный объект диспет чера — объект ядра, который будет рассмотрен далее в этой главе.
144 ГЛ А В А 3 БЕЗОПАСНОСТЬ Методы объекта Атрибут «методы», последний из перечисленных в таблице 36, состоит из набора внутренних процедур, похожих на конструкторы и деструкторы C++, т. е. на процедуры, автоматически вызываемые при создании или уничтоже нии объекта. В диспетчере объектов эта идея получила дальнейшее разви тие: он вызывает методы объекта и в других ситуациях, например при откры тии или закрытии описателя объекта или при попытке изменения парамет ров защиты объекта. В некоторых типах объектов методы определяются в зависимости от того, как должен использоваться данный тип объектов. При создании нового типа объектов компонент исполнительной систе мы может зарегистрировать у диспетчера объектов один или несколько ме тодов. После этого диспетчер объектов вызывает методы на определенных этапах жизненного цикла объектов данного типа — обычно при их созда нии, удалении или модификации. Поддерживаемые диспетчером объектов методы перечислены в таблице 37. Таблица 3-7. Методы объекта Метод Когда происходит вызов метода Open При открытии описателя объекта Close При закрытии описателя объекта Delete Перед удалением объекта диспетчером объектов Query name При запросе потоком имени объекта (например, файла), существующего во вторичном пространстве имен объектов Parse При поиске диспетчером объектов имени, существующего во вторичном пространстве имен объектов Security При считывании или изменении процессом параметров защиты объекта, например файла, существующего во вторич ном пространстве имен объектов Диспетчер объектов вызывает метод open всякий раз, когда создает опи сатель объекта (что происходит при создании или открытии объекта). Од нако метод open определен только в одном типе объектов — WindowStation. Этот метод необходим таким объектам для того, чтобы Win32k.sys мог ис пользовать часть памяти совместно с процессом, который служит в качестве пула памяти, связанного с объектом «рабочий стол». Пример использования метода close можно найти в подсистеме ввода вывода. Диспетчер вводавывода регистрирует метод close для объектов типа «файл», а диспетчер объектов вызывает метод close при закрытии каждого описателя объекта этого типа. Метод close проверяет, не осталось ли у про цесса, закрывающего описатель файла, какихлибо блокировок для файла, и, если таковые есть, снимает их. Диспетчер объектов не может и не должен самостоятельно проверять наличие блокировок для файла. Перед удалением временного объекта из памяти диспетчер объектов вы зывает метод delete, если он зарегистрирован. Например, диспетчер памяти регистрирует для объектов типа «раздел» метод delete, освобождающий фи
ГЛАВА 9 Системные механизмы 145 зические страницы, используемые данным разделом. Перед удалением объекта «раздел» этот метод также проверяет различные внутренние струк туры данных, выделенные для раздела диспетчером памяти. Диспетчер объектов не мог бы сделать эту работу, поскольку он ничего не знает о внут реннем устройстве диспетчера памяти. Методы delete других объектов вы полняют аналогичные функции. Если диспетчер объектов находит существующий вне его пространства имен объект, метод parse (по аналогии с методом query name) позволяет это му диспетчеру передавать управление вторичному диспетчеру объектов. Когда диспетчер объектов анализирует имя объекта, он приостанавливает анализ, встретив объект с сопоставленным методом parse, и вызывает метод parse, передавая ему оставшуюся часть строки с именем объекта. Кроме про странства имен диспетчера объектов, в Windows есть еще два пространства имен: реестра (реализуемое диспетчером конфигурации) и файловой сис темы (реализуемое диспетчером вводавывода через драйверы файловой системы). О диспетчере конфигурации см. главу 5; о диспетчере вводавы вода и драйверах файловой системы см. главу 9. Например, когда процесс открывает описатель объекта с именем \Device\ Floppy0\docs\resume.doc, диспетчер объектов просматривает свое дерево имен и ищет объект с именем Floppy0. Обнаружив, что с этим объектом со поставлен метод parse, он вызывает его, передавая ему остаток строки с име нем объекта (в данном случае — строку \docs\resume.doc). Метод parse объек тов «устройство» (device objects) является процедурой вводавывода, которая регистрируется диспетчером вводавывода при определении типа объекта «устройство». Процедура parse диспетчера вводавывода принимает строку с именем и передает ее соответствующей файловой системе, которая ищет файл на диске и открывает его. Подсистема вводавывода также использует метод security, аналогичный методу parse. Он вызывается каждый раз, когда поток пытается запросить или изменить параметры защиты файла. Эта информация для файлов отличает ся от таковой для других объектов, поскольку хранится в самом файле, а не в памяти. Поэтому для поиска, считывания или изменения параметров защи ты нужно обращаться к подсистеме вводавывода. Описатели объектов и таблица описателей, принадлежащая процессу Когда процесс создает или открывает объект по имени, он получает описа тель (handle), который дает ему доступ к объекту. Ссылка на объект по опи сателю работает быстрее, чем по имени, так как при этом диспетчер объек тов может сразу найти объект, не просматривая список имен. Процессы так же могут получать описатели объектов, вопервых, путем их наследования в момент своего создания (если процесссоздатель разрешает это, указывая со ответствующий флаг при вызове CreateProcess, и если описатель помечен как наследуемый либо в момент создания, либо позднее, вызовом Windowsфун кции SetHandleInformation), а вовторых, за счет приема дублированного опи сателя от другого процесса (см. описание Windowsфункции DuplicateHandle).
146 ГЛ А В А 3 БЕЗОПАСНОСТЬ Чтобы потоки процесса пользовательского режима могли оперировать объектом, им нужен описатель этого объекта. Идея применения описателей для управления ресурсами сама по себе не нова. Например, стандартные библиотеки языков С, Pascal (и других) при открытии файла возвращают его описатель. Описатели служат косвенными указателями на системные ресур сы, что позволяет прикладным программам избегать прямого взаимодей ствия с системными структурами данных. ПРИМЕЧАНИЕ Компоненты исполнительной системы и драйверы ус тройств могут обращаться к объектам напрямую, поскольку выполня ются в режиме ядра и ввиду этого имеют доступ к структурам объек тов в системной памяти. Однако они должны объявлять о своем ис пользовании объектов, увеличивая значение счетчика ссылок, что га рантирует сохранность нужного объекта (см. раздел «Хранение объек тов в памяти» далее в этой главе). Описатели дают и другие преимущества. Вопервых, описатели файлов, событий или процессов совершенно одинаковы — просто ссылаются на разные объекты. Это дает возможность создать унифицированный интер фейс для ссылок на объекты любого типа. Вовторых, только диспетчер объектов имеет право физически создавать описатели и искать их объекты, а значит, он может проанализировать любое действие с объектом в пользо вательском режиме и решить, позволяет ли профиль защиты вызывающей программы выполнить над объектом запрошенную операцию. ЭКСПЕРИМЕНТ: просмотр открытых описателей Запустите Process Explorer и убедитесь, что в его окне нижняя секция вклю чена и настроена на отображение открытых описателей. (Выберите View, Lower Pane View и Handles.) Затем откройте окно командной строки и про смотрите таблицу описателей для нового процесса Cmd.exe. Вы должны увидеть открытый описатель файла — текущего каталога. Например, если текущий каталог — C:\, Process Explorer выводит следующее.
ГЛАВА 9 Системные механизмы 147 Если вы теперь смените текущий каталог командой CD, то Process Explorer покажет, что описатель предыдущего каталога закрыт и от крыт описатель нового текущего каталога. Предыдущий описатель ненадолго выделяется красным цветом, а новый — зеленым. Длитель ность подсветки настраивается щелчком кнопки Options и регулиров кой параметра Difference Highlight Duration. Такая функциональность Process Explorer упрощает наблюдение за изменениями в таблице описателей. Например, если в процессе про исходит утечка описателей, просмотр таблицы описателей в Process Explorer позволяет быстро увидеть, какой описатель (или описатели) открывается, но не закрывается. Эта информация помогает програм мисту обнаружить утечку описателей. Таблицу открытых описателей также можно вывести, используя ко мандную строку утилиты Handle (www.sysinternals.com). Например, об ратите внимание на следующий фрагмент вывода Handle, где показана таблица описателей для процесса Cmd.exe до и после смены каталога: C:\>handle p cmd.exe Handle v2.2 Copyright (C) 19972004 Mark Russinovich Sysinternals  www.sysinternals.com ——————————————————————————————— cmd.exe pid: 3184 BIGDAVID\dsolomon b0: File C:\ C:\>cd windows C:\WINDOWS>handle p cmd.exe . . cmd.exe pid: 3184 BIGDAVID\dsolomon b4: File C:\WINDOWS Описатель объекта представляет собой индекс в таблице описателей, принадлежащей процессу. На нее указывает блок процесса исполнительной системы (EPROCESS), рассматриваемый в главе 6. Индекс первого описателя равен 4, второго — 8 и т. д. Таблица содержит указатели на все объекты, опи сатели которых открыты данным процессом. Эти таблицы реализованы по трехуровневой схеме аналогично тому, как блок управления памятью в сис темах типа x86 реализует трансляцию виртуальных адресов в физические, поддерживая более 16 000 000 описателей на каждый процесс (см. главу 7). При создании процесса в Windows 2000 диспетчер объектов формирует верхний уровень таблицы описателей, содержащий указатели на таблицы среднего уровня; средний уровень содержит первый массив указателей на таблицы вторичных описателей, а нижний — первую таблицу вторичных описателей. На рис. 320 показана структура таблицы описателей в Windows 2000. В этой операционной системе диспетчер объектов интерпретирует младшие 24 бита описателя объекта как три 8битных поля, являющиеся
148 ГЛ А В А 3 БЕЗОПАСНОСТЬ индексами для каждого из трех уровней таблицы описателей. В Windows XP и Windows Server 2003 при создании процесса создается лишь таблица опи сателей нижнего уровня — остальные уровни формируются по мере необ ходимости. В Windows 2000 таблица вторичных описателей состоит из 255 элементов. В Windows XP и Windows Server 2003 такая же таблица включает столько элементов, сколько помещается на страницу памяти минус один элемент, который используется для аудита описателей (handle auditing). На пример, на x86системах размер страницы составляет 4096 байтов. Делим это значение на размер элемента (8 байтов), вычитаем 1 и получаем всего 511 элементов в таблице описателей нижнего уровня. Наконец, таблица опи сателей среднего уровня в Windows XP и Windows Server 2003 содержит пол ную страницу указателей на таблицы вторичных описателей, поэтому коли чество таблиц вторичных описателей зависит от размеров страницы и ука зателя на конкретной аппаратной платформе. Рис. 3-20. Структура таблицы описателей, принадлежащая процессу в Windows 2000 ЭКСПЕРИМЕНТ: создание максимального количества описателей Тестовая программа Testlimit (www.sysinternals.com/windowsinternals. shtml) позволяет открывать описатели объекта до тех пор, пока не бу дет исчерпан их лимит. С ее помощью вы увидите, сколько описате лей можно создать в одном процессе в вашей системе. Поскольку па мять под таблицу описателей выделяется из пула подкачиваемых стра ниц, этот пул может быть исчерпан до того, как вы достигнете предель ного числа описателей, допустимых в одном процессе. 1. Скачайте файл Testlimit.zip по только что упомянутой ссылке и раз архивируйте его в какойнибудь каталог.
ГЛАВА 9 Системные механизмы 149 2. Запустите Process Explorer, щелкните View, затем System Information. Обратите внимание на текущий и максимальный размеры пула подкачиваемой памяти. (Для вывода максимальных размеров пулов Process Explorer нужно настроить на доступ к символам для образа ядра, Ntoskrnl.exe.) Пусть эта информация отображается, когда вы запустите программу Testlimit. 3. Откройте окно командной строки. 4. Запустите программу Testlimit с ключом –h (для этого введите test limit h). Когда Testlimit не удастся открыть очередной описатель, она сообщит общее число созданных ею описателей. Если это зна чение окажется меньше, чем около 16 миллионов, то, вероятно, вы исчерпали пул подкачиваемой памяти до достижения теоретичес ки предельного числа описателей. 5. Закройте окно командной строки; это приведет к завершению про цесса Testlimit и автоматическому закрытию всех открытых описа телей. Как показано на рис. 321, в x86системах каждый элемент таблицы опи сателей состоит из структуры с двумя 32битными элементами: указателем на объект (с флагами) и маской доступа. В 64разрядных системах каждый элемент имеет размер 12 байтов и состоит из 64битного указателя на заго ловок объекта и 32битной маски доступа (маски доступа описываются в главе 8). В Windows 2000 первый 32битный элемент содержит указатель на заго ловок объекта и четыре флага. Поскольку заголовки объектов всегда вырав ниваются по границе 8 байтов, в качестве флагов используются младшие 3 бита и один старший. Старший бит является флагом блокировки (lock). Ког да диспетчер объектов транслирует описатель в указатель на объект, он бло кирует соответствующую запись на время трансляции. Так как все объекты находятся в системном адресном пространстве, старший бит указателя на объект устанавливается в 1. (Гарантируется, что адреса всегда будут превы шать 0x80000000 даже на системах, запускаемых с ключом загрузки /3GB.) Так что, пока элемент таблицы описателей не заблокирован, диспетчер объектов может сбросить старший бит в 0. При блокировке элемента табли цы диспетчер объектов устанавливает этот бит и получает корректное зна чение указателя. Диспетчер блокирует всю таблицу описателей (используя специальную блокировку, сопоставляемую с каждым процессом), только если процесс создает новый описатель или закрывает существующий. В Windows XP и Windows Server 2003 флаг блокировки хранится в младшем бите указателя на объект. А флаг, который в Windows 2000 хранился в этом бите, теперь хранится в ранее зарезервированном бите маски доступа.
150 ГЛ А В А 3 Рис. 3-21. БЕЗОПАСНОСТЬ Структура элемента таблицы описателей Первый флаг указывает, имеет ли право вызывающая программа закры вать данный описатель. Второй определяет, получат ли процессы, созданные данным процессом, копию этого описателя. (Как уже отмечалось, наследо вание описателя можно указать при его создании или позже, через Windows функцию SetHandleInformation. Этот флаг тоже можно задать вызовом Set HandleInformation.) Третий задает, будет ли генерироваться сообщение ауди та при закрытии объекта. (Этот флаг не предоставляется в Windows и пред назначен для внутреннего использования диспетчером объектов.) Системным компонентам и драйверам устройств зачастую нужно откры вать описатели объектов, доступа к которым у приложений пользовательского режима нет. Это достигается созданием описателей в таблице описателей ядра (kernel handle table) (внутреннее имя — ObpKernelHandleTable). Описа тели в этой таблице доступны только в режиме ядра в контексте любого про цесса. Это значит, что функции режима ядра могут ссылаться на эти описа тели из контекста любого процесса без ущерба для производительности. Дис петчер объектов распознает ссылки на описатели в таблице описателей ядра, когда старший бит в них установлен, т. е. когда в таких ссылках содержатся значения, превышающие 0x80000000. В Windows 2000 таблица описателей ядра является независимой таблицей описателей, но в Windows XP и Windows Server 2003 она служит и таблицей описателей для процесса System. ЭКСПЕРИМЕНТ: просмотр таблицы описателей с помощью отладчика ядра Команда !handle отладчика ядра допускает следующие аргументы: !handle <индекс_описателя> <флаги> <идентификатор_процесса> Индекс описателя определяет элемент в таблице описателей (0 — вывод всех описателей). Индекс первого описателя равен 4, второго — 8 и т. д. Например, введя !handle 4, вы увидите первый описатель в те кущем процессе. Вы можете указывать флаги, являющиеся битовыми масками, где бит 0 означает, что нужно вывести лишь информацию из элемента таблицы, бит 1 — показать не только используемые, но и свободные описатели, а бит 2 — сообщить информацию об объекте, на который ссылается описатель. Следующая команда выводит полную информа цию о таблице описателей в процессе с идентификатором 0x408.
ГЛАВА 9 Системные механизмы 151 kd> !handle 0 7 408 processor number 0 Searching for Process with Cid == 408 PROCESS 865f0790 SessionId: 0 Cid: 0408 Peb: 7ffdf000 ParentCid: 01dc DirBase: 04fd3000 ObjectTable: 856ca888 TableSize: 21. Image: i386kd.exe Handle Table at e2125000 with 21 Entries in use 0000: free handle 0004: Object: e20da2e0 GrantedAccess: 000f001f Object: e20da2e0 Type: (81491b80) Section ObjectHeader: e20da2c8 HandleCount: 1 PointerCount: 1 0008: Object: 80b13330 GrantedAccess: 00100003 Object: 80b13330 Type: (81495100) Event ObjectHeader: 80b13318 HandleCount: 1 PointerCount: 1 Защита объектов Открывая файл, нужно указать, для чего это делается — для чтения или за писи. Если вы попытаетесь записать чтонибудь в файл, открытый для чте ния, то получите ошибку. Аналогичным образом действует и исполнитель ная система: когда процесс создает объект или открывает описатель суще ствующего объекта, он должен указывать набор желательных прав досту па (desired access rights), сообщая тем самым, что именно он собирается де лать с объектом. Процесс может запросить либо набор стандартных прав доступа (чтение, запись, выполнение), применимых ко всем объектам, либо специфические права доступа, различные для объектов разного типа. Так, в случае объекта «файл» процесс может запросить права на удаление файла или дозапись, а в случае объекта «поток» — права на приостановку потока или его завершение. Когда процесс открывает описатель объекта, диспетчер объектов вызы вает так называемый монитор состояния защиты* (security reference moni tor), часть подсистемы защиты, работающую в режиме ядра, и посылает ему уведомление о наборе желательных для процесса прав доступа. Монитор состояния защиты проверяет, разрешает ли дескриптор защиты объекта зап рашиваемый тип доступа. Если да, монитор состояния защиты возвращает процессу набор предоставленных прав доступа (granted access rights), ин формацию о которых диспетчер объектов сохраняет в создаваемом им опи сателе объекта. Как подсистема защиты определяет, кто и к каким объектам может получать доступ, рассматривается в главе 8. * На самом деле этот компонент представляет собой нечто вроде монитора запро сов к подсистеме защиты. — Прим. перев.
152 ГЛ А В А 3 БЕЗОПАСНОСТЬ После этого всякий раз, когда потоки процесса используют описатель, дис петчер объектов может быстро проверить, соответствует ли набор предостав ленных прав доступа, хранящихся в описателе, действиям, которые намере вается выполнить вызванный потоками сервис объекта. Так, если вызывающая программа запросила доступ для чтения к объекту «раздел», а затем вызывает сервис для записи в этот объект, последний сервис не выполняется. Хранение объектов в памяти Объекты бывают двух типов: временные (temporary) и постоянные (per manent). Большинство объектов временные, т. е. они хранятся, пока исполь зуются, и освобождаются, как только необходимость в них отпадает. Посто янные объекты существуют до тех пор, пока они не освобождаются явным образом. Поскольку большинство объектов временные, остальная часть это го раздела будет посвящена тому, как диспетчер объектов реализует хране ние объектов в памяти (object retention), т. е. сохранение временных объек тов лишь до тех пор, пока они используются, с их последующим удалением. Так как для доступа к объекту все процессы пользовательского режима дол жны сначала открыть его описатель, диспетчер объектов может легко отсле живать, сколько процессов и даже какие именно из них используют объект. Учет описателей является одним из механизмов, реализующих хранение объектов в памяти. Этот механизм двухфазный. Первая фаза называется хра нением имен (name retention) и контролируется числом открытых описате лей объекта. Каждый раз, когда процесс открывает описатель объекта, дис петчер увеличивает значение счетчика открытых описателей в заголовке объекта. По мере того как процессы завершают использование объекта и закрывают его описатели, диспетчер уменьшает значение этого счетчика. Когда счетчик обнуляется, диспетчер удаляет имя объекта из своего глобаль ного пространства имен. После этого новые процессы уже не смогут откры вать описатели данного объекта. Вторая фаза заключается в том, что прекращается хранение тех объектов, которые больше не используются (т. е. они удаляются). Так как код операци онной системы обычно обращается к объектам по указателям, а не описате лям, диспетчер объектов должен регистрировать и число указателей объектов, переданных процессам операционной системы. При каждой выдаче указате ля на объект он увеличивает значение счетчика ссылок на объект. Компонен ты режима ядра, прекратив использовать указатель, вызывают диспетчер объектов для уменьшения счетчика ссылок. Система также увеличивает счет чик ссылок при увеличении счетчика описателей, а при уменьшении счетчи ка описателей соответственно уменьшает счетчик ссылок, поскольку описа тель тоже является подлежащей учету ссылкой на объект (подробнее об этих механизмах см. описание функции ObReferenceObjectByPointer или ObDere ferenceObject в DDK). На рис. 322 показаны два задействованных объектасобытия. Процесс А открыл первый объект, а процесс В — оба объекта. Кроме того, на первый объект ссылается какаято структура режима ядра, и его счетчик ссылок ра
ГЛАВА 9 Системные механизмы 153 вен 3. Так что, даже если оба процесса закроют свои описатели первого объек та, он попрежнему будет существовать, поскольку его счетчик ссылок еще не обнулится. Но, когда процесс В закроет свой описатель второго объекта, этот объект будет удален. Рис. 3-22. Счетчики описателей и ссылок Таким образом, даже если счетчик открытых описателей объекта обну лится, счетчик ссылок может превышать нулевое значение, указывая, что операционная система еще использует объект. В конце концов счетчик ссы лок тоже обнулится, и тогда диспетчер удалит соответствующий объект из памяти. Такой механизм позволяет хранить объект и его имя в памяти, просто не закрывая его описатель. Программистам, создающим приложения с двумя и более взаимодействующими процессами, не приходится беспокоиться о том, что один из процессов удалит объект в то время, когда он еще используется другим процессом. Кроме того, закрытие описателей объекта, принадлежа щих приложению, еще не означает, что этот объект будет немедленно уда лен, — он может использоваться операционной системой. Например, какой то процесс создает второй процесс для выполнения программы в фоновом режиме, после чего немедленно закрывает описатель созданного процесса. Так как второй процесс еще не закончил свою работу и выполняется опера ционной системой, она поддерживает ссылку на этот объект «процесс». Дис
154 ГЛ А В А 3 БЕЗОПАСНОСТЬ петчер сможет обнулить счетчик ссылок на второй процесс и удалить его, только когда завершится выполнение этого процесса. Учет ресурсов Учет ресурсов, как и хранение объектов, тесно связан с использованием опи сателей объектов. Положительное значение счетчика открытых описателей указывает на то, что данный ресурс задействован какимито процессами. Когда счетчик описателей и счетчик ссылок на некий объект обнуляются, процессы, использовавшие этот объект, больше не занимают память, отве денную под него. Во многих операционных системах для ограничения доступа процессов к системным ресурсам применяется система квот. Однако типы устанавли ваемых для процессов квот иногда весьма разнообразны, а отслеживающий квоты код распределен по всей операционной системе. Так, в некоторых операционных системах компонент вводавывода может регистрировать и ограничивать число файлов, которые может открыть процесс, а компонент управления памятью может накладывать ограничения на объем памяти, вы деляемой потокам процесса. Компонент, отвечающий за управление процес сами, способен ограничивать максимальное число новых процессов или новых потоков процесса. Каждое из этих ограничений отслеживается и ре ализуется в различных частях операционной системы. Диспетчер объектов Windows, напротив, представляет собой компонент централизованного учета ресурсов. В заголовке каждого объекта содержит ся атрибут квоты, определяющий, насколько диспетчер объектов уменьша ет квоту подкачиваемой или неподкачиваемой памяти процесса при откры тии его потоком описателя этого объекта. У каждого процесса в Windows имеется структура квот, регистрирующая лимиты и текущее количество используемой памяти из подкачиваемого и неподкачиваемого пулов, а также из страничного файла. (Введите dt nt!_ EPROCESS_QUOTA_ENTRY в отладчике ядра, чтобы увидеть формат этой структуры.) Значения данных квот по умолчанию равны 0 (ограничений нет), но их можно указать, модифицировав параметры в реестре (см. пара метры NonPagedPoolQuota, PagedPoolQuota и PagingFileQuota в разделе HKLM\System\CurrentControlSet\Session Manager\Memory Management). За метьте, что все процессы в интерактивном сеансе используют один и тот же блок квот (документированного способа создания процессов с собственны ми блоками квот нет). Имена объектов Важное условие для создания множества объектов — эффективная система учета. Для учета диспетчеру объектов нужна следующая информация: 쐽 способ, которым можно было бы отличать один объект от другого; 쐽 метод поиска и получения конкретного объекта.
ГЛАВА 9 Системные механизмы 155 Первое требование реализуется за счет присвоения имен объектам. Это расширение обычной для большинства операционных систем функцио нальности, в которых отдельным системным ресурсам, например файлам, каналам или блокам разделяемой памяти, можно присваивать имена. Испол нительная система, напротив, позволяет именовать любой объект, представ ляющий ресурс. Второе требование (поиск и получение объектов) также реализуется через именование объектов. Если диспетчер хранит объекты в соответствии с их именами, он может быстро найти объект по его имени. Имена объектов отвечают и третьему требованию, не упомянутому в пре дыдущем списке: процессам должна быть предоставлена возможность совме стного использования объектов. Пространство имен объектов исполнитель ной системы является глобальным, видимым любому процессу в системе. Если один процесс создает объект и помещает его имя в глобальное про странство имен, то другой процесс может открыть описатель этого объек та, указав нужное имя. Если объект не предназначен для совместного исполь зования, процесссоздатель просто не присваивает ему имя. Для большей эффективности диспетчер объектов не ищет имя объекта при каждой попытке его использования. Поиск по имени ведется только в двух случаях. Вопервых, при создании процессом именованного объекта: перед тем как сохранить имя объекта в глобальном пространстве имен, дис петчер проверяет, нет ли в нем такого же имени. Вовторых, открывая опи сатель именованного объекта, диспетчер ищет объект по имени и возвраща ет его описатель, который затем используется для ссылки на объект. Диспет чер позволяет выбирать, надо ли при поиске учитывать регистр букв. Эта функциональность поддерживается POSIX и другими подсистемами окруже ния, в которых имена файлов чувствительны к регистру букв. Где именно хранятся имена объектов, зависит от типа объектов. В табли це 38 перечислены стандартные каталоги объектов, имеющиеся на всех системах под управлением Windows. Пользовательским программам видны только каталоги \BaseNamedObjects и \GLOBAL?? (\?? в Windows 2000). Поскольку имена базовых объектов ядра вроде мьютексов, событий, се мафоров, ожидаемых таймеров и разделов хранятся в одном каталоге, они не должны совпадать, даже если относятся к объектам разных типов. Это ограничение подчеркивает, насколько осторожно надо выбирать имена, что бы они не конфликтовали с другими (используйте, например, префиксы имен в виде названия вашей компании и программного продукта). Таблица 3-8. Стандартные каталоги объектов Каталог Типы объектов, имена которых хранятся в каталоге \GLOBAL?? (\?? в Windows 2000) Имена устройств MSDOS (\DosDevices является символь ной ссылкой на этот каталог) \BaseNamedObjects Мьютексы, события, семафоры, ожидаемые таймеры и разделы \Callback Объекты обратного вызова \Device Объекты устройств см. след. стр.
156 ГЛ А В А 3 БЕЗОПАСНОСТЬ Таблица 3-8. (окончание) Каталог Типы объектов, имена которых хранятся в каталоге \Driver Объекты драйверов \FileSystem Объекты драйверов файловых систем и объекты распознавания файловых систем \KnownDlls Имена разделов и пути поиска известных DLL (DLL, проецируемых системой при запуске) \Nls Имена разделов спроецированных таблиц поддержки национальных языков \ObjectTypes Имена типов объектов \RPC Control Объекты портов, используемые для вызова удаленных процедур (RPC) \Security Имена объектов, специфичных для системы защиты \Windows Порты подсистемы Windows и объекты WindowStation Имена объектов глобальны в пределах компьютера (или всех процессо ров на многопроцессорной системе) и невидимы через сеть. Однако метод parse диспетчера объектов позволяет получать доступ к именованным объек там, существующим на других компьютерах. Так, диспетчер вводавывода, предоставляющий сервисы объектов «файл», расширяет функции диспетче ра объектов для работы с файлами на удаленных компьютерах. При запро се на открытие объекта «файл» на удаленном компьютере диспетчер объек тов вызывает метод parse, что позволяет диспетчеру вводавывода перехва тить запрос и направить его сетевому редиректору — драйверу, обращающе муся к файлам через сеть. Серверный код на удаленной Windowsсистеме вызывает диспетчер объектов и диспетчер вводавывода на этой системе для поиска нужного объекта «файл» и возврата данных через сеть. ЭКСПЕРИМЕНТ: просмотр именованных базовых объектов Список именованных базовых объектов можно просмотреть с помо щью утилиты Winobj (www.sysinternals.com). Запустите Winobj.exe и щелкните каталог \BaseNamedObjects, как показано ниже.
ГЛАВА 9 Системные механизмы 157 Именованные объекты отображаются справа. Тип объектов обозна чается следующими значками: 쐽 «stop» — мьютексы; 쐽 в виде микросхем памяти — разделы (объекты «проекция файла»); 쐽 в виде восклицательного знака — события; 쐽 похожие на светофоры — семафоры; 쐽 в виде изогнутой стрелки — символьные ссылки. Объекты «каталоги объектов» (object directory objects) С помо щью этих объектов диспетчер объектов поддерживает иерархическую струк туру пространства имен. Этот объект аналогичен каталогу файловой систе мы и содержит имена других объектов, а также другие каталоги объектов. Он включает информацию, достаточную для трансляции имен объектов в ука затели на сами объекты. Диспетчер использует указатели для создания опи сателей объектов, возвращаемых программам пользовательского режима. Каталоги для хранения объектов могут создаваться как кодом режима ядра (включая компоненты исполнительной системы и драйверы устройств), так и кодом пользовательского режима (в том числе подсистемами). Например, диспетчер вводавывода создает каталог объектов \Device с именами объек тов, представляющих устройства вводавывода. Символьные ссылки (symbolic links) В некоторых файловых систе мах (например, NTFS и отдельных UNIXсистемах) с помощью символьной ссылки можно создать имя файла или каталога, которое при использовании будет транслироваться операционной системой в другое имя файла или ка талога. Символьные ссылки — простой метод неявного разделения файлов или каталогов за счет создания перекрестных ссылок между различными каталогами в обычной иерархической структуре каталогов. Диспетчер объектов реализует объект «символьная ссылка», который вы полняет аналогичную функцию в отношении имен объектов в пространстве имен. Символьная ссылка может находиться в любом месте строки с именем объекта. Когда вызывающая программа ссылается на имя объекта «символь ная ссылка», диспетчер просматривает пространство имен в поисках тако го объекта. Далее он анализирует содержимое символьной ссылки и нахо дит строку, которую надо подставить вместо ссылки. После этого начинает ся поиск другого объекта, соответствующего полученному имени. Исполнительная система использует такие объекты при трансляции имен устройств в стиле MSDOS во внутренние имена устройств Windows. Пользо ватель обращается к гибким и жестким дискам по именам A:, B:, C: и т. д. или к последовательным портам по именам COM1, COM2 и т. п. Подсистема Win dows делает эти объекты «символьная ссылка» в защищенные глобальные данные, помещая их в каталог объектов \?? (в Windows 2000) или \GLOBAL?? (в Windows XP и Windows Server 2003).
158 ГЛ А В А 3 БЕЗОПАСНОСТЬ Пространство имен сеанса Windows NT изначально создавалась в расчете на регистрацию в системе одного интерактивного пользователя и выполнение лишь одного экземпля ра любого из интерактивных приложений. Добавление Windows Terminal Services в Windows 2000 Server и поддержки быстрого переключения пользо вателей в Windows XP потребовало некоторых изменений в модели про странства имен диспетчера объектов для поддержки множества интерактив ных пользователей одновременно. (Базовые сведения о службах терминала и сеансах см. в главе 1.) Пользователь, зарегистрированный в консольном сеансе, получает доступ к глобальному пространству имен, которое является первым экземпляром пространства имен. Дополнительные сеансы получают свое (закрытое) пред ставление пространства имен, называемое локальным пространством имен. Части пространства имен, локальные для каждого сеанса, включают \Dos Devices, \Windows и \BaseNamedObjects. Формирование раздельных копий одних и тех же частей называется созданием экземпляров (instancing) про странства имен. Создание экземпляров каталога \DosDevices позволяет каж дому пользователю обозначать сетевые дисковые устройства разными буква ми и поразному именовать такие объекты, как, например, последовательные порты. В Windows 2000 глобальный каталог \DosDevices называется \?? и яв ляется каталогом, на который указывает символьная ссылка \DosDevices, а локальные каталоги \DosDevices идентифицируются по идентификатору для сеанса сервера терминала. В Windows XP и более поздних операционных си стемах глобальный каталог \DosDevices называется \Global?? и является ката логом, на который указывает \DosDevices, а локальные каталоги \DosDevices определяются по идентификатору сеанса входа (logon session). Win32k.sys создает в каталоге \Windows интерактивный объект Window Station, \WinSta0. Среда Terminal Services может поддерживать несколько интерактивных пользователей, но для сохранения иллюзии доступа к пред определенному интерактивному объекту WindowStation в Windows каждо му пользователю нужна собственная версия WinSta0. Наконец, в каталоге \BaseNamedObjects приложения и система создают разделяемые объекты, включая события, мьютексы и разделы. Если приложение, создающее име нованный объект, запущено двумя пользователями, то в каждом сеансе нуж на своя версия этого объекта, чтобы два экземпляра приложения не меша ли друг другу, обращаясь к одному объекту. Диспетчер объектов реализует локальное пространство имен, создавая закрытые версии трех каталогов, которые находятся в каталоге, сопоставлен ном с сеансом пользователя (\Sessions\X, где X — идентификатор сеанса). Например, когда некое Windowsприложение во время удаленного сеанса номер 2 создает именованное событие, диспетчер объектов перенаправля ет имя этого объекта из \BaseNamedObjects в \Sessions\2\BaseNamedObjects. Все функции диспетчера объектов, связанные с управлением простран ством имен, знают о локальных экземплярах каталогов и участвуют в под
ГЛАВА 9 Системные механизмы 159 держании иллюзии того, что в удаленных сеансах используется то же про странство имен, что и в консольных. DLLмодули подсистемы Windows до бавляют к именам, передаваемым Windowsприложениями, которые ссыла ются на объекты в \DosDevices, префиксы \?? (например, C:\Windows превра щается в \??\C:\Windows). Когда диспетчер объектов обнаруживает специаль ный префикс \??, предпринимаемые им действия зависят от версии Windows, но при этом он всегда полагается на поле DeviceMap в объекте «процесс», создаваемом исполнительной системой (executive process object) (EPROCESS, о котором пойдет речь в главе 6). Это поле указывает на структуру данных, разделяемую с другими процессами в том же сеансе. Поле DosDevicesDirectory структуры DeviceMap указывает на каталог диспетчера объектов, представ ляющий локальный \DosDevices процесса. Целевой каталог зависит от кон кретной системы. 쐽 Если системой является Windows 2000 и Terminal Services не установле ны, поле DosDevicesDirectory в структуре DeviceMap процесса указывает на каталог \??, так как локальных пространств имен нет. 쐽 Если системой является Windows 2000 и Terminal Services установлены, то, когда активным становится новый сеанс, система копирует все объекты из глобального каталога \?? в локальный для сеанса каталог \DosDevices, и поле DosDevicesDirectory структуры DeviceMap указывает на этот локаль ный каталог. 쐽 В Windows XP и Windows Server 2003 система не копирует глобальные объекты в локальные каталоги DosDevices. Диспетчер объектов, встретив ссылку на \??, находит локальный для процесса каталог \DosDevices, ис пользуя поле DosDevicesDirectory структуры DeviceMap. Если нужного объекта в этом каталоге нет, он проверяет поле DeviceMap объекта «ката лог» и, если это допустимо, ищет объект в каталоге, на который указыва ет поле GlobalDosDevicesDirectory структуры DeviceMap. Этим каталогом всегда является \Global??. В определенных обстоятельствах приложениям, поддерживающим Termi nal Services, нужен доступ к объектам в консольном сеансе, даже если сами приложения выполняются в удаленном сеансе. Это может понадобиться при ложениям для синхронизации со своими экземплярами, выполняемыми в других удаленных или консольных сеансах. В таких случаях для доступа к глобальному пространству имен приложения могут использовать специаль ный префикс \Global, поддерживаемый диспетчером объектов. Так, объект \Global\ApplicationInitialized, открываемый приложением в сеансе номер 2, направляется вместо каталога \Sessions\2\BaseNamedObjects\Application Initialized в каталог \BasedNamedObjects\ApplicationInitialized. В Windows XP и Windows Server 2003 приложение, которому нужно об ратиться к объекту в глобальном каталоге \DosDevices, не требуется исполь зовать префикс \Global, если только этого объекта нет в локальном катало ге \DosDevices. Это вызвано тем, что диспетчер объектов автоматически ищет объект в глобальном каталоге, не найдя его в локальном. Однако при
160 ГЛ А В А 3 БЕЗОПАСНОСТЬ ложение, работающее в Windows 2000 с Terminal Services, должно всегда ука зывать префикс \Global для доступа к объектам в глобальном каталоге \Dos Devices. ЭКСПЕРИМЕНТ: просмотр экземпляров пространства имен Вы можете увидеть, как диспетчер объектов создает экземпляры про странства имен, создав сеанс, отличный от консольного, и просмот рев таблицу описателей для процесса в этом сеансе. В Windows XP Home Edition или Windows XP Professional в системе, которая не вхо дит в домен, отключите консольный сеанс [откройте меню Start (Пуск), щелкните Log Off (Выход из системы) и выберите Disconnect and Switch User (Смена пользователя) или нажмите комбинацию клавиш Win dows+L]. Теперь войдите в систему под новой учетной записью. Если вы работаете с Windows 2000 Server, Advanced Server или Datacenter Server, запустите клиент Terminal Services, подключитесь к серверу и войдите в систему. Войдя в систему в новом сеансе, запустите Winobj (www.sysinternals.com), щелкните каталог \Sessions и вы увидите подкаталог с числовым име нем для каждого активного удаленного сеанса. Открыв один из таких каталогов, вы обнаружите подкаталоги \DosDevices, \Windows и \Base NamedObjects, которые относятся к локальному пространству имен сеанса. Одно из таких локальных пространств имен показано на ил люстрации ниже. Далее запустите Process Explorer и выберите какойнибудь процесс в новом сеансе (вроде Explorer.exe). Просмотрите таблицу описателей, щелкнув View, Lower Pane View и Handles. Вы должны увидеть описа тель \Windows\Windowstations\WinSta0 под \Sessions\n, где n — иден тификатор сеанса. Объекты с глобальными именами появятся в \Ses sions\n\BaseNamedObjects.
ГЛАВА 9 Системные механизмы 161 Синхронизация Концепция взаимоисключения (mutual exclusion) является одной из ключе вых при разработке операционных систем. Ее смысл в следующем: в каждый момент к конкретному ресурсу может обращаться один — и только один — поток. Взаимоисключение необходимо, когда ресурс не предназначен для разделения или когда такое разделение может иметь непредсказуемые по следствия. Например, если бы два потока одновременно копировали данные в порт принтера, отпечатанный документ представлял бы собой нечитаемую мешанину. Аналогичным образом, если бы один поток считывал какойто участок памяти, когда другой записывал бы туда данные, первый поток по лучил бы непредсказуемый набор данных. В общем случае доступные для записи ресурсы нельзя разделять без ограничений. Рис. 323 иллюстрирует, что происходит, когда два потока, выполняемые на разных процессорах, одновременно записывают данные в циклическую очередь. Рис. 3-23. Некорректное разделение памяти Поскольку второй поток получил значение указателя на конец очереди до того, как первый поток завершил его обновление, второй вставил свои данные в то же место, что и первый. Таким образом, данные первого потока были перезаписаны другими данными, а один участок очереди остался пус тым. Хотя рис. 323 иллюстрирует, что могло бы случиться в многопроцес сорной системе, аналогичную ошибку было бы нельзя исключить и в одно процессорной системе — при переключении контекста на второй поток до того, как первый поток успел бы обновить указатель на конец очереди. Разделы кода, обращающиеся к неразделяемым ресурсам, называются кри тическими секциями (critical sections). В критической секции единовремен но может выполняться только один поток. Пока один поток записывает в файл, обновляет базу данных или модифицирует общую переменную, доступ к этому ресурсу со стороны других потоков запрещен. Псевдокод, показанный на рис. 323, представляет собой критическую секцию, которая некорректно обращается к разделяемой структуре данных без взаимоисключения.
162 ГЛ А В А 3 БЕЗОПАСНОСТЬ Взаимоисключение, важное для всех операционных систем, особенно зна чимо (и запутанно) в случае операционной системы с жестко связанной сим метричной мультипроцессорной обработкой (tightlycoupled symmetric multiprocessing), например в Windows, в которой один и тот же системный код, выполняемый на нескольких процессорах одновременно, разделяет не которые структуры данных, хранящиеся в глобальной памяти. В Windows под держка механизмов, с помощью которых системный код может предотвра тить одновременное изменение двумя потоками одной и той же структуры, возлагается на ядро. Оно предоставляет специальные примитивы взаимоис ключения, используемые им и остальными компонентами исполнительной системы для синхронизации доступа к глобальным структурам данных. Так как планировщик синхронизирует доступ к своим структурам данных при IRQL уровня «DPC/dispatch», ядро и исполнительная система не могут полагаться на механизмы синхронизации, которые могли бы привести к ошибке страницы или к перераспределению процессорного времени при IRQL уровня «DPC/dispatch» или выше (эти уровни также известны под на званием «высокий IRQL»). Из следующих разделов вы узнаете, как ядро и ис полнительная система используют взаимоисключение для защиты своих глобальных структур данных при высоком IRQL и какие механизмы синхро низации и взаимоисключения они применяют при низких уровнях IRQL (ниже «DPC/dispatch»). Синхронизация ядра при высоком IRQL Ядро должно гарантировать, что в каждый момент только один процессор выполняет код в критической секции. Критическими секциями ядра являют ся разделы кода, модифицирующие глобальные структуры данных, напри мер базу данных диспетчера ядра или его очередь DPC. Операционная сис тема не смогла бы корректно работать, если бы ядро не гарантировало вза имоисключающий доступ потоков к этим структурам данных. В этом плане больше всего проблем с прерываниями. Так, в момент об новления ядром глобальной структуры данных может возникнуть прерыва ние, процедура обработки которого изменяет ту же структуру. В простых однопроцессорных системах развитие событий по такому сценарию исклю чается путем отключения всех прерываний на время доступа к глобальным данным, однако в ядре Windows реализовано более сложное решение. Перед использованием глобального ресурса ядро временно маскирует прерывания, обработчики которых используют тот же ресурс. Для этого ядро повышает IRQL процессора до самого высокого уровня, используемого любым потен циальным источником прерываний, который имеет доступ к глобальным данным. Например, прерывание на уровне «DPC/dispatch» приводит к запус ку диспетчера ядра, использующего диспетчерскую базу данных. Следова тельно, любая другая часть ядра, имеющая дело с этой базой данных, повы шает IRQL до уровня «DPC/dispatch», маскируя прерывания того же уровня перед обращением к диспетчерской базе данных.
ГЛАВА 9 Системные механизмы 163 Эта стратегия хорошо работает в однопроцессорных системах, но не го дится для многопроцессорных конфигураций. Повышение IRQL на одном из процессоров не исключает прерываний на другом процессоре, а ядро дол жно гарантировать взаимоисключающий доступ на всех процессорах. Взаимоблокирующие операции Простейшая форма механизмов синхронизации опирается на аппаратную поддержку безопасных операций над целыми значениями и выполнения сравнений в многопроцессорной среде. Сюда относятся такие функции, как InterlockedIncrement, InterlockedDecrement, InterlockedExchange и Interlocked CompareExchange. Скажем, функция InterlockedDecrement, использует пре фикс x86инструкции lock (например, lock xadd) для блокировки многопро цессорной шины на время операции вычитания, чтобы другой процессор, модифицирующий тот же участок памяти, не смог выполнить свою опера цию в момент между чтением исходных данных и записью их нового (мень шего) значения. Эта форма базовой синхронизации используется ядром и драйверами. Спин-блокировки Механизм, применяемый ядром для взаимоисключения в многопроцес сорных системах, называется спин блокировкой (spinlock). Спинблокиров ка — это блокирующий примитив, сопоставленный с какойлибо глобальной структурой данных вроде очереди DPC (рис. 324). Рис. 3-24. Применение спин-блокировки Перед входом в любую из критических секций, показанных на рис. 324, ядро должно установить спинблокировку, связанную с защищенной очередью DPC. Если спинблокировка пока занята, ядро продолжает попытки установить спинблокировку до тех пор, пока не достигнет успеха. Термин получил такое название изза поведения ядра (и соответственно процессора), которое «кру тится» (spin) в цикле, повторяя попытки, пока не захватит блокировку.
164 ГЛ А В А 3 БЕЗОПАСНОСТЬ Спинблокировки, как и защищаемые ими структуры данных, находятся в глобальной памяти. Код для их установки и снятия написан на языке ас семблера для максимального быстродействия. Во многих архитектурах спинблокировка реализуется аппаратно поддерживаемой командой test andset, которая проверяет значение переменной блокировки и устанавли вает блокировку, выполняя всего одну атомарную команду. Это предотвра щает захват блокировки вторым потоком в промежуток между проверкой переменной и установкой блокировки первым потоком. Всем спинблокировкам режима ядра в Windows назначен IRQL, всегда соответствующий уровню «DPC/dispatch» или выше. Поэтому, когда поток пытается установить спинблокировку, все действия на этом или более низ ком уровне IRQL на данном процессоре прекращаются. Поскольку диспетче ризация потоков осуществляется при уровне «DPC/dispatch», поток, удержи вающий спинблокировку, никогда не вытесняется, так как данный IRQL мас кирует механизмы диспетчеризации. Такая маскировка не дает прервать вы полнение критической секции кода под защитой спинблокировки и обеспе чивает быстрое ее снятие. Спинблокировки используются в ядре с большой осторожностью и устанавливаются на минимально возможное время. ПРИМЕЧАНИЕ Поскольку IRQL — достаточно эффективный меха низм синхронизации для однопроцессорных систем, функции уста новки и снятия спинблокировки в однопроцессорных версиях HAL на самом деле просто повышают и понижают IRQL. Ядро предоставляет доступ к спинблокировкам другим компонентам исполнительной системы через набор функций ядра, включающий KeAcqui reSpinlock и KeReleaseSpinlock. Например, драйверы устройств требуют спин блокировки, чтобы система гарантировала единовременный доступ к реги страм устройства и другим глобальным структурам данных со стороны лишь одной части драйвера (и только с одного процессора). Спинблокировка не предназначена для пользовательских программ — они должны оперировать объектами, которые рассматриваются в следующем разделе. Спинблокировки ядра накладывают ограничения на использующий их код. Как уже отмечалось, их IRQL всегда равен «DPC/dispatch», поэтому уста новивший спинблокировку код может привести к краху системы, если по пытается заставить планировщик выполнить операцию диспетчеризации или вызовет ошибку страницы. Спин-блокировки с очередями В некоторых ситуациях вместо стандартной спинблокировки применяет ся особый тип спинблокировки — с очередью (queued spinlock). Спинбло кировка с очередью лучше масштабируется в многопроцессорных системах, чем стандартная. Как правило, Windows использует лишь стандартные спин блокировки, когда конкуренция за спинблокировку ожидается низкой. Спинблокировка с очередью работает так: процессор, пытаясь устано вить такую спинблокировку, которая в данный момент занята, ставит свой
ГЛАВА 9 Системные механизмы 165 идентификатор в очередь, сопоставленную с этой спинблокировкой. Осво бодив спинблокировку, удерживавший ее процессор передает блокировку тому процессору, чей идентификатор стоит в очереди первым. Между тем процессор, ожидающий занятую спинблокировку, проверяет статус не са мой спинблокировки, а флага того процессора, чей идентификатор распо лагается в очереди прямо перед идентификатором ждущего процессора. Тот факт, что спинблокировка с очередью устанавливает флаги, а не гло бальные блокировки, имеет два следствия. Вопервых, уменьшается интенсив ный трафик, связанный с межпроцессорной синхронизацией. Вовторых, вместо случайного выбора процессора из группы ожидающих спинблоки ровку реализуется четкий порядок спинблокировки по типу FIFO («первым вошел, первым вышел»). Такой порядок позволяет достичь более согласован ной работы процессоров, использующих одну и ту же блокировку. Windows определяет ряд глобальных спинблокировок с очередями, со храняя указатели на них в массиве, который содержится в блоке PCR (pro cessor control region) каждого процессора. Глобальную спинблокировку можно получить вызовом KeAcquireQueuedSpinlock с индексом в массиве PCR, по которому сохранен указатель на эту спинблокировку. Количество гло бальных спинблокировок растет по мере появления новых версий опера ционной системы, и таблица их индексов публикуется в заголовочном файле Ntddk.h, поставляемом с DDK. ЭКСПЕРИМЕНТ: просмотр глобальных спин-блокировок с очередями Вы можете наблюдать за состоянием глобальных спинблокировок с очередями, используя команду !qlock отладчика ядра. Эта команда име ет смысл лишь в многопроцессорной системе, так как в однопроцес сорной версии HAL спинблокировки не реализованы. В следующем примере (подготовленном в Windows 2000) спинблокировка с очере дью для базы данных диспетчера ядра удерживается процессором но мер 1, а остальные спинблокировки этого типа не затребованы (о базе данных диспетчера ядра см. главу 6). kd> !qlocks Key: O = Owner, 1n = Wait order, blank = not owned/waiting, C = Corrupt Lock Name KE KE MM MM CC CC       Dispatcher Context Swap PFN System Space Vacb Master Processor Number 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 O
166 ГЛ А В А 3 БЕЗОПАСНОСТЬ Внутристековые спин-блокировки с очередями Помимо статических спинблокировок с очередями, определяемых глобаль но, ядра Windows XP и Windows Server 2003 поддерживают динамически создаваемые спинблокировки с очередями. Для их создания предназначе ны функции KeAcquireInStackQueuedSpinlock и KeReleaseInStackQueuedSpin lock. Этот тип блокировок используется несколькими компонентами, в том числе диспетчером кэша, диспетчером пулов исполнительной системы (exe cutive pool manager) и NTFS. Упомянутые функции документированы в DDK для сторонних разработчиков драйверов. KeAcquireInStackQueuedSpinlock принимает указатель на структуру данных спинблокировки и описатель очереди спинблокировки. Этот описатель в дей ствительности является структурой данных, в которой ядро хранит информа цию о состоянии блокировки, в частности сведения о владельце блокировки и об очереди процессоров, ожидающих освобождения этой блокировки. Взаимоблокирующие операции в исполнительной системе Ядро предоставляет ряд функций синхронизации, использующих спинблоки ровки для более сложных операций, например для добавления и удаления эле ментов из одно и двунаправленных связанных списков. К таким функциям, в частности, относятся ExInterlockedPopEntryList и ExInterlockedPushEntryList (для однонаправленных связанных списков), ExInterlockedInsertHeadList и ExInter lockedRemoveHeadList (для двунаправленных связанных списков). Все эти функ ции требуют передачи стандартной спинблокировки в качестве параметра и интенсивно используются в ядре и драйверах устройств. Синхронизация при низком IRQL Компоненты исполнительной системы вне ядра также нуждаются в синхро низации доступа к глобальным структурам данных в многопроцессорной среде. Например, у диспетчера памяти есть только одна база данных блоков страниц. Обращение к ней осуществляется как к глобальной структуре дан ных, и драйверам устройств необходима гарантия получения монопольно го доступа к своим устройствам. Вызывая функции ядра, исполнительная система может создать спинблокировку, установить ее и снять. Однако спинблокировка лишь частично удовлетворяет потребности ис полнительной системы в синхронизации. Поскольку спинблокировка озна чает фактическую остановку процессора, она применяется только при двух условиях: 쐽 требуется непродолжительное обращение к защищенным ресурсам без сложного взаимодействия с другим кодом; 쐽 код критической секции нельзя выгрузить в страничный файл, он не ссы лается на данные в подкачиваемой памяти, не вызывает внешние проце дуры (включая системные сервисы) и не генерирует прерывания или ис ключения.
ГЛАВА 9 Системные механизмы 167 Эти противоречащие друг другу ограничения нельзя соблюсти одновре менно ни при каких обстоятельствах. Более того, кроме взаимоисключения, исполнительная система должна выполнять и другие алгоритмы синхрони зации, а также предоставлять механизмы синхронизации пользовательско му режиму. Существует несколько дополнительных механизмов синхронизации, при меняемых, когда спинблокировки не годятся: 쐽 объекты диспетчера ядра (kernel dispatcher objects); 쐽 быстрые мьютексы (fast mutexes) и защищенные мьютексы (guarded mu texes); 쐽 блокировки с заталкиванием указателя (push locks); 쐽 ресурсы исполнительной системы (executive resources). В таблице 39 кратко сравниваются возможности этих механизмов и их взаимосвязь с доставкой APC режима ядра. Таблица 3-9. Механизмы синхронизации режима ядра Предоставляется драйверам устройств Отключает обычные APC режима ядра доступ Отключает специальные APC режима ядра Поддерживает разделяемый и моно- Поддерживапольный ет рекурсивзахват ный захват Мьютексы диспетчера ядра Да Да Нет Да Нет Семафоры диспетчера ядра Да Нет Нет Нет Нет Быстрые мьютексы Да Да Да Нет Нет Защищенные мьютексы Нет Да Да Нет Нет Блокировки с заталкиванием указателя Нет Нет Нет Нет Да Да Нет Да Да Ресурсы исполни Да тельной системы Объекты диспетчера ядра Ядро предоставляет исполнительной системе дополнительные механизмы синхронизации в форме объектов, в совокупности известных как объекты диспетчера ядра. Синхронизирующие объекты, видимые из пользовательско го режима, берут свое начало именно от этих объектов диспетчера ядра. Каж дый синхронизирующий объект, видимый из пользовательского режима, ин капсулирует минимум один объект диспетчера ядра. Семантика синхрониза ции исполнительной системы доступна программистам через Windowsфунк ции WaitForSingleObject и WaitForMultipleObjects, реализуемые подсистемой Windows на основе аналогичных системных сервисов, предоставляемых дис петчером объектов. Поток в Windowsприложении можно синхронизировать
168 ГЛ А В А 3 БЕЗОПАСНОСТЬ по таким Windowsобъектам, как процесс, поток, событие, семафор, мьютекс, ожидаемый таймер, порт завершения вводавывода или файл. Еще один тип синхронизирующих объектов исполнительной системы назван (без особой на то причины) ресурсами исполнительной системы (executive resources). Эти ресурсы обеспечивают как монопольный доступ (по аналогии с мьютексами), так и разделяемый доступ для чтения (когда несколько потоков«читателей» обращается к одной структуре только для чтения). Однако они доступны лишь коду режима ядра, а значит, недоступ ны через Windows API. Ресурсы исполнительной системы являются не объек тами диспетчера ядра, а скорее структурами данных, память для которых выделяется прямо из неподкачиваемого пула, имеющего свои специализи рованные сервисы для инициализации, блокировки, освобождения, запро са и ожидания. Структур