개요
FlexOS는 OS에서 보안과 성능을 향상시키기 위해 유연한 격리 메커니즘을, 즉 Process abstraction, 제공하는 새로운 운영체제(OS) 설계를 제안하였다. 이 연구는 모듈화 원칙을 활용하여 애플리케이션 요구사항에 따라 격리 수준을 조정할 수 있는 세분화된 격리를 가능하게 하였다. FlexOS는 보안을 강화하면서도 성능을 저하시키지 않도록 디자인 하였다.
Motivation
기존 운영체제는 다양한 환경에서 보안과 성능의 균형을 유지하는 데 어려움을 보인다. 기존 솔루션은 정적인 격리 메커니즘을 제공하며, 이는 보안 요구사항의 변화를 효과적으로 반영하지 못하거나 성능 저하를 초래한다. 특히 다음의 문제가 있었다.
- Per-application OS Specialization이 안됨
- Application은 보통 여러개의 다른 Trust와 Performance에 대한 요구사항을 가지는 부분으로 이루어져 있음
- 새로운 보안 모델은 하드웨어 벤더사에 의해서 제안되고 적용됨, 또한 기존의 정적인 운영체제 설계 모델은 하드웨어 취약점 발견시 대응을 어렵게 함
Challenge
- How can variable isolation granularities be offered without compromising performance: Library OS를 채택하였다.
- 어떻게 Developer가 쉽고 안전하게 다양한 Isolation과 Protection기법을 Deployment시간에 변경할 수 있도록 할 것인가: 다양한 Isolation, Protection기법들을 Abstraction으로 API로 제공하여, 최소한의 수정으로 적용할 수 있도록 하였다. 또한 POSIX Interface를 LibOS가 제공하도록 하였다. 또한 Shared할 부분을 Annotation하는 문법을 서로 다양한 Protection기법을 적용하더라도 공유하도록 하였다.
- 다양한 Design space중에서 어떤 것으로 선택할지 Developer가 쉽게 적용할 수 있도록 할 것인가: Partial safety ordering이라는 기법을 도입하여 쉽게 Performance와 Security trade-off를 반영하도록 하였다.
Main Idea
- 애플리케이션과의 호환성을 유지하면서 모듈식이고 세분화된 격리를 지원하는 OS 아키텍처 개발.
- 보안, 성능, 사용성 간의 절충점을 관리.
Design
FlexOS는 Modulization이 잘 구현되어 있는 Unikraft를 기반으로 하여 구현하였다. FlexOS는 기존 커널과는 다르게 Isolation에 대한 고려는 다지인 단계에서 고려되지 않았다. Build time에 Cross domain콜은 Call gate를 통과하도록 하여서, OS의 Isolation디자인이 아니라 Call gate디자인에 따라서 Isolation방식이 달라지도록 하였다.
- API Design
- Flex OS는 다음 두개를 고려하였다. 1) Protection domain의 정의와 Context switching mechansism 2) Shared memory를 위한 방식 제공. 대다수의 Protection domain은 이 2개만을 지원하기 떄문에 충분하다고 주장한다. Call gate는 이 두 디자인을 반영하여 각 디자인에 맞추어 Protection domain을 바꾼다.
- Data Ownership Approach
- FlexOS는 Library에 의해서 할당된 static and dynamic메모리를 모두 private인것으로 여긴다. 각 변수들은 반드시 공유되기 위해서 Shared로 마킹되어야 한다. Shared는 수동으로 해야 하며, Protection mechanisms에 따라서 최대 가능한 동시 Shared변수의 개수가 정해진다.
Conclusion
Flex OS는 다음과 같은 한계가 있을 수 있다.
- Call gate를 정적 분석을 통해서 찾아야 하나, Function pointer와 같은 경우는 힘들 수 있다. 이 경우에는 programmer의 Annotation이 필요하다.
- 라이브러리와 Application에 Shared로 Marking시키는 Development cost가 추가로 든다.
- Shared의 개수가 Mechanisms마다 달라지기 떄문에, 결국 수동 코스트가 또 들 수도 있을 것 같다. 또한 공유 변수의 수를 줄이는 것은 간단한 개발 비용으로 처리할 수 있지 아니할 것 같다.
- TCB가 큰 편이다.