stringtranslate.com

EROS (микроядро)

Extremely Reliable Operating System ( EROS ) — операционная система , разработанная с 1991 года в Университете Пенсильвании , а затем в Университете Джонса Хопкинса и The EROS Group, LLC. Функции включают автоматическое сохранение данных и процессов , некоторую предварительную поддержку в реальном времени и безопасность на основе возможностей . EROS — это чисто исследовательская операционная система, которая никогда не была развернута в реальном мире. По состоянию на 2005 год разработка была остановлена ​​в пользу системы-преемницы, CapROS.

Ключевые понятия

Главной целью системы EROS (и ее родственников) является обеспечение надежной поддержки на уровне операционной системы для эффективной реструктуризации критически важных приложений в небольшие взаимодействующие компоненты. Каждый компонент может взаимодействовать с другими только через защищенные интерфейсы и изолирован от остальной части системы. Защищенный интерфейс в этом контексте — это тот, который обеспечивается самой нижней частью операционной системы, ядром . Это единственная часть системы, которая может перемещать информацию из одного процесса в другой. Он также имеет полный контроль над машиной и (если правильно построен) не может быть обойден. В EROS предоставляемый ядром механизм, с помощью которого один компонент называет и вызывает службы другого, является возможностью , использующей межпроцессное взаимодействие (IPC). Обеспечивая защищенные возможностями интерфейсы, ядро ​​гарантирует, что все коммуникации с процессом поступают через намеренно экспортированный интерфейс. Оно также гарантирует, что никакой вызов невозможен, если вызывающий компонент не имеет действительной возможности для вызываемого компонента. Защита в системах возможностей достигается путем ограничения распространения возможностей от одного компонента к другому, часто с помощью политики безопасности, называемой ограничением .

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

В совокупности эти преимущества приводят к заметно более надежным и безопасным системам. Plessey System 250 была системой, изначально разработанной для использования в телефонных коммутаторах, чья конструкция на основе возможностей была выбрана специально из соображений надежности.

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

Архитектуры чистых возможностей поддерживаются хорошо проверенными и зрелыми математическими моделями безопасности. Они использовались для формальной демонстрации того, что системы, основанные на возможностях, могут быть сделаны безопасными, если они реализованы правильно. Было показано, что так называемое «свойство безопасности» разрешимо для систем чистых возможностей (см. Lipton). Ограничение, которое является фундаментальным строительным блоком изоляции, было формально проверено на возможность принудительного применения системами чистых возможностей [1] и сведено к практической реализации конструктором EROS и фабрикой KeyKOS . Не существует сопоставимой проверки для любого другого примитивного механизма защиты. В литературе есть фундаментальный результат, показывающий, что безопасность математически неразрешима в общем случае (см. HRU , но обратите внимание, что это, конечно, доказуемо для неограниченного набора ограниченных случаев [2] ). Более важное практическое значение имеет то, что безопасность оказалась ложной для всех примитивных механизмов защиты, поставляемых в современных товарных операционных системах. Безопасность является необходимым предварительным условием для успешного принудительного применения любой политики безопасности. На практике этот результат означает, что в принципе невозможно защитить текущие товарные системы, но потенциально возможно защитить системы на основе возможностей, если они реализованы с достаточной тщательностью. Ни EROS, ни KeyKOS никогда не были успешно взломаны, и их механизмы изоляции никогда не были успешно преодолены каким-либо внутренним злоумышленником, но неизвестно, были ли эти две реализации достаточно осторожны. Одной из целей проекта Coyotos было продемонстрировать, что изоляция компонентов и безопасность были окончательно достигнуты путем применения методов проверки программного обеспечения.

Система L4.sec, которая является преемницей семейства микроядер L4 , является системой, основанной на возможностях, и на нее значительное влияние оказали результаты проекта EROS. Влияние взаимное, поскольку работа EROS над высокопроизводительным вызовом была сильно мотивирована успехами Йохена Лидтке с семейством микроядер L4 .

История

Основным разработчиком EROS был Джонатан С. Шапиро. Он также был движущей силой Coyotos, который был «эволюционным шагом» [3] за пределами операционной системы EROS. [4]

Проект EROS начался в 1991 году как реконструкция более ранней операционной системы KeyKOS в чистой комнате . KeyKOS была разработана Key Logic, Inc. и была прямым продолжением работы над более ранней системой Great New Operating System In the Sky ( GNOSIS ), созданной Tymshare, Inc. Обстоятельства, окружавшие крах Key Logic в 1991 году, сделали лицензирование KeyKOS нецелесообразным. Поскольку KeyKOS в любом случае не работала на популярных процессорах, было принято решение реконструировать ее из общедоступной документации.

К концу 1992 года стало ясно, что архитектура процессора значительно изменилась с момента появления идеи возможностей, и уже не было очевидно, что структурированные по компонентам системы были практичны. Системы на основе микроядра , которые также отдают предпочтение большому количеству процессов и IPC, сталкивались с серьезными проблемами производительности, и было неясно, можно ли их успешно решить. Архитектура x86 явно становилась доминирующей архитектурой, но дорогостоящая задержка перехода пользователь/супервизор на 386 и 486 представляла серьезные проблемы для изоляции на основе процессов. Проект EROS превращался в исследовательскую работу и был перемещен в Университет Пенсильвании, чтобы стать центром диссертационного исследования Шапиро. К 1999 году была продемонстрирована высокопроизводительная реализация для процессора Pentium , которая была напрямую конкурентоспособна по производительности с семейством микроядер L4 , которое известно своей исключительной скоростью в IPC. Механизм ограничения EROS был формально проверен, в процессе создания общей формальной модели для безопасных систем возможностей.

В 2000 году Шапиро присоединился к факультету компьютерных наук в Университете Джонса Хопкинса. В Хопкинсе целью было показать, как использовать возможности, предоставляемые ядром EROS, для создания безопасных и защищаемых серверов на уровне приложений. Финансируемый Агентством перспективных исследовательских проектов Министерства обороны и Исследовательской лабораторией ВВС , EROS использовался в качестве основы для доверенной оконной системы [5] , высокопроизводительного, защищаемого сетевого стека [6] и зачатков безопасного веб-браузера. Он также использовался для исследования эффективности облегченной статической проверки [7] . В 2003 году были обнаружены некоторые очень сложные проблемы безопасности [8] , которые присущи любой архитектуре системы, основанной на синхронных примитивах IPC (в частности, включая EROS и L4). Работа над EROS была остановлена ​​в пользу Coyotos, который решил эти проблемы. [ необходима цитата ]

По состоянию на 2006 год EROS и ее последователи являются единственными широкодоступными системами управления возможностями, работающими на серийном оборудовании.

Статус

Работа над EROS и Coyotos первоначальной группой была остановлена, но есть система-преемница. [4] CapROS (Capability Based Reliable Operating System), преемница EROS, является операционной системой с открытым исходным кодом, ориентированной на коммерческое использование. [9]

Смотрите также

Ссылки

  1. ^ Шапиро, Джонатан С.; Вебер, Сэмюэл (29 октября 1999 г.). Проверка механизма ограничения EROS (PDF) . Симпозиум IEEE 2000 по безопасности и конфиденциальности. Беркли, Калифорния, США. doi :10.1109/SECPRI.2000.848454.
  2. ^ Ли, Питер. "Proof-Carrying Code". Архивировано из оригинала 22 сентября 2006 г.
  3. ^ Шапиро, Джонатан (2 апреля 2006 г.). «Различия между койотами и ЭРОСами: краткое изложение». Архивировано из оригинала 31 июля 2012 г.
  4. ^ ab Shapiro, Jonathan S. (7 апреля 2009 г.). "Status of Coyotos". coyotos-dev (список рассылки). Архивировано из оригинала 24 июля 2014 г. . Получено 16 марта 2022 г. . Активная работа над Coyotos прекратилась несколько месяцев назад и вряд ли возобновится.
  5. ^ Шапиро, Джонатан С.; Вандербург, Джон; Нортап, Эрик; Чизмадиа, Дэвид (2004). Проектирование системы доверенных окон EROS (PDF) . 13-й симпозиум по безопасности USENIX. Сан-Диего, Калифорния, США.
  6. ^ Синха, Аншумал; Сарат, Сандип; Шапиро, Джонатан С. (2004). Перезагрузка сетевых подсистем: высокопроизводительная, защищенная сетевая подсистема (PDF) . Ежегодная техническая конференция USENIX 2004 года. Бостон, Массачусетс, США.
  7. ^ Чен, Хао; Шапиро, Джонатан С. «Использование встроенной в сборку статической проверки для сохранения инвариантов корректности» (PDF) . Архивировано из оригинала (PDF) 3 марта 2016 г.
  8. ^ Шапиро, Джонатан С. (2003). Уязвимости в синхронных проектах IPC (PDF) . Симпозиум по безопасности и конфиденциальности 2003 года. Беркли, Калифорния, США. doi :10.1109/SECPRI.2003.1199341.
  9. ^ Чакраборти, Пинаки (2010). «Операционные системы исследовательского назначения – широкий обзор». GESJ: Компьютерные науки и телекоммуникации . 3 (26). ISSN  1512-1232.

Журналы

  1. Липтон, Р. Дж.; Снайдер, Л. (июль 1977 г.). «Линейный алгоритм времени для принятия решения о безопасности субъекта». Журнал ACM . 24 (3): 455–464. doi : 10.1145/322017.322025 . S2CID  291367.
  2. Харрисон, Майкл А.; Руццо, В. Л.; Ульман, Джеффри Д. (август 1976 г.). «Защита в операционных системах». Сообщения ACM . 19 (8): 461–471. doi : 10.1145/360303.360333 . S2CID  5900205.

Внешние ссылки