Abstract
Safe Language를 통해서 운영체제를 만들면 어떤 장점 & 단점이 있을까? 3개의 요소로 파악. SFI를 통한 프로그램 서비스의 분리, Channel의 디자인, 그리고 Manifest-based의 프로그램 verification.
Problem & Importance
OS가 처음 태동하던 1970년대와 2000년대의 컴퓨팅 환경은 완전히 다르다. 그때 사용하던 OS디자인 컨셉을 지금도 사용하는 것은 보안과 개발 측면에서 문제가 있다. 따라서 이러한 환경에서 Singularity는 새로운 디자인 컨셉을 Safe Langauge란 측면에서 살펴보면서 어떠한 점이 Improvement가 있을 수 있는지를 탐색하는 것이 중요해 졌다.
Design
- Software-Isolated Processes
- Software-Isolated Processes (SIP)이란 Process같은 건데, Safe Language의 도움으로 Type safety와 Memory management를 이용하여 Context change를 매우 빠르게 할 수 있었다. SIP사이에서는 데이터를 공유하는 것이 아니라, Message의 공유로 이루어진다. SIP은 ABI를 통해서 커널과 직접 통신한다. SIP은 다른 SIP과 Writable메모리를 공유하지 않는점, Page table과 같은 Hardware protection이 아니라 SFI를 통해서 보호받는 점을 들어서 기존의 Process와는 구분된다.
- Contract-Based Channels
- SIP사이의 Message passing은 Contract-based channel을 통해서 이루어진다. Language Level에서 이루어지는 Channel의 정의를 통해서 SIP은 효율적이고 분석 가능한 통신을 SIP사이에 제공한다. 또한 이 명시적인 Channel은 실수를 줄이고 Language level에서 safety를 제공하기 때문에 Zero-copy가 가능하게 한다.
- Manifest-Based Programs
- Manifest라는 프로그램의 코드 리소스, 시스템 리소스, Capability그리고 Dependencies들을 기록하는 파일을 통해서 모든 SIP이 실행되도록 하였다. MBP를 통해서 프로그램이 적절한 Requirement를 요구하고있는지를 사전에 체크하고 리소스를 배분할 수 있도록 하였다. MBP를 통해서 SIP이 수행되는 것이 적절한지를 Static time에 그리고 Dynamic time에 검증할 수 있도록 하였다. MBP에는 Type과 Memory safety에 관한 내용. Privileged-mode instruction에 대한 내용과 같이 시스템 전반에 어느정도의 권한을 가지고 접근할 수 있는지 가 명시되어 있다. 이러한 MBP는 Microsfot Intermediate Language (MSIL)이라는 Type information에 대한 정보가 포함된 CPU independent한 명령어 집합과 함께 주어져서 static time에 체크하게 된다.
Contribution
Safe language를 사용해서 운영체제를 만들면, MMU와 Ring없이 SFI로만 Application과 Hardware를 나누면 어떠한 장점이 있는지, 운영체제 디자인에서 어떠한 점을 이점으로 삼을 수 있는지 면밀히 탐구해본 연구로써 매우 큰 가치가 있다. 또한 Implementation측면에서도 Sing#, Verifier, Compiler, Operating System처럼 근간을 이루는 모든 Stack에서 Tightly하게 연결된 구현과 디자인을 수행함으로써 서로 어떠한 영향을 미치는지 연구하여 매우큰 후속연구의 도움을 주는 연구가 된다.
criticizing
- 모든 Application을 Sing#을 이용해서 작성해야 한다.
- 간단한 Hardware protection이 아니라 SFI를 사용함으로서, TCB가 늘어난다.
- 10%의 운영체제 구현에서는 Unsafe Sing#을 사용하였는데, 이 부분에서의 Safety문제를 완벽히 해결할 수 없다.