ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 04.02.2024
Просмотров: 183
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Раздел II. Проектирование
операционных систем
Лекция 3. Требования к операционным системам
и обзор подходов их реализации
Обзор требований, предъявляемых к операционным системам: расширяемость, переносимость, надежность и отказоустойчивость, совместимость, безопасность, производительность операционных систем.
Операционная система выполняет связующую роль между оборудованием и прикладными программами. Она является важ- нейшим элементом программной инфраструктуры, от свойств кото- рой зависит качество работы прикладного программного обеспече- ния. Поэтому при проектировании операционных систем уделяют внимание специальным функциональным требованиям – более ши- роким, чем при проектировании прикладных программ.
Расширяемость. Код операционной системы должен быть написан таким образом, чтобы при необходимости можно было легко внести дополнения и изменения, не нарушая целостности системы.
Во времена первых компьютеров считалось, что по мере об- новления аппаратного обеспечения код операционных систем будет создаваться заново, с нуля. Однако практика показала, что разработ- ка программного обеспечения значительно более трудоемка, чем разработка аппаратуры. Возникла необходимость защиты инвести- ций как в разработку операционной системы, так и в прикладные программы, функционирующие под ее управлением.
В то время как аппаратная часть компьютера устаревает за не- сколько лет, полезная жизнь операционной системы может изме-
24 ряться десятилетиями (Unix). Аппаратные изменения, к которым должна быть, в первую очередь, адаптирована архитектура операци- онных систем, связаны с развитием периферийного оборудования.
Например, современные модификации в операционных системах связаны с новыми технологиями хранения данных (накопители
SSD), сетевого взаимодействия (беспроводные сети, оптические ка- налы высокой пропускной способности), новыми пользовательски- ми интерфейсами (жестовый ввод, голосовой ввод, сенсорные пане- ли). Сохранение целостности кода операционной системы, учиты- вая, что происходит постоянная модернизация аппаратуры, является одной из целей проектирования операционной системы.
Расширяемость может достигаться за счет модульной структу- ры операционной системы, при которой ее части состоят из сильно связанных внутри и слабо связанных между собой модулей. Взаи- модействие между модулями организуется через стандартизирован- ные интерфейсы. Новые компоненты, добавляемые в операционную систему, функционируют, используя интерфейсы, поддерживаемые существующими компонентами. Можно заменить код устаревших модулей, не затрагивая работоспособность системы в целом.
Использование объектов для представления системных ресур- сов также улучшает расширяемость системы. Объекты позволяют единообразно управлять системными ресурсами. Добавление новых объектов не разрушает существующие объекты и не требует изме- нений существующего кода.
Вариантом модульной организации является применение ар- хитектуры клиент-сервер и микроядра. В ней модули изолированы в отдельных процессах и могут замещаться даже без перекомпиляции и остановки вычислений.
Другой возможностью расширить функциональные возможно- сти операционной системы являются средства вызова удаленных процедур (RPC), которые могут добавляться в любую машину сети и немедленно поступать в распоряжение прикладных программ на других машинах сети.
Некоторые операционные системы для улучшения расширяе- мости поддерживают загружаемые драйверы, которые добавляются в систему во время ее работы. Новые файловые системы, устройства и сети могут поддерживаться путем написания драйвера устройства,
25 драйвера файловой системы или транспортного драйвера и загрузки его в систему.
Переносимость. Код операционной системы должен легко пе- реноситься между процессорами и аппаратными платформами раз- личной архитектуры. Аппаратная платформа включает наряду с ти- пом процессора и способ организации всей аппаратуры компьютера.
Расширяемость позволяет улучшать операционную систему по мере обновления периферийного оборудования. Переносимость дает возможность перемещать всю систему целиком на машину, базиру- ющуюся на обновленном процессоре или аппаратной платформе, делая при этом по возможности небольшие изменения в коде. Опе- рационные системы разрабатываются либо как переносимые, либо как непереносимые. Ключевым моментом в оценке переносимости является стоимость необходимых изменений.
При написании переносимой операционной системы нужно следовать перечисленным ниже правилам.
Большая часть кода должна быть написана на языке высокого уровня, например, как Unix на языке Си. Код, написанный на Ас- семблере, не является переносимым, если только он не переносится на машину, обладающую командной совместимостью с исходной машиной.
Необходимо учитывать аппаратную платформу, на которую операционная система должна быть перенесена. Например, система, построенная на 32-битовых адресах, не может быть перенесена на машину с 16-битовыми адресами.
Следует минимизировать или по возможности исключить ча- сти кода, которые непосредственно взаимодействуют с аппаратурой.
Оставшийся после такой оптимизации аппаратно-зависимый код, который не может быть исключен, локализуется в отдельных моду- лях (HAL – hardware abstraction layer). Очевидные формы зависимо- сти от аппаратуры включают прямое манипулирование регистрами процессора, аппаратно-зависимыми структурами данных (контекст процесса, дескрипторы страниц и сегментов), обращение к контрол- лерам периферийного оборудования.
Надежность и отказоустойчивость. Система должна быть защищена от отказов оборудования и внутренних ошибок. Действия операционной системы должны быть предсказуемыми. Прикладные процессы не должны иметь возможность наносить вред как самой
26 операционной системе, так и другим процессам. Надежность обес- печивается применением микроядерной архитектуры.
Совместимость. Операционная система должна иметь сред- ства для выполнения прикладных программ, написанных для других операционных систем или для более ранних версий данной опера- ционной системы. Пользовательский интерфейс должен быть совме- стим с существующими системами и стандартами. Совместимость операционных систем рассматривается на двух уровнях как двоич- ная совместимость и совместимость по исходным кодам.
Двоичная совместимость достигается совместимостью на уровне команд процессора, системных вызовов и на уровне библио- течных вызовов, если они являются динамически связываемыми.
Совместимость по исходным кодам требует наличия соответ- ствующего компилятора в составе программного обеспечения, а также совместимости на уровне библиотек и системных вызовов, при этом необходима перекомпиляция.
Совместимость на уровне исходных текстов важна для разра- ботчиков приложений. Для конечных пользователей практическое значение имеет только двоичная совместимость, благодаря которой один и тот же коммерческий продукт можно использовать в различ- ных операционных средах и на различных машинах. Совместимость зависит от многих факторов, самый важный фактор – архитектура процессора. Если процессор, на который переносится операционная система, использует аналогичный набор команд и тот же диапазон адресов, двоичная совместимость может быть достигнута достаточ- но просто.
Двоичная совместимость между процессорами, основанными на разных архитектурах, требует написания специальных эмулято- ров и использования прикладных сред. Для исполнения кода в гос- тевой операционной системе требуется: процедура загрузки, адапти- рованная под формат исполняемого файла; интерпретация команд целевого процессора на гостевом процессоре (если процессорные архитектуры различаются); имитация системных вызовов (вызовов библиотечных функций операционной системы) с использованием заранее написанной библиотеки функций аналогичного назначения.
Примером прикладных сред в Windows NT являются подси- стемы для исполнения Win32 приложений, консольных приложений
OS/2 и Unix, шестнадцатиразрядных DOS и Win16 приложений.
27
Среда исполнения языка Java, как основной механизм переносимо- сти программ, использует программную эмуляцию архитектуры
Java, которая может быть реализована полностью на аппаратном уровне. Для запуска Win32(64) приложений на Linux используется программная среда Wine. Среда Cygwin, наоборот, представляет со- бой инструмент для переноса программ UNIX в Windows и является библиотекой, которая реализует интерфейс к системным вызовам
Win32.
Средствами обеспечения совместимости на уровне исходных кодов являются стандартизированный язык высокого уровня и стан- дартизированные интерфейсы системных вызовов. Примером стан- дартизированного процедурного языка программирования является
Си (новый стандарт для языка ISO/IEC 9899:2011 вышел 19 декабря
2011 года). Наиболее известным набором стандартов, описывающих интерфейсы между операционной системой и прикладной програм- мой, является POSIX (Portable Operating System Interface for Unix – переносимый интерфейс операционных систем Unix). Стандарт со- здан для обеспечения совместимости различных UNIX-подобных операционных систем и переносимости прикладных программ на уровне исходного кода. Использование стандарта POSIX (IEEE Std
1003.1-2004, ISO/IEC 9945) позволяет создавать программы в стиле
UNIX, которые могут легко переноситься из одной вычислительной системы в другую.
Для семейства операционных систем, основанных на Linux, имеется стандарт совместимости LSB (Linux Standard Base). LSB специфицирует: стандартные библиотеки, несколько команд и ути- лит в дополнение к стандарту POSIX, структуру иерархии файловой системы, уровни запуска и различные расширения системы X
Window System.
Безопасность. Операционная система должна обладать сред- ствами защиты. Правила безопасности определяют способы защиты ресурсов пользователя и устанавливают квоты по ресурсам для предотвращения захвата пользователем всех системных ресурсов
(например, памяти).
Основы безопасности были заложены стандартом «Критерии оценки надежных компьютерных систем» (Department of De- fenseTrusted Computer System Evaluation Criteria, TCSEC, DoD
5200.28-STD, 26 декабря 1985 года). Этот документ часто называют
28
«Оранжевой книгой». Аналогом «Оранжевой книги» является меж- дународный стандарт ISO/IEC 15408, опубликованный в 2005 году.
В соответствии с требованиями «Оранжевой книги» безопас- ной считается такая система, которая «посредством специальных механизмов защиты контролирует доступ к информации таким об- разом, что только имеющие соответствующие полномочия лица или процессы, выполняющиеся от их имени, могут получить доступ на чтение, запись, создание или удаление информации».
Иерархия уровней безопасности, приведенная в «Оранжевой книге», выделяет четыре уровня (D, С, B, A) и 6 классов безопасно- сти внутри уровней (C1, C2, B1, B2, B3, A1). В уровень D попадают системы, оценка которых выявила их несоответствие требованиям безопасности. Уровень C обеспечивает произвольное управление доступом; уровень B – принудительное управление доступом; уро- вень A – верифицируемую безопасность. В каждом классе от C1 к
A1 требования по безопасности расширяются.
Коммерческие системы обычно соответствуют уровню C. Вот некоторые требования безопасности этого уровня: 1) наличие защи- щенных средств секретного входа, обеспечивающих идентифика- цию пользователя путем ввода логина и пароля; 2) избирательный
(дискреционный) контроль доступа, позволяющий владельцу ресур- са определить, кто имеет доступ к ресурсу и что он может с ним де- лать путем предоставляемых прав доступа пользователю или группе пользователей; 3) средства учета и наблюдения, обеспечивающие возможность обнаружить и зафиксировать важные события, связан- ные с безопасностью: любые попытки создать, получить доступ и удалить системные ресурсы; 4) защита памяти, обеспечивающая инициализацию перед повторным использованием.
Системы уровня B реализуют мандатный (принудительный) контроль доступа. Каждому пользователю присваивается рейтинг защиты и он может получать доступ к данным только в соответ- ствии с этим рейтингом. Этот уровень, в отличие от уровня C, обес- печивает централизованное управление потоками данных в системе и защищает систему от ошибочного поведения пользователя.
Однако существует проблема, впервые описанная Батлером
Лэмпсоном в 1973 году, известная как «скрытый канал» или про- блема ограждения. Лэмпсон показал, что в защищенной системе
29 возможны неконтролируемые принудительной системой безопасно- сти потоки информации. Определяют два вида скрытых каналов.
Скрытый канал памяти. Процессы взаимодействуют благода- ря тому, что один может прямо или косвенно записывать информа- цию в некоторую область памяти, а второй считывать. Обычно име- ется в виду, что у процессов с разными уровнями безопасности име- ется доступ к некоторому ресурсу (например, возможность прове- рить наличие файла).
Скрытый канал времени. Один процесс посылает информа- цию другому, модулируя своё собственное использование систем- ных ресурсов (например, процессорное время) таким образом, что эта операция воздействует на реальное время отклика, наблюдаемое вторым процессом.
Критерии «Оранжевой книги» требуют, чтобы анализ скрытых каналов памяти был классифицирован как требование для системы класса B2, а анализ скрытых каналов времени как требование для класса B3.
Уровень A является самым высоким уровнем безопасности, он требует в дополнение ко всем требованиям уровня B выполнения формального (математически обоснованного) доказательства соот- ветствия системы требованиям безопасности.
Производительность. Система должна обладать настолько хорошим быстродействием и временем реакции, насколько это поз- воляет аппаратная платформа. На практике удовлетворение рас- смотренных выше требований к операционным системам, особенно по надежности и безопасности, приводит к большому потреблению системных ресурсов на функционирование самой операционной си- стемы. Снижение ресурсных требований и повышение производи- тельности является нетривиальной исследовательской задачей при проектировании новых операционных систем.
Лекция 4. Архитектуры операционных систем
Монолитные системы: модульные и многоуровневые. Клиент- серверные архитектуры: микроядерные и гибридные. Объектно-
30 ориентированные архитектуры. Виртуальные машины: гипервизо- ры, экзоядра, наноядра.
Монолитные система – классическая, наиболее распростра- нённая архитектура ядероперационных систем. Все части монолит- ного ядра работают в одном адресном пространстве (рис.4.1).
Рис. 4.1. Монолитная операционная система
При использовании этой технологии код ядра операционной системы состоит из процедур. Каждая процедура системы имеет определённый интерфейс и может вызывать любую другую проце- дуру, а также обращаться непосредственно к аппаратуре. Код ядра выполняется в режиме супервизора.
Рис. 4.2. Структура ядра монолитной системы
Аппаратура
Процедуры опе- рационной систе- мы
Системный интерфейс
Главная программа
Сервисные про- цедуры
Утилиты (работающие непосред- ственно с аппаратурой)
31
Обычно процедуры операционной системы разделяют на главную программу, сервисные процедуры и утилиты (рис.4.2). Вза- имодействие кода пользователя с операционной системой происхо- дит посредством системных вызовов. В отличие от обычных вызо- вов подпрограмм, в системном вызове происходит передача управ- ления и данных между кодом режима пользователя и кодом режима супервизора (ядра). При обращении к системным вызовам главная программа помещает параметры вызова в строго определённое ме- сто (регистры, стек) и переключает машину из режима пользователя в режим ядра (например, вызывая специальные программные пре- рывания).
В режиме ядра по сформированному коду системного вызова вычисляется адрес сервисной процедуры в пространстве ядра и вы- полняется вызов. У каждого системного вызова имеется своя сер- висная процедура, а утилиты выполняют функции, нужные несколь- ким сервисным процедурам.
В классической монолитной архитектуре все процедуры опе- рационной системы собраны в один объектный файл. Модульное
ядро – современная, усовершенствованная модификация архитекту- ры монолитных ядер, в которой код ядра разделяется на отдельно компилируемые и загружаемые модули.
Модульные ядра предоставляют механизм загрузки модулей ядра, поддерживающих аппаратное обеспечение (например, драйве- ров). Загрузка модулей может быть как динамической (без переза- грузки операционной системы), так и статической (выполняемой при перезагрузке). Большинство современных ядер, такие как
OpenVMS, Linux, FreeBSD, NetBSD и Solaris, позволяют во время работы динамически (по необходимости) подгружать и выгружать модули, выполняющие часть функций ядра.
Модули ядра работают в адресном пространстве ядра и могут пользоваться всеми функциями, предоставляемыми ядром. Поэтому модульные ядра продолжают оставаться монолитными. Модуль- ность ядра осуществляется на уровне бинарного образа, а не на ар- хитектурном уровне ядра, так как динамически подгружаемые мо- дули загружаются в адресное пространство ядра и в дальнейшем ра- ботают как его часть.
Имеется вариант монолитной архитектуры, когда код ядра операционной системы строится как иерархия уровней. Такая архи-
32 тектура ядра называется многоуровневой. Уровни образуются груп- пами функций, каждый уровень взаимодействует только со своими непосредственными соседями через строго определенные интерфей- сы. Многоуровневая архитектура была предложена Эдсгером
Дейкстра в проекте пакетной системы THE в 1968 году.
В системе THE функции ядра распределялись по уровням сле- дующим образом. Уровень 0 занимался распределением времени процессора, реализуя базовую многозадачность. Уровень 1 осу- ществлял управление памятью через механизм виртуальной памяти.
Уровень 2 отвечал за связь между консолью оператора и процесса- ми. Уровень 3 управлял буферизацией и взаимодействием с устрой- ствами ввода-вывода. На уровне 4 работали программы пользовате- ля. Уровень 5 – это пользователь системы.
Многоуровневая архитектура операционной системы THE, в основном, служила средством разработки. Однако каждый уровень может быть наделён привилегиями и выполнять системный вызов с контролем параметров для обращения к другому уровню. В данной архитектуре уровни называются кольцами защиты. Многоуровневая архитектура с кольцами защиты была реализована в операционной системе Multics.
Проблемой многоуровневой архитектуры является множе- ственность и размытость интерфейсов между слоями, так как слож- но выполнить однозначную группировку функций по уровням. Ос- новной проблемой монолитной архитектуры является низкая надеж- ность. Она вызвана большим объемом критического к сбою кода, который сложно сопровождать. Также из-за того, что весь код рабо- тает в общем адресном пространстве, ошибка в одной из процедур может привести к повреждению разделяемых всеми процедурами данных и выходу системы из строя. Подобная ситуация может быть и при злонамеренном повреждении кода через модифицированные злоумышленниками подгружаемые модули ядра.
Монолитная архитектура, между тем, имеет преимущества с точки зрения удобства организации взаимодействия между частями операционной системы. Оно организуется проще, так как может ис- пользовать глобальные структуры данных системы. По этой же при- чине и по причине отсутствия переключения режима процессора
операционных систем
Лекция 3. Требования к операционным системам
и обзор подходов их реализации
Обзор требований, предъявляемых к операционным системам: расширяемость, переносимость, надежность и отказоустойчивость, совместимость, безопасность, производительность операционных систем.
Операционная система выполняет связующую роль между оборудованием и прикладными программами. Она является важ- нейшим элементом программной инфраструктуры, от свойств кото- рой зависит качество работы прикладного программного обеспече- ния. Поэтому при проектировании операционных систем уделяют внимание специальным функциональным требованиям – более ши- роким, чем при проектировании прикладных программ.
Расширяемость. Код операционной системы должен быть написан таким образом, чтобы при необходимости можно было легко внести дополнения и изменения, не нарушая целостности системы.
Во времена первых компьютеров считалось, что по мере об- новления аппаратного обеспечения код операционных систем будет создаваться заново, с нуля. Однако практика показала, что разработ- ка программного обеспечения значительно более трудоемка, чем разработка аппаратуры. Возникла необходимость защиты инвести- ций как в разработку операционной системы, так и в прикладные программы, функционирующие под ее управлением.
В то время как аппаратная часть компьютера устаревает за не- сколько лет, полезная жизнь операционной системы может изме-
24 ряться десятилетиями (Unix). Аппаратные изменения, к которым должна быть, в первую очередь, адаптирована архитектура операци- онных систем, связаны с развитием периферийного оборудования.
Например, современные модификации в операционных системах связаны с новыми технологиями хранения данных (накопители
SSD), сетевого взаимодействия (беспроводные сети, оптические ка- налы высокой пропускной способности), новыми пользовательски- ми интерфейсами (жестовый ввод, голосовой ввод, сенсорные пане- ли). Сохранение целостности кода операционной системы, учиты- вая, что происходит постоянная модернизация аппаратуры, является одной из целей проектирования операционной системы.
Расширяемость может достигаться за счет модульной структу- ры операционной системы, при которой ее части состоят из сильно связанных внутри и слабо связанных между собой модулей. Взаи- модействие между модулями организуется через стандартизирован- ные интерфейсы. Новые компоненты, добавляемые в операционную систему, функционируют, используя интерфейсы, поддерживаемые существующими компонентами. Можно заменить код устаревших модулей, не затрагивая работоспособность системы в целом.
Использование объектов для представления системных ресур- сов также улучшает расширяемость системы. Объекты позволяют единообразно управлять системными ресурсами. Добавление новых объектов не разрушает существующие объекты и не требует изме- нений существующего кода.
Вариантом модульной организации является применение ар- хитектуры клиент-сервер и микроядра. В ней модули изолированы в отдельных процессах и могут замещаться даже без перекомпиляции и остановки вычислений.
Другой возможностью расширить функциональные возможно- сти операционной системы являются средства вызова удаленных процедур (RPC), которые могут добавляться в любую машину сети и немедленно поступать в распоряжение прикладных программ на других машинах сети.
Некоторые операционные системы для улучшения расширяе- мости поддерживают загружаемые драйверы, которые добавляются в систему во время ее работы. Новые файловые системы, устройства и сети могут поддерживаться путем написания драйвера устройства,
25 драйвера файловой системы или транспортного драйвера и загрузки его в систему.
Переносимость. Код операционной системы должен легко пе- реноситься между процессорами и аппаратными платформами раз- личной архитектуры. Аппаратная платформа включает наряду с ти- пом процессора и способ организации всей аппаратуры компьютера.
Расширяемость позволяет улучшать операционную систему по мере обновления периферийного оборудования. Переносимость дает возможность перемещать всю систему целиком на машину, базиру- ющуюся на обновленном процессоре или аппаратной платформе, делая при этом по возможности небольшие изменения в коде. Опе- рационные системы разрабатываются либо как переносимые, либо как непереносимые. Ключевым моментом в оценке переносимости является стоимость необходимых изменений.
При написании переносимой операционной системы нужно следовать перечисленным ниже правилам.
Большая часть кода должна быть написана на языке высокого уровня, например, как Unix на языке Си. Код, написанный на Ас- семблере, не является переносимым, если только он не переносится на машину, обладающую командной совместимостью с исходной машиной.
Необходимо учитывать аппаратную платформу, на которую операционная система должна быть перенесена. Например, система, построенная на 32-битовых адресах, не может быть перенесена на машину с 16-битовыми адресами.
Следует минимизировать или по возможности исключить ча- сти кода, которые непосредственно взаимодействуют с аппаратурой.
Оставшийся после такой оптимизации аппаратно-зависимый код, который не может быть исключен, локализуется в отдельных моду- лях (HAL – hardware abstraction layer). Очевидные формы зависимо- сти от аппаратуры включают прямое манипулирование регистрами процессора, аппаратно-зависимыми структурами данных (контекст процесса, дескрипторы страниц и сегментов), обращение к контрол- лерам периферийного оборудования.
Надежность и отказоустойчивость. Система должна быть защищена от отказов оборудования и внутренних ошибок. Действия операционной системы должны быть предсказуемыми. Прикладные процессы не должны иметь возможность наносить вред как самой
26 операционной системе, так и другим процессам. Надежность обес- печивается применением микроядерной архитектуры.
Совместимость. Операционная система должна иметь сред- ства для выполнения прикладных программ, написанных для других операционных систем или для более ранних версий данной опера- ционной системы. Пользовательский интерфейс должен быть совме- стим с существующими системами и стандартами. Совместимость операционных систем рассматривается на двух уровнях как двоич- ная совместимость и совместимость по исходным кодам.
Двоичная совместимость достигается совместимостью на уровне команд процессора, системных вызовов и на уровне библио- течных вызовов, если они являются динамически связываемыми.
Совместимость по исходным кодам требует наличия соответ- ствующего компилятора в составе программного обеспечения, а также совместимости на уровне библиотек и системных вызовов, при этом необходима перекомпиляция.
Совместимость на уровне исходных текстов важна для разра- ботчиков приложений. Для конечных пользователей практическое значение имеет только двоичная совместимость, благодаря которой один и тот же коммерческий продукт можно использовать в различ- ных операционных средах и на различных машинах. Совместимость зависит от многих факторов, самый важный фактор – архитектура процессора. Если процессор, на который переносится операционная система, использует аналогичный набор команд и тот же диапазон адресов, двоичная совместимость может быть достигнута достаточ- но просто.
Двоичная совместимость между процессорами, основанными на разных архитектурах, требует написания специальных эмулято- ров и использования прикладных сред. Для исполнения кода в гос- тевой операционной системе требуется: процедура загрузки, адапти- рованная под формат исполняемого файла; интерпретация команд целевого процессора на гостевом процессоре (если процессорные архитектуры различаются); имитация системных вызовов (вызовов библиотечных функций операционной системы) с использованием заранее написанной библиотеки функций аналогичного назначения.
Примером прикладных сред в Windows NT являются подси- стемы для исполнения Win32 приложений, консольных приложений
OS/2 и Unix, шестнадцатиразрядных DOS и Win16 приложений.
27
Среда исполнения языка Java, как основной механизм переносимо- сти программ, использует программную эмуляцию архитектуры
Java, которая может быть реализована полностью на аппаратном уровне. Для запуска Win32(64) приложений на Linux используется программная среда Wine. Среда Cygwin, наоборот, представляет со- бой инструмент для переноса программ UNIX в Windows и является библиотекой, которая реализует интерфейс к системным вызовам
Win32.
Средствами обеспечения совместимости на уровне исходных кодов являются стандартизированный язык высокого уровня и стан- дартизированные интерфейсы системных вызовов. Примером стан- дартизированного процедурного языка программирования является
Си (новый стандарт для языка ISO/IEC 9899:2011 вышел 19 декабря
2011 года). Наиболее известным набором стандартов, описывающих интерфейсы между операционной системой и прикладной програм- мой, является POSIX (Portable Operating System Interface for Unix – переносимый интерфейс операционных систем Unix). Стандарт со- здан для обеспечения совместимости различных UNIX-подобных операционных систем и переносимости прикладных программ на уровне исходного кода. Использование стандарта POSIX (IEEE Std
1003.1-2004, ISO/IEC 9945) позволяет создавать программы в стиле
UNIX, которые могут легко переноситься из одной вычислительной системы в другую.
Для семейства операционных систем, основанных на Linux, имеется стандарт совместимости LSB (Linux Standard Base). LSB специфицирует: стандартные библиотеки, несколько команд и ути- лит в дополнение к стандарту POSIX, структуру иерархии файловой системы, уровни запуска и различные расширения системы X
Window System.
Безопасность. Операционная система должна обладать сред- ствами защиты. Правила безопасности определяют способы защиты ресурсов пользователя и устанавливают квоты по ресурсам для предотвращения захвата пользователем всех системных ресурсов
(например, памяти).
Основы безопасности были заложены стандартом «Критерии оценки надежных компьютерных систем» (Department of De- fenseTrusted Computer System Evaluation Criteria, TCSEC, DoD
5200.28-STD, 26 декабря 1985 года). Этот документ часто называют
28
«Оранжевой книгой». Аналогом «Оранжевой книги» является меж- дународный стандарт ISO/IEC 15408, опубликованный в 2005 году.
В соответствии с требованиями «Оранжевой книги» безопас- ной считается такая система, которая «посредством специальных механизмов защиты контролирует доступ к информации таким об- разом, что только имеющие соответствующие полномочия лица или процессы, выполняющиеся от их имени, могут получить доступ на чтение, запись, создание или удаление информации».
Иерархия уровней безопасности, приведенная в «Оранжевой книге», выделяет четыре уровня (D, С, B, A) и 6 классов безопасно- сти внутри уровней (C1, C2, B1, B2, B3, A1). В уровень D попадают системы, оценка которых выявила их несоответствие требованиям безопасности. Уровень C обеспечивает произвольное управление доступом; уровень B – принудительное управление доступом; уро- вень A – верифицируемую безопасность. В каждом классе от C1 к
A1 требования по безопасности расширяются.
Коммерческие системы обычно соответствуют уровню C. Вот некоторые требования безопасности этого уровня: 1) наличие защи- щенных средств секретного входа, обеспечивающих идентифика- цию пользователя путем ввода логина и пароля; 2) избирательный
(дискреционный) контроль доступа, позволяющий владельцу ресур- са определить, кто имеет доступ к ресурсу и что он может с ним де- лать путем предоставляемых прав доступа пользователю или группе пользователей; 3) средства учета и наблюдения, обеспечивающие возможность обнаружить и зафиксировать важные события, связан- ные с безопасностью: любые попытки создать, получить доступ и удалить системные ресурсы; 4) защита памяти, обеспечивающая инициализацию перед повторным использованием.
Системы уровня B реализуют мандатный (принудительный) контроль доступа. Каждому пользователю присваивается рейтинг защиты и он может получать доступ к данным только в соответ- ствии с этим рейтингом. Этот уровень, в отличие от уровня C, обес- печивает централизованное управление потоками данных в системе и защищает систему от ошибочного поведения пользователя.
Однако существует проблема, впервые описанная Батлером
Лэмпсоном в 1973 году, известная как «скрытый канал» или про- блема ограждения. Лэмпсон показал, что в защищенной системе
29 возможны неконтролируемые принудительной системой безопасно- сти потоки информации. Определяют два вида скрытых каналов.
Скрытый канал памяти. Процессы взаимодействуют благода- ря тому, что один может прямо или косвенно записывать информа- цию в некоторую область памяти, а второй считывать. Обычно име- ется в виду, что у процессов с разными уровнями безопасности име- ется доступ к некоторому ресурсу (например, возможность прове- рить наличие файла).
Скрытый канал времени. Один процесс посылает информа- цию другому, модулируя своё собственное использование систем- ных ресурсов (например, процессорное время) таким образом, что эта операция воздействует на реальное время отклика, наблюдаемое вторым процессом.
Критерии «Оранжевой книги» требуют, чтобы анализ скрытых каналов памяти был классифицирован как требование для системы класса B2, а анализ скрытых каналов времени как требование для класса B3.
Уровень A является самым высоким уровнем безопасности, он требует в дополнение ко всем требованиям уровня B выполнения формального (математически обоснованного) доказательства соот- ветствия системы требованиям безопасности.
Производительность. Система должна обладать настолько хорошим быстродействием и временем реакции, насколько это поз- воляет аппаратная платформа. На практике удовлетворение рас- смотренных выше требований к операционным системам, особенно по надежности и безопасности, приводит к большому потреблению системных ресурсов на функционирование самой операционной си- стемы. Снижение ресурсных требований и повышение производи- тельности является нетривиальной исследовательской задачей при проектировании новых операционных систем.
Лекция 4. Архитектуры операционных систем
Монолитные системы: модульные и многоуровневые. Клиент- серверные архитектуры: микроядерные и гибридные. Объектно-
30 ориентированные архитектуры. Виртуальные машины: гипервизо- ры, экзоядра, наноядра.
Монолитные система – классическая, наиболее распростра- нённая архитектура ядероперационных систем. Все части монолит- ного ядра работают в одном адресном пространстве (рис.4.1).
Рис. 4.1. Монолитная операционная система
При использовании этой технологии код ядра операционной системы состоит из процедур. Каждая процедура системы имеет определённый интерфейс и может вызывать любую другую проце- дуру, а также обращаться непосредственно к аппаратуре. Код ядра выполняется в режиме супервизора.
Рис. 4.2. Структура ядра монолитной системы
Аппаратура
Процедуры опе- рационной систе- мы
Системный интерфейс
Главная программа
Сервисные про- цедуры
Утилиты (работающие непосред- ственно с аппаратурой)
31
Обычно процедуры операционной системы разделяют на главную программу, сервисные процедуры и утилиты (рис.4.2). Вза- имодействие кода пользователя с операционной системой происхо- дит посредством системных вызовов. В отличие от обычных вызо- вов подпрограмм, в системном вызове происходит передача управ- ления и данных между кодом режима пользователя и кодом режима супервизора (ядра). При обращении к системным вызовам главная программа помещает параметры вызова в строго определённое ме- сто (регистры, стек) и переключает машину из режима пользователя в режим ядра (например, вызывая специальные программные пре- рывания).
В режиме ядра по сформированному коду системного вызова вычисляется адрес сервисной процедуры в пространстве ядра и вы- полняется вызов. У каждого системного вызова имеется своя сер- висная процедура, а утилиты выполняют функции, нужные несколь- ким сервисным процедурам.
В классической монолитной архитектуре все процедуры опе- рационной системы собраны в один объектный файл. Модульное
ядро – современная, усовершенствованная модификация архитекту- ры монолитных ядер, в которой код ядра разделяется на отдельно компилируемые и загружаемые модули.
Модульные ядра предоставляют механизм загрузки модулей ядра, поддерживающих аппаратное обеспечение (например, драйве- ров). Загрузка модулей может быть как динамической (без переза- грузки операционной системы), так и статической (выполняемой при перезагрузке). Большинство современных ядер, такие как
OpenVMS, Linux, FreeBSD, NetBSD и Solaris, позволяют во время работы динамически (по необходимости) подгружать и выгружать модули, выполняющие часть функций ядра.
Модули ядра работают в адресном пространстве ядра и могут пользоваться всеми функциями, предоставляемыми ядром. Поэтому модульные ядра продолжают оставаться монолитными. Модуль- ность ядра осуществляется на уровне бинарного образа, а не на ар- хитектурном уровне ядра, так как динамически подгружаемые мо- дули загружаются в адресное пространство ядра и в дальнейшем ра- ботают как его часть.
Имеется вариант монолитной архитектуры, когда код ядра операционной системы строится как иерархия уровней. Такая архи-
32 тектура ядра называется многоуровневой. Уровни образуются груп- пами функций, каждый уровень взаимодействует только со своими непосредственными соседями через строго определенные интерфей- сы. Многоуровневая архитектура была предложена Эдсгером
Дейкстра в проекте пакетной системы THE в 1968 году.
В системе THE функции ядра распределялись по уровням сле- дующим образом. Уровень 0 занимался распределением времени процессора, реализуя базовую многозадачность. Уровень 1 осу- ществлял управление памятью через механизм виртуальной памяти.
Уровень 2 отвечал за связь между консолью оператора и процесса- ми. Уровень 3 управлял буферизацией и взаимодействием с устрой- ствами ввода-вывода. На уровне 4 работали программы пользовате- ля. Уровень 5 – это пользователь системы.
Многоуровневая архитектура операционной системы THE, в основном, служила средством разработки. Однако каждый уровень может быть наделён привилегиями и выполнять системный вызов с контролем параметров для обращения к другому уровню. В данной архитектуре уровни называются кольцами защиты. Многоуровневая архитектура с кольцами защиты была реализована в операционной системе Multics.
Проблемой многоуровневой архитектуры является множе- ственность и размытость интерфейсов между слоями, так как слож- но выполнить однозначную группировку функций по уровням. Ос- новной проблемой монолитной архитектуры является низкая надеж- ность. Она вызвана большим объемом критического к сбою кода, который сложно сопровождать. Также из-за того, что весь код рабо- тает в общем адресном пространстве, ошибка в одной из процедур может привести к повреждению разделяемых всеми процедурами данных и выходу системы из строя. Подобная ситуация может быть и при злонамеренном повреждении кода через модифицированные злоумышленниками подгружаемые модули ядра.
Монолитная архитектура, между тем, имеет преимущества с точки зрения удобства организации взаимодействия между частями операционной системы. Оно организуется проще, так как может ис- пользовать глобальные структуры данных системы. По этой же при- чине и по причине отсутствия переключения режима процессора