Unikernel은 어려웠다. '었다'가 핵심이다
Unikernels were hard. key word: were
Geoffrey Huntley는 Justin Cormack과의 대화에서 unikernel이 다시 주목받는 이유를 설명한다. 과거에는 애플리케이션이 운영체제 자체가 되는 unikernel을 만들려면 TCP 스택부터 스토리지까지 직접 라이브러리로 구현해야 해서 진입 장벽이 높았다. 하지만 이제 AI가 그 어려운 개념을 모델 가중치에 내재화했고, 필요한 라이브러리를 포팅하는 일도 에이전트에게 맡기면 몇 시간이면 끝난다. Huntley는 일주일 만에 OCaml로 Microsoft Orleans를 포팅한 분산 unikernel 운영체제 'Spaceleans'를 만들며 unikernel이 더 이상 어렵지 않다는 것을 증명했다.
Unikernel은 어려웠다. 핵심 단어는 '었다'. 이제 우리에겐 AI가 있다.
HN 토론
13- vsgherzi
이 주제에 대해 전에도 언급한 적이 있는데. 디버깅 능력은 어떡할 건가? 이제 애플리케이션 오버플로가 네트워크 스택의 일부를 망가뜨린다.
Oxide 에피소드에서 데이터 라인을 읽어내는 것에 대한 언급이 좀 있었지만, 솔직히 그건 실용적이지 않다고 본다.
줄어든 공격 표면은 멋지지만, 내 시스템의 가시성과 활성 상태를 희생하면서까지는 아니다
- lasiotus
Unikernel은 스펙트럼의 작은 쪽에 있고, Linux는 큰 쪽에 있으며, 그 중간에 공간이 아주 많다...
- eyberg
공격 표면을 줄이는 건 확실히 장점이지만, unikernel을 실행하는 것의 넘버원 보안 이점에는 전혀 가까이 못 간다.
그래서 나는 '공격 표면 줄이기'에 대해 그렇게까지 이야기하는 걸 별로 좋아하지 않았다. 왜냐하면 사람들은 필연적으로 코드 라인 수로 눈을 돌리는데, 줄어드는 건 좋긴 해도 가장 큰 문제가 진짜 무엇인지를 전혀 전달하지 못하기 때문이다.
취약점 익스플로잇은 데이터 유출의 넘버원 진입점이고, OS 명령어 주입은 작년 CISA Kev에서 넘버원 CWE다.
작년 DBIR에서 시스템 침입은 64번인가 반복되었다.
운영체제 자체가 말 그대로 문제다. OS는 본질적으로 여러 다른 프로그램을 실행하도록 만들어진 반면, unikernel은 단 하나만 실행하기 때문이다.