| Asterinas: A Linux ABI-Compatible, Rust-Based Framekernel OS with a Small and Sound TCB | |
|---|---|
| Author | Yuke Peng, SUSTech; Hongliang Tian, Ant Group; Junyang Zhang and Ruihan Li,
Peking University and Zhongguancun Laboratory; Chengjun Chen and Jianfeng Jiang, Ant Group; Jinyi Xian, SUSTech; Xiaolin Wang, Chenren Xu, Diyu Zhou, and Yingwei Luo, Peking University and Zhongguancun Laboratory; Shoumeng Yan, Ant Group; Yinqian Zhang, SUSTech |
| Conference | USENIX ATC 2025 |
| https://www.usenix.org/system/files/atc25-peng-yuke.pdf | |
| Year | 2025 |
개요
최소한의 TCB를 가지고 Rust로 OS를 만들기 위해서, Rust의 Unsafe한 부분들을 한 곳에 몰아 넣고 Framekernel이라는 것을 만든다음, 거기 위에 점층적으로 쌓아 올라가면 TCB를 최소화 할 수 있다.
Motivation
아무리 safe한 언어로 semantic으로 프로그램을 작성한다고 하더라도, 결국에는 성능 혹은 Compatibility를 위해서 unsafe한 라이브러리/코드를 사용하게 된다. 기존에는 이러한 unsafe한 부분때문제 전체 시스템의 안정성이 위협받았다. 따라서 아무리 Safe한 Rust로 OS를 만든다고 하더라도, TCB가 기존에는 컸다.
일례로, Unsafe한 부분을 포함한 Crate는 Linux의 55%, Tock의 93%, RedLeaf의 62%, 그리고 Theseus의 32%를 차지 하였다.
Main Idea
커널을 로직컬하게 두부분으로 쪼갠다. 우선 Privielged OS framework를 담는 TCB가 되는 부분과, Service를 실행시키는 Safe한 Rust언어로만 작성된 De-priveilged OS service로 나누면, TCB가 framework 부분에만 집중되기 때문에 크게 줄일 수 있다.
그렇다면, Unsafe한 파트에서 일어날 수도 있는 Fault는 어떻게 처리하는가?
- Langauge-Level의 Undefined Behavior: KernMiri라는 Rust테스팅 툴로 Testing해봐서 없으면 없다고 생각한다.
- Environment UB: KernelMiri
- Architecture-level UB: IOMMU를 이용해서 Isolation한다.
Conclusion
개인적으로는, Unsafe한 부분을 하나의 라이브러리에 모아 관리한다고 해서 전체 시스템의 TCB(Trusted Computing Base)가 실질적으로 낮아진다고 보기는 어렵다고 생각한다. 물론 이 방식이 프로그래밍의 편의성(Programmability)이나 디버깅 용이성(Debuggability) 측면에서는 긍정적인 효과가 있을 것이다. 하지만 TCB를 계산할 때, 단순히 Unsafe한 코드를 특정 라이브러리에 집중시켰다고 해서 그 라이브러리를 사용하는 전체 코드가 TCB 범위 밖에 있다고 보기보다는, 여전히 해당 라이브러리를 호출하는 모든 경로가 영향을 받을 수 있기 때문에, TCB 측면에서는 유사한 수준으로 간주하는 것이 더 타당하다고 본다. 결국 중요한 것은, 시스템 전체에서 버그 가능성이 있는 코드가 어느 정도의 비중을 차지하는지이며, 코드의 물리적 분리보다는 해당 코드가 시스템에 미치는 실제 영향 범위가 더 본질적인 판단 기준이 되어야 한다고 본다. 또한 KernelMiri는 Unit test같은 느낌인데, 과연 KernelMiri를 통해서 테스팅을 통과했다고, 전체시스템에 복잡한 UB가 없다는 것을 보장할 수 있을지도 의문이 든다.