FTL, 리눅스 바이너리 호환 사용자 공간 OS로 클라우드 컨테이너 격리 겨냥

v0.1.0이 방금 나왔는데 멀티스레드 Tokio 런타임 기반 async Rust 지원이랑 리눅스 호환 레이어에서 빠져 있던 것들을 많이 채웠음. 내 프로젝트는 아님.

이거 유니커널이냐고 물어보면 좀 애매함. 시스템 콜을 받는 커널이고 하드웨어 드라이버 대신 하이퍼바이저랑 통신하도록 줄여놓은 거라, 유니커널이라는 용어 자체가 깨진 것 같음. 라이브러리처럼 링크하는 거면 아니고 단일 프로세스 지원이 목적이면 맞음.

읽어보니 gVisor보다 Unikraft에 가까운 것 같은데, intercept 경로는 더 빠른 걸 수도 있겠음. 첫인상이 그랬어.

프로젝트에서 관련 선행 연구를 FAQ로 명확히 정리해주면 채택이 늘 거라고 봄. 사람이든 AI든 독자가 알아서 비교하게 두면 안 됨.

둘 다인 것 같기도 함. 자기 게스트로 돌긴 하는데 리눅스 syscall에 1:1로 맞춘 걸 구현하는 게 아니라 리눅스가 라이브러리로 돌고 축소된 집합으로 정상 syscall 경로를 타는 구조임. 그래서 공통 경로에서 gvisor의 syscall에서 vmexit로 가는 대신 process에서 게스트 syscall, 다시 vmexit로 가니까 더 싸지는 않을 듯.

지금 KVM 0day에 VM escape 취약점까지 나온 상황이니, 기본적으로 메모리 안전하고 레거시 부담 없는 새 운영체제를 볼 때가 된 것 같음.

마이크로커널 비슷한 거고 리눅스 프로그램을 돌리며 자기 웹사이트를 서비스할 정도면 충분함. 잘 됐으면 좋겠음.

Rust로 작성했는데 사이트에는 그 얘기가 없음. 이제 그 단계는 지난 모양임.

이제는 왜 Rust로 안 썼냐고 묻는 시대로 넘어간 거지.

FTL에 new라는 단어를 보고 게임 FTL인 줄 알고 신났는데 아쉽게도 그 게임은 아님.

"클라우드용 OS"가 무슨 뜻인지 궁금함. KVM이나 paravirtualization에 디바이스 모델을 맡기고 FTL 게스트가 내부에서 여러 보안 워크로드를 돌리는 구조인지, 아니면 네이티브 하드웨어용 OS를 처음부터 만드는 건지. 하드웨어 지원 제약을 어디까지 두는지도 궁금하고, 리눅스가 가진 걸 다 다시 구현하지 않으려는 계산인지도 궁금함.

컨테이너는 대부분 독립 커널이 필요 없음. 이 설계는 컨테이너를 사실상 chroot jail에 가깝게 만들지만 그게 오히려 좋은 것임.

작성자는 seiya.me고 Vercel에서 일함. 꽤 제대로 된 사람임.

커널 설계 일부가 zircon이 떠오름. handle 기반 객체, VMO 같은 개념인데 선을 긋는 위치는 다름. 커널이 스레드는 알지만 프로세스는 모르는 식임.

MirageOS도 OS in a library라고 소개하는데 이거랑 비슷한 건지 궁금함.