Материал: Операционные системы . учебное пособие. Лопатин Р.С

В класс D попадают системы, оценка которых выявила их несоответствие требо­ваниям всех других классов.

Основными свойствами, характерными для систем класса С, являются наличие подсистемы учета событий, связанных с безопасностью, и избирательный кон­троль доступа. Класс (уровень) С делится на 2 подуровня: уровень С1, обеспечи­вающий защиту данных от ошибок пользователей, но не от действий злоумыш­ленников; и более строгий уровень С2. На уровне С2 должны присутствовать:

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

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

- средства учета и наблюдения (auditing), обеспечивающие возможность обна­ружить и зафиксировать важные события, связанные с безопасностью, или любые попытки создать, получить доступ или удалить системные ресурсы;

- защита памяти, заключающаяся в том, что память инициализируется перед тем, как повторно используется.

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

Системы уровня В основаны на помеченных данных и распределении пользо­вателей по категориям, то есть реализуют мандатный контроль доступа. Каждо­му пользователю присваивается рейтинг защиты, и он может получать доступ к данным только в соответствии с этим рейтингом. Этот уровень в отличие от уровня С защищает систему от ошибочного поведения пользователя. Уровень А является самым высоким уровнем безопасности, он требует в допол­нение ко всем требованиям уровня В выполнения формального, математически обоснованного доказательства соответствия системы требованиям безопасности. Различные коммерческие структуры (например, банки) особо выделяют необхо­димость учетной службы, аналогичной той, что предлагают государственные ре­комендации С2. Любая деятельность, связанная с безопасностью, может быть отслежена и тем самым учтена. Это как раз то, чего требует стандарт для систем класса С2, и что обычно нужно банкам. Однако коммерческие пользователи, как правило, не хотят расплачиваться производительностью за повышенный уровень безопасности. А-уровень безопасности занимает своими управляющими меха­низмами до 90 % процессорного времени, что, безусловно, в большинстве случа­ев уже неприемлемо. Более безопасные системы не только снижают эффективность, но и существенно ограничивают число доступных прикладных пакетов, которые соответствующим образом могут выполняться в подобной системе. На­пример, для ОС Solaris (версия UNIX) есть несколько тысяч приложений, а для ее аналога В-уровня - только около ста.

3.1. Микроядерные операционные системы

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

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

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

Созданная в университете Карнеги Меллон технология микроядра Mach служит основой для многих ОС.

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

- управление виртуальной памятью;

- задания и потоки;

- межпроцессные коммуникации;

- управление поддержкой ввода/вывода и

прерываниями;

- сервисы набора хостами процессора.

3.2. Монолитные операционные системы

Монолитные ОС являются прямой противоположностью микроядерным ОС.

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

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

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

Микроядерные ОС в настоящее время разрабатываются чаще монолитных. Од­нако следует заметить, что использование технологии клиент - сервер - это еще не гарантия того, что ОС станет микроядерной. В качестве подтверждения мож­но привести пример с ОС Windows NT, которая построена на идеологии клиент-сервер, но которую тем не менее трудно назвать микроядерной. Для того чтобы согласиться с таким высказыванием, достаточно сравнить ОС QNX и ОС Win­dows NT.

3.3. Интерфейс прикладного программирования

Разделим общий термин API (application program interface, интерфейс прикладного программирования) на следующие направления:

Q API как интерфейс высокого уровня, принадлежащий к библиотекам RTL;

D API прикладных и системных программ, входящих в поставку операционной системы;

0 прочие API.

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

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

API используется не только прикладными, но и многими системны­ми программами как в составе ОС, так и в составе системы программирования.

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

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

Существует несколько вариантов реализации API:

- реализация на уровне ОС;

- реализация на уровне системы программирования;

- реализация на уровне внешней библиотеки процедур и

функций.

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

Возможности API можно оценивать со следующих позиций:

- эффективность выполнения функций API - включает в себя

скорость вы­полнения функций и объем вычислительных ре

сурсов, потребных для их вы­полнения;

- широта предоставляемых возможностей;

- зависимость прикладной программы от архитектуры це

левой вычислитель­ной системы.

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

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

Реализация функций API на уровне ОС

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

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

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

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

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

Хорошо известным примером API такого рода может служить набор функций, предоставляемых пользователю со стороны ОС типа Microsoft Windows - WinAPI (Windows API). Надо сказать, что даже внутри этого корпоративного API суще­ствует определенная несогласованность, которая несколько ограничивает пере­носимость программ между различными ОС типа Windows. Еще одним приме­ром такого API можно считать набор сервисных функций ОС типа MS-DOS, реализованный в виде набора подпрограмм обслуживания программных преры­ваний.

Реализация функций API на уровне системы программирования

Если функции API реализуются на уровне системы программирования, они пре­доставляются пользователю в виде библиотеки функций соответствующего язы­ка программирования. Обычно речь идет о библиотеке времени исполнения - RTL (run time library). Система программирования предоставляет пользователю библиотеку соответствующего языка программирования и обеспечивает подклю­чение к результирующей программе объектного кода, ответственного за выпол­нение этих функций.

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

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

Единообразное выполнение функций языка обеспечивается системой программи­рования. При ориентации на различные архитектуры целевой вычислительной системы в системе программирования могут потребоваться различные комбина­ции вызовов функций ОС для выполнения одних и тех же функций исходного языка. Это должно быть учтено в коде RTL. В общем случае для каждой архи­тектуры целевой вычислительной системы будет требоваться свой код RTL язы­ка программирования. Выбор того или иного объектного кода RTL для подклю­чения к результирующей программе система программирования обеспечивает автоматически.

Например, рассмотрим функции динамического выделения памяти в языках С и Pascal. В С это функции mall ос, real 1 ос и free (функции new и delete в C++), в Pascal - функции new и dispose. Если использовать эти функции в исходном тексте программы, то с точки зрения исходной программы они будут действо­вать одинаковым образом в зависимости только от семантики исходного кода. При этом для разработчика исходной программы не имеет значения, на какую архитектуру ориентирована его программа. Это имеет значение для системы про­граммирования, которая для каждой из этих функций должна подключить к ре­зультирующей программе объектный код библиотеки. Этот код будет выполнять обращение к соответствующим функциям ОС. Не исключено даже, что для од­нотипных по смыслу функций в разных языках (например, mall ос в С и new в языке Pascal выполняют схожие по смыслу действия) этот код будет выполнять схожие обращения к ОС. Однако для различных вариантов ОС этот код будет различен даже при использовании одного и того же исходного языка.