Файл: А. В. Гордеев А. Ю. Молчанов системное программное обеспечение электронный вариант книги издательства Питер СанктПетербург Челябинск юургу каф. Автоматика и управление 2002 2 Предисловие Настоящий учебник.pdf

248
к информации таким образом, что только имеющие соответствующие полномочия лица или процессы, выполняющиеся от их имени, могут получить доступ на чте- ние, запись, создание или удаление информации».
Иерархия уровней безопасности, приведенная в Оранжевой книге, помечает низший уровень безопасности как D, а высший – как А.
В класс D попадают системы, оценка которых выявила их несоответствие тре- бованиям всех других классов.
Основными свойствами, характерными для систем класса С, являются наличие подсистемы учёта событий, связанных с безопасностью, и избирательный контроль доступа. Класс (уровень) С делится на 2 подуровня: уровень С1, обеспечивающий защиту данных от ошибок пользователей, но не от действий злоумышленников; и более строгий уровень С2. На уровне С2 должны присутствовать:
♦ средства секретного входа, обеспечивающие идентификацию пользователей путём ввода уникального имени и пароля перед тем, как им будет разрешен доступ к системе;
♦ избирательный контроль доступа, позволяющий владельцу ресурса опреде- лить, кто имеет доступ к ресурсу и что он может с ним делать. Владелец делает это путём предоставляемых прав доступа пользователю или группе пользователей;
♦ средства учёта и наблюдения (auditing), обеспечивающие возможность об- наружить и зафиксировать важные события, связанные с безопасностью, или лю- бые попытки создать, получить доступ или удалить системные ресурсы;
♦ защита памяти, заключающаяся в том, что память инициализируется перед тем, как повторно используется.
На этом уровне система не защищена от ошибок пользователя, но поведение его может быть проконтролировано по записям в журнале, оставленным средства- ми наблюдения и аудита.
Системы уровня В основаны на помеченных данных и распределении пользо- вателей по категориям, то есть реализуют мандатный контроль доступа. Каждому пользователю присваивается рейтинг защиты, и он может получать доступ к дан-

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

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

251
серверами. В результате микроядро обеспечивает только пять различных типов сервисов:
♦ управление виртуальной памятью;
♦ задания и потоки;
♦ межпроцессные коммуникации (IPC
1
);
♦ управление поддержкой ввода/вывода и прерываниями;
♦ сервисы набора хоста
1
и процессора.
Другие подсистемы и функции операционной системы, такие как системы управления файлами, поддержка внешних устройств и традиционные программные интерфейсы, размещаются в одном или более системных сервисах либо в задаче операционной системы. Эти программы работают как приложения микроядра.
Следуя концепции множественных потоков на одно задание, микроядро соз- даёт прикладную среду, обеспечивающую использование мультипроцессоров без требования, чтобы какая-то конкретная машина была мультипроцессорной: на од- нопроцессорной различные потоки просто выполняются в разные времена. Вся поддержка, требуемая для мультипроцессорных машин, сконцентрирована в срав- нительно малом и простом микроядре.
Благодаря своим размерам и способности поддерживать стандартные сервисы программирования и характеристики в виде прикладных программ сами микроядра проще, чем ядра монолитных или модульных операционных систем. С микроядром функция операционной системы разбивается на модульные части, которые могут быть сконфигурированы целым рядом способов, позволяя строить большие систе- мы добавлением частей к меньшим. Например, каждый аппаратно-независимый нейтральный сервис логически отделён и может быть сконфигурирован в широком диапазоне способов. Микроядра также облегчают поддержку мультипроцессоров созданием стандартной программной среды, которая может использовать множест- венные процессоры в случае их наличия, однако не требует их, если их нет. Спе- циализированный код для мультипроцессоров ограничен самим микроядром. Более того, сети из общающихся между собой микроядер могут быть использованы для
1
IPC (inter-process communication) – межпроцессные коммуникации.

252
обеспечения операционной системной поддержки возникающего класса массивно параллельных машин. В некоторых случаях определенной сложностью использо- вания микроядерного подхода на практике является замедление скорости выполне- ния системных вызовов при передаче сообщений через микроядро по сравнению с классическим подходом. С другой стороны, можно констатировать и обратное. По- скольку микроядра малы и имеют сравнительно мало требуемого к исполнению кода уровня ядра, они обеспечивают удобный способ поддержки характеристик ре- ального времени, требующихся для мультимедиа, управления устройствами и вы- сокоскоростных коммуникаций. Наконец, хорошо структурированные микроядра обеспечивают изолирующий слой для аппаратных различий, которые не маскиру- ются применением языков программирования высокого уровня. Таким образом,
они упрощают перенесение кода и увеличивают уровень его повторного использо- вания.
Наиболее ярким представителем микроядерных ОС является ОС реального времени QNX. Микроядро QNX поддерживает только планирование и диспетчери- зацию процессов, взаимодействие процессов, обработку прерываний и сетевые службы нижнего уровня (более подробно об ОС QNX см. в главе 8). Микроядро обеспечивает всего лишь пару десятков системных вызовов, но благодаря этому оно может быть целиком размещено во внутреннем кэше даже таких процессоров,
как Intel 486. Как известно, разные версии этой ОС имели и различные объемы ядер – от 8 до 46 Кбайт.
Чтобы построить минимальную систему QNX, требуется добавить к микрояд- ру менеджер процессов, который создаёт процессы, управляет процессами и памя- тью процессов. Чтобы ОС QNX была применима не только во встроенных и без- дисковых системах, нужно добавить файловую систему и менеджер устройств. Эти менеджеры исполняются вне пространства ядра, так что ядро остаётся небольшим.
1
Host – главный компьютер. Сейчас этим термином обозначают любой компьютер, имеющий IP-адрес.

253
Монолитные операционные системы
Монолитные ОС являются прямой противоположностью микроядерным ОС.
При этом можно согласиться с тем, как трактуется архитектура монолитных ОС в работе [54]. В монолитной ОС, несмотря на её возможную сильную структуриза- цию, очень трудно удалить один из уровней многоуровневой модульной структу- ры. Добавление новых функций и изменение существующих для монолитных ОС
требует очень хорошего знания всей архитектуры ОС и чрезвычайно больших уси- лий. Поэтому более современный подход к проектированию ОС, который может быть условно назван как «клиент-серверная» технология, позволяет в большей ме- ре и с меньшими трудозатратами реализовать перечисленные выше принципы про- ектирования ОС.
Модель клиент–сервер предполагает наличие программного компонента, яв- ляющегося потребителем какого-либо сервиса – клиента, и программного компо- нента, служащего поставщиком этого сервиса – сервера. Взаимодействие между клиентом и сервером стандартизируется, так что сервер может обслуживать клиен- тов, реализованных различными способами и, может быть, разными разработчика- ми. При этом главным требованием является использование единообразного ин- терфейса. Инициатором обмена обычно является клиент, который посылает запрос на обслуживание серверу, находящемуся в состоянии ожидания запроса. Один и тот же программный компонент может быть клиентом по отношению к одному ви- ду услуг и сервером для другого вида услуг. Модель клиент–сервер является ско- рее удобным концептуальным средством ясного представления функций того или иного программного элемента в какой-либо ситуации, нежели технологией. Эта модель успешно применяется не только при построении ОС, но и на всех уровнях программного обеспечения и имеет в некоторых случаях более узкий, специфиче- ский смысл, сохраняя, естественно, при этом все свои общие черты.
При поддержке монолитных ОС возникает ряд проблем, связанных с тем, что все функции макроядра работают в едином адресном пространстве. Во-первых, это опасность возникновения конфликта между различными частями ядра; во-вторых –
сложность подключения к ядру новых драйверов. Преимущество микроядерной

254
архитектуры перед монолитной заключается в том, что каждый компонент системы представляет собой самостоятельный процесс, запуск или остановка которого не отражается на работоспособности остальных процессов.
Микроядерные ОС в настоящее время разрабатываются чаще монолитных.
Однако следует заметить, что использование технологии клиент–сервер – это ещё
не гарантия того, что ОС станет микроядерной. В качестве подтверждения можно привести пример с ОС Windows NT, которая построена на идеологии клиент–сер- вер, но которую тем не менее трудно назвать микроядерной. Для того чтобы согла- ситься с таким высказыванием, достаточно сравнить ОС QNX и ОС Windows NT.
Требования, предъявляемые к ОС реального времени
Как известно, система реального времени (СРВ) должна давать отклик на лю- бые непредсказуемые внешние воздействия в течение предсказуемого интервала времени. Для этого должны быть обеспечены следующие свойства:
♦ Ограничение времени отклика, то есть после наступления события реакция на него гарантированно последует до предустановленного крайнего срока. Отсут- ствие такого ограничения рассматривается как серьезный недостаток программно- го обеспечения.
♦ Одновременность обработки: даже если наступает более одного события одновременно, все временные ограничения для всех событий должны быть выдер- жаны. Это означает, что системе реального времени должен быть присущ паралле- лизм. Параллелизм достигается использованием нескольких процессоров в системе и/или многозадачного подхода.
Примерами систем реального времени являются системы управления атомны- ми электростанциями или какими-нибудь технологическими процессами, меди- цинского мониторинга, управления вооружением, космической навигации, развед- ки, управления лабораторными экспериментами, управления автомобильными дви- гателями, робототехника, телеметрические системы управления, системы антибло- кировки тормозов, системы сигнализации – список в принципе бесконечен.

255
Иногда можно услышать из разговоров специалистов, что различают системы
«мягкого» и «жёсткого» реального времени. Различие между жёсткой и мягкой
СРВ зависит от требований к системе – система считается жёсткой, если «наруше- ние временных ограничений не допустимо», и мягкой, если «нарушение времен- ных ограничений нежелательно». Ведётся множество дискуссий о точном смысле терминов «жёсткая» и «мягкая» СРВ. Можно даже аргументировать, что мягкая
СРВ не является СРВ вовсе, ибо основное требование соблюдения временных ог- раничений не выполнено. В действительности термин СРВ часто неправомерно применяют по отношению к быстрым системам.
Часто путают понятия СРВ и ОСРВ
1
, а также неправильно используют атри- буты «мягкая» и «жёсткая». Иногда говорят, что та или иная ОСРВ мягкая или жё- сткая. Нет мягких или жёстких ОСРВ. ОСРВ может только служить основой для построения мягкой или жёсткой СРВ. Сама по себе ОСРВ не препятствует тому,
что ваша СРВ будет мягкой. Например, вы решили создать СРВ, которая должна работать через Ethernet по протоколу TCP/IP. Такая система не может быть жёст- кой СРВ, поскольку сама сеть Ethernet в принципе непредсказуема вследствие ис- пользования случайного метода доступа к среде передачи данных, в отличие, на- пример, от IBM Token Ring или ARC-Net, в которых используются детерминиро- ванные методы доступа.
Итак, перечислим основные требования к ОСРВ.

256 1000 MHz бесполезна для ОСРВ, ибо одно приложение может захватить управле- ние и заблокировать систему для остальных.
Первое требование состоит в том, что ОС должна быть многопоточной по принципу абсолютного приоритета (прерываемой). То есть планировщик должен иметь возможность прервать любой поток и предоставить ресурс тому потоку, ко- торому он более необходим. ОС (и аппаратура) должны также обеспечивать пре- рывания на уровне обработки прерываний.
Приоритеты задач (потоков)
Требование 2. В ОС должно существовать понятие приоритета потока. Про- блема в том, чтобы определить, какой задаче ресурс требуется более всего. В иде- альной ситуации ОСРВ отдаёт ресурс потоку или драйверу с ближайшим крайним сроком (это называется управлением временным ограничением, deadline driven
OS). Чтобы реализовать это временное ограничение, ОС должна знать, сколько времени требуется каждому из выполняющихся потоков для завершения.
ОС, построенных по этому принципу, практически нет, так как он слишком сложен для реализации. Поэтому разработчики ОС принимают иную точку зрения:
вводится понятие уровня приоритета для задачи, и временные ограничения сводят к приоритетам. Так как умозрительные решения чреваты ошибками, показатели
СРВ при этом снижаются. Чтобы более эффективно осуществить указанное преоб- разование ограничений, проектировщик может воспользоваться теорией расписа- ний или имитационным моделированием, хотя и это может оказаться бесполезным.
Тем не менее, так как на сегодняшний день не имеется иного решения, понятие приоритета потока неизбежно.
Наследование приоритетов
Требование 3. В ОС должна существовать система наследования приоритетов.
На самом деле именно этот механизм синхронизации и тот факт, что различ- ные треды используют одно и то же пространство памяти, отличают их от процес- сов, Как мы уже знаем, процессы почти не разделяют одно и то же пространство памяти, а в основном работают в своих локальных адресных пространствах. Так,
например, старые версии UNIX не являются мультитредовыми (multi-threaded).