1. Введение: Особенности операционных систем реального времени




страница8/10
Дата20.04.2017
Размер1.03 Mb.
Просмотров1250
Скачиваний0
1   2   3   4   5   6   7   8   9   10
PURE хорошо конфигурируется и обладает высоким уровнем детализации настройки.
Вышеописанные подходы приводят к хорошим результатам для устройств или компьютеров, функциональность которых известна заранее.
4.1.2.
Динамическая адаптация, инициированная администратором

Этот класс ОС поддерживает адаптацию во время раскрутки или выполнения, которую осуществляет администратор, а иногда и пользователь. Такая адаптация достигается двумя способами.
Первый способ – это метод загружаемого модуля ядра (loadable kernel module) дает возможность доверенному лицу (обычно администратору или пользователю с полномочиями root) загрузить модули в ядро, таким образом, изменяя или расширяя функциональность ОС. Преимущество данного метода заключается в его простоте – это напоминает динамическую загрузку класса обычных приложений. Недостатком является возможность нарушения механизмов безопасности системы при добавлении произвольного кода в ядро, что может вызвать крах системы. Кроме того, стабильное состояние системы может стать нестабильным после загрузки злоумышленного или просто ошибочного модуля в ядро.
Второй способ – это настройка (tuning) системы. Обычно политики ОС параметризуются, и такие параметры могут изменяться либо администратором, либо пользователем. Кроме того, существуют счетчики производительности, которые помогают оценить преимущества той или иной политики, настроенной через параметры. Преимущество этого подхода состоит в том, что здесь не дискредитируются механизмы зашиты. Недостатком можно считать тот факт, что при таком подходе ограничиваются широта применения и уровень детализации.
Динамическая адаптация от имени администратора широко применяется во всех промышленных ОС (Linux, Solaris, Windows NT). Windows 2000 имеет сотни счетчиков производительности и соответствующих системных переменных. Ядро Linux интенсивно использует загружаемые модули.
Следует отметить, что контекст и мотивы расширения и адаптируемости различны для промышленных и исследовательских ОС. В академическом сообществе для ОС главной движущей силой является производительность, часто в не удостоверенном (untrusted) контексте. Инициатор адаптации не может считаться удостоверенным и, следовательно, целостность ОС нужно защищать. В промышленных ОС расширяемость, главным образом, используется для добавления разных форм функциональности в
74 удостоверенном контексте, где инициатор адаптации является удостоверенным
(например, администратор файловой системы). Метод загружаемого модуля ядра используется для наращивания ядра новыми драйверами устройств с поддержкой новых файловых систем с новыми способами аутентификации, а также другими видами функциональности.
Модули улучшения производительности, а также механизмов защиты целостности очень редки на практике. Как следствием этого, многие исследовательские результаты по адаптируемости и наращиванию не находят применения в промышленных ОС.
4.2. Адаптация, инициированная приложением
Адаптация, инициированная приложением, может производиться только динамически, и ее применение полезно в ОС общего назначения. В то время как традиционные ОС имели большие трудности при добавлении новых возможностей, требующихся, например, для обработки мультимедийных приложений, настраиваемые ОС быстрее адаптировались в новых условиях.
Приложение часто знает свои потребности и может от своего имени инструктировать ОС о необходимой настройке. Механизмы, предоставляющие возможность настройки от имени приложений во время выполнения, вводят накладные расходы по производительности. Однако цель динамически настраиваемых ОС состоит в том, чтобы достичь лучшей производительности всей системы в целом, разрешая настройки, которые приводят к преобладанию преимуществ над накладными расходами.
4.2.1. Адаптация с уровня приложения
Рассмотрим системы, которые разрешают приложениям настраивать сервисы
ОС через введение кода с уровня пользователя или непривилегированного уровня. Такие ОС обычно называются микроядерными, потому что они струк- турируются вокруг микроядра. Истинное микроядро должно быть минимальным, и должно предполагать отсутствие в нем каких-либо сервисов или политик.
4.2.1.1.

Микроядерные ОС

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

75
Выбранный набор абстракций, интегрированных в ядро, существенным образом влияет на производительность и гибкость. Чем меньше абстракций, тем большая гибкость остается для приложений. В ядре должны присутствовать только те абстракции, которые необходимы для деятельности самого ядра. Это хорошо сформулировано в работах Лидке [Lie95, Lie96] о системе L4 – в ней ядерными абстракциями являются адресные пространства, потоки, IPC и уникальные идентификаторы. С этими абстракциями L4 поддерживает рекурсивную конструкцию адресных пространств – исходное адресное пространство включает всю память и порты ввода/вывода и принадлежит исходной подсистеме или приложению.
Результатом приближения микроядерной философии к ее логической крайности становится ОС, в которой все системные сервисы выведены за пределы ядра и реализованы в виде библиотек, а само ядро становится попросту абстракцией аппаратных ресурсов. Такой экстрим реализован в ОС
Exokernel [EKO95]. В ядре Exokernel отсутствуют какие-либо абстракции ОС и весь его интерфейс сведен к надстройке над аппаратурой. Единственная функция, которая оставлена в Exokernel – это выделить, вернуть и мультиплексировать физические ресурсы (страницы памяти, кванты времени процессора, блоки дисков и т.п.) безопасным образом. Композиция наиболее используемых интерфейсов в Exokernel до сих пор остается большой проблемой [SSF99].
Систему 2K [2K] можно отнести к микроядерным ОС. Система 2K основана на компонентах, и ее основной задачей является обеспечение настраиваемого каркаса для поддержки адаптации в сетевом окружении. Способность к адаптации регулируется параметрами, такими как пропускная способность сети, связность, доступность памяти, протоколы взаимодействия и компоненты аппаратных средств. ОС 2K строится над Corba и использует данные метауровня и их методы, которые предлагает уровень ORB (object request broker) для адаптации. Компонент 2K – это динамически загружаемый программный модуль, который хранится в динамически подключаемой библиотеке (DLL). Следует отметить, что система 2K использует крупный уровень детализации.
4.2.1.2.

Портал-ориентированные системы

Портал-ориентированная система – это микроядро, которое имеет минимально возможный код и работает в самом доступном привилегированном режиме.
Такие системы обладают доменами защиты, которые обеспечивают безопасность работы пользователя. Порталы используются для взаимодействия между доменами. Домен защиты состоит из набора страниц и совокупности порталов, причем порталы могут разделять и страницы, и порталы.
Примером портал-ориентированной системы служит Kea портал- ориентированное микроядро, которое обеспечивает низкоуровневые концепции для конструирования высокоуровневых сервисов [VH96]. Под низкоуровневыми концепциями понимаются домены (виртуальные адресные
76 пространства), обращения доменов друг к другу (IPC) и порталы. Портал ассоциирован с определенным сервисом – это точка входа для обращения к домену. Каждый сервис обязан регистрировать свой идентификатор в ядре, а ядро управляет доступом к этому интерфейсу. В отличие от истинных микроядерных ОС Kea не дает полной свободы для проектирования и реализации сервисов. Все же Kea дает возможность вводить динамическую реконфигурацию. При обращении к сервису (через его портал) ядро может решать, какую реализацию выбрать. Например, при использовании файлового сервиса администратор может наложить обязательный вызов сервиса сжатия данных перед передачей их файловому сервису. Более сложная реконфигурация возникает в случае, когда приложение ассоциирует новый портал с идентификатором для некоторого сервиса. Например, при использовании менеджером виртуальной памяти портала для сервиса замещения страниц приложение может заставить его использовать для своих страниц свой собственный сервис замещения страниц. В Kea уровень детализации адаптации определяется реализацией сервисов. Если менеджер виртуальной памяти фиксирует политику замещения страниц (вместо использования для нее портала, как в примере), никто не может ее изменить, пока не заменит весь сервис.
В системе SPACE [PBK91] единственной абстракцией, присутствующей в ядре, является обобщение управления исключительными ситуациями, т.е. механизм управления прерываниями. Если бы такой обобщенный механизм управления исключительными ситуациями мог бы быть реализован на аппаратном уровне, операционную систему можно было бы считать
“безъядерной”.
Система Pebble [MBG00], так же, как и SPACE, поддерживает взаимодействие через домены защиты, реализованное как обобщение управления прерываниями. Как и Kea, Pebble осуществляет взаимодействие доменов через порталы и допускает реконфигурацию порталов. Порталы реализуются как обобщенные обработчики прерываний. Ядро Pebble содержит только код, реализующий передачу потоков от одного домена защиты другому, и небольшое количество функций поддержки режима ядра. Как и Exokernel,
Pebble отдает реализацию абстракций ресурсов на уровень пользователя, но в отличие от Exokernel, Pebble обеспечивает совокупность высокоуровневых абстракций, которые реализуются компонентами пользовательского уровня, что упоминалось в разделе о статической адаптации, инициированной проектировщиком. Каждый компонент уровня пользователя выполняется в своем собственном домене защиты, изолированном аппаратными средствами защиты памяти.
4.2.1.3.

Системы мандатов (Capability Systems)
Системы Fluke и EROS являются системами мандатов, которые структурированы вокруг микроядра. Здесь под мандатом понимается пара, состоящая из идентификатора объекта и набора санкционированных операций над этим объектом (его интерфейс). Дескрипторы файлов в UNIX могут

77 служить примером таких мандатов. В системах мандатов каждый процесс содержит мандаты и может совершать только те операции, которые санкционированы этими мандатами. Мандаты – единственные средства инициации операций над объектами, и единственные операции, которые могут выполняться с помощью мандата — это операции, разрешенные этим мандатом. Это означает, что каждый ресурс обслуживается через посредника и полностью инкапсулирован.
Архитектура вложенных процессов системы Fluke сочетает микроядро с виртуальными машинами [FHL96]. Ядро обеспечивает базовые сервисы и интерфейс к ним. Виртуальные машины используют этот интерфейс и реэкспортируют его на следующий уровень. Каждый слой полностью симулирует среду для вышележащего уровня – интерфейс между слоями всегда один и тот же, что позволяет компоновать сервисы с помощью наложения
(stacking) виртуальных машин.
Благодаря такому наложению или многоуровневому представлению
Fluke поддерживает вертикальную декомпозицию сервисов, в то время как микроядро обеспечивает горизон- тальную декомпозицию, перенося традиционную функциональность ядра на серверы пользовательского уровня, расположенные как бы рядом (side-by-side).
Необходимость поддерживать согласованность интерфейсов между виртуальными машинами вносит большие трудности при добавлении новых методов или параметров. Несмотря на то, что архитектура Pebble близка к архитектуре вложенных процессов системы Fluke, Pebble дает возможность расширять систему с большим уровнем детализации благодаря механизму замещения порталов.
Система EROS (Extremely Reliable Operating System) состоит из ядра, которое реализует небольшой набор примитивных мандатных типов [SSF99].
Возможности, которые предлагает ядро EROS, относятся к довольно низкому уровню. Большинство системных функций реализуется приложениями уровня пользователя. Например, ядро EROS напрямую предоставляет страницы дисковой памяти, но не файловой системы. Файловая абстракция полностью строится на уровне приложений, и файловое приложение просто хранит содержимое файла в адресном пространстве, увеличивая адресное пространство по мере необходимости так, чтобы оно могло содержать весь файл. Обязанность файлового приложения состоит в том, чтобы реализовать такие операции, как чтение и запись, которые выполняются над файлом. Такой метод проектирования – создание высокоуровневых функций за счет объединения базовых примитивов операционной системы в повторно используемые компоненты – основная стратегия для создания приложений
EROS. Каждый экземпляр компонента реализуется с помощью отдельного процесса, а ядро обеспечивает высокопроизводительный механизм связи между процессами, позволяющий эффективно объединять эти компоненты.
Фактически, крайне редко приложения EROS работают с предлагаемыми ядром объектами напрямую. Большинство приложений повторно использует компоненты, предоставляемые системой, или реализуют новые компоненты, которые обеспечивают необходимую функцию структурированным способом.
78
Приложения EROS структурируются как защищенные, связанные мандатами компоненты. Каждый экземпляр компонента работает с индивидуально указанными мандатами, определяющими его полномочия. Мандаты защищены ядром, как и объекты, на которые они указывают. Единственные операции, которые могут выполняться с мандатом – это операции, определяемые объектом. Благодаря этому сочетанию защиты и посредничества, приложение, которое выполняет злоумышленный код, не может повредить систему в целом или нанести ущерб другим пользователям, а также не может использовать привилегии пользователя для того, чтобы повредить другие части пользовательской среды. Точно также, мандаты управляют доступом к ресурсам, не позволяя злоумышленному коду злоупотреблять ресурсами или вывести остальную часть системы из работоспособного состояния.
4.2.1.4.

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

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

79 недостаточно, приложение может клонировать мета-просранство и мигрировать в него. После этого приложение будет иметь полный контроль над мета-просранством и, таким образом, над собственной средой выполнения.
4.2.2. Адаптация на уровне ядра
Системы, допускающие адаптацию на уровне ядра, обычно называются наращиваемыми ядрами (extensible kernels). Эти системы применяют передовые технологии, которые гарантируют целостность ядра. Наращиваемые ядра принимают код пользователя и выполняют его в привилегированном безопасном режиме, динамически изменяя поведение ядра. Эта технология позволяет избавиться от переключений между режимами пользователя и ядра и между адресными пространствами. Поскольку коду, который вводится приложением в ядро, нельзя доверять, решающим фактором для наращиваемых ядер становится применяемый механизм безопасности.
Политика безопасности в ОС проводится в жизнь через верификацию или через защиту (protection). Защита пытается гарантировать корректное поведение приложения после его инсталляции, или ограничить последствия нанесенного вреда. Защита достигается как аппаратными, так и программными средствами.
Защита с помощью аппаратуры обычно осуществляется в микроядрах. В таких системах аппаратные средства гарантируют, что настройки системы, про- исходящие на уровне пользователя, никогда не смогут модифицировать ядро.
Верификация гарантирует корректное поведение расширения до инсталляции и развертывания. При обсуждении ОС рассматриваются два вида верификации – верификация источника и верификация поведения.
При верификации источника код считается безопасным, если он введен в систему удостоверенной стороной (например, администратором). Такая практика применяется в промышленных ОС (UNIX, Windows NT), где такой подход носит название метода загружаемого модуля ядра. Загрузка модуля может выполняться как администратором, так и приложением с правами root, или даже приложениями с правами пользователя, которому разрешена такая загрузка, если он является удостоверенной третьей стороной (например, производитель данной ОС).
При верификации поведения ОС старается проанализировать, действительно ли данный код ведет себя должным образом. Очень привлекательна автоматическая верификация поведения, но ее трудно осуществлять.
4.2.2.1.

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

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

приложение может заместить реализацию метода некоторого объекта ядра (ресурса), если это разрешено, – это позволяет изменять стандартное поведение ресурсов,

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

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

81 статическую проверку типов. Языки Modula-3 и Java обладают меньшим формализмом, поэтому чтобы гарантировать в них политику безопасности, необходимо выполнять многочисленные проверки типов во время выполнения.
Однако ML, как декларативный язык, имеет недостаточную эффективность во время выполнения.
Система SPIN основана на языке Modula-3 [BSP95]. Все взаимодействия между приложением и ядром осуществляются с помощью расширений. Каждое рас-ширение связывается с событием. Расширение должно быть зарегистрировано диспетчером, который инсталлирует расширения и передает события расширениям. С отдельным событием может быть связано несколько расширений. Расширения замещаются или добавляются диспетчером. Modula-
3, в основном, используется для гарантирования защиты памяти.
Дополнительные ограничения накладываются диспетчером и стандартными расширениями. Динамический компоновщик гарантирует, что расширение видит только санкционированные события.
Очевидным недостатком таких систем является их жесткая привязанность к определенному языку – весь системный код и расширения должны быть написаны на этом языке. Еще один недостаток состоит в том, что политика безопасности фиксирована и определяется выбранным языком. Кроме того, многочисленные проверки во время выполнения сильно понижают производительность системы.
4.2.2.2.

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


Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8   9   10


База данных защищена авторским правом ©nethash.ru 2017
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал