Архитектура ядра операционной системы windows

Время на прочтение8 мин

Количество просмотров63K

Windows – одна из наиболее многогранных и гибких ОС, она работает на совершенно разных архитектурах и доступна в разных вариантах. На сегодня она поддерживает архитектуры x86, x64, ARM и ARM64. Windows в своё время поддерживала Itanium, PowerPC, DEC Alpha и MIPS. Кроме того, Windows поддерживает целый набор SKU, работающих в различных условиях; от дата-центров, ноутбуков, Xbox и телефонов до встраиваемых версий для интернета вещей, например, в банкоматах.

Самый удивительный аспект состоит в том, что ядро Windows практически не меняется в зависимости от всех этих архитектур и SKU. Ядро динамически масштабируется в зависимости от архитектуры и процессора, на котором оно работает, так, чтобы пользоваться всеми возможностями оборудования. Конечно, в ядре присутствует определённое количество кода, связанного с конкретной архитектурой, однако его там минимальное количество, что позволяет Windows запускаться на разнообразных архитектурах.

В этой статье я расскажу об эволюции ключевых частей ядра Windows, которые позволяют ему прозрачно масштабироваться от чипа NVidia Tegra низкого потребления, работающего на Surface RT 2012 года, до гигантских монстров, работающих в дата-центрах Azure.

Менеджер задач Windows, работающий на пререлизной машине класса Windows DataCenter, с 896 ядрами, поддерживающими 1792 логических процессора и 2 Тб памяти

Эволюция единого ядра

Перед тем, как обсудить детали ядра Windows, сделаем небольшое отступление в сторону рефакторинга. Рефакторинг играет ключевую роль в увеличении случаев повторного использования компонентов ОС на различных SKU и платформах (к примеру, клиент, сервер и телефон). Базовая идея рефакторинга – позволить повторно использовать одни и тем же DLL на разных SKU, поддерживая небольшие модификации, сделанные специально под нужный SKU, не переименовывая DLL и не ломая работу приложений.

Базовая технология рефакторинга Windows – мало документированная технология под названием «наборы API». Наборы API – это механизм, позволяющий ОС разъединять DLL и место их применения. К примеру, набор API позволяет приложениям для win32 продолжать пользоваться kernel32.dll, притом, что реализация всех API прописана в другой DLL. Эти DLL с реализацией также могут отличаться у разных SKU. Посмотреть наборы API в деле можно, запустив обход зависимостей на традиционной Windows DLL, например, kernel32.dll.

Закончив это отступление по поводу строения Windows, позволяющего системе максимизировать повторное и совместное использование кода, перейдём к техническим глубинам запуска ядра по планировщику, являющегося ключом к масштабированию ОС.

Компоненты ядра

Windows NT – это, по сути, микроядро, в том смысле, что у него есть своё core Kernel (KE) с ограниченным набором функций, использующее исполняемый уровень (Executive layer, Ex) для выполнения всех политик высокого уровня. EX всё ещё является режимом ядра, так что это не совсем микроядро. Ядро отвечает за диспетчеризацию потоков, синхронизацию между процессорами, обработку исключений аппаратного уровня и реализацию низкоуровневых функций, зависящих от железа. Слой EX содержит различные подсистемы, обеспечивающие набор функциональности, который обычно считается ядром – IO, Object Manager, Memory Manager, Process Subsystem, и т.д.

Чтобы лучше представить себе размер компонентов, вот примерное разбиение по количеству строк кода в нескольких ключевых каталогах дерева исходников ядра (включая комментарии). В таблицу не вошло ещё много всего, относящегося к ядру.

Более подробная информация об архитектуре Windows содержится в серии книг “Windows Internals”.

Планировщик

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

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

Проработав квантовое время (минимальное количество времени, которое может работать поток), поток испытывает уменьшение динамического приоритета, чтобы потоки с высоким приоритетом не могли работать вечно, душа всех остальных. Когда для работы пробуждается другой поток, ему повышают приоритет, рассчитанный на основе важности события, из-за которого произошло ожидание ( например, приоритет сильно повышается для находящегося на переднем плане интерфейса пользователя, и несильно – для завершения операций ввода/вывода). Поэтому поток работает с высоким приоритетом, пока он остаётся интерактивным. Когда он становится связанным преимущественно с вычислениями (CPU-bound), его приоритет падает, и к нему возвращаются уже после того, как другие потоки с высоким приоритетом получат своё процессорное время. Кроме того, ядро произвольным образом увеличивает приоритет готовых потоков, не получивших процессорного времени за определённый промежуток, чтобы предотвратить их вычислительное голодание и подправить инверсию приоритетов.

У планировщика Windows изначально была одна очередь готовности, из которой он выбирал следующий, наивысший по приоритету поток для запуска. Однако с началом поддержки всё большего количества процессоров, единственная очередь превратилась в узкое место, и примерно в районе выхода Windows Server 2003 планировщик поменял работу и организовал по одной очереди готовности на процессор. При переходе на поддержку нескольких запросов на один процессор единую глобальную блокировку, защищающую все очереди, делать не стали, и разрешили планировщику принимать решения на основе локальных оптимумов. Это означает, что в любой момент в системе работает один поток с наивысшим приоритетом, но не обязательно означает, что N самых приоритетных потоков в списке (где N – число процессоров) работают в системе. Такой подход оправдывал себя, пока Windows не начала переходить на CPU с низким энергопотреблением, например, на ноутбуки и планшеты. Когда на таких системах поток с наивысшим приоритетам не работал (например, поток переднего плана интерфейса пользователя), это приводило к заметным глюкам интерфейса. Поэтому в Windows 8.1 планировщик перевели на гибридную модель, с очередями для каждого процессора для потоков, связанных с этим процессором, и разделяемой очередью готовых процессов для всех процессоров. Это не сказалось на быстродействии заметным образом благодаря другим изменениям в архитектуре планировщика, например, рефакторингу блокировки базы данных диспетчера.

В Windows 7 ввели такую вещь, как динамический планировщик со справедливыми долями (Dynamic Fair Share Scheduler, DFSS); это в первую очередь касалось терминальных серверов. Эта особенность пыталась решить проблему, связанную с тем, что одна терминальная сессия с высокой загрузкой CPU могла повлиять на потоки в других терминальных сессиях. Поскольку планировщик не учитывал сессии и просто использовал приоритет для распределения потоков, пользователи в разных сессиях могли повлиять на работу пользователей в других сессиях, задушивая их потоки. Также это давало несправедливое преимущество сессиям (и пользователям) с большим количеством потоков, поскольку у сессии с большим количеством потоков было больше возможностей получить процессорное время. Была сделана попытка добавить в планировщик правило, по которому каждую сессию рассматривали на равных с другими по количеству процессорного времени. Подобная функциональность есть и в ОС Linux с их абсолютно честным планировщиком (Completely Fair Scheduler). В Windows 8 эту концепцию обобщили в виде группы планировщика и добавили в планировщик, в результате чего каждая сессия попадала в независимую группу. Кроме приоритетов для потоков, планировщик использует группы планировщика как индекс второго уровня, принимая решение по поводу того, какой поток запускать следующим. В терминальном сервере все группы планировщика имеют одинаковый вес, поэтому все сессии получают одинаковое количество процессорного времени вне зависимости от количества или приоритетов потоков внутри групп планировщика. Кроме того, такие группы также используют для более точного контроля над процессами. В Windows 8 рабочие объекты (Job) были дополнены так, чтобы поддерживать управление процессорным временем. При помощи специального API можно решать, какую часть процессорного времени может использовать процесс, должно это быть мягкое или жёсткое ограничение, и получать уведомления, когда процесс достигает этих ограничений. Это похоже на управление ресурсами в cgroups на Linux.

Начиная с Windows 7, в Windows Server появилась поддержка более 64 логических процессоров на одном компьютере. Чтобы добавить поддержку такому большому количеству процессоров, в системе ввели новую категорию, «процессорная группа». Группа – неизменный набор логических процессоров количеством не более 64 штук, которые рассматриваются планировщиком как вычислительная единица. Ядро при загрузке определяет, какой процессор к какой группе отнести, и у машин с количеством процессорных ядер менее 64 этот подход практически невозможно заметить. Один процесс может разделяться на несколько групп (например, экземпляр SQL-сервера), единственный поток в один момент времени может выполняться только в рамках одной группы.

Но на машинах, где число ядер CPU превышает 64, Windows начала демонстрировать новые узкие места, не дававшие таким требовательным приложениям, как SQL-сервер, масштабироваться линейно с ростом количества ядер процессора. Поэтому, даже при добавлении новых ядер и памяти, замеры скорости не показывали её существенного увеличения. Одной из главных проблем, связанных с этим, был спор по поводу блокировки базы диспетчера. Блокировка базы диспетчера защищала доступ к объектам, работу которых необходимо было запланировать. Среди этих объектов – потоки, таймеры, порты ввода/вывода, другие объекты ядра, подверженные ожиданию (события, семафоры, мьютексы). Под давлением необходимости разрешения таких проблем, в Windows 7 была проделана работа по устранению блокировки базы диспетчера и замене её на более точные подстройки, например, пообъектную блокировку. Это позволило таким замерам производительности, как SQL TPC-C, продемонстрировать рост скорости на 290% по сравнению с предыдущей схемой на некоторых конфигурациях. Это был один из крупнейших взлётов производительности в истории Windows, случившихся благодаря изменению единственной особенности.

Windows 10 принесло другую инновацию, внедрив наборы процессоров (CPU Sets). CPU Sets позволяют процессу разделять систему так, что процесс может распределиться на несколько групп процессоров, не позволяя другим процессам пользоваться ими. Ядро Windows даже не даёт прерываниям устройств пользоваться процессорами, входящими в ваш набор. Это гарантирует, что даже устройства не смогут исполнять свой код на процессорах, выданных группе вашего приложения. Это похоже на низкотехнологичную виртуальную машину. Понятно, что это мощная возможность, поэтому в неё встроено множество мер безопасности, чтобы разработчик приложения не допустил больших ошибок, работая с API. Функциональность наборов CPU используется в игровом режиме (Game Mode).

Наконец, мы приходим к поддержке ARM64, появившейся у Windows 10. Архитектура ARM поддерживает архитектуру big.LITTLE, гетерогенную по своей природе – «большое» ядро работает быстро и потребляет много энергии, а «малое» ядро работает медленно и потребляет меньше. Идея в том, что малозначительные задачи можно выполнять на малом ядре, экономя таким образом батарею. Для поддержки архитектуры big.LITTLE и увеличения времени работы от батареи при работе Windows 10 на ARM, в планировщик добавили поддержку гетерогенной планировки, учитывающую пожелания приложения, работающего с архитектурой big.LITTLE.

Под пожеланиями я имею в виду то, что Windows старается качественно обслуживать приложения, отслеживая потоки, выполняющиеся на переднем плане (или те, которым не хватает процессорного времени), и гарантируя их выполнение на «большом» ядре. Все фоновые задачи, сервисы, другие вспомогательные потоки выполняются на малых ядрах. Также в программе можно принудительно отметить маловажность потока, чтобы заставить его работать на малом ядре.

Работа от чужого имени [Work on Behalf]: в Windows довольно много работы на переднем плане осуществляется другими сервисами, работающими в фоне. К примеру, при поиске в Outlook сам поиск проводится фоновым сервисом Indexer. Если мы просто запустим все сервисы на малом ядре, пострадает качество и скорость работы приложений на переднем плане. Чтобы при таких сценариях работы она не замедлялась на архитектурах big.LITTLE, Windows отслеживает вызовы приложения, поступающие к другим процессам, чтобы выполнять работу от их имени. В таком случае мы выдаём приоритет переднего плана потоку, относящемуся к сервису, и заставляем его выполняться на большом ядре.

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

Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку

Чтобы выяснить, насколько хороша Windows на самом деле, нужно изучить ее ядро и понять, как оно устроено и что оно может. В данной статье мы сравниваем Windows с Linux и Mac OS X и выявляем сильные и слабые стороны этой операционной системы, имеющей так много пользователей и так мало поклонников.

Картинка с сайта: ichip.ru

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

Картинка с сайта: ichip.ru

Windows Debugger анализирует образ памяти и показывает причины сбоев — в нашем случае виноват драйвер режима ядра

Картинка с сайта: ichip.ru

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

Картинка с сайта: ichip.ru

Ядро Linux отвечает за управление командами ввода-вывода, памятью и процессами. На самом низком уровне ядра находятся функции, управляющие прерыванием процессов

Картинка с сайта: ichip.ru

Доступ к ядру Linux открыт каждому. На рисунке — фрагмент конфигурации ядра версии 2.6.19

Картинка с сайта: ichip.ru

Ядро системы Apple основано на двух источниках: в нем используются функции основанной на Unix подсистемы BSD наряду с частями микроядра Mach Со словом «Windows» связано много предубеждений и мифов. Например, бытует мнение, что работать в Windows крайне опасно, так как миллионы вирусов, гуляющих по Интернету, атакуют исключительно эту ОС. К тому же многие уверены, что детище Microsoft не отличается высокой производительностью: чем дольше вы пользуетесь этой системой, тем медленнее она работает. Что касается стабильности, то всем хорошо знаком пресловутый «синий экран». Это и неудивительно: Vista состоит из семидесяти миллионов строк кода — как тут не запутаться! Чтобы выяснить, справедливы ли все эти обвинения, необходимо заглянуть в самое ядро операционной системы и проверить, насколько оно отвечает трем критериям: безопасность, производительность и стабильность. А для сравнения возьмем ядра двух других систем — Linux и Mac OS X. Кроме того, мы подробно расскажем, какие методы используют Windows и ее конкуренты.

Контроль над системой

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

Чтобы обеспечить безопасность системы, ядро следит за всеми текущими процессами, определяя, какие программы и как долго могут пользоваться аппаратными ресурсами. Стабильность достигается за счет структурирования ресурсов. За этим стоят функции, к которым обращаются каждый день — например, отображение файловых систем на жестком диске. Высокая производительность важна при возникновении конфликтов доступа — например, когда две программы пытаются записать данные на жесткий диск одновременно. В этом случае ядро расставляет приоритеты и предоставляет доступ одной из программ, в то время как второй приходится ждать. Ниже мы подробно расскажем, как именно Windows справляется со всеми этими задачами.

Обзор типов ядер

Монолитное.

Одно большое ядро для всех задач — в этом заключается идея монолита. Такое ядро отвечает за управление памятью и процессами, за коммуникацию между процессами, а также предлагает функции для поддержки драйверов и оборудования. Именно к этой категории относятся Windows, Linux и Mac OS X.

Микро. Ошибка в ядре может вывести из строя всю операционную систему. Поэтому микроядро отличается предельно малыми размерами — чтобы свести ошибки и сбои к минимуму. Но поскольку ядро должно поддерживать широкий набор функций, оно подразделяется на несколько модулей, из которых только один работает в режиме ядра. Классическим примером является Mach — компонент Mac OS X. Так или иначе, до сих пор ни одна операционная система с микроядром не завоевала популярности среди домашних пользователей.

Гибрид.

Гибридное ядро представляет собой нечто среднее между монолитным и микроядром. Само ядро делается облегченным, а для дополнительных задач существуют динамические модули. В Linux и OS X тоже можно подгружать части ядра, но не в таких масштабах, чтобы отнести их ядра к гибридным.

Windows : работает на любом оборудовании

Начиная с NT, в архитектуре Windows выделяется два режима: пользовательский и привилегированный, или режим ядра. Это относится и к Vista.

В режиме пользователя работает практически все, что видит пользователь, то есть приложения вроде Word или Photoshop. В этом режиме программы не имеют прямого доступа к оборудованию или оперативной памяти. Таким образом, пользовательский режим надежно изолирован, а все обращения к глубинам системы направляются через специальные интерфейсы, такие как Win32 API с системными библиотеками DLL (Dynamic Link Libraries).

Такой режим ядра — фоновый и практически незаметен для пользователя. Все хорошо до тех пор, пока не возникнет какая-либо проблема — например, драйвер режима ядра (см. схему ядра Windows) не обрушит всю систему, и взору пользователя предстанет синий экран.

Центральное значение здесь имеет файл ntoskrnl.exe.

По аналогии с режимом ядра и пользовательским режимом его задачи также делятся на две группы — слой ядра и исполнительная система. Главная задача слоя ядра — планировать загрузку центрального процессора, то есть распределять процессорное время между отдельными программами. Исполнительная система отвечает за виртуальную память, процессы ввода-вывода и другие задачи.

Глубже всего в системе располагается уровень аппаратных абстракций (Hardware Abstraction Layer, HAL). Он предоставляет другим слоям ОС службы для работы со встроенным оборудованием. Так, слой ядра может распределять процессорное время между программами независимо от того, какой процессор используется в компьютере — двуядерный AMD или четырехъядерный Intel. Если бы не HAL, Microsoft пришлось бы разрабатывать отдельную Windows для каждого компьютера.

Средства для отладки Windows WINDBG Чтобы проанализировать состояние памяти при выдаче «синего экрана», вам понадобится программа-отладчик, такая как WinDbg. На странице загрузок Microsoft вы найдете также соответствующий файл символов. www.microsoft.com/whdc/DevTools/Debugging NotMyFault тестирует систему на прочность: эта программа провоцирует ошибки в Windows и пытается ее обрушить. Экспериментируйте осторожно! Process Explorer. Управление процессами — одна из главных задач операционных систем. Process Explorer показывает все текущие процессы, соответствующие дескрипторы и связи между процессами. http://download.sysinternals.com

Linux : подгружает модули при необходимости

Хотя ядро Linux (см. схему) основано на Unix, но сходства с Windows у него больше, чем можно подумать. Оно также располагается непосредственно над оборудованием и играет роль своеобразной прослойки между оборудованием и работающими программами. Стандартные задачи тоже сходны: как и в Windows, ядро сотрудничает с устройствами ввода-вывода и берет на себя управление памятью. Оно также управляет процессами, то есть решает, какая задача в данный момент имеет приоритет, и получает доступ к процессорному времени. Для этого на самых нижних уровнях ядра располагаются функции управления прерываниями (interrupts).

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

Архитектура Linux, как и Windows, имеет монолитное строение. Тем не менее, ядро может динамически догружать различные модули. В основном они дополняют имеющиеся компоненты или даже полностью заменяют их.

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

Mac OS X : сила двух ядер

Ядро Mac OS X сокращенно обозначается как XNU — X is Not Unix.

Эта аббревиатура соответствует действительности, потому что ядро операционной системы Apple скомбинировано из двух источников, и лишь его часть имеет отношение к Unix (см. рис.). Остальное компания взяла из проекта Mach — классического примера микроядра (см. рис.). При этом Mach используется только для передачи сообщений (message passing), то есть эффективной коммуникации между отдельными частями ядра. Помимо Mach XNU содержит код проекта FreeBSD, который основан на Unix. Эта часть отвечает за взаимодействие с пользователем, обработку сигналов и совместимость со стандартами POSIX.

Последнее гарантирует, что большинство программ для Unix будут функционировать и в Mac OS X.

Важным компонентом Mach является система ввода-вывода (I/O Kit).

Именно здесь заключается существенное отличие от Windows и Linux: I/O Kit представляет собой дополнительный слой абстракций между оборудованием и остальной системой.

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

Помимо служб ядра Mac OS X позволяет также использовать расширения ядра. Система загружает их динамически по мере необходимости. Часто в таких случаях говорят о гибридном ядре, однако эксперты относят ядро Mac OS X скорее к монолитным из-за особенностей его строения.

Процессы: цифровая подпись как средство защиты

Важной задачей ядра является управление процессами.

Под этим подразумевается не только расстановка приоритетов, но и обеспечение безопасности. В классическом варианте в Windows процессы запускаются и управляются через интерфейс Win32 API.

В ядре этим занимается исполнительная система NTOS.

Доступ к объектам ядра, относящимся к про цессу обеспечивают так называемые дескрипторы (handles). Процессы в Windows могут запускать новые процессы. Так, Word (процесс 1) может открыть новый документ (процесс 2). В классической модели Windows Word имеет право также стереть или изменить новый документ. Иными словами, по общему правилу процесс может распоряжаться порожденными собою же процессами.

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

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

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

Защищенные процессы — показательный пример того, как Microsoft приспосабливает устаревшую архитектуру Windows к современным проблемам.

В Linux и Mac OS X процессная модель сходна с моделью Windows: процессы-«родители» контролируют порожденных ими «детей». Однако защищенных процессов, таких как в Vista, нет. Это неудивительно: Microsoft использует эту технологию в первую очередь для цифрового управления правами (Digital Rights Management).

Таким образом, при наличии администраторских (root) прав в Linux и Mac OS X можно делать все, даже анализировать процессы и манипулировать ими.

ASLR : «неуловимые» адреса

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

Например, NX-бит препятствует исполнению данных DEP (Data Execution Prevention).

При попытке выполнить код, который находится в участке памяти, помеченном «не для исполнения», возникает внутренняя ошибка. В Windows отключить DEP для 64-битных программ и драйверов нельзя, зато для 32-битных (все еще весьма распространенных) — без проблем. Это позволяет злоумышленникам вызвать переполнение буфера. В результате они могут инфицировать такие процессы, как Internet Explorer, и проникнуть внутрь системы. После того как вредитель закрепился в Windows, он может использовать Windows-API в своих интересах — например, для того, чтобы считать нужные ему данные или изменить конфигурацию системы.

Поэтому Microsoft ввела новую функцию защиты ядра — Address Space Load Randomization (ASLR, «рандомизация адресного пространства»). Частично она была реализована уже в SP2 для ХР, но полностью — только в Vista. Ее суть заключается в следующем. В Windows входными воротами для злоумышленников обычно являются библиотеки DLL, которые в предшествовавших версиях системы всегда загружались в одни и те же участки памяти. С ASLR системные DLL и исполняемые файлы при каждой загрузке системы попадают в разные участки оперативной памяти, чтобы вредоносное ПО больше не могло атаковать системные операции по стандартным адресам. Для этого менеджер памяти имеет в своем распоряжении 256 различных адресов и при загрузке DLL выбирает один из них случайным образом. Такая «плавающая» стратегия ASLR имеет дополнительное преимущество: адресное пространство упаковано плотнее, чем в более ранних версиях Windows, так что непрерывных свободных участков в памяти остается больше.

В специальных дистрибутивах Linux, таких как Hardened Gentoo, ASLR уже полностью реализована. В стандартном же ядре содержится лишь неполный вариант. В современном OS X Build ASLR используется для нескольких библиотек, но их полноценная реализация, к сожалению, отсутствует.

Проверка подлинности: надежный код

В качестве противоядия Microsoft использует в Vista подпись кода в режиме ядра (KMCS), которая разрешает загружать лишь те драйверы устройств, которые снабжены цифровой подписью. Большинство драйверов получают подписи через лабораторию WHQl (Windows Hardware Quality Lab), однако разработчики могут подписывать свой код сами — правда, для этого им нужен действительный сертификат. Windows проверяет также, имеет ли выданный сертификат отношение к одному из центров сертификации, данные о которых содержатся в загрузчике Windows и ядре ОС. Надо сказать, что 32-битные системы Vista хотя и проверяют цифровые подписи драйверов, все-таки позволяют загрузить неподписанные драйверы.

В 64-битных Windows такой номер не пройдет.

Все модули ядра в Mac OS X и Linux, в принципе, могут иметь цифровую подпись. Хотя теоретически это относится и к драйверам, никаких механизмов проверки в этих операционных системах не встроено.

MMCSS : приоритет видео

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

Чтобы такого не происходило, например, когда вы смотрите фильм, в Windows встроены специальные функции для мультимедийных файлов. Поэтому антивирусы и службы Windows в основном работают в фоновом режиме и не мешают просмотру.

В Vista приоритет фильмов и музыки обеспечивается службой планирования мультимедийных классов — MMCSS. Для этого мультимедийное приложение, такое как Media Player, сначала должно зарегистрироваться в этой службе. Данная служба, реализованная в файле %SystemRoot%System32Mmcss.dll, включает в себя поток для управления приоритетами. Windows предусматривает ступени приоритетности от 0 до 31, при этом MMCSS имеет очень высокую приоритетность — 27. Соответственно, приоритетность всех зарегистрированных мультимедийных потоков поднимается до 27. С 16-й ступени начинается режим реального времени, то есть потоку с приоритетом 16 остальные помешать уже не могут.

Linux предлагает еще более высокую градацию шкалы приоритетности — от 0 до 99. Для мультимедийных задач, например, на медиасерверах, такая разбивка подходит лучше. В Mac OS X планировщик является одним из используемых компонентов Mach.

Шкала приоритетности здесь еще мельче — от 0 до 127, и это не единственное подтверждение того, что Mach намного современнее, чем Linux и Windows. В OS X мультимедийное приложение может даже присвоить себе фиксированную долю вычислительного времени. При достаточной мощности это практически исключает риск образования узких мест.

Ввод-вывод: приоритетность задач

Высокая приоритетность при просмотре фильмов может негативно отразится на многозадачности. Так, до ХР в Windows существовали серьезные проблемы с фоновыми службами, например, автоматической дефрагментацией.

Конечно, это помогало поддерживать жесткий диск в порядке, но кому же понравится, когда, к примеру, Outlook выпадает из обоймы на два часа? Однако благодаря приоритетности ввода-вывода ждать больше не придется. Так, в Vista процессы «переднего плана» (не фоновые) всегда пользуются преимуществом, и дефрагментация приостановится до тех пор, пока пользователь не сделает в своей работе очередную паузу. Система ввода-вывода в Vista предполагает пять ступеней приоритетности — от «очень низкая» до «критически важная»; стандартный уровень — «нормальная». Фоновым задачам Windows автоматически присваивает низкую приоритетность, однако менеджер памяти всегда считается критически важным: действительно, когда оперативной памяти начинает не хватать, он должен незамедлительно сбросить данные на жесткий диск.

Команды ввода-вывода, посылаемые от драйверов устройств (такие как движение мыши), поступают в очередь со средней приоритетностью.

Еще одна ценная возможность заключается в том, что Vista может резервировать для операций ввода-вывода фиксированные диапазоны. Так, например, Media Player может потребовать от системы ввода-вывода гарантию, что фильм будет считываться с DVD в определенном темпе.

Тогда как в Vista приоритетность ввода-вывода — нововведение, в Mac OS X и Linux данный прием используется давно. В Mac OS X это заложено в архитектуре, так как для передачи сообщений используется Mach. В системах семейства Linux, начиная с ядра 2.6, тоже встроена эффективная схема приоритетов.

Адресное пространство: динамическое управление

32-битные процессоры накладывают на Windows и инсталлированные программы серьезные ограничения в отношении адресного пространства. Так, ядро Windows не может занимать больше 2 Гбайт. Когда нужно выделить место для драйверов, кеша файловой системы и стека, это может привести к определенным трудностям. Поэтому в Vista адресное пространство ядра динамическое. Оно занимается раздачей и разблокированием участков в зависимости от рабочих потребностей.

Операционные системы Linux и Mac OS X не имеют строгих ограничений. И в этих операционных системах общие размеры ядра имеют свой предел. В целом формат отдельных компонентов никак не ограничен. Действительно, в отличие от Windows в этих системах нет четкого разграничения между пространством ядра и пространством драйверов.

КТМ: предотвращение программных сбоев

Если приложение намерено предпринять ряд взаимосвязанных изменений, оно может создать либо дескриптор КТм («диспетчера транзакций ядра») и транзакцию DTC (Distributed Transaction Coordinator, «координатора распределенных транзакций»), либо просто дескриптор КТМ, и выполнять изменения файлов и ключей реестра в рамках этой транзакции. Если все прошло успешно, транзакция подтверждается — изменения приняты. До этого программа может в любой момент отменить весь процесс. Дополнительное преимущество заключается в том, что другие приложения видят эти изменения только после того, как транзакция принята.

Ядра Mac OS X и Linux тоже работают с транзакциями.

Пользователь, как правило, этого совсем не замечает, если не считать сбоев при установке обновлений. Впрочем, в обеих ОС это никак не подрывает стабильность системы, просто транзакции не будут исполнены.

Windows 7, 8, 9…

Не секрет, что Microsoft работает над новой архитектурой Windows. Прототипом операционной системы будущего (после Win7) должны стать два проекта.

Singularity обещает нам Windows без «синих экранов» и зависаний. Проект основан на трех ключевых функциях: программно-изолированные процессы (SIP), микроядро и каналы (channels).

Микроядро обеспечивает лишь неотъемлемые «ядерные» функции, такие как управление памятью, процессами и каналами, планировка процессорного времени и управление вводом-выводом. Все другие функции перекладываются на модули и реализуются изолированно друг от друга через SIP-процессы.

Проект Midori рассчитан на отдаленную перспективу. Его ядро будет иметь модульную структуру.

Преимущество заключается в том, что Windows будет лучше работать на различных платформах, таких как нетбуки, КПК или мобильные телефоны.

Вывод

Прошлые версии Windows на фоне Linux и Mac OS X смотрятся совсем неплохо. Хотя конкуренты несколько моложе, они во многом основаны на старых принципах Unix. Vista доказывает, что устаревшую архитектуру Windows можно компенсировать современными технологиями безопасности, такими как защищенные процессы или цифровые подписи кода для модулей ядра. Но, к сожалению, эти функции часто работают только в 64-битном мире, а в ХР они и вовсе отсутствуют. К тому же Linux и OS X не нуждаются в уловках вроде ASLR, поскольку они не так сильно подвержены атакам хакеров. Да и получить права администратора в Linux и Mac OS X сложнее, чем в Windows.

В Windows много застарелых проблем: например, даже в Vista дефектный драйвер все еще может обрушить всю систему. OS X выглядит несколько более современно: высокая производительность обеспечивается главным образом за счет использования компонентов Mach для коммуникаций внутри ядра, а также системы ввода-вывода I/O Kit.

В этом смысле Windows отстает, и компенсировать разрыв сумела только Vista. В пользу Linux говорит ее открытость: каждый может сконфигурировать ядро по своему усмотрению.

Для рядовых пользователей работа с ПК под управлением Windows — это как полёт в самолёте. С одной стороны дико тошнит от багов и глюков, а с другой – выйти всё равно некуда. Zip File, мамкины хаЦкеры. С вами Денчик и нынче мы наконец-то обсудим верхние уровни устройства операционной системы Windows. Рассмотрим детально процесс загрузки, архитектурные особенности и нюансы. Ну и конечно же разберём потенциальные уязвимости, которые могут встречаться в операционных процессах данной системы. Если вам интересна данная тема и вы давненько хотите узнать, что же скрывается в неё под капотом. Тогда устраивайтесь по удобней, наливайте свежую порцию чего-нибудь по забористей и приготовьтесь к путешествию в полную Виндузятню. Погнали.

Но перед тем, как мы начнём обсуждение основной темы, я бы хотел рассказать вам о партнёрах данного выпуска, хостинг-провайдере FirstVDS. FirstVDS — это крупный хостинг-провайдер, который на рынке уже 20 лет. 6 декабря ребята начали отмечать юбилей, и в честь этого праздника запустили крутейшую акцию. Что же будет 6 декабря? Будут скидки, занимательная статистика для клиентов, розыгрыш техники Apple и игра FirstRunner. Игра FirstRunner была создана разработчиками специально к 20-летию FirstVDS. Участникам предлагается помочь Ферст Джону пробежать от медленного 2002 до сверхбыстрого 2022. Играйте, ищите пасхалки, входите в ТОП и получайте дополнительный подарки. Каждому клиенту, который поиграет в игру, выпадает возможность выиграть макбук, айфон, плейстейшн или сертификаты на баланс. FirstVDS будет ждать всех на странице акции с 6 по 13 декабря! Присоединяйтесь по ссылке в описании к видео. 

Стандартное устройство машины

Ну а мы возвращаемся к основной теме нашего выпуска. Как вы помните, эталонно любая машина состоит у нас из процессора, исполняющего команды программ, быстрой памяти (ОЗУ), дискового пространства для долговременного хранения и подключения к сетке.

Касательно этих терминов вроде бы всё просто и очевидно, однако и по сей день многие ITшники называют «программами» то, что на поверку является приложением. Не путайте пожалуйста. Это совершенно разные вещи.

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

В данном случае под операционной системой я подразумеваю совокупность ядра (Kernel) и драйверов устройств. Последние соответственно относятся к самому нижнему, так называемому, железному уровню.

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

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

Ключевые версии Windows

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

Из тех, с которыми вы ещё можете столкнуться тут Windows XP. Я буквально пару лет назад работал в крупной конторе, где 90% парка состояло из ХРюш и никого это особо не парило. Как говорится, лучшее, враг хорошего.

Windows Server 2003 был весьма прорывным и дико сложным для освоения на то время. Именно с него начинается эпоха сисадминства в России. Восьмой сервер в свою очередь был чутка дружелюбнее.

Однако почему-то дико тяжёлым и ел столько оперативы, что запустить его на одной физической тачке с Касперским было практически нереально.

А учитывая то, что SSDшников ещё не было от слова совсем, удовольствия админы получили изрядную порцию.

Седьмая Винда имела кучу проблем с совместимостью. Хотя со временем с помощью обнов и сервис-паков это исправили. Точно также Мелкомягкие допилили и Восьмой сервер выпустив R2 версию, которая, как по мне и по сей день является практически идеальным решением для мелких и средних контор.

Ну про остальные ОСи говорить в целом особо нечего, ибо вы и сами можете попробовать их в деле у себя дома или на рабочих местах.

По 16 серваку в связке с 10 виндой в роли клиента у меня кстати есть целый авторский видеокурс. Можете чекнуть как-нибудь на досуге, если любите иногда развиваться, а не только писю гонять.

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

Как показывает практика, если вы шарите, то набрать команду можно в разы быстрее, нежели тыкать мышью в иконки. Рекомендую.

Application Programming Interface (API)

Интерфейс программного взаимодействия или API позволяет одной программе взаимодействовать с другой. Например, приложению с Windows.

API также имеют разные версии. Для 32 разрядных ОС они одни, для 64 разрядных другие.

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

Даю подсказку. Это как-то связано с особенностями программ. Как вы помните, программа – это набор инструкций для выполнения. Тут всё логично. Однако давайте помимо программы введём ещё такое понятие, как процесс.

Процесс – это совокупность из загруженного и исполняемого набора инструкций и контейнера для ресурсов. Ни больше ни меньше.

Любой процесс обладает рядом особенностей. Наиболее важным для вас из этого списка является PID. Он же Process ID. Он же идентификатор процесса.

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

Один процесс может запускать целое дерево из созависимых процессов. И каждый процесс в этом дереве будет иметь равные права. Это же работает в обратную сторону.

Т.е. если вы хлопните какой-нибудь процесс Explorer, всё что так или иначе связано с интерфейсом у вас отвалится. Это в целом достаточно удобная штука. Также для расширенной работы с процессами рекомендую юзать Sysinternals.

Это такой набор расширенных системных инструментов Windows от Марка Руссиновича, позволяющий получить больше информации, чем при апеллировании стандартными инструментами.

Внутри процессов у нас существуют потоки исполнения (threads). Т.е. то, что Windows может запускать на ядре процессора на исполнение.

Также внутри работающего процесса есть как минимум один поток. Windows выделяет каждому потоку квант времени для выполнения на процессоре и быстро переключает исполняющиеся потоки.

Именно это и создаёт так называемую иллюзию «параллельности» работы приложений. Ключевая идея тут заключается в разделении задач на разные потоки, чтобы не было «подвисаний».

Например, один поток рисует графический интерфейс, а другой — выполняет сложную работу. Всё, как в жизни. От каждого по возможностям на благо общего дела.

Архитектура

Windows и приложения – это, как мы знаем исполняемый код, поэтому существует задача ограничения возможностей приложений. В современных процессорах (речь про x64) по дефолту определены 4 уровня привилегий.

Про UserMode мы с вами уже поговорили в общих чертах. Kernel же, являясь по сути ядром, даёт доступ к процессору и всей оперативной памяти.

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

Наш процесс самостоятельно вызывает соответствующий сервис в ядре. Там выполняется специальная команда, переводящая вызывающий поток в kernel mode, а после завершения возвращающая его обратно в user.

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

Память

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

Поскольку процессов много, Windows распределяет между ними участки памяти так, что для процесса они как бы непрерывные, однако на самом деле это не так.

Т.е. в моменте процессор не видит этих пробелов. Для него есть только синенькие полосочки или только зелёненькие. Такие вот специфические особенности области видимости.

Если есть нужда посмотреть более детальную информацию о карте памяти процесса, то можно воспользоваться ещё одной утилитой от Руссиновича под названием VMMap.

Для примера я, как обычно, запустил стандартный блокнот. С помощью данной программы наглядно видно, что помимо самого файла notepad.exe (он будет в самом низу списка), загружается много dll файлов.

Библиотеки DLL

DLL (они же Dynamic-link library) – это специальный формат файлов, позволяющий хранить исполняемый код (т.е. инструкции), которые могут использоваться различного рода процессами.

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

В основном это будут Кернелы. Именно эти библиотеки служат своеобразным слоем, который транслирует документированные вызовы функций в вызовы к сервисам Windows.

Глобально разделение на Kernel Mode и User Mode со стороны выглядит следующим образом. В самом низу мы видим вариант Мелкомягкого гипервизора. Эта деталь не является обязательной.

Если точнее, то она актуальна для ситуаций, когда на одном железе крутится несколько операционных систем. Само ядро, согласно схеме, находится над ХАЛом (набором общих инструкций).

При этом ядро загружается при старте машины и берёт управление на себя. А гипервизор, хоть и исполняется в 0-ом кольце, но при этом изолирует себя от ядра и может как бы «наблюдать» за всей ситуацией со стороны.

Или как говорят умные дядьки, осуществляет мониторинг. В самом User Mode выделяется 4 типа процессов: пользовательские — процессы, получаемые из обычных (т.е. устанавливаемых пользователем или предустановленных) приложений;

Сервисы (они же службы) — чаще всего процессы, которые выполняются в «фоновом режиме», например, службы печати, службы индексирования.

Environment Subsystems — поддержка различных окружений (ранее поддерживалось POSIX, сейчас только Windows). Поэтому обратной совместимости нет.

Ну и само-собой различного рода системные процыки. Уже упомянутый POSIX (Portable Operating System Interface) — это набор стандартов, предназначенный для организации совместимости между ОС.

Начиная с Windows 10, в состав операционки вошла подсистема WSL (Windows Subsystem for Linux). И как понятно из названия она предоставляет возможность запуска Linux-приложений из командной строки.

Вернее, так работала первая версия. WSL 2 уже представляет собой отдельную виртуалку на гипервизоре и даёт гораздо больше возможностей для сисадминов и безопасников в плане доступа к кишкам ОСи.

Ключевые файлы и драйвера

Теперь что касается ключевых файлов в системе. На слайде представлены основные каталоги, которые необходимо запомнить. Современные версии ОС Windows не позволяют как-либо работать с ними.

Однако во времена Windows 2000 вы могли удалить с компьютера папку system32 и тем самым провести небольшой саботаж. Папка окажется в корзине, восстановить вы её не сможете, винда зависнет, но при этом не выключится.

Короче, ад и Израиль. Благо, что мелкомягкие пофиксили этот забавный баг. Но сам факт существования такой вот хурмы заставляет задуматься о тщетности бытия.

Ладненько, помимо файлов есть ещё драйвера, которые представляют собою программный код, обеспечивающий поддержку той или иной функциональности устройств, протоколов и файл-систем.

Системные драйвера располагаются в каталоге System32\Drivers, а пользовательские — в произвольных каталогах, выбираемых в момент инсталляции.

Загрузка

Процесс загрузки компьютера начинается не с работы операционной системы Windows, а с работы встроенного ПО — BIOS.

BIOS зашит в материнскую плату и отвечает за базовую инициализацию оборудования и процедуру самотестирования (она же POST).

BIOS анализирует диски в установленном порядке для поиска MBR (Master Boot Record) — специальным образом оформленной области на диске.

Сам MBR загружает Boot Manager, который уже непосредственно и запускает ОС.

Для Windows это каталог %SystemDrive%\bootmgr (к слову в файловой системе он не отображается).

Ну а дальше Boot Manager загружает так называемый Windows Loader (файлик winload.exe), который уже будит наш Kernel, т.е. загружает ядро Винды.

Вот такой вот хитро**ный процесс. А вы это даже не цените. Давайте резюмирую. Сначала BIOS, затем Boot Manager, далее Loader и только затем ядро, а после уж и рабочий стол с пышногрудой девицей.

Есть ещё вариант с UEFI. Это такой интерфейс, пришедший на смену BIOS, который позволяет писать приложения, подписывать их и проверять конечную подпись.

Собственные UEFI есть у Samsung, ASUS и других популярных вендеров. Схематически работа этой истории выглядит следующим образом.

Да, возможно чутка сложнее, чем в случае с классическим BIOS, зато в разы дружелюбнее для конечного пользователя.

Помимо прочего есть ещё утилиты позволяющие модифицировать BOOT-систему. Например, bcdedit. Либо msconfig, если предпочитаете графический интерфейс. Если захотите поковырять, рекомендую делать это на виртуалке.

И последнее о чём мне бы хотелось сегодня поговорить – это процесс smss.exe. Данный процесс запускает ядро session manager subsystem.

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

Ее мы с вами подробно разберём в следующем видео из цикла информационная безопасность с нуля до джуна.

Так что, если не хочешь пропустить это дело и более детально изучить механизмы безопасности операционной системы Windows – обязательно подпишись на канал кликнув на колокольчик.

Не пойму правда, какого лешего ты не сделал этого раньше, но всё-таки дам шанс и возможность исправить карму по-братски, раз уж ты так напрягся и досмотрел ролик до этой минуты.

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

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

Не забываем сделать домашнее задание по теме лекции. Ссылочка, как обычно, будет закреплена в описании. Ну и если урок зашёл – не пожидитесь и отблагодарите жирнейшим лайкосиком.

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

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

Берегите себя и данные своих пользователей. Не позволяйте криворуким ломать винду. Для этого регулярно делайте бэкапы на сервер с наиболее важных тачек. И будем вам счастье.

Помните, технологии – это весело. Во всяком случае, если речь идёт об IT. Тут без креативности, улыбки и хорошего чувства юмора в принципе никуда. Унынение – главный враг любого развития.

Капец, я, как всегда, под конец видео ударяюсь в никому не нужную диванную философию. Всё короче. До новых встреч, мои кайфные друже. Всем пока.

NT задумывалась как распределенная, клиент-серверная ОС, поддерживающая симметричные многопроцессорные аппаратные платформы. Сегодня разработчики наносят завершающие штрихи в своем новом творении — Windows NT 5.0 [оригинальная статья была опубликована в IEEE Computer до того, как Microsoft объявила новое название своей ОС — Windows 2000 — Прим. перев.], однако теперь, почти десять лет спустя, когда компания вносит завершающие штрихи в свое творение, можно с уверенностью сказать, что фундаментальные основы архитектуры NT в версии 5.0 не были изменены.

Кроме того, от NT требовалась, совместимость со стандартом POSIX 1003.1, поддержка Unicode для адаптации к требованиям мирового рынка, выполнение большинство существующих 16-разрядных приложений для MS-DOS и Windows 3.х. Разработчики должны были обеспечить переносимость, надежность, совместимость «снизу-вверх», высокую производительность и возможность расширения в соответствии с меняющимися требованиями рынка. Сегодня, почти десять лет спустя, можно с уверенностью сказать, что фундаментальные основы архитектуры NT в версии 5.0 не были изменены. Да, были добавлены новые операционные и сетевые возможности, однако, ядро не было переписано, а лишь расширено. Попытаемся в данной статье дать краткий обзор архитектуры Windows NT 5.0, рассмотрев такие ее черты как plug-and-play, объекты «Задание», поддержка непосредственно адресуемой большой памяти (подробную информацию о NT 5.0 и ее новых чертах можно найти по адресу http://www.microsoft.com/windowsnt5).

Архитектура системы

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

Режим ядра

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

Компоненты режима ядра Windows NT спроектированы на основе принципов построения объектно-ориентированных систем. Например, они не работают напрямую со структурами данных, поддерживаемых индивидуальными компонентами. Вместо этого для передачи параметров, доступа и/или модификации структур данных они используют формальный интерфейс. Вместе с тем, несмотря на повсеместное использование объектов для представления разделяемых системных ресурсов, Windows NT не является объектно-ориентированной системой в точном смысле этого понятия, поскольку основная часть кода системы написана на Си из соображений обеспечения высокой скорости выполнения и переносимости.

В режиме ядра выполняются следующие компоненты ОС:

• исполняемая часть NT, которая включает управление памятью, процессами, потоками, безопасностью, вводом/выводом, межпроцессорными обменами;
• ядро Windows NT выполняет низкоуровневые функции операционной системы: диспетчеризация потоков, прерываний и исключений, синхронизация процессоров. Ядро также включает набор процедур и базовых объектов, используемый исполняемой частью для создания высокоуровневых конструкций;
• слой абстракции от оборудования (HAL — Hardware Abstraction Layer), изолирует ядро, драйверы устройств и исполняемую часть NT от аппаратных платформ, на которых должна работать операционная система;
• драйверы устройств включают как файловую систему, так и аппаратные драйверы, которые транслируют пользовательские вызовы функций ввода/вывода в запросы физических устройств ввода/вывода;
• функции графического интерфейса пользователя работают с окнами, элементами управления и рисунками.

Исполняемая часть

Исполняемая часть Windows NT — верхний слой программы — ядра NTOSKRNL.EXE. (Само ядро — это нижний слой). Исполняемая часть содержит следующие компоненты.

• Менеджер процессов и потоков управляет процессами и потоками. Фактически потоки и процессы поддерживаются в NT нижележащим слоем. Исполняемая часть добавляет дополнительную семантику и функции к этим объектам нижнего уровня.
• Менеджер виртуальной памяти использует схему управления, при которой каждый процесс получает собственное достаточно большое адресное пространство, защищенное от воздействия других процессов. Менеджер памяти также обеспечивает низкоуровневую поддержку для менеджера кэш-памяти.
• Монитор безопасности проводит политику обеспечения мер безопасности на локальном компьютере, охраняя системные ресурсы и выполняя процедуры аудита и защиты объектов.
• Система ввода/вывода использует независимый от устройств ввод/вывод и отвечает за пересылку данных соответствующим драйверам для дальнейшей обработки.
• Менеджер кэш-памяти улучшает производительность системы ввода/вывода файлов, размещая читаемые с диска данные в основной памяти для ускорения доступа к ним, а также откладывая на короткое время запись измененных данных на диск.

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

• Менеджер объектов, который создает, удаляет объекты и абстрактные типы данных, а также управляет ими. Объекты используются в Windows NT для представления таких ресурсов операционной системы, как процессы, потоки и объекты синхронизации.
• LPC передает сообщения между клиентским процессом и процессом сервера на том же самом компьютере. По сути, LPC — это оптимизированная версия известной процедуры удаленного вызова RPC (Remote Procedure Call), стандарта для организации взаимодействия процессов в архитектуре клиент/сервер.
• Широкий набор библиотечных функций общего типа: обработка строк, арифметические операции, преобразование типов данных, обработка структур.
• Процедуры распределения памяти, взаимообмен между процессами через память, два специальных типа объектов синхронизации — ресурсы и объекты fast mutex.

Ядро

Ядро NTOSKRNL.EXE выполняет большинство основных операций NT, определяющих порядок использования процессора: диспетчеризация потоков; диспетчеризация и обработка исключений; cинхронизация работы процессоров; обеспечение базовых объектов ядра, которые используются исполняемой частью (и в некоторых случаях экспортируются в режим пользователя).

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

Объекты ядра. Одна из функций ядра — обеспечение низкоуровневой базы для хорошо определенных примитивов операционной системы, которые обеспечивают работу компонентов высшего уровня. Ядро изолирует само себя от остальной части ОС, что позволяет вынести принятие политических решений из ядра, за исключением диспетчеризации потоков. Ядро использует набор простейших объектов, называемых объектами ядра, позволяющих управлять работой центрального процессора и порядком создания вычисляемых объектов. Большинство вычисляемых объектов включает в себя один или более объектов ядра, включая определенные ядром атрибуты. Один из наборов объектов называется объектами управления и включает объект процесса ядра, объект АРС, объект процедуры отложенного вызова DPC (Deferred Procedure Call) и несколько объектов, используемых системой ввода/вывода (например, объект обработки прерывания).

Другой набор объектов ядра — объекты диспетчеризации, включает объекты синхронизации потоков, поток ядра, mutex, объекты события, семафора, таймера, таймера ожидания и ряд других.

Поддержка оборудования. Другой главнейшей задачей ядра является абстрагирование (или изоляция) исполняемой части и драйверов устройств от различий микропроцессорных платформ, на которых способна работать Windows NT: х86 и Alpha AXP. Специфичные для архитектуры функции (такие, как контекстное переключение потока) реализованы в ядре. Функции, которые могут отличаться от машины к машине, реализованы в составе HAL.

Ядро поддерживает набор интерфейсов, семантически идентичных для всех архитектур. Некоторые из интерфейсов реализованы по-разному для разных архитектур, однако, и идентичны внешне интерфейсы реализованы с помощью специфичного для архитектуры кода. Независимый от архитектуры интерфейс может быть вызван на любой машине, и его семантика будет той же, несмотря на то, зависит ли код от архитектуры или нет. Некоторые интерфейсы ядра (например, процедуры синхронизации SMP) реализованы в HAL, поскольку их реализация может изменяться даже внутри одного семейства компьютеров. В качестве примера зависящего от архитектуры кода можно назвать также поддержку кэша центрального процессора.

Абстракция от оборудования

Загружаемый модуль ядра HAL обеспечивает низкоуровневый интерфейс с аппаратной платформой, что позволяет скрыть такие зависимые от аппаратуры детали, как интерфейс ввода/вывода, контроллеры прерываний, механизм обмена данными между процессорами — любые аппаратно-зависимые и специфические для архитектуры функции.

Драйверы устройств. Драйверы устройств — это загружаемые модули, которые работают в режиме ядра, обеспечивая интерфейс между системой ввода/ вывода и соответствующим оборудованием. Названия этих модулей обычно имеют расширение .SYS. Все они, как правило, написаны на Си (иногда С++) с использованием вызовов процедур HAL и могут быть переносимыми на уровне двоичного кода между платформами, поддерживаемыми NT. Имеется несколько типов драйверов устройств:

• Драйверы, манипулирующие устройствами (с использованием HAL) для записи выходных данных или получения входных данных от физических устройств или через сеть.
• Драйверы файловой системы, которые принимают запросы на файловый ввод/вывод и транслируют их в запросы ввода/вывода, связанные с конкретными устройствами.
• Драйверы фильтров. Примером могут быть драйверы поддержки зеркальных дисков, шифрования данных, перехвата ввода/вывода для дополнительной обработки данных перед передачей их на следующий уровень и т.д.
• Сетевые драйверы, которые передают и принимают удаленные запросы на ввод/вывод.

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

Пользовательские процессы

Имеется четыре базовых типа пользовательских процессов.

• Специальные процессы поддержки системы, например, процесс регистрации пользователя и менеджер сессий, которые не являются службами NT.
• Процессы сервера, которые являются службами NT (аналог демонов в ОС Unix). Примером может быть регистратор событий (Event Logger). Многие дополнительно устанавливаемые приложения, такие как Microsoft SQL Server и Exchange Server, также включают компоненты, работающие как службы NT.
• Подсистемы среды, которые обеспечивают пользовательским приложениям среду других операционных систем. Windows NT поставляется с тремя подсистемами: Win32, Posix и OS/2 2.1.
• Пользовательские приложения одного из пяти типов: Win32, Windows 3.1, MS-DOS, Posix или OS/2 1.2.

Подсистемы среды и библиотеки DLL

Как видно из рис. 1, Windows NT имеет три подсистемы среды (Win32, Posix и OS/2 2.1), которые работают только на платформе х86. Подсистема Win32 специфична для Windows NT и не может работать вне нее.

Каждая из подсистем обеспечивает пользовательским приложениям доступ к разным поднаборам служб Windows NT. Это означает, что некоторые вещи могут быть сделаны из приложения, построенного на одной подсистеме, и не возможны из приложения, построенного в другой подсистеме. Так, приложение для Win32 не может использовать функцию fork подсистемы Posix.

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

Пользовательские процессы не вызывают службы NT напрямую, а используют библиотеки динамических связей (DLL) соответствующей подсистемы среды. Роль библиотек, принадлежащих подсистеме среды, в том, чтобы транслировать документированные функции среды в соответствующие вызовы недокументированных служб NT. Эти библиотеки DLL экспортируют документированный интерфейс, который могут вызывать связанные с подсистемой программы. Например, библиотеки DLL подсистемы Win32 используют функции Win32 API. Библиотека DLL подсистемы Posix использует функции Posix 1003.1 API.

Подсистема Win32. Главные компоненты подсистемы Win32 — процесс подсистемы среды и драйвер режима ядра. Процесс подсистемы среды поддерживает:

• консольные (текстовые) окна;
• создание и удаление процессов и потоков;
• работу виртуальной 16-разрядной DOS машины;
• иные функции (GetTempFile, DefineDosDevice, ExitWindowsEx и др.).

Драйвер режима ядра поддерживает:

• менеджер окон, который управляет отображением окон, выводом на экран, вводом с клавиатуры, от мыши и других устройств, а также передачей пользовательских сообщений приложениям;
• интерфейс графических устройств GDI (Graphical Device Interface), библиотека функций для вывода на графические устройства, для рисования текста, линий, фигур и манипуляций графическими объектами;
• зависимые от устройств драйверы графики, принтера и видеопорта;
• несколько библиотек DLL, которые транслируют документированные функции Win32 API в соответствующие недокументированные вызовы NTOSKRNL.EXE и WIN32K.SYS.

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

NTDLL.DLL — это специальная система поддержки DLL — библиотек. Она содержит два типа функций.

• Первая группа функций обеспечивает интерфейс к службам NT, которые могут быть вызваны из пользовательского режима. Существует более 200 таких функций, например NtCreateFile, NtSetEvent и т.д. Для каждой из них имеется точка входа в NTDLL.DLL с тем же именем. Внутренний код функции содержит специфичные для архитектуры команды, которые вызывают переход в режим ядра для обращения к реальным службам NT, код которых содержится в NTOSKRNL.EXE.
• Вторая группа функций содержит большое количество функций поддержки: загрузчик исполняемых модулей, коммуникационные функции для процессов подсистемы Win32, библиотека функций реального времени пользовательского режима, диспетчер вызовов асинхронных процедур АРС (Asynchronous Procedure Call) пользовательского режима, диспетчер исключений.

Новые черты ядра NT 5.0

Несмотря на декларируемую расширяемость архитектуры Windows NT, некоторые нововведения в NT 5.0 (plug-and-play, управление электропитанием, объекты «Задание», управление большой памятью для компьютеров Alpha) повлекли, тем не менее, серьезные структурные изменения в архитектуре ядра.

Plug-and-play

Технология Plug-and-play (PnP) поддерживается комбинацией аппаратного и программного обеспечения, позволяющей распознавать и настраивать аппаратные изменения в конфигурации почти без вмешательства пользователя. Можно динамично добавлять и удалять устройства без необходимости реконфигурации системы и знания сложного компьютерного оборудования.

Эволюция PnP. Впервые концепция PnP была реализована в ОС Windows 95, но с того времени эта технология получила существенное развитие в плане управления системой, конфигурирования устройств и управления энергопотреблением, особенно благодаря инициативной проектной группе OnNow. Одним из результатов работы этой группы стала спецификация ACPI (Advanced Configuration and Power Interface) версии 1.0, определившая новый дизайн материнских плат и BIOS, обеспечивающий управление энергопотреблением и новые конфигурационные возможности под полным управлением операционной системы.

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

Реализация в Windows NT 5.0. При проектировании архитектуры PnP в Windows NT 5.0 ставились две основные цели:

• расширение существующей инфраструктуры ввода/вывода для поддержки PnP и управления энергопотреблением для работы с оборудованием по стандартам PnP;
• создание единых интерфейсов для драйверов устройств, поддерживающих PnP и управление энергопотреблением, для классов устройств, работающих под Windows NT 5.0 и Windows 98.

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

Драйверы PnP не назначают устройствам собственные ресурсы. Вместо этого требуемые ресурсы идентифицируются системой во время распознавания устройств. Основываясь на запросах устройств на ресурсы, диспетчер PnP назначает соответствующие аппаратные ресурсы (например, порты ввода/вывода, каналы DMA и т.д.), распределяет память. Диспетчер PnP реконфигурирует назначенные ресурсы по необходимости, когда устройства добавляются к системе и запрашивают уже распределенные ресурсы. Кроме того, диспетчер PnP определяет, какие драйверы требуются для поддержки конкретных устройств, и загружает эти драйверы.

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

Изменения в драйверах. Поддержка PnP в Windows NT 5.0 потребовала внести ряд изменений в ранее разработанную модель драйверов Windows NT:

Драйверы шины отделены от HAL для координации с изменениями и расширениями существующих компонентов режима ядра (исполняемая часть, драйверы ядра, HAL). Драйверы шины управляют шиной ввода/вывода, включая управление отдельными слотами, независимыми от устройств.

Новые методы и возможности для поддержки установки устройств и конфигурации потребовали изменения таких существующих компонентов режима пользователя, как диспетчер буфера вывода, установщики классов, приложений Control Panel, Setup. Добавлены новые компоненты для поддержки PnP как в режиме ядра, так и в режиме пользователя.

Добавлены интерфейсы PnP API для чтения и записи информации из реестра (registry). Теперь структура регистра поддерживает PnP и позволяет вносить совершенствования в будущих версиях NT, в то же время обеспечивая совместимость снизу вверх.

Windows NT 5.0 будет поддерживать унаследованные драйверы, но их использование уменьшит возможности системы в области поддержки PnP. Производителям, желающим реализовать полные возможности PnP для своего оборудования и использовать одни и те же драйверы под NT и Windows 98, необходимо разработать новые драйверы, интегрирующие последние достижения технологии PnP и управления энергопотреблением.

Объект «Задание»

Windows NT 5.0 включает расширение модели процессов. «Задание» — это поименованный, безопасный, разделяемый объект, управляющий некоторыми атрибутами процессов. Его главная задача — управлять и манипулировать группой процессов как самостоятельной единицей. В ряде случаев этот объект компенсирует отсутствие в NT структурированного дерева процессов. Объект «Задание» также записывает базовую учетную информацию обо всех процессах, ассоциированных с ним, и позволяет накладывать на связанные с ним процессы: ограничения на время использования процессора в режиме пользователя; ограничение на время использования процессора в режиме пользователя каждым из процессов; максимальное число активных процессов; класс приоритета процесса «Задание».

Задания могут быть выстроены в очередь к объекту «Порт» для завершения операций ввода/вывода. Могут быть заданы границы безопасности на процессы в задании. В завершение всего, могут быть определены ограничения на пользовательские интерфейсы для процессов, например, на операции чтения и/или записи в clipboard, открытия принадлежащих потоку обработчиков окон за пределами «Задания», изменения параметров системы через функцию Win32 SystemParametersInfo.

Управление памятью большой емкости

В Windows NT 5.0 добавлено расширение VLM (Very Large Memory), позволяющее непосредственно адресовать 28 Гбайт оперативной памяти компьютеров на платформе Alpha. Сейчас VLM не предназначается для семейства процессоров х86, но в Microsoft готовят единую 64-разрядную версию NT для платформ Alpha AXP и будущей архитектуры Intel IA-64.

В NT 4.0 поддерживалась 64-разрядная адресация в операциях ввода/вывода, но каждый процесс все же ограничивался использованием 2-гигабайтного пространства (3 Гбайт для Windows NT Server Enterprise Edition). В 1997 году Microsoft объявила о своем намерении создать полную 64-разрядную версию NT, имея в виду, что каждый 64-разрядный процесс будет наделен адресным пространством по крайней мере в 512 Гбайт. Причина перехода к 64-разрядной платформе та же, что и для перехода от 16-разрядных систем к 32-разрядным — это постоянно возрастающие требования к хранению и обработке огромных объемов данных в памяти компьютеров.

VLM позволяет использовать в приложениях 64-разрядные указатели, получая, таким образом, прямой доступ к адресному пространству свыше 2 Гбайт. Это необходимо для удовлетворения нужд приложений, работающих с большими объемами информации (например, СУБД), для которых ограничение адресного пространства цифрой 2-3 Гбайт неприемлемо. Для адресации 28 Гбайт памяти и использования 64-разрядных указателей на системах Alpha в версию языка Visual C++ 5.0 добавлены указатели _ptr64 и небольшой набор новых интерфейсов Win32 API для работы с ними. В 64-разрядной версии NT будет использоваться программный интерфейс Win64, обеспечивающий перенос приложений с Win32 и компиляцию исходного кода в двоичный как в 32-разрядном, так и в 64-разрядном режимах. Предполагается, что «младший» режим будет использоваться для выполнения существующих 32-разрядных приложений на платформах Alpha и Merced, а новые 64-разрядные приложения будут выполняться уже в «родном» 64-разрядном режиме. Однако одновременная смесь двух режимов в одном процессе допускаться не будет.

Пока же VLM содержит существенное ограничение на виртуальные адреса при работе с 64-разрядными указателями: такие адреса должны быть поддержаны зарезервированной физической памятью — другими словами, вся подразумеваемая память должна быть обеспечена физической памятью, доступной в момент адресации. Недостающие страницы памяти никогда не берутся по адресам VLM, если эти адреса не используются для отражения реального файла данных. Каждая страница будет отсутствовать только один раз при первом обращении, затем она блокируется в памяти и никогда не удаляется. Несмотря на это ограничение, VLM отвечает потребностям приложений, которые требуют быстрого доступа к большим порциям памяти.

Резюме

Архитектура Windows NT отражает современные представления о дизайне 32-разрядной операционной системы, а версия Windows NT 5.0 удовлетворяет постоянно меняющимся требованиям, предъявляемым к операционной системе для настольных систем и рабочих станций. Эта версия также может работать с высокоуровневыми серверными приложениями.

David A. Solomon, The Windows NT Kernel Architecture. IEEE Computer, October 1998, pp. 40-47. Reprinted with Permission, Copyright IEEE CS, 1998. All rights reserved.

Об авторе

Дэвид Соломон — руководитель David Solomon Expert Seminars, семинаров для преподавателей по структуре Windows NT и системному программированию. Автор книг Inside Windows NT (Microsoft Press) и Windows NT for OpenVMS Professionals (Digital Press/Butterworth Heinemann). Начав свою трудовую карьеру как консультант по программному обеспечению в корпорации Digital Equipment, затем девять лет работал в качестве руководителя проекта в группе разработчиков ОС VMS. Соломон является также техническим руководителем ряда конференций по Windows NT.

Активный каталог

Одной из наиболее важных новых черт Windows NT 5.0 является активный каталог (Active Directory), призванный упростить администрирование больших сетей на NT. Активный каталог играет ключевую роль в улучшении безопасности распределенных систем.

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

• гибкая иерархическая структура;
• расширяемая память для новых классов объектов и их атрибутов;
• частичное делегирование прав доступа;
• поддержка протокола LDAP версии 3;
• встроенный сервер имен DNS;
• масштабируемость до миллионов объектов;
• программируемая память для классов.

Программируемость и расширяемость — важные свойства активного каталога, поскольку-независимо от установленных служб разработчики и администраторы имеют дело с простым набором интерфейсов. Программируемый интерфейс ADSI (Active Directory Service Interface) доступен из любого языка программирования. Для программистов на языке Си активный каталог доступен также через низкоуровневый API-интерфейс LDAP.

Система безопасности распределенных систем

Система безопасности распределенных систем Windows NT 5.0 имеет много новых черт, упрощающих администрирование узлов, повышающих производительность и включает интегрированную технологию Internet c кодированием ключей доступа.

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

Windows NT 5.0 имеет новую систему аутентификации пользователей, основанную на стандартных протоколах безопасности Internet, включая версию Kerberos 5.0 и TLS (Transport Layer Protocol), а также поддержку протоколов NT LAN Manager для целей совместимости. Протоколы безопасности поддерживают работу с удостоверениями личности пользователей в форме сертификатов открытых ключей к существующим учетным номерам Windows NT. Для управления доступом и учетной информацией используется общий инструмент администрирования. Для организаций, выпускающих сертификаты Х.509 версии 3 в Windows NT предлагается Microsoft Certificate Server. В системе вводится управление сертификатами CryptoAPI и модули для обработки сертификатов общественных ключей, включая сертификаты стандартного формата, выпущенные службой коммерческих сертификатов, третьей стороной, либо Microsoft Certificate Server.