Extremely Reliable Operating System

Перейти к навигацииПерейти к поиску

Extremely Reliable Operating System (EROS) — операционная система на основе мандатов, призванная выполнять требования защиты и надёжности активных систем. Пользователи активных систем могут в любое время вводить и исполнять произвольный код, в том числе ошибочный или даже вредоносный. Активные системы представляют собой разделяемые платформы, которые должны одновременно поддерживать потенциально конкурирующих пользователей на одной машине в одно и то же время.

Принцип работы

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

История проекта

Проект EROS начинался как эталонная реализация KeyKOS, операционной системы, созданной Нормом Харди и его коллегами для IBM System/370. Основной вклад EROS заключается в формальной проверке некоторых основных свойств защиты архитектуры, инжиниринге реализации конкретных характеристик работы. Этих характеристик защиты и производительности удалось добиться двумя способами.

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

Джереми Салцер и Майкл Шредер выработали многие принципы проектирования EROS при реализации проекта Multics и интегрировали другие на основе своего опыта работы над иными проектами. Согласованности производительности и архитектуры системы удалось добиться исключительно за счёт поиска наилучших способов точного выполнения этих принципов вплоть до нюансов, при этом не снижая производительности.

Разработчики EROS строго придерживались принципов архитектуры при проектировании EROS/KeyKOS] по следующим трём причинам. Нужно быть уверенным в том, что система работает, и знать, почему она работает. Если для каждого фрагмента системного кода невозможно сказать, каков руководящий принцип или обязательное ограничение, гарантирующее корректность, добиться этой цели очень сложно. Связь такого рода также необходима для оценок работы системы с высокой степенью достоверности. Предполагалось, что чёткая архитектура сама будет способствовать высокопроизводительной реализации. Проведённые тесты на производительность подтвердили правильность таких предположений.

Архитектура ядра EROS

Самое непосредственное влияние принципов проектирования в EROS сказалось на структуре и реализации ядра. В некоторых случаях жёсткое следование принципам проектирования приводило к неожиданным архитектурным решениям.

Безопасная перезагрузка

В защищённых системах необходимо гарантировать, что после перезагрузки система находится в непротиворечивом и защищённом состоянии. В большинстве операционных систем существует первоначальный набор процессов, которые специально создаются ядром. Эти процессы выполняют проверку непротиворечивости, ограничивают свои полномочия теми, которые предполагаются в стабильном режиме, а затем инициируют остальные программы в системе. В этой ситуации возникает две проблемы. Проверка непротиворечивости является эвристической, в силу чего определить её корректность довольно сложно. К примеру, команда fsck в Unix должна определить, какие файлы удалить, а какие оставить, не зная о том, как эти файлы взаимосвязаны. Следовательно, состояние файлов паролей и групп могут оказаться несогласованными друг с другом. Первоначальные процессы получают свои полномочия с помощью средств, которые выходят за рамки обычных механизмов предоставления или передачи полномочий. Разработчики должны создать особые средства для демонстрации того, что система корректным образом управляет этими полномочиями и сокращает их. Сложность этих средств сравнима со сложностью средств обеспечения корректности остальной части системы.

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

Ядро, не сохраняющее состояние

EROS — это ядро, не сохраняющее состояние — состояние исполнения системы размещается в зарезервированной пользователем памяти. Приемлемая производительность ядра достигается за счёт кэширования этого состояния. Архитектура кэширования поддерживает механизм контрольных точек и обеспечивает контроль зависимостей в ядре. Чтобы гарантировать, что зарезервированная пользователем память всегда при проверке предоставляет корректные значения, ядро должно иметь возможность восстанавливать своё состояние по требованию. Эти зависимости предлагают определённую форму самопроверки. Ядро может иногда сравнивать своё кэшированное состояние с пользовательским состоянием, чтобы выявить несогласованность, тем самым не позволяя записывать на диск некорректное состояние.

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

См. также

Ссылки