Building Bridges: Safe Interactions with Foreign Languages through Omniglot: Difference between revisions

Latest revision as of 05:29, 24 July 2025

Building Bridges: Safe Interactions with Foreign Languages through Omniglot
Author	Leon Schuermann and Jack Toubes, Princeton University; Tyler Potyondy and Pat Pannuto, University of California San Diego; Mae Milano and Amit Levy, Princeton University
Conference	USENIX OSDI 2025
pdf	https://www.usenix.org/conference/osdi25/presentation/schuermann
Year	2025

개요

Memory, type safety language와 같은 경우에는 버그를 없애긴 하지만 100% 완벽하게 버그를 없앨 수는 없다. 이는 Unsafe한 파트가 항상 존재하기 때문이다. Omniglot은 Rust의 safety와 soundness에 대한 면밀한 분석을 통해서 Unsafe한 파트(즉 unsafe library)와 아닌 Safe라이브러리의 분리를 통해서 안전한 시스템을 달성하고자 하였다. Omniglot은 kernel와 POSIX Compatible user-level library두 모델로 포팅되었으며, 두 경우 모두 성능과 안정성 모두 State-of-the-art의 경향을 보였다.

Motivation & Importance

아무리 safe한 언어로 semantic으로 프로그램을 작성한다고 하더라도, 결국에는 성능 혹은 Compatibility를 위해서 unsafe한 라이브러리/코드를 사용하게 된다. 기존에는 이러한 unsafe한 부분때문제 전체 시스템의 안정성이 위협받았다.

Main Idea

우선 모든 Unsafe한 파트를 하나의 라이브러리에 몰아 넣는다. 그리고 Language safety를 이용해서, 모든 unsafe한 코드 수행을 sandboxing하는 framework를 통해서만 호출하도록 한다.

Design

급하게 읽어서 정리가 부족할 수 있으며, 내용에 일부 오류가 있을 수도 있습니다.

Memory Safety: Intel MPK와 같은 하드웨어 기반의 Memory sandboxing mechanism을 적용하여서 Memory safety를 달성한다.

Aliasing and Mutability: API디자인을 통해서 구현

Type Safety: Return value를 Taint type으로 하여서, Return시에 Runtime check를 통해서 Taint한지 안한지를 체크한다.

Concurrently: 외부 코드가 잘 작성되었을 가정을한다.

@@ Line 12: / Line 12: @@
 우선 모든 Unsafe한 파트를 하나의 라이브러리에 몰아 넣는다. 그리고 Language safety를 이용해서, 모든 unsafe한 코드 수행을 sandboxing하는 framework를 통해서만 호출하도록 한다.
-== [[Conclusion]] ==
+== Design ==
-개인적으로는, Unsafe한 부분을 하나의 라이브러리에 모아 관리한다고 해서 전체 시스템의 TCB(Trusted Computing Base)가 실질적으로 낮아진다고 보기는 어렵다고 생각한다. 물론 이 방식이 프로그래밍의 편의성(Programmability)이나 디버깅 용이성(Debuggability) 측면에서는 긍정적인 효과가 있을 것이다. 하지만 TCB를 계산할 때, 단순히 Unsafe한 코드를 특정 라이브러리에 집중시켰다고 해서 그 라이브러리를 사용하는 전체 코드가 TCB 범위 밖에 있다고 보기보다는, 여전히 해당 라이브러리를 호출하는 모든 경로가 영향을 받을 수 있기 때문에, TCB 측면에서는 유사한 수준으로 간주하는 것이 더 타당하다고 본다. 결국 중요한 것은, 시스템 전체에서 버그 가능성이 있는 코드가 어느 정도의 비중을 차지하는지이며, 코드의 물리적 분리보다는 해당 코드가 시스템에 미치는 실제 영향 범위가 더 본질적인 판단 기준이 되어야 한다고 본다. <수정중>
+급하게 읽어서 정리가 부족할 수 있으며, 내용에 일부 오류가 있을 수도 있습니다.
+; Memory Safety
+: [[Intel MPK]]와 같은 하드웨어 기반의 Memory sandboxing mechanism을 적용하여서 Memory safety를 달성한다.
+; Aliasing and Mutability
+: API디자인을 통해서 구현
+; Type Safety
+: Return value를 Taint type으로 하여서, Return시에 Runtime check를 통해서 Taint한지 안한지를 체크한다.
+; Concurrently
+: 외부 코드가 잘 작성되었을 가정을한다.