Операционные системы реального времени

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

     EAL3 определяется, как методически протестированный  и проверенный. На уровне EAL3 осуществляется  более полное, чем на уровне EAL2, тестирование покрытия функций безопасности, а также контроль среды разработки и управление конфигурацией объекта оценки.

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

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

В соответствии с требованиями Общих критериев, продукты определенного класса (например, операционные системы) оцениваются  на соответствие ряду функциональных критериев и критериев доверия  – профилей защиты. Существуют различные  определения профилей защиты в отношении операционных систем, брандмауэров, смарт-карт и прочих продуктов, которые должны соответствовать определенным требованиям в области безопасности. Например, профиль защиты систем с разграничением доступа (Controlled Access Protection Profile) действует в отношении операционных систем и призван заменить старый уровень защиты С2, определявшийся в соответствии с американским стандартом TCSEC. В соответствии с оценочными уровнями доверия сертификация на соответствие более высокому уровню означает более высокую степень уверенности в том, что система защиты продукта работает правильно и эффективно, и, согласно условиям Общих критериев, уровни 5-7 рассчитаны на тестирование продуктов, созданных с применением специализированных технологий безопасности.

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

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

     2. Настраиваемость операционных систем 

     В последнее время одной из главных  тем исследовательских работ в области операционных систем стало исследование настраиваемости (customizability) или адаптируемости операционной системы. Настраиваемой или адаптируемой операционной системой называется операционная система, допускающая гибкую модификацию основных механизмов, стратегий и политик системы. В зависимости от контекста, настраиваемость системы может преследовать различные цели. В операционных системах общего назначения, как правило, такой целью является производительность системы в целом. Для встроенных систем настраиваемость служит целям энергосбережения и/или сокращения объема программного обеспечения.

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

     2.1. Адаптация, осуществляемая человеком 

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

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

2.1.1Статическая адаптация, инициированная проектировщиком 

     В ОС этой категории все системные  функции и политики определяются на этапе проектирования, а все  системные сервисы встроены в ядро. Основное предназначение таких ОС – это специфическая операционная система, возможно даже для единственного приложения. Инициатором адаптации является проектировщик, функциональность и требования хорошо известны и понятны уже на этапе проектирования. Такой подход ведет к обедненным и высокопроизводительным системам, в которых может присутствовать только строго ограниченная функциональность, а все сервисы оптимизируются статически под вполне определенное приложение. Ясно, что новая функциональность и приложения другой категории не могут поддерживаться такой системой. Это значит, что для каждого приложения должна проектироваться и реализовываться новая система, и что один тип устройств или компьютеров будет поддерживать только одно приложение (или ограниченного число приложений) [KLM93]. Появляются каркасы (framework) ОС общего назначения, которые помогают избежать проектирования каждой новой ОС с нуля.

     Flux OSKit – это система, состоящая  из каркаса и библиотечных  модулей [FBB97]. Каркас OSKit представляет собой набор библиотек, из которых компонуется ядро ОС. Все компоненты состоят из модулей. Используются интегрирующие (glue) слои, через которые осуществляется взаимодействие между компонентами и сервисами. Вообще говоря, компоненты скорее обладают крупным уровнем детализации, и являются, в основном, подсистемами, такими как файловая система, стек сетевого протокола или набор драйверов устройств.

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

     Термин  маршрут (path) означает поток данных через систему от источника ввода/вывода к стоку ввода/вывода. Это понятие можно рассматривать как последовательность решений о маршрутизации внутри модульной системы. Маршрут состоит из двух частей – последовательности модулей, которые определяют семантику (надежность, безопасность и согласование по времени), и требований на ресурсы, необходимых для обработки и прохождения данных. Маршруты через граф модулей создаются и разрушаются в динамике. Такое понятие маршрута хорошо подходит для распределения ресурсов и оптимизации производительности, т.к. маршрут обеспечивает нелокальный контекст, который не доступен внутри отдельного модуля.

     В работе Спатчека и Петерсона [SP97] определяется архитектура безопасности, которая  дает возможность проектировщику устанавливать политику безопасности для операционной системы Scout. Эта архитектура безопасности добавляет в Scout также многочисленные домены защиты, которые иначе находились бы в едином адресном пространстве.

     Choices – это объектно-ориентированная,  настраиваемая ОС, в которой для настраиваемости используются каркасная технология и подсистемы [CRJ87, CIR93]. Основное предназначение Choices – обеспечить пользователям возможность простой оптимизации и адаптации системы в соответствии с поведением приложений и рабочей нагрузкой. Система Choices спроектирована как иерархия каркасов, поддерживающих удобную организацию операционной системы по слоям. В Choices каркас состоит из набора классов, представляющих системные сущности, такие как диски, память, планировщики и т.д. Различные подсистемы ОС, такие как управление памятью, управление процессами, файловое запоминающее устройство, управление исключительными ситуациями и т.д. создаются непосредственно из объектно-ориентированных каркасов. Ресурсы системы, механизмы и политики представляются как экземпляры классов, принадлежащих некоей иерархии классов, где настройка осуществляется через использование наследования. Таким образом, специфическая ОС создается путем конкретизации классов и реализации набора объектов, которые вместе формируют данную ОС. Интерфейсом приложения является совокупность объектов ядра, экспортируемых через уровень защиты приложение/ядро.

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

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

     Система PURE (Portable Universal Runtime Executive) является хорошо конфигурируемой системой и предоставляет  средства для подбора требуемой  функциональности [Beu99]. Хотя применение PURE и не ограничено какой-либо областью приложений, все же ее главное предназначение находится в области глубоко встроенных систем. Проектирование PURE основано на двух концепциях – семейства программ и объектно-ориентированного подхода. Концепция семейства программ обеспечивает иерархическую структуру системы, в которой минимальный набор системных функций используется как платформа для реализационных или системных расширений. Объектно-ориентированный подход служит основой для реализации. Минимальным компонентом является класс, т.е. систему PURE можно рассматривать как библиотеку классов. Например, компонент, реализующий управление потоками, состоит из 45 классов, выстроенных в 14-уровневую иерархию.

     Компоненты PURE упорядочиваются в структуру, состоящую из ядер и их расширений. Ядра, так называемые CORE (concurrent runtime executive), отвечают за реализацию минимального набора системных функций, управляющих прерываниями и потоками. Дополнительные возможности, называемые минимальными системными расширениями, добавляются в систему с помощью ядерных расширений, называемых NEXT (Nucleus Extension).

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

     2.1.2. Динамическая адаптация, инициированная администратором 

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

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