Meltdown과 Spectre: 예측실행이 남긴 CPU 부채널 취약점
Meltdown과 Spectre의 비순차실행·예측실행 악용 원리, 캐시 타이밍 공격 방식과 운영체제·하드웨어 대응책을 정리한다.
2026-08-14 · 최초 발행 2025-06-04
CPU 최적화가 캐시에 남기는 흔적
Meltdown과 Spectre는 2018년 초 공개된 프로세서 취약점이다. 비순차실행(Out-of-Order Execution)과 예측실행(Speculative Execution)처럼 성능을 높이기 위해 설계된 기능이 공격의 출발점이 됐다.
비순차실행은 CPU가 명령어를 프로그램에 적힌 순서와 다르게 처리하는 방식이다. 명령어 사이에 의존성이 없다면 앞선 작업이 끝날 때까지 기다리지 않고 실행해 파이프라인 지연을 줄인다.
예측실행은 분기 예측(Branch Prediction)을 바탕으로 앞으로 실행될 가능성이 높은 경로를 미리 처리한다. 예측이 맞으면 계산 결과를 그대로 쓰고, 틀리면 결과를 버린다. 이 방식도 잠재적인 지연 시간을 낮춘다.
문제는 예측이 빗나가 결과가 폐기되더라도 캐시 상태의 변화까지 함께 되돌아가지는 않는다는 데 있다. 실행 중 접근 권한이 없는 메모리에 일시적으로 닿을 수 있고, 그 과정에서 남은 캐시 흔적을 부채널(Side-channel)로 관찰하면 보호된 정보를 유출할 수 있다.
Meltdown과 Spectre가 겨냥하는 경계
Meltdown은 주로 Intel 프로세서에 영향을 준다. 비순차실행 중 접근 권한 검사가 지연되는 점을 이용해 커널 메모리와 사용자 메모리 사이의 격리를 우회하며, 사용자 공간에서 커널 메모리 내용을 읽을 수 있다.
Spectre는 거의 모든 현대 프로세서에 영향을 미친다. 프로세서의 분기 예측 메커니즘을 악용해 프로그램이 자신의 메모리 경계를 넘어 데이터를 읽도록 유도한다. 변형이 다양해 방어가 더 어렵다.
Flush+Reload로 캐시 접근 시간을 읽는 방식
Flush+Reload는 관찰 대상 메모리를 캐시에서 먼저 제거한 뒤, 예측실행 과정에서 남는 캐시 흔적을 다시 읽는 방식이다.
먼저 공격자는 확인에 사용할 메모리를 준비하고 캐시에서 해당 항목을 삭제한다(Flush). 이어 원래 실행되어서는 안 되는 코드를 실행해 보호된 메모리에 일시적으로 접근한다.
실행이 허용되지 않는다는 사실이 확인되면 해당 명령은 파이프라인에서 제거된다. 다만 확인과 실제 취소 사이에는 misspeculation window가 존재하며, 공격자는 이 구간을 최대화하기 위한 기법을 사용한다.
이 구간에서 보호된 정보에 접근한 뒤, 그 값에 대응하는 메모리 영역을 읽으면 캐시에 흔적이 남는다. 이후 준비했던 메모리를 순차적으로 다시 읽어 접근 시간을 측정한다. 캐시에 남은 영역은 빠르게 접근되며, 캐시 접근 속도 차이인 약 200 사이클 vs 2000 사이클로 보호된 정보를 간접적으로 유추할 수 있다. 공격이 너무 느리거나 취소가 빨리 이뤄지면 실패한다.
Prime+Probe에서 관찰하는 캐시 탈락
Prime+Probe는 공격자가 먼저 데이터를 캐시에 채우고, 이후 캐시에서 밀려난 항목을 확인하는 방식이다.
공격자는 확인할 메모리를 준비해 캐시에 적재한다(Prime). 이후 비순차실행 또는 예측실행 과정에서 보호된 메모리에 일시적으로 접근하고, 그 값에 대응하는 메모리 영역에 쓰기 작업을 수행한다.
이 과정은 해당 위치의 캐시 항목을 탈락시킬 수 있다. 명령이 취소되기 전의 misspeculation window가 공격에 쓰이며, 이후 메모리를 다시 읽어 느려진 영역을 찾아 보호된 정보를 간접적으로 유추한다. 이 경우에도 공격이 충분히 빨리 수행되지 않거나 취소가 빠르면 정보 추출에 실패한다.
격리 경계를 넘어선 영향
이 취약점은 Intel, AMD, ARM 등 대부분의 현대 프로세서에 영향을 미친다. 클라우드 환경에서는 가상머신 간 격리 우회 가능성이 있고, 브라우저 샌드박스 보안 메커니즘도 무력화될 수 있다. 암호화 키와 패스워드 같은 민감 정보 역시 탈취 대상이 될 수 있다.
공개 이후 AWS, Google Cloud, Azure 등 클라우드 제공업체는 긴급 패치를 적용했다. 브라우저 개발사들은 JavaScript 타이머의 정밀도를 낮추는 대응책을 도입했으며, 다수의 연구팀은 실제 환경에서 수 KB/s 속도의 정보 유출을 시연했다.
완화책이 요구하는 비용
운영체제 수준에서는 KPTI(Kernel Page Table Isolation)로 커널과 사용자 공간 메모리를 완전히 분리하는 방식이 사용된다. KAISER는 Linux의 KPTI 구현이며, 인터럽트 처리 메커니즘 개선도 대응 범위에 포함된다.
하드웨어 측면에서는 마이크로코드 업데이트로 일부 영향을 완화할 수 있다. 새 프로세서 설계에는 보안 고려사항을 통합하고, Intel SGX와 같은 보안 확장 기능을 강화하는 접근도 이뤄진다.
대부분의 대응책은 5-30% 성능 저하를 초래한다. 완전한 해결책에는 하드웨어 재설계가 필요하며, 일부 환경에서는 취약점 위험과 성능 유지 사이에서 선택이 이뤄진다.
하드웨어부터 다시 본 보안
Meltdown과 Spectre는 컴퓨터 구조와 보안의 관계를 다시 보게 만든 취약점이다. 약 20년간 프로세서 설계가 성능 최적화에 집중하는 동안 잠재적인 보안 문제가 간과됐다는 점이 드러났다. 하드웨어 설계 단계부터 보안을 고려하는 Security by Design 원칙이 필요한 이유이기도 하다.
이 취약점은 악성 소프트웨어나 구현 버그가 아니라, 의도대로 작동하는 하드웨어의 기본 특성에서 발생했다. 보안을 소프트웨어 계층에만 맡길 수 없으며, 하드웨어부터 애플리케이션까지 전체 스택을 함께 다뤄야 한다는 사실을 남겼다.