최근 리눅스 데스크톱에서 가상화 경험을 매끄럽게 만드는 기술들이 빠르게 발전 중임
GPU 드라이버가 Mesa를 통해 네이티브 컨텍스트를 지원하고, Wayland의 게스트–호스트 간 공유 기능도 개선되고 있음
예전엔 sommelier나 wayland-proxy-virtwl 같은 복잡한 프로토콜 파싱이 필요했지만, 이제는 wl-cross-domain-proxy 프로젝트가 이를 제대로 구현 중임
이 기능들을 활용하는 VMM으로는 muvm, 그리고 이들을 통합하는 솔루션으로 munix가 있음
정말 흥미로움. munix를 사용하는 머신 간에 앱을 라이브 마이그레이션할 수 있을지 궁금함
일시정지 후 전송하고 다시 재개하는 식으로 가상머신을 옮길 수 있다면 멋질 것 같음
이런 이유로 Red Hat은 2025년에도 여전히 중요함
이런 종류의 인프라 작업은 항상 필요함
오히려 반대 주장을 할 수도 있음
Red Hat이 보안 관련 커밋을 선택(cherry-pick)할 때, 상류(upstream)에서 어떤 커밋이 보안과 관련 있는지 알려주지 않으면 어떻게 알 수 있겠음?
가끔 100% 보안이 완벽한 OS를 꿈꿔봄
아마 형식 검증(formal verification) 이나 Rust가 열쇠일지도 모르겠음
해킹당하지 않는다는 확신을 갖고 싶음
“해킹당하지 않는 OS”라니 멋짐. 하지만 결국 사회공학 공격이 남음
결국 인간 자신이 가장 큰 취약점임
이런 시도는 이미 여러 번 있었음. Microsoft의 Verve OS가 대표적임
심지어 어셈블리까지 검증되었고, Dafny도 여기서 나왔음
하지만 시장에서는 ‘좋은 품질보다 빠른 배포’가 우선이라 이런 아이디어가 주류로 가기까지는 수십 년이 걸림
대부분의 경우 보안 버그로 침해되는 격리 기능은 실제로는 관리 편의성 때문에만 쓰임
진짜 격리를 위해선 가상화나 물리적 분리가 필요함
그래서 “100% 안전한 OS”에 많은 기여자를 모으긴 어려움
그래도 이런 주제에 관심 있다면 여러 OS 개발 프로젝트가 있음
솔직히 Encrypted Client Hello가 널리 지원되기 전까지는 굳이 할 필요가 없다고 생각함
Caddy로 설정하는 건 쉽지만, 개인 블로그처럼 정적 사이트라면 암호화의 실익이 거의 없음
어차피 도메인과 IP는 평문으로 노출되니까 큰 차이가 없음
그들이 정말 그렇게 생각한다면 CNA를 제거했어야 하지 않겠음?
그건 곧 “모든 보안 연구자가 커널 취약점을 임의로 정의할 수 있다”는 뜻이 됨
하지만 일부 연구자는 CVE 개수만 늘리려는 경향이 있어서, 실제로는 무해한 버그에도 높은 우선순위를 부여하려 함
“보안 문제를 보고하려면 암호화를 강제한다면, 이 정책을 재고하라(UK 정부를 말하는 거임)”
이 부분은 그냥 웃김
“버그는 버그일 뿐”이라는 말은 너무 단순함 root 권한이 필요한 DoS와 비권한 사용자에서 시스템 장악은 완전히 다름
어떤 버그는 명확히 보안 경계 위반을 일으키는데, 이런 건 보안 버그로 분류해야 함
Greg에게 이건 수십 년째 설명된 내용임
결론적으로, 최신 버전을 돌리지 않으면 커널은 완전히 패치되지 않은 상태임
CVE는 기피되고, 취약점 수정은 커밋 로그에 숨겨짐, 공격자는 그걸 보고 알아챔
“최신 버전만 패치된다는 건 대부분의 소프트웨어에도 해당되는 얘기 아닌가?”
왜 굳이 이걸 강조해야 하는지 모르겠음
고객들이 Docker 이미지에서 커널 관련 패치를 요구함
하지만 Docker는 커널을 포함하지 않는데 말이지
커널 없이 이미지를 배포할 방법이 있어야 함
리눅스 커널이 컨테이너 이미지에 실수로 포함될 수 있나?
일반적인 베이스 이미지는 커널을 포함하지 않음
Hacker News 의견들
최근 리눅스 데스크톱에서 가상화 경험을 매끄럽게 만드는 기술들이 빠르게 발전 중임
GPU 드라이버가 Mesa를 통해 네이티브 컨텍스트를 지원하고, Wayland의 게스트–호스트 간 공유 기능도 개선되고 있음
예전엔 sommelier나 wayland-proxy-virtwl 같은 복잡한 프로토콜 파싱이 필요했지만, 이제는 wl-cross-domain-proxy 프로젝트가 이를 제대로 구현 중임
이 기능들을 활용하는 VMM으로는 muvm, 그리고 이들을 통합하는 솔루션으로 munix가 있음
일시정지 후 전송하고 다시 재개하는 식으로 가상머신을 옮길 수 있다면 멋질 것 같음
이런 이유로 Red Hat은 2025년에도 여전히 중요함
이런 종류의 인프라 작업은 항상 필요함
Red Hat이 보안 관련 커밋을 선택(cherry-pick)할 때, 상류(upstream)에서 어떤 커밋이 보안과 관련 있는지 알려주지 않으면 어떻게 알 수 있겠음?
가끔 100% 보안이 완벽한 OS를 꿈꿔봄
아마 형식 검증(formal verification) 이나 Rust가 열쇠일지도 모르겠음
해킹당하지 않는다는 확신을 갖고 싶음
결국 인간 자신이 가장 큰 취약점임
심지어 어셈블리까지 검증되었고, Dafny도 여기서 나왔음
하지만 시장에서는 ‘좋은 품질보다 빠른 배포’가 우선이라 이런 아이디어가 주류로 가기까지는 수십 년이 걸림
진짜 격리를 위해선 가상화나 물리적 분리가 필요함
그래서 “100% 안전한 OS”에 많은 기여자를 모으긴 어려움
그래도 이런 주제에 관심 있다면 여러 OS 개발 프로젝트가 있음
보안은 끝없는 경쟁임
한편 2026년이 되었는데도 Greg의 개인 웹사이트는 아직 TLS를 지원하지 않음
Caddy로 설정하는 건 쉽지만, 개인 블로그처럼 정적 사이트라면 암호화의 실익이 거의 없음
어차피 도메인과 IP는 평문으로 노출되니까 큰 차이가 없음
그들이 정말 그렇게 생각한다면 CNA를 제거했어야 하지 않겠음?
하지만 일부 연구자는 CVE 개수만 늘리려는 경향이 있어서, 실제로는 무해한 버그에도 높은 우선순위를 부여하려 함
“보안 문제를 보고하려면 암호화를 강제한다면, 이 정책을 재고하라(UK 정부를 말하는 거임)”
이 부분은 그냥 웃김
“버그는 버그일 뿐”이라는 말은 너무 단순함
root 권한이 필요한 DoS와 비권한 사용자에서 시스템 장악은 완전히 다름
어떤 버그는 명확히 보안 경계 위반을 일으키는데, 이런 건 보안 버그로 분류해야 함
Greg에게 이건 수십 년째 설명된 내용임
결론적으로, 최신 버전을 돌리지 않으면 커널은 완전히 패치되지 않은 상태임
CVE는 기피되고, 취약점 수정은 커밋 로그에 숨겨짐, 공격자는 그걸 보고 알아챔
왜 굳이 이걸 강조해야 하는지 모르겠음
고객들이 Docker 이미지에서 커널 관련 패치를 요구함
하지만 Docker는 커널을 포함하지 않는데 말이지
커널 없이 이미지를 배포할 방법이 있어야 함
일반적인 베이스 이미지는 커널을 포함하지 않음