Архитектура windows nt: Архитектура ядра Windows NT

Содержание

Архитектура Windows NT | это… Что такое Архитектура Windows NT?

Архитектура Windows NT

Windows NT 3.1, Windows NT 3.5, Windows NT 3.51, Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7 и Windows 8 являются частью семейства операционных систем на ядре NT. Все они являются операционными системами с вытесняющей многозадачностью. Они разработаны для работы как с однопроцессорными, так и с симметричными мультипроцессорными компьютерами. Для обработки запросов ввода\вывода используется пакетноуправляемый ввод/вывод, который применяет пакеты запросов ввода\вывода (IRP) и асинхронный ввод/вывод.

Архитектура Windows NT имеет модульную структуру и состоит из двух основных уровней — компоненты, работающие в режиме пользователя и компоненты режима ядра. Программы и подсистемы, работающие в режиме пользователя имеют ограничения на доступ к системным ресурсам. Режим ядра имеет неограниченный доступ к системной памяти и внешним устройствам. Ядро системы NT называют гибридным ядром или макроядром. Архитектура включает в себя само ядро, уровень аппаратных абстракций (HAL), драйверы и ряд служб (Executives), которые работают в режиме ядра (Kernel-mode drivers) или в пользовательском режиме (User-mode drivers)^[1]^[2].

Пользовательский режим Windows NT состоит из подсистем, передающих запросы ввода/вывода соответствующему драйверу режима ядра посредством менеджера ввода/вывода. Есть две подсистемы на уровне пользователя: подсистема окружения (запускает приложения, написанные для разных операционных систем) и интегрированная подсистема (управляет особыми системными функциями от имени подсистемы окружения). Режим ядра имеет полный доступ к аппаратной части и системным ресурсам компьютера. И также предотвращает доступ к критическим зонам системы со стороны пользовательских служб и приложений.

Режим пользователя

Режим пользователя состоит из подсистем, которые передают запросы ввода\вывода соответствующему драйверу режима ядра посредством менеджера Ввода-вывода. Уровень пользователя состоит из двух подсистем — подсистема окружения(Environment) и интегральная подсистема (Integral).

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

Подсистема окружения состоит из следующих подсистем — подсистема Win32, подсистема OS/2 и подсистема POSIX. Подсистема окружения Win32 запускает 32-разрядные Windows приложения. Она содержит консоль и поддержку текстового окна, обработку ошибок для всех других подсистем окружения. Поддерживает VDM (Virtual DOS Machine), которая позволяет запускать 16-разрядные DOS и Windows(Win16) приложения. VDM запускается в своем собственном адресном пространстве и эмулирует систему MS-DOS, запущенную на компьютере с процессором Intel 80486. Программы Win16 запускаются в режиме Win16 VDM. Каждая программа запускается в одном процессе с использованием одного адресного пространства, но для каждой программы используется свой отдельный поток. Однако Windows NT позволяет запускать Win16 программы в отдельных Win16 VDM процессах, реализуя вытесняющую многозадачность. Процесс подсистемы окружения Win32 — csrss.exe также включает в себя функциональность менеджера окон, то есть обрабатывает входящие события, такие как нажатие клавиш клавиатуры и мыши, и передает их на обработку соответствующим приложениям. Каждое приложение само производит перерисовку окон в ответ на эти сообщения.

Подсистема окружения OS/2 поддерживает неграфические 16-разрядные приложения операционной системы OS/2 и эмулирует систему OS/2 2.1.x.

Подсистема окружения POSIX поддерживает приложения написанные в соответствии со стандартом POSIX.1

Интегрированная подсистема (Integral subsystem) следит за некоторыми функциями операционной системы от имени подсистемы окружения. Состоит из подсистемы безопасности, службы рабочей станции и службы сервера. Служба безопасности обращается с маркерами доступа, позволяет или запрещает доступ к учетной записи пользователя, обрабатывает запросы авторизации и инициирует процесс входа пользователя в систему. Служба Рабочая станция обеспечивает доступ компьютера к сети — является API для сетевого редиректора (ПО эмулирующее доступ к удаленной файловой системе как к локальной). Служба Сервер позволяет компьютеру предоставлять сетевые сервисы.

Режим ядра

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

Архитектура x86 поддерживает 4 уровня привилегий — от 0 до 3 , но используются только 0 и 3 уровень. Режим пользователя использует уровень 3, а режим ядра — 0. Это было сделано для возможности переноса на платформу RISC, которая использует только два уровня привилегий. Режим ядра состоит из исполнительных служб, которые представляют собой различные модули, выполняющие определенные задачи, драйвера ядра, само ядро и уровень аппаратных абстракций HAL

Исполнительная подсистема.

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

Менеджер объектов

Это исполнительная подсистема, к которой обращаются все остальные модули исполнительной подсистемы, в частности системные вызовы, когда им необходимо получить доступ к ресурсам Windows NT. Менеджер объектов служит для уменьшения дублирования объектов, что может привести к ошибкам в работе системы. Для менеджера объектов каждый ресурс системы является объектом — будь то физический ресурс типа периферийного устройства, файловой системы, или логический ресурс — файл и др. Каждый объект имеет свою структуру, или тип объекта.

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

Примечания

↑ Графические драйверы ATI Catalyst в операционной системе Windows Vista | Видеокарты — 3DNews — Daily Digital Digest
↑ w:User-Mode Driver Framework

Краткий обзор архитектуры

После краткого обзора исходных замыслов проектирования и компоновки Windows рассмотрим основные компоненты системы, составляющие ее архитектуру. Упрощенная версия архитектуры показана на рис. 2.1. Нужно иметь в виду, что эта схема носит общий характер и не отображает все компоненты. (Например, на ней не показаны сетевые компоненты и иерархия различных типов драйверов устройств.)

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

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

Четырем основным процессам пользовательского режима можно дать следующие описания:

Фиксированные (или реализованные на аппаратном уровне) вспомогательные системные процессы, такие как процесс входа в систему и администратор сеансов — Session Manager, которые не входят в службы Windows (они не запускаются диспетчером управления службами).
Служебные процессы, реализующие такие службы Windows, как Диспетчер задач (TaskScheduler) и спулер печати (PrintSpooler). Как правило, от служб требуется, чтобы они работали независимо от входов пользователей в систему. Многие серверные приложения Windows, такие как Microsoft SQL Server и Microsoft Exchange Server, также включают компоненты, работающие как службы.
Пользовательские приложения, которые могут относиться к одному из следующих типов: для 32- или 64-разрядной версии Windows, для 16-разрядной версии Windows 3.1, для 16-разрядной версии MS-DOS или для 32- или 64-разрядной версии POSIX. Следует учесть, что 16-разрядные приложения могут запускаться только на 32-разрядной версии Windows.
Серверные процессы подсистемы окружения, которые реализуют часть поддержки среды операционной системы или специализированную часть, представляемую пользователю и программисту. Изначально Windows NT поставляется тремя подсистемами среды: Windows, POSIX и OS/2. Но подсистемы POSIX и OS/2 последний раз поставлялись с Windows 2000. Выпуски клиентской версии Windows Ultimate и Enterprise, а также все серверные версии включают поддержку для усовершенствованной подсистемы POSIX, которая называется подсистемой для приложений на основе Unix (Unix-based Applications, SUA).

Обратите внимание на прямоугольник «Подсистемы DLL-библиотек», который на рис. 2.1 находится под прямоугольниками «Служебные процессы» и «Пользовательские приложения». При выполнении под управлением Windows пользовательские приложения не вызывают имеющиеся в операционной системе Windows службы напрямую, а проходят через одну или несколько подсистем динамически подключаемых библиотек (dynamic-link libraries, DLL).

Подсистемы DLL-библиотек предназначены для перевода документированной функции в соответствующий внутренний (и зачастую недокументированный) вызов системной службы. Этот перевод может включать в себя (или не включать) отправку сообщения процессу подсистемы среды, обслуживающему пользовательское приложение.

В Windows входят следующие компоненты, работающие в режиме ядра:

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

Уровень аппаратных абстракций (hardware abstraction layer, HAL), являющийся уровнем кода, который изолирует ядро, драйверы устройств и остальную исполняющую систему Windows от аппаратных различий конкретных платформ (таких как различия между материнскими платами).
Система организации многооконного интерфейса и графики, реализующая функции графического пользовательского интерфейса (graphical user interface, GUI), более известные как имеющиеся в Windows USER- и GDI-функции, предназначенные для работы с окнами, элементами управления пользовательского интерфейса и графикой.

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

Имя файла	Компоненты
Ntoskrnl.exe	Исполняющая система и ядро
Ntkrnlpa.exe (только в 32-разрядных системах)	Исполняющая система и ядро с поддержкой расширения физического адреса — Physical Address Extension (PAE), позволяющего 32-разрядным системам осуществлять адресацию вплоть до 64 Гб физической памяти и помечать память как не содержащую исполняемый код
Hal.dll	Уровень аппаратных абстракций
Win32k.sys	Часть подсистемы Windows, работающей в режиме ядра
Ntdll.dll	Внутренние вспомогательные функции и заглушки диспетчера системных служб к исполняющим функциям
Kernel32. dll, Advapi32.dll, User32.dll, Gdi32.dll	Основные Windows-подсистемы DLL-библиотек

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

Архитектура Windows — Основы

Впервые опубликовано на TECHNET 10 апреля 2007 г.

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

Итак, без лишних слов — начнем со знакомства с Windows API…

Интерфейс прикладного программирования Windows (API) — это интерфейс программирования для семейства операционных систем Microsoft Windows. Он предоставляет службы, используемые всеми приложениями на базе Windows, чтобы приложения могли предоставлять графический интерфейс пользователя (GUI), получать доступ к системным ресурсам, включать звук и многое другое. API состоит из тысяч документированных вызываемых подпрограмм, таких как СоздатьПроцесс и Создать файл . Основные категории функций Windows API включают базовые службы, службы компонентов, графику и мультимедиа, обмен сообщениями, работу в сети и веб-службы. Существуют сотни книг и веб-сайтов, описывающих программирование с использованием Windows API, но позвольте мне лишь добавить, что программирование с использованием Windows API ни в коем случае не является задачей «начального уровня»! А с этим пора переходить к услугам…

При рассмотрении служб с точки зрения программирования служба может относиться к вызываемой процедуре в операционной системе, драйверу устройства или серверному процессу. Однако с точки зрения пользователя мы рассматриваем службу как процесс, загружаемый ОС в пользовательском режиме, независимо от вошедшего в систему пользователя. Службы контролируются диспетчером служб Windows. Службы можно загружать с помощью системной учетной записи или учетных данных, которые назначены конкретно для этой службы — либо во время установки службы, либо через страницу свойств для этой службы. Некоторые распространенные службы включают службу диспетчера очереди печати, которая управляет печатью, службу сервера, которая поддерживает общий доступ к файлам, печати и именованным каналам по сети, и службу клиента DHCP, которая регистрирует и обновляет IP-адреса и записи DNS.

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

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

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

Исполняемая программа, состоящая из исходного кода и данных
Частное виртуальное адресное пространство
Системные ресурсы, доступные всем потокам в процессе
Уникальный идентификатор, называемый идентификатором процесса.
Хотя бы один поток выполнения
Контекст безопасности (также известный как маркер доступа)

Диаграмма ниже, которая находится в Внутреннее устройство Windows книга показывает, как взаимодействуют компоненты

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

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

И это подводит нас к концу нашего поста об архитектуре Windows 101. Оставайтесь с нами, чтобы узнать больше…

Дополнительные ресурсы:

Обзор MSDN Windows API
Справочник по API Windows (MSDN)
Windows API в Википедии
Microsoft® Windows® Internals, четвертое издание: Microsoft Windows Server™ 2003, Windows XP и. ..

— CC Хамид

Архитектура Windows. Учебное пособие

Вернуться к учебному пособию

Ядро является наиболее надежной частью операционной системы. Множественные кольца защиты были одной из самых революционных концепций, представленных в операционной системе Multics. Большинство систем общего назначения используют только два кольца, даже если аппаратное обеспечение, на котором они работают, обеспечивает больше режимов ЦП, чем это. Например, Windows 7 и Windows Server 2008 (и их предшественники) используют только два кольца, где кольцо 0 соответствует режиму ядра, а кольцо 3 — пользовательскому режиму, поскольку более ранние версии Windows работали на процессорах, поддерживающих только два уровня защиты.

Многие современные архитектуры ЦП (включая популярную архитектуру Intel x86) включают некоторую форму кольцевой защиты, хотя операционная система Windows NT, например Unix, не полностью использует эту функцию. В DOS ядро, драйверы и приложения обычно работают в кольце 3 (однако это относится только к случаю, когда используются драйверы защищенного режима и/или расширители DOS; в качестве ОС реального режима система работает практически без защиты). ), тогда как менеджеры памяти 386, такие как EMM386, работают в кольце 0,9.0005

Процессоры x86 имеют четыре разных режима, разделенных на четыре разных кольца. Программы, работающие в кольце 0, могут делать с системой все, что угодно, а код, работающий в кольце 3, должен иметь возможность дать сбой в любой момент без воздействия на остальную часть компьютерной системы. Кольцо 1 и кольцо 2 используются редко, но могут быть настроены с разными уровнями доступа. В большинстве существующих систем переключение с «пользовательского режима» на «режим ядра» связано с высокими затратами на производительность.

Память Windows

Каждый процесс, запущенный в x86-версии Windows, использует плоскую модель памяти в диапазоне от 0x00000000 до 0xFFFFFFFF. Нижняя половина памяти, 0x00000000 – 0x7FFFFFFF, зарезервирована для кода пользовательского пространства. В то время как верхняя половина памяти, 0x80000000 — 0xFFFFFFFF, зарезервирована для кода ядра. Операционная система Windows также не использует сегментацию (на самом деле использует, потому что должна), но таблица сегментов содержит дескрипторы сегментов, которые используют все линейное адресное пространство. Есть четыре сегмента, два для пользователя и два для режима ядра, которые описывают данные и код для каждого из режимов. Но на самом деле все дескрипторы содержат одно и то же линейное адресное пространство. Это означает, что все они указывают на один и тот же сегмент памяти длиной 0xFFFFFFFF бит, что доказывает отсутствие сегментации в системах Windows.

Сегментация фактически не используется системой Windows. Поэтому мы можем использовать термины «виртуальное адресное пространство» и «линейное адресное пространство» взаимозаменяемо, потому что в данном конкретном случае они одинаковы. Из-за этого, когда мы говорим о коде пользовательского пространства, загружаемом в виртуальное адресное пространство от 0x00000000 до 0x7FFFFFFF, мы фактически говорим о линейных адресах. Затем эти адреса отправляются в пейджинговый модуль для преобразования в физические адреса. Мы только что определили, что хотя каждый процесс использует плоскую модель памяти, охватывающую все линейное адресное пространство размером 4 ГБ, он может использовать только его половину. Это связано с тем, что другая половина зарезервирована для кода ядра: таким образом, программа может использовать максимум 2 ГБ памяти.

Каждый процесс имеет свое уникальное значение в регистре CR3, которое указывает на таблицу каталогов страниц процесса. Поскольку каждый процесс имеет свою собственную таблицу каталогов страниц, которая используется для преобразования линейного адреса в физический адрес, два процесса могут использовать один и тот же линейный адрес, в то время как их физические адреса различны. Итак, у каждой программы есть собственное адресное пространство, зарезервированное только для этого процесса, но как насчет пространства ядра? На самом деле ядро загружается в память только один раз и каждая программа должна его использовать. Вот почему каждый процесс нуждается в соответствующей настройке указателей, которые делают именно это. Это означает, что PDE, хранящиеся в каталоге страниц каждого процесса, указывают на одну и ту же таблицу страниц ядра.

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

На изображении выше мы видим HAL (уровень аппаратной абстракции), который является первым уровнем абстракции, который абстрагирует детали оборудования от операционной системы. Затем операционная система может вызывать те же функции API, а HAL позаботится о том, как они на самом деле выполняются на базовом оборудовании. Каждый драйвер, загружаемый в режиме ядра, использует HAL для взаимодействия с аппаратными компонентами, поэтому даже драйверы не взаимодействуют с оборудованием напрямую. Драйверы ядра могут напрямую взаимодействовать с оборудованием, но обычно в этом нет необходимости, поскольку они могут использовать HAL API для выполнения некоторых действий. API уровня аппаратной абстракции предоставляется с файлом библиотеки hal.dll, который находится в каталоге C:\WINDOWS\system32\, как показано ниже:

Остальные компоненты ядра системы предоставляются следующими библиотеками и исполняемыми файлами:

exe : управляет пользовательскими процессами и потоками
sys : пользователь и драйвер графического устройства (GDI)
dll: доступ к таким ресурсам, как файловая система, устройства, процессы, потоки и обработка ошибок в системах Windows
dll: доступ к реестру Windows, выключение/перезапуск системы, запуск/остановка/создание служб, управление учетными записями пользователей
dll: создание и управление экранными окнами, кнопками, полосами прокрутки, получение ввода с мыши и клавиатуры
dll: выводит графическое содержимое на мониторы, принтеры и другие устройства вывода
dll: диалоговые окна для открытия и сохранения файлов, выбора цвета и шрифта
dll: доступ к строкам состояния, индикаторам выполнения, инструментам, вкладкам
dll: доступ к оболочке операционной системы
dll: доступ к сетевым функциям

Программы могут использовать Windows API (Win 32 API) для выполнения необходимых действий.

Архитектура windows nt: Архитектура ядра Windows NT | Открытые системы. СУБД