Пользовательский режим и режим ядра

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

Все процессы, кроме процесса System, выполняются в пользовательском режиме (кольцо 3 на архитектуре Intel x86 и x64), ­тогда как драйверы устройств и компоненты операционной системы, такие как исполнительная система и ядро, выполняются только в режиме ядра.

Режим ядра обращается к режиму выполнения (кольцо 0 на x86 и x64) в процессоре, который предоставляет доступ ко всей системной памяти и ко всем инструкциям ЦП. Предоставляя низкоуровневому программному обеспечению операционной системы более высокий уровень полномочий чем ­имеют процессы пользовательского режима, процессор предоставляет необходимую основу разработчикам операционной системы, гарантируя, что неправильно себя ведущее приложение не может разрушить устойчивость системы в целом.

Примечание. Надо различать пользовательский режим и режима ядра,  пользовательские права и права администратора. "Пользовательский режим" означает, что в этом режиме "имеются только стандартные пользовательские полномочия."

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

Операционная система помечает («тегирует», tags) каждую страницу виртуальной памяти, определяя режим доступа, которым должен обладать процессор, чтобы считать или записать страницу.

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

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

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

Операционная система выполняет соответствующую внутреннюю функцию, которая для ReadFile является функцией ядра NtReadFile. Служебные функции ядра проверяют параметры и выполняют ­соответствующие проверки доступа, используя Монитор безопасности (Security Reference Monitor) прежде, чем они выполнят требуемую работу. Когда выполнение функции закончено, операционная система переключает режим процессора в пользовательский режим.

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

Дескрипторы

Ядро Windows (режим ядра), который реализуется в Ntoskrnl.exe, состоит из различных подсистем, таких как диспетчер памяти, диспетчер процессов, диспетчер ввода-вывода, и диспетчер конфигурации (реестр)(Memory Manager, Process Manager, I/O Manager, and Configuration Manager (registry), каждая из которых являются частями исполнительной системы. Каждая из этих подсистем определяет один или более типов объектов с помощью Диспетчера объектов (Object Manager), чтобы представить ресурсы, которые они представляют приложениям. Например, диспетчер конфигурации (Configuration Manager) определяет объект Ключ (Key object)для того, чтобы представить открытый ключ регистра; Диспетчер памяти определяет объект Секция для разделяемой памяти; исполнительная ситсема определяет Семафор (Semaphore), Мутант (Mutant) (внутреннее имя для взаимного исключения - mutex), и ­объекты синхронизации cобытий ­(которые являются объектами, описывающие структуры данных, определенные  ядром операционной системы); менеджер по вводу-выводу определяет объект Файл для того, чтобы ­предоставить открытые ресурсы драйверу устройства (файлы файловой системы) и диспетчер процессов, котрый создает объекты Поток и Процесс.

Каждая вверсия Windows представляет новые типы объектов. В  Windows 7 определено в общей сложности 42 объекта. Можно видеть типы объектов, которые определены в версии Windows, выполняя утилиту WinObj (описанный в Главе, "Утилиты информации о Системе") с правами администратора, обращающаяся к каталогу ObjectTypes в пространстве имен Диспетчера объектов.

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

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

Это значение дескриптора - то, что приложение использует для последующих операций с ресурсом. Чтобы запросить или управлять ресурсом, приложение передает значение дескриптора в качестстве параметра API-функциям, напрмер, таким как ReadFile, SetEvent, SetThreadPriority, и MapViewOfFile.

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

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

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

Когда процесс больше не нуждается в доступе к объекту он может освободить дескриптор к этому объекту, обычно передавая значение дескриптора API CloseHandle. (Необходимо отмептиь, что диспетчеры обеспечивают различный API, чтобы высвободить свои роесурса), Когда процесс завершается, каждый дескриптор, который он обладал, освобождаются.