Что входит в ядро 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 представляет собой операционную систему с гибридным ядром (см. лекцию 1 «Введение в операционные системы»). В ней основные системные функции по управлению процессами, памятью, устройствами, файловой системой и безопасностью реализованы в компонентах, работающих в режиме ядра; но существует ряд важных системных компонентов пользовательского режима, например системные процессы входа в систему, локальной аутентификации, диспетчера сеансов, а также подсистемы окружения.

Архитектура Windows представлена на рис.4.1 [5; 2].

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

Рис.
4.1.
Архитектура Windows

Компоненты пользовательского режима

В пользовательском режиме работают следующие виды процессов:

• системные процессы (system processes) – компоненты Windows, отвечающие за решение критически важных системных задач (т. е. аварийное завершение одного из этих процессов вызывает крах или нестабильную работу всей системы), но выполняемые в пользовательском режиме.
  Основные системные процессы:
  • Winlogon.exe – процесс входа в систему и выхода из неё;
  • Smss.exe (Session Manager – диспетчер сеансов) – процесс выполняет важные операции при инициализации системы (загрузка необходимых DLL, запуск процессов Winlogon и Csrss и др.), а затем контролирует работу Winlogon и Csrss;
  • Lsass.exe (Local Security Authentication Subsystem Server – сервер подсистемы локальной аутентификации) – процесс проверяет правильность введенных имени пользователя и пароля;
  • Wininit.exe – процесс инициализации системы (например, запускает процессы Lsass и Services);
  • Userinit.exe – процесс инициализации пользовательской среды (например, запускает системную оболочку – по умолчанию, Explorer.exe);
  • Services.exe (SCM, Service Control Manager – диспетчер управления службами) – процесс, отвечающий за выполнение служб – см. ниже;
• службы (сервисы, services) – приложения, работающие в фоновом режиме и не требующие взаимодействия с пользователем. Службы могут быть как частью операционной системы (например, Windows Audio – служба для работы со звуком, или Print Spooler – диспетчер печати), так и частью пользовательского приложения (например, служба СУБД SQL Server). За службы отвечает системный процесс Services.exe;
• пользовательские приложения (user applications) ¬– прикладные программы, запускаемые пользователем;
• подсистемы окружения (environment subsystems) – компоненты, предоставляющие доступ приложениям к некоторому подмножеству системных функций. Windows поддерживает две подсистемы окружения:
  • собственно Windows – при помощи данной подсистемы выполняются 32 разрядные приложения Windows (Win32), а также 16 разрядные приложения Windows (Win16), приложения MS DOS и консольные приложения (Console). За подсистему Windows отвечает системный процесс Csrss.exe и драйвер режима ядра Win32k.sys;
  • POSIX (Portable Operating System Interface for UNIX – переносимый интерфейс операционных систем UNIX) – подсистема для UNIX-приложений. Начиная с Windows Server 2003 R2 компонент, реализующий эту подсистему, называется SUA (Subsystem for UNIX-based Applications). Компонент не устанавливается в Windows по умолчанию.

Все перечисленные процессы пользовательского режима (кроме подсистемы POSIX^{1Подсистема POSIX использует библиотеку Psxdll.dll.}) для взаимодействия с модулями режима ядра используют библиотеки Windows DLL (Dynamic Link Library – динамически подключаемая библиотека). Каждая DLL экспортирует набор Windows API функций, которые может вызывать процесс.

Windows API (Windows Application Programming Interface, WinAPI) – это способ взаимодействия процессов пользовательского режима с модулями режима ядра. WinAPI включает тысячи функций и хорошо документирован [10].

Основные Windows DLL следующие:

• Kernel32.dll – базовые функции, в том числе работа с процессами и потоками, управление памятью и вводом выводом;
• Advapi32.dll – функции, в основном связанные с управлением безопасностью и доступом к реестру;
• User32.dll – функции, отвечающие за управление окнами и их элементами в GUI приложениях (Graphical User Interface – графический интерфейс пользователя);
• Gdi32.dll – функции графического пользовательского интерфейса (Graphics Device Interface, GDI), обеспечивающие рисование на дисплее и принтере графических примитивов и вывод текста.

Библиотека Ntdll.dll экспортирует в большинстве своем недокументированные системные функции, реализованные, в основном, в Ntoskrnl.exe. Набор таких функций называется Native API («родной» API).

Библиотеки Windows DLL преобразуют вызовы документированных WinAPI функций в вызовы функций Native API и переключают процессор на режим ядра.

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

Диспетчер системных сервисов (System Service Dispatcher) работает в режиме ядра, перехватывает вызовы функций от Ntdll.dll, проверяет их параметры и вызывает соответствующие функции из Ntoskrnl.exe.

Исполнительная система и ядро содержатся в Ntoskrnl.exe (NT Operating System Kernel – ядро операционной системы NT) (по поводу использования термина «ядро» в Windows см. лекцию 1 «Введение в операционные системы»).

Исполнительная система (Executive) представляет собой совокупность компонентов (называемых диспетчерами – manager), которые реализуют основные задачи операционной системы:

• диспетчер процессов (process manager) – управление процессами и потоками (см. лекцию 6 «Процессы и потоки»);
• диспетчер памяти (memory manager) – управление виртуальной памятью и отображение её на физическую (см. лекцию 8 «Управление памятью»);
• монитор контроля безопасности (security reference monitor) – управление безопасностью (см. лекцию 9 «Безопасность»);
• диспетчер ввода вывода (I/O manager), диспетчер кэша (cache Manager), диспетчер Plug and Play (PnP Manager) – управление внешними устройствами и файловыми системами (см. лекцию 10 «Управление устройствами» и лекцию 11 «Файловая система NTFS»);
• диспетчер электропитания (power manager) – управление электропитанием и энергопотреблением;
• диспетчер объектов (object manager), диспетчер конфигурации (configuration manager), механизм вызова локальных процедур (local procedure call) – управление служебными процедурами и структурами данных, которые необходимы остальным компонентам.

Ядро (Kernel) содержит функции, обеспечивающие поддержку компонентам исполнительной системы и осуществляющие планирование потоков (см. лекцию 7 «Планирование потоков»), механизмы синхронизации, обработку прерываний.

Компонент Windows USER и GDI отвечает за пользовательский графический интерфейс (окна, элементы управления в окнах – меню, кнопки и т. п., рисование), является частью подсистемы Windows и реализован в драйвере Win32k.sys.

Взаимодействие диспетчера ввода вывода с устройствами обеспечивают драйверы (drivers) – программные модули, работающие в режиме ядра, обладающие максимально полной информацией о конкретном устройстве (драйверы подробнее рассматриваются в лекции 10 «Управление устройствами»).

Однако, и драйверы, и ядро не взаимодействуют с физическими устройствами напрямую – посредником между программными компонентами режима ядра и аппаратурой является HAL (Hardware Abstraction Layer) – уровень абстрагирования от оборудования, реализованный в Hal.dll. HAL позволяет скрыть от всех программных компонентов особенности аппаратной платформы (например, различия между материнскими платами), на которой установлена операционная система.

Резюме

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

В следующей лекции рассматривается исследовательское ядро Windows (Windows Research Kernel) – вариант Ntoskrnl.exe с исходным кодом, доступным академическим организациям.

Контрольные вопросы

1. К какому типу ядер в большей степени относится Windows NT, к монолитным или микроядрам? Ответ обоснуйте.
2. Перечислите основные компоненты пользовательского режима.
3. Перечислите основные компоненты режима ядра.
4. Что такое Windows API? Где можно найти информацию по этому вопросу?
5. Каковы основные функции исполнительной системы, входящей в состав Ntoskrnl.exe?
6. Каковы основные функции ядра, входящего в состав Ntoskrnl.exe?
7. Что такое HAL?

Картинка с сайта: fileenergy.com

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

Что такое архитектура Windows?

Архитектура Windows — это совокупность программных и аппаратных компонентов, которые определяют, как операционная система управляет ресурсами компьютера, обеспечивает взаимодействие между приложениями и устройствами, решает проблемы и защищает данные от постороннего доступа. Архитектура Windows может быть разделена на два основных уровня: ядро (kernel) и пользовательский режим (user mode). Ядро — это низкоуровневая часть операционной системы, которая работает в специальном режиме процессора и имеет непосредственный доступ к аппаратным ресурсам. Пользовательский режим — это высокоуровневая часть операционной системы, которая работает в обычном режиме процессора и содержит разнообразные приложения и службы. Ядро и пользовательский режим общаются друг с другом через специальные механизмы, такие как системные вызовы (system calls), сообщения (messages) и объекты ядра (kernel objects).

Windows поддерживает различные архитектуры процессоров, такие как x86, x64, ARM и ARM64. Каждая архитектура имеет свои особенности, такие как размер адресного пространства, набор инструкций, регистры и т.д. Windows адаптируется к разным архитектурам с помощью специального слоя абстракции аппаратного обеспечения (hardware abstraction layer, HAL), который предоставляет единый интерфейс для доступа к аппаратным ресурсам.

Windows отличается от других операционных систем своей гибкостью и совместимостью. Windows может запускать приложения, написанные для разных API (application programming interface), таких как Win32, POSIX, WinRT и т.д., благодаря подсистемам пользовательского режима, которые реализуют эти API. Windows также может работать с разными типами устройств, таких как клавиатуры, мыши, диски, принтеры и т.д., благодаря драйверам устройств, которые обеспечивают связь между ядром и устройствами.

Ядро: сердце операционной системы

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

Ядро Windows имеет гибридную структуру, то есть оно состоит из нескольких компонентов, которые работают на разных уровнях абстракции. Основные компоненты ядра Windows — это:

Ядро (kernel) — это самая низкоуровневая часть ядра, которая содержит базовые функции для работы с процессором, памятью и прерываниями. Ядро также содержит диспетчер объектов (object manager), который управляет объектами ядра, такими как потоки (threads), процессы (processes), события (events), семафоры (semaphores) и т.д., и предоставляет механизмы для синхронизации и коммуникации между ними.

Слой абстракции аппаратного обеспечения (hardware abstraction layer, HAL) — это часть ядра, которая адаптирует ядро к разным архитектурам процессоров и аппаратным платформам. HAL предоставляет единый интерфейс для доступа к аппаратным ресурсам, таким как таймеры, прерывания, шины и т.д., и скрывает от ядра специфические детали реализации этих ресурсов.

Executive — это часть ядра, которая содержит высокоуровневые службы для управления системными ресурсами, такими как память (memory manager), процессы (process manager), потоки (thread manager), ввод-вывод (I/O manager), безопасность (security reference monitor), конфигурация (configuration manager) и т.д. Executive также содержит подсистему Plug and Play (PnP), которая обнаруживает, устанавливает и управляет устройствами в системе.

Драйверы — это часть ядра, которая содержит программы для работы с различными типами устройств, такими как диски, клавиатуры, мыши, принтеры и т.д. Драйверы обеспечивают связь между ядром и устройствами через стек ввода-вывода (I/O stack) и модель драйверов Windows (WDM).

Ядро Windows работает в соответствии с моделью клиент-сервер. Клиентами являются приложения и подсистемы пользовательского режима, которые отправляют запросы к ядру через системные вызовы (system calls). Серверами являются компоненты ядра, которые обрабатывают эти запросы и возвращают результаты клиентам. Системные вызовы — это специальные функции API, которые переводят процессор из обычного режима в специальный режим и передают управление ядру. Системные вызовы обычно имеют префикс Nt или Zw, например, NtCreateFile или ZwQuerySystemInformation.

Ядро Windows также работает в соответствии с моделью прерываний. Прерывания — это сигналы от аппаратных устройств или программ, которые требуют срочного внимания от ядра. Прерывания могут быть синхронными или асинхронными. Синхронные прерывания — это прерывания, которые возникают в результате действий текущего потока, например, деления на ноль или обращения к неверному адресу памяти. Асинхронные прерывания — это прерывания, которые возникают в результате действий внешних устройств, например, нажатия клавиши или прихода пакета по сети. Прерывания обрабатываются специальными функциями, называемыми обработчиками прерываний (interrupt handlers), которые выполняют необходимые действия и возвращают управление ядру.

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

Подсистемы: мост между ядром и приложениями

Подсистемы — это часть операционной системы, которая работает в пользовательском режиме и предоставляет различные API (application programming interface) для приложений. API — это набор функций, констант, типов данных и структур, которые определяют, как приложение может взаимодействовать с операционной системой и использовать ее ресурсы. Подсистемы реализуют разные API для разных типов приложений, таких как Win32, POSIX, WinRT и т.д.

Win32 — это основной API для приложений Windows, который поддерживает графический интерфейс пользователя (GUI), файловую систему, сетевое взаимодействие, безопасность и т.д. Win32 состоит из двух частей: пользовательской (user) и ядерной (kernel). Пользовательская часть отвечает за работу с окнами, меню, диалогами, контролами и т.д. Ядерная часть отвечает за работу с файлами, реестром, процессами, потоками и т.д.

POSIX — это API для приложений, написанных для UNIX-подобных операционных систем, который поддерживает базовые функции для работы с файлами, процессами, сигналами и т.д. POSIX позволяет запускать на Windows приложения, которые были разработаны для других платформ.

WinRT — это API для приложений Windows Store, который поддерживает сенсорный интерфейс пользователя (touch), метро-стиль (metro-style), контракты (contracts), уведомления (notifications) и т.д. WinRT основан на объектно-ориентированной модели COM (component object model) и может быть использован из разных языков программирования, таких как C#, C++, JavaScript и т.д.

Подсистемы пользовательского режима общаются с ядром через системные вызовы (system calls), которые передают запросы от приложений к ядру и возвращают результаты от ядра к приложениям. Подсистемы также общаются друг с другом через механизмы IPC (interprocess communication), такие как каналы (pipes), очереди сообщений (message queues), разделяемая память (shared memory) и т.д.

Подсистемы пользовательского режима работают под управлением интегральной подсистемы (integral subsystem), которая выполняет системные функции от имени подсистем среды. Интегральная подсистема состоит из двух компонентов: службы локального процедурного вызова (local procedure call service, LPCS) и службы сервера процессов (process server service, PSS). LPCS отвечает за передачу сообщений между подсистемами пользовательского режима и ядром через порты LPC (local procedure call ports). PSS отвечает за создание и завершение процессов подсистем пользовательского режима.

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

Драйверы устройств: связующее звено между ядром и устройствами

Драйверы устройств — это часть операционной системы, которая содержит программы для работы с различными типами устройств, такими как диски, клавиатуры, мыши, принтеры и т.д. Драйверы устройств обеспечивают связь между ядром и устройствами через стек ввода-вывода (I/O stack) и модель драйверов Windows (WDM).

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

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

Промежуточный слой (intermediate layer) — это слой, который содержит драйверы устройств, которые реализуют протоколы для работы с данными, например, SCSI, USB, TCP/IP и т.д.

Низший слой (lower layer) — это слой, который содержит драйверы устройств, которые реализуют физические функции для работы с данными, например, чтение и запись на диск, передача и прием по сети и т.д.

Модель драйверов Windows (WDM) — это стандарт для разработки драйверов устройств для Windows, который определяет общие требования и интерфейсы для драйверов устройств разных типов. WDM состоит из трех частей: WDM базовый (WDM basic), WDM расширенный (WDM extended) и WDM потоковый (WDM stream). WDM базовый определяет общие функции для всех драйверов устройств, такие как загрузка и выгрузка драйверов, обработка запросов ввода-вывода (I/O requests), обработка прерываний и т.д. WDM расширенный определяет специфические функции для драйверов устройств Plug and Play (PnP) и энергосбережения (power management), такие как обнаружение и удаление устройств, переход в разные состояния питания и т.д. WDM потоковый определяет специфические функции для драйверов устройств аудио-видео потоков (audio-video streams), такие как форматирование и обработка потоковых данных, синхронизация потоков и т.д.

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

Подводим итоги

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

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

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

Чтобы лучше понять архитектуру Windows я подготовил такой рисунок:

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

При запуске Windows приложения идет обращение к «Подсистеме Windows«, а уже от туда идет обращение к «Исполнительной системе«, которая запустит процесс для этого приложения.

Microsoft также разработали «Подсистему для Linux» (WSL). Для этого в режим ядра поместили два драйвера: Lxss.sys и Lxcore.sys. Эти драйвера эмулируют ядро Linux. А также, в пользовательском режиме работает специальный менеджер — LX Manager. Этот менеджер обрабатывает приложения для Linux.

Когда вы запускаете Linux приложение, например bash.exe, то идет обращение через LX Manager к драйверам эмулирующим ядро Linux. И уже это ядро запускает и обслуживает данный процесс.

То-есть для Windows приложений существует «Подсистема Windows» в пользовательском режиме и «Исполнительная система» в режиме ядра. А для Linux приложений существует LX Manager в пользовательском режиме и специальные драйвера в режиме ядра.

Помимо «Исполнительной системы» и драйверов эмулирующих работу ядра Linux в режиме ядра работают:

• драйвера устройств или приложений, которые являются исполняемыми файлами с расширением .sys;
• ядро операционной системы;
• HAL — прослойка между ядром (или драйверами) и оборудованием (системной платой).

Ядро

В системе Windows ядро не выполняет все задачи, которые выполняются в режиме ядра. Ядру помогает «Исполнительная система«. Подробнее про неё будет написано в следующей статье. А пока посмотрим чем занимается само ядро.

Ядро состоит из набора функций Ntoskrnl.exe, которые являются фундаментальными в операционной системе. Эти функции используются компонентами исполнительной системы.

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

С другим оборудованием ядро работает через HAL.

HAL

HAL — слой абстрагирования от оборудования. Он представляет собой загружаемый модуль режима ядра hal.dll, и является прослойкой между ядром и оборудованием. Под оборудованием я подразумеваю системную плату или платы расширения, а не периферию. Так драйвера принтеров работают напрямую с принтерами, а не через HAL.

Таким образом ядро и драйвера не работают напрямую с материнской платой, а вызывают функции HAL.

Для Windows x86 включена пара библиотек HAL, но загружается одна в зависимости от типа системной платы:

• halacpi.dll — платы с поддержкой acpi, но без поддержки apic;
• halmacpi.dll — платы с поддержкой acpi и apic.

Для Windows x64 существует только один образ hal:

• hal.dll — платы с поддержкой x64 всегда поддерживают acpi и apic.

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

• HalExtPL080.dll — расширение для контроллера DMA PL080;
• HalExtIntcLpioDMA.dll — для некоторых платформ intel с пониженным энергопотреблением.

Создание расширений HAL требует сотрудничества с компанией MicroSoft. В связи с этим расширения снабжаются цифровой подписью.

Вернуться к оглавлению

Если понравилась статья, подпишись на мой канал в VK или Telegram.