Вопрос 6. Структура системных файлов ОС Windows и их взаимодействие между собой. Ядро системы. Функции Nature API .


Добавил:DMT
Дата создания:30 декабря 2007, 18:57
Дата обновления:9 января 2008, 23:44
Просмотров:10782 последний вчера, 10:15
Комментариев: 0

Вопрос 6. Структура системных файлов ОС Windows и их взаимодействие между собой. Ядро системы. Функции Nature API .

Ядро состоит из следующих компонентов:

  1. Исполнительная система ( Executive ) - управление памятью, процессами и потоками;
  2. Ядро ( Kernel ) - планирование потоков, диспетчеризация прерываний и исключений и др. (реализовано в Ntoskrnl . exe );
  3. Драйверы устройств ( Device Drivers ) - драйверы аппаратных устройств, сетевые драйверы, драйверы файловых систем;
  4. Уровень абстрагирования от оборудования ( Hardware Abstraction Layer , HAL) - изолирует три вышеперечисленных компонента от различий между аппаратными архитектурами (реализован в Hal.dll );
  5. Подсистема поддержки окон и графики ( Windowing And Graphics System ) - функции графического пользовательского интерфейса ( Graphic User Interface , GUI) (реализована в Win32k.sys ).

Рис. 1. Схема взаимодействия системных файлов.

Уровень аппаратных абстракций

Уровень аппаратных абстракций (HAL) представляет собой создаваемый производителями аппаратных сре дств сл ой программного обеспечения, который скрывает (или абстрагирует), особенности и различия аппаратуры от верхних уровней операционной системы. Благодаря обеспечиваемому HAL ом фильтру, различные аппаратные средства выглядят аналогично с точки зрения операционной системы; снимается необходимость специальной поднастройки операционной системы под используемое оборудование. Процедуры HAL называются как средствами операционной системы (включая ядро), так и драйверами устройств. При работе с драйверами устройств уровень аппаратных абстракций обеспечивает поддержку различных технологий ввода - вывода.

Ядро

Ядро ( Kernel ) работает в тесном контакте с уровнем аппаратных абстракций. Этот модуль занимается планированием действий компьютерного процессора. В случае если компьютер содержит несколько процессоров, ядро синхронизирует их работу с целью достижения максимальной производительности системы. Ядро осуществляет диспетчеризацию нитей управления ( threads ), которые являются основными объектами в системе, таким образом, чтобы максимально загрузить процессоры системы и обеспечить первоочередную обработку нитей с более высоким приоритетом. (32 значения приоритета, которые сгруппированы в два класса приоритетов: real-time и variable ). Подкомпоненты исполняющей системы, такие как диспетчер ввода вывода и диспетчер процессов, используют ядро для синхронизации действий. Они также взаимодействуют с ядром для более высоких уровней абстракции, называемых объектами ядра.

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

Исполняющая система Windows NT

Исполняющая система ( Executive ), в состав которой входит ядро и уровень аппаратных абстракций HAL, обеспечивает общий сервис системы, который могут использовать все подсистемы среды. Каждая группа сервиса находится под управлением одной из отдельных составляющих исполняющей системы: диспетчера объектов ( Object Manager ) диспетчера виртуальной памяти ( Virtual Memory Manager ); диспетчера процессов ( Process Manager ) средства вызова локальных процедур ( Local Procedure Call Facility ); диспетчера ввода - вывода (E/O Maneger ); мониторы безопасности ( Security Reference Monitor ). Монитор безопасности совместно с процессором входа в сиситему ( Logon ) и защищёнными подсистемами реализует модель безопасности Windows NT. Верхний уровень исполняющей системы называется системным сервисом ( System Services ).

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

Native API

Native API для Windows NT является средством, которое реализует контролируемый вызов системных сервисов, исполняемых в режиме ядра. Этот интерфейс API является интерфейсом системных вызовов и не предназначается для непосредственного использования пользовательскими программами, кроме того, его документация ограничена. В Windows NT Native интерфейс спрятан от прикладных программистов под интерфейсами API более высокого уровня, таких как Win32, OS/2, POSIX, DOS/Win16.

Native API предоставляется коду пользовательского режима библиотекой ntdll.dll . Библиотека ntdll.dll, имеющая точки входа в Native API для кода пользовательского режима, содержит также код загрузки модуля и запуска потока процесса. Однако большинство входов в Native API являются заглушками, которые просто передают управление режиму ядра. Это осуществляется путем генерации программного исключения, например, ассемблерный код функции NtCreateFile () в библиотеке ntdll.dll, выглядит следующим образом:

mov еах , 0x00000017

lea edx , [esp+04]

int Ox 2 E

ret Ox 2 C

Первая инструкция загружает реги стр пр оцессора индексным номером конкретной функции Native API (каждая функция Native API имеет уникальный индексный номер). Вторая инструкция загружает в регистр указатель на параметры вызова. Следующая инструкция - команда генерации программного исключения. ОС регистрирует обработчик ловушки для перехвата управления, переключения из пользовательского режима в режим ядра и передачи управления в фиксированную точку ОС при возникновении прерывания или исключения. В случае вызова системного сервиса (на процессорах х86 программное исключение для вызова системных сервисов генерируется кодом Ох2Е), этот обработчик ловушки передает управление диспетчеру системных сервисов. Последняя инструкция забирает параметры из стека вызывающего потока.

Для функций, содержащихся в ntoskrnl.exe (так называемый Native API ), зарезервированы позиции в таблицах 0x0000 — 0x0FFF. Диапазон значений 0x1000 — 0x1FFF отведен под функции win32k.sys .

Диспетчер системных сервисов определяет, является ли корректным индексный номер функции Native API. Индексный номер, переданный из пользовательского режима, используется для входа в таблицу распределения системных сервисов ( KeServiceDescriptorTable ). Каждый элемент этой таблицы включает указатель на соответствующий системный сервис и число параметров. Диспетчер системных сервисов берет параметры, переданные в стеке пользовательского режима (указатель стека находится в регистре edx ) и помещает их в стек ядра, а затем передает управление для обработки запроса соответствующему системному сервису, который исполняется в режиме ядра и находится в ntoskrnl.exe .

Все функции прикладного уровня, вызывающие это прерывание, сосредоточены в модуле ntdll.dl l и имеют в своем названии префикс Nt либо Zw , например, NtCreateFile ()/ ZwCreateFile (). Точка входа для двух таких имен одна. Вызов многих функций различных подсистем рано или поздно приведет к вызову соответствующей функции из ntdll.dll. При этом не все, что есть в ntdll.dll вызывается из подсистемы Win32.

Вызов системных сервисов возможен не только из прикладной программы, но и из ядра ОС, то есть из драйверов. Имена соответствующих функций ядра имеют префикс либо Zw , либо Nt ( ZwCreateFile (), NtCreateFile ()). Функции с префиксом Zw обращаются к сервисам посредством прерывания 2Е, тогда как функции с префиксом Nt являются собственно точками входа стандартных системных сервисов. Из этого следует, что число функций с префиксом Nt неизменно, а множество этих функций является подмножеством функций с префиксом Zw .

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

Код на C++
  1. //bytesReturnedPtr содержит информацию о размере буфера
  2. #define TAG_GET_PROC_THREAD_INFO             5
  3. #define FIRST_GUESS_AT_PROC_THREAD_INFO_SIZE 8192 //первоначальный р-р буфера
  4. #define INCREMENT_FOR_PROC_THREAD_INFO_SIZE  1024 //инкремент буфера
  5.  
  6. char *GetProcessAndThreadInfo (ULONG *bytesReturnedPtr)
  7. {
  8.   char *buf;         // буфер для информации
  9.   ULONG bufSize;     // размер буфера
  10.   NTSTATUS status;   // код статуса, возвращаемый ZwQuerySystemInformation
  11.  
  12.   bufSize = FIRST_GUESS_AT_PROC_THREAD_INFO_SIZE;
  13.   while ((buf = ExAllocatePool(NonPagedPool, bufSize)) != NULL) 
  14.   {
  15.     *bytesReturnedPtr = 0;
  16.     status = ZwQuerySystemInformation (TAG_GET_PROC_THREAD_INFO,
  17.                                       buf, bufSize, bytesReturnedPtr);
  18.     if (status == STATUS_SUCCESS) return buf;
  19.  
  20.     // если неправильный размер буфера - увеличить его
  21.     ExFreePool(buf);
  22.     if (status == STATUS_BUFFER_OVERFLOW ||
  23.         status == STATUS_INFO_LENGTH_MISMATCH)
  24.         bufSize = MAX(*bytesReturnedPtr,
  25.                     bufSize + INCREMENT_FOR_PROC_THREAD_INFO_SIZE);
  26.     else return NULL;
  27.   }
  28.   return NULL;
  29. }
При использовании обязательна ссылка на http://DMTSoft.ru
up