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

• Операционные  системы с кэшированием

     Cache Kernel – это ядро операционной системы V++ [CD94]. В этой системе приложения выполняются поверх ядер приложений, либо в том же самом, либо в другом адресном пространстве. Ядра приложений реализуют сервисы операционной системы. Они выполняются на уровне пользователя и обеспечивают загрузку и разгрузку объектов ОС (потоков, адресных пространств и других ядер приложений) в соответствии с их собственными политиками. Собственно ядро Cache Kernel функционирует как кэш для таких объектов. В его интерфейс включены операции для загрузки и разгрузки системных объектов. Для указания того, должен ли некоторый объект быть загружен или разгружен, используются сигналы.  

• Рефлективные  операционные системы:

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

     MetaOS – это объектно-ориентированная  ОС, основанная на использовании языка Java [HPM98]. Архитектура этой ОС состоит из трех уровней. Объекты приложений располагаются на базовом уровне. На уровне ниже находятся мета-объекты, динамически сгруппированные в мета-пространства. Каждое мета-пространство поддерживает ряд приложений с похожими требованиями. Этот уровень носит название мета-уровня. В самом низу находится мета-мета-уровень, который сжат до единственного мета-пространства – главного (master) мета-пространства. Это мета-пространство распределяет ресурсы согласно динамически замещаемой политике. В MetaOS используется открытая реализация для поддержки определения и конструирования объектов, мета-объектов и их интерфейсов. Через эти интерфейсы мета-пространства могут быть адаптированы и расширены динамическим и безопасным образом. Когда приложение начинает выполняться, оно выбирает наиболее подходящее доступное мета-пространство, в котором оно может инициировать ряд изменений с большим уровнем детализации. Если этого окажется недостаточно, приложение может клонировать мета-пространство и мигрировать в него. После этого приложение будет иметь полный контроль над мета-пространством и, таким образом, над собственной средой выполнения.  

     2.2.2. Адаптация на уровне ядра 

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

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

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

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

     При верификации источника код считается безопасным, если он введен в систему удостоверенной стороной (например, администратором). Такая практика применяется в промышленных ОС (UNIX, Windows NT), где такой подход носит название метода загружаемого модуля ядра. Загрузка модуля может выполняться как администратором, так и приложением с правами root, или даже приложениями с правами пользователя, которому разрешена такая загрузка, если он является удостоверенной третьей стороной (например, производитель данной ОС).

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

• Программная защита.

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

• Программная локализация неисправностей.

     Программная локализация неисправностей обеспечивает защиту памяти в едином адресном пространстве (например, внутри ядра) [WLA93]. Она осуществляется в два этапа. Сначала ненадежный код загружается в собственный изолированный домен (так называемый “неисправный” домен), который является областью памяти, логически разделенной с ядром. Затем код модифицируется таким образом, что из него нельзя осуществить запись или выполнить команду перехода за пределы этого изолированного домена. Одним из способов реализации этого подхода является sandboxing (механизм обеспечения безопасности подкачанных из сети или полученных по электронной почте программ, предусматривающий изоляцию на время выполнения загружаемого кода в ограниченную среду – "песочницу"). Изолированный домен состоит из сегмента кода и сегмента данных. В старших битах адреса содержится идентификатор сегмента. Перед каждой ненадежной инструкцией в сегменте кода вставляются инструкции, которые записывают в старшие биты адреса в ненадежной инструкции идентификатор изолированного сегмента, не давая ей возможности обратиться по адресу за пределы этого домена. Взаимодействие между изолированными сегментами осуществляется через RPC-интерфейс (remote procedure calls).

     В системе VINO [SS97] также применяется  программная локализация неисправностей. В этой системе каждое расширение в ядре имеет свои собственные  стек и область памяти. Защиту памяти гарантирует программная локализация  неисправностей. Кроме того, VINO использует систему облегченных транзакций для управления выполнением расширений и использованием ресурсов. Наращиваемость в VINO можно осуществить двумя способами: приложение может заменить реализацию метода некоторого объекта ядра (ресурса), если это разрешено, – это позволяет изменять стандартное поведение ресурсов, приложение может зарегистрировать в ядре обработчик некоего события, такого как подключение в сети к конкретному порту, что позволяет инсталлировать в ядре новые сервисы.

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

• Безопасные  языки

     Другим  распространенным способом сохранения целостности ядра является наложение ограничений на абстракции языка программирования. Наиболее интересным механизмом такого типа является метод проверки типов (type checking), который подразумевает, что безопасные языки являются типизированными и обладают типовой безопасностью.

     Безопасные  языки, широко используемые в исследовательских  проектах, – это Modula-3, Java и ML. Язык ML имеет формальную типовую систему, известную как систему Hindley-Milner, и  дает возможность осуществлять статическую  проверку типов. Языки Modula-3 и Java обладают меньшим формализмом, поэтому, чтобы гарантировать в них политику безопасности, необходимо выполнять многочисленные проверки типов во время выполнения. Однако ML, как декларативный язык, обеспечивает недостаточную эффективность во время выполнения.

     Система SPIN основана на языке Modula-3 [BSP95]. Все  взаимодействия между приложением  и ядром осуществляются с помощью  расширений. Каждое расширение связывается  с событием. Расширение должно быть зарегистрировано диспетчером, который инсталлирует расширения и передает события расширениям. С отдельным событием может быть связано несколько расширений. Расширения замещаются или добавляются диспетчером. Modula-3, в основном, используется для гарантирования защиты памяти. Дополнительные ограничения накладываются диспетчером и стандартными расширениями. Динамический компоновщик гарантирует, что расширение видит только санкционированные события.

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

• Автоматическая  верификация

     Метод автоматической верификации основан  на представлении кода в определенном формате, называемом PCC (Proof-Carrying Code) [Nec97]. PCC-модуль содержит формальное доказательство соответствия кода данной политике безопасности. Истинность доказательства гарантирует безопасность кода, и программный модуль может выполняться без проверок во время выполнения. Политика безопасности ядра описывается с помощью аксиом и правил вывода в доказательствах, а также формулируется в виде предикатов логики первого порядка для каждой инструкции, в которых указывается, при каких обстоятельствах выполнение каждой инструкции будет оставаться безопасным. Приложение использует предикаты политики безопасности для вычисления предиката безопасности. Затем доказывается безопасность этого предиката по правилам логики первого порядка с использованием аксиом и правил вывода политики безопасности. Доказательство присоединяется к расширению. Ядро, в свою очередь, также вычисляет предикат безопасности и проверяет истинность ассоциированного доказательства для этого предиката. Проверка достоверности может быть сделана через простую и эффективную проверку типов (type checking).

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

     2.3. Автоматическая адаптация 

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

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

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

     Система Synthetix предназначена для обеспечения специализированных реализаций сервисов операционной системы, генерируемых во время выполнения, на основании частичной оценки [CBK96]. Степень детализации и широта настраиваемости ограничены – проектировщик решает, какой сервис может быть конкретизирован и выбирает параметры конкретизации. Параметры сервиса вводятся с помощью инвариантов, с которыми связаны блоки защиты (guards). После проверки корректности параметров модуль сервиса замещается реализацией с новыми параметрами. Например, системный вызов открытия файла может возвращать конкретизированный код, обеспечивающий чтение файла. Такой код мог бы иметь инварианты, такие как размер блока на диске, последовательный доступ, монопольный доступ и т.п. Когда тот же самый файл позже открывается другим приложением, инвариант монопольного доступа становится некорректным из-за нарушения блока защиты, связанного с системным вызовом открытия файла.

     Автоматический  подход к настраиваемости исследовался в проекте VINO [SS97], который уже  рассматривался выше, однако этот подход в VINO не был реализован. По мнению авторов для осуществления автоматической адаптации поведения системы необходимо получать сведения из следующих трех источников:

     - периодическая статистика от каждой подсистемы VINO,

     - специализированный компилятор,

     - трассы и журналы, которые регистрируют входящие запросы и произведенные результаты.

     Вся информация собирается в реальных обстоятельствах, во время выполнения приложения. Затем  эта информация анализируется с  целью обнаружения чрезвычайных обстоятельств – например, ситуаций, когда потребление ресурсов превышает ожидаемую норму. В таких ситуациях адаптация проводится согласно известным эвристикам. Например, пусть некое приложение интенсивно листает страницы; тогда создаются трассы для запрашиваемых страниц. Результирующие трассы исследуются на предмет совпадения с хорошо известными моделями подкачки страниц. Если такая модель находится, инсталлируется соответствующий алгоритм. Проект VINO интересен тем, что в нем используются эвристики для хорошо известных случаев. В отличие от системы Synthetix, в которой адаптируются только функции и параметры, определенные проектировщиком, VINO поддерживает механизм, с помощью которого система могла бы разрабатывать и тестировать новые алгоритмы для вновь возникающих проблем.