EROS(마이크로커널)
EROS (microkernel)개발자 | 펜실베이니아 대학교 존스 홉킨스 대학교 EROS 그룹, LLC |
---|---|
기입처 | C |
OS 패밀리 | 기능 베이스 |
동작 상태 | 단종 |
초기 릴리즈 | 전( |
최신 릴리즈 | 최종 / 2005; | (
마케팅 대상 | 조사. |
이용가능기간: | 영어 |
갱신 방법 | 소스 코드에서 컴파일 |
플랫폼 | IA-32 |
커널 타입 | 실시간 마이크로커널 |
체납 사용자 인터페이스 | 명령줄 인터페이스 |
선행 | 키 KOS |
에 의해 성공자 | 캡로스 |
EROS(Extremy Reliable Operating System)는 1991년 펜실베니아 대학교, 존스 홉킨스 대학교 및 EROS Group, LLC에서 개발된 운영 체제입니다.기능에는 자동 데이터 및 프로세스 지속성, 몇 가지 사전 실시간 지원 및 기능 기반 보안이 포함됩니다.EROS는 순전히 연구용 운영체제이며 실제 사용에는 도입되지 않았습니다.2005년 이후로는[update] 후속 시스템인 CapROS를 위해 개발이 중단되었습니다.
주요 개념
EROS 시스템(및 그 관계)의 최우선 목표는 중요한 애플리케이션을 작은 통신 컴포넌트로 효율적으로 재구성하기 위해 운영체제 차원에서 강력한 지원을 제공하는 것입니다.각 컴포넌트는 보호된 인터페이스를 통해서만 다른 컴포넌트와 통신할 수 있으며 시스템의 나머지 부분과 분리되어 있습니다.여기서 보호된 인터페이스는 운영 체제의 가장 낮은 수준인 커널에 의해 실행되는 인터페이스입니다.시스템 내에서 프로세스 간에 정보를 이동할 수 있는 유일한 부품입니다.또한 기계를 완전히 제어할 수 있으며 (적절하게 구성된 경우) 우회할 수 없습니다.EROS에서 어떤 컴포넌트가 다른 컴포넌트의 서비스를 명명하고 호출하는 커널 제공 메커니즘은 Inter-Process Communication(IPC; 프로세스 간 통신)을 사용하는 기능입니다.커널은 기능으로 보호된 인터페이스를 적용함으로써 의도적으로 내보낸 인터페이스를 통해 프로세스에 대한 모든 통신이 확실하게 도착하도록 합니다.또한 호출 컴포넌트가 호출된 컴포넌트에 대해 유효한 기능을 보유하지 않는 한 호출이 불가능하도록 합니다.기능 시스템에서의 보호는 한 컴포넌트에서 다른 컴포넌트로의 기능 전파를 제한함으로써 달성됩니다.종종 제한이라고 불리는 보안 정책을 통해 이루어집니다.
기능 시스템은 자연스럽게 컴포넌트 기반의 소프트웨어 구조를 촉진합니다.이 조직적 접근법은 객체 지향 프로그래밍의 프로그래밍 언어 개념과 유사하지만 더 큰 세분화에서 발생하며 상속 개념을 포함하지 않습니다.이러한 방법으로 소프트웨어를 재구성하면 다음과 같은 몇 가지 이점이 있습니다.
- 개별 컴포넌트는 가장 자연스럽게 이벤트루프로 구조화 됩니다일반적으로 이러한 방식으로 구성된 시스템의 예로는 항공기 비행 제어 시스템(공중 시스템과 장비 인증에 대한 DO-178B 소프트웨어 고려사항 참조), 전화 교환 시스템(5ESS 스위치 참조) 등이 있다.이러한 시스템에서는 주로 라이프 크리티컬 및 미션 크리티컬 시스템에서 필수적인 특성인 단순성과 견고성 때문에 이벤트 기반 프로그래밍이 선택됩니다.
- 컴포넌트가 작아져 개별적으로 테스트 가능해져 결함이나 버그를 보다 쉽게 특정할 수 있습니다.
- 각 컴포넌트를 다른 컴포넌트로부터 분리함으로써 문제가 발생하거나 소프트웨어가 잘못 동작했을 때 발생할 수 있는 손상의 범위가 제한됩니다.
이러한 이점을 종합하면, 보다 견고하고 안전한 시스템을 얻을 수 있습니다.Plesey System 250은 원래 텔레포니 스위치용으로 설계된 시스템으로, 기능 기반 설계가 특히 견고성을 이유로 선택되었습니다.
이전의 많은 시스템과 달리 EROS에서는 리소스가 명명되고 사용되는 유일한 메커니즘이 기능이며, 순수한 기능 시스템이라고도 합니다.이와는 대조적으로 IBM i는 상업적으로 성공한 기능 시스템의 한 예이지만 순수한 기능 시스템은 아닙니다.
순수 기능 아키텍처는 충분히 테스트되고 성숙한 수학적 보안 모델에 의해 지원됩니다.이들은 올바르게 구현될 경우 기능 기반 시스템을 안전하게 보호할 수 있음을 공식적으로 입증하기 위해 사용되었습니다.이른바 "안전 특성"은 순수 능력 시스템에 대해 결정 가능한 것으로 나타났다(립톤 참조).고립의 기본 구성 요소인 구속은 순수한 능력 [1]시스템에 의해 집행 가능한 것으로 공식적으로 검증되었으며, EROS 구축업체와 KeyKOS 공장에 의해 실질적인 구현으로 축소되었습니다.다른 기본 보호 메커니즘에 대해 비교할 만한 검증은 없습니다.문헌에는 안전성이 일반적인 경우 수학적으로 결정 불가능함을 보여주는 근본적인 결과가 있다(HRU 참조, 그러나 제한된[2] 사례의 무제한 세트에 대해서는 물론 입증할 수 있다).보다 실질적으로 중요한 것은 현재의 범용 운영 체제에서 출하되는 모든 원시적인 보호 메커니즘에 대해 안전성이 잘못된 것으로 판명되었다는 것입니다.보안 정책을 성공적으로 수행하기 위해서는 안전이 필수 조건입니다.이 결과는 현재의 상품 시스템을 확보하는 것은 원칙적으로는 불가능하지만, 충분히 주의를 기울여 실시하면 능력 기반의 시스템을 확보할 수 있다는 것을 의미한다.EROS와 KeyKOS의 어느 쪽도 침입에 성공한 적이 없으며 분리 메커니즘도 내부 공격자에 의해 성공적으로 파괴된 적은 없지만 두 구현이 충분히 주의를 기울였는지는 알 수 없습니다.Coyotos 프로젝트의 목표 중 하나는 소프트웨어 검증 기술을 적용하여 컴포넌트 격리 및 보안이 확실하게 달성되었음을 입증하는 것이었습니다.
L4.sec 시스템은 L4 마이크로커널 패밀리의 후계 기종으로 기능 기반의 시스템으로 EROS 프로젝트의 결과에 큰 영향을 받고 있습니다.고성능 호출에 대한 EROS 작업은 L4 마이크로커널 패밀리에 대한 Jochen Liettke의 성공에 의해 강하게 동기 부여되었기 때문에 그 영향은 상호적이다.
역사
EROS의 주요 개발자는 Jonathan S였습니다.샤피로.그는 또한 EROS 운영체제를 [4]뛰어넘는 "진화 단계"[3]였던 코요토스의 원동력이기도 했다.
EROS 프로젝트는 1991년 이전 운영체제인 KeyKOS의 클린룸 재구축으로 시작되었습니다.KeyKOS는 Key Logic, Inc.에 의해 개발되었으며 Tymshare, Inc.에 의해 개발된 초기 GNOSIS(Great New Operating System In the Sky) 시스템에서 직접 작업을 계속했습니다.1991년 Key Logic의 종말을 둘러싼 상황은 KeyKOS의 라이선스를 비현실적으로 만들었다.KeyKOS는 어떤 경우에도 일반적인 범용 프로세서에서 실행되지 않았기 때문에 공개 문서에서 재구축하기로 결정했습니다.
1992년 후반에는 기능 아이디어가 도입된 이후 프로세서 아키텍처가 크게 변화했다는 것이 분명해졌고, 컴포넌트 구조 시스템이 실용적이라는 것은 더 이상 분명하지 않았습니다.마찬가지로 다수의 프로세스와 IPC를 선호하는 마이크로커널 기반 시스템은 심각한 성능 문제에 직면해 있으며 이러한 문제가 성공적으로 해결될 수 있을지는 불확실했습니다.x86 아키텍처가 주요 아키텍처로 부상하고 있는 것은 분명하지만 386 및 486에서는 사용자/슈퍼바이저 전환 지연 시간이 비싸 프로세스 기반 격리에는 심각한 문제가 있었습니다.EROS 프로젝트는 연구 노력으로 바뀌어 펜실베니아 대학으로 옮겨 샤피로의 논문 연구의 초점이 되었다.1999년까지 Pentium 프로세서의 하이 퍼포먼스 실장은 IPC에서 탁월한 속도로 알려진 L4 마이크로커널 패밀리와 직접 경쟁하는 것으로 입증되었습니다.EROS 제한 메커니즘은 보안 기능 시스템을 위한 일반적인 공식 모델을 만드는 과정에서 공식적으로 검증되었다.
2000년, 샤피로는 존스 홉킨스 대학의 컴퓨터 공학부에 들어갔다.Hopkins에서는 EROS 커널이 제공하는 기능을 사용하여 애플리케이션 수준에서 안전하고 방어 가능한 서버를 구축하는 방법을 보여 주는 것이 목표였습니다.국방고등연구프로젝트국과 공군연구소의 자금 지원을 받은 EROS는 신뢰할 수 있는 윈도 시스템,[5] 고성능 방어 가능한 네트워크 [6]스택 및 안전한 웹 브라우저의 기초로서 사용되었습니다.또한 경량 정적 [7]체크의 효과를 탐색하기 위해 사용되었습니다.2003년에는 동기 IPC 프리미티브(특히 EROS 및 L4 포함)에 기초한 시스템아키텍처 고유의 매우 어려운 보안 문제가 몇 가지[8] 발견되었습니다.EROS 작업은 코요토스를 위해 중단되어 이러한 [citation needed]문제를 해결했습니다.
2006년 현재[update] EROS와 그 후속 제품은 범용 하드웨어에서 실행되는 유일한 널리 이용 가능한 기능 시스템입니다.
상황
원래 그룹의 EROS와 코요토스에 대한 작업은 중단되었지만, 후계자 [4]체제는 있다.CapROS 시스템은 EROS 코드 베이스에서 직접 구축되고 있습니다.CapROS는 다양한 상용 [citation needed]배치로 출시될 예정입니다.
「 」를 참조해 주세요.
레퍼런스
- ^ Shapiro, Jonathan S.; Weber, Samuel (October 29, 1999). Verifying the EROS Confinement Mechanism (Report). Archived from the original on March 3, 2016.
- ^ Lee, Peter. "Proof-Carrying Code". Archived from the original on September 22, 2006.
- ^ Shapiro, Jonathan (April 2, 2006). "Differences Between Coyotos and EROS: A Quick Summary". Archived from the original on 2012-07-31.
- ^ a b Shapiro, Jonathan S. (April 7, 2009). "Status of Coyotos". coyotos-dev (Mailing list). Archived from the original on July 24, 2014. Retrieved 16 March 2022.
Active work on Coyotos stopped several months ago, and is unlikely to resume.
- ^ Shapiro, Jonathan S.; Vanderburgh, John; Northup, Eric; Chizmadia, David. "Design of the EROS Trusted Window System". Archived from the original on March 3, 2016.
- ^ Sinha, Anshumal; Sarat, Sandeep; Shapiro, Jonathan S. "Network Subsystems Reloaded: A High-Performance, Defensible Network Subsystem". Archived from the original on March 3, 2016.
- ^ Chen, Hao; Shapiro, Jonathan S. "Using Build-Integrated Static Checking to Preserve Correctness Invariants" (PDF). Archived from the original (PDF) on March 3, 2016.
- ^ Shapiro, Jonathan S. "Vulnerabilities in Synchronous IPC Designs". Archived from the original on March 3, 2016.
일지
- Lipton, R. J.; Snyder, L. (July 1977). "A Linear Time Algorithm for Deciding Subject Security". Journal of the ACM. 24 (3): 455–464.
- Harrison, Michael A.; Ruzzo, W. L.; Ullman, Jeffrey D. (August 1976). "Protection in Operating Systems". Communications of the ACM. 19 (8): 461–471.