Meltdown과 Spectre는 2018년 1월 함께 공개됐지만 같은 취약점은 아니다. 둘 다 CPU가 성능을 위해 먼저 실행한 명령의 microarchitectural side effect를 관찰해 데이터를 추론한다. 다만 공격하는 경계와 필요한 완화책이 다르다.
권한 검사가 성공한 채로 데이터를 읽는 공격이 아니다
현대 CPU는 다음에 필요할 가능성이 높은 명령을 미리 실행한다. 예측이 틀리면 architecture 관점의 결과는 폐기한다. 그러나 cache, buffer와 branch predictor 같은 내부 상태에는 흔적이 남을 수 있다.
공격자는 대략 다음 흐름으로 이 흔적을 이용한다.
- CPU가 접근 검사가 끝나기 전에 명령을 transient하게 실행하도록 유도한다.
- 보호된 값에 따라 서로 다른 cache line을 건드리게 한다.
- architecture 결과는 폐기되고 fault 또는 잘못된 예측이 처리된다.
- 이후 memory access 시간을 재 cache 상태의 차이를 측정한다.
- 여러 번 반복해 비밀 값의 일부를 추론한다.
즉, 일반 load가 권한 검사를 통과해 값을 반환하는 방식이 아니다. 폐기된 실행이 남긴 timing side channel을 관찰한다. 이 차이를 이해해야 “추측 실행을 전부 끄면 된다”거나 “OS permission만 있으면 막힌다”는 단순화를 피할 수 있다.
Meltdown과 Spectre는 공격 경계가 다르다
| 구분 | 대표 CVE | 핵심 메커니즘 | 대표 완화 방향 |
|---|---|---|---|
| Meltdown, Variant 3 | CVE-2017-5754 | Rogue Data Cache Load로 권한 경계를 넘는 transient load의 흔적 이용 | Page Table Isolation과 CPU·OS update |
| Spectre Variant 1 | CVE-2017-5753 | 조건 분기의 bounds check를 잘못 예측하도록 유도 | bounds clipping, LFENCE, compiler·code 변경 |
| Spectre Variant 2 | CVE-2017-5715 | indirect branch target predictor를 오염시켜 gadget으로 유도 | retpoline, IBRS/eIBRS, IBPB, STIBP, microcode |
Meltdown은 original disclosure에서 특히 user와 kernel의 privilege boundary가 중심이었다. CVE-2017-5754로 분류되며 Rogue Data Cache Load라고도 불린다. Linux의 Page Table Isolation(PTI)은 user mode page table에서 불필요한 kernel mapping을 분리해 공격 표면을 줄인다.
Spectre는 공격자가 victim의 branch prediction을 조작해 원래 실행되면 안 되는 경로를 transient하게 실행하도록 유도한다. Variant 1은 conditional check, Variant 2는 indirect branch prediction을 주로 겨냥한다. Process, sandbox, VM과 privilege 경계 등 공격 scenario가 다양해 하나의 patch로 끝나지 않는다.
모든 CPU가 같은 방식으로 영향받지는 않는다
“Meltdown은 Intel, Spectre는 모든 CPU”처럼 한 문장으로 고정하면 제품과 variant 차이를 놓친다. CPU vendor, family, microcode, firmware, kernel과 virtualization 구성이 실제 영향 범위를 결정한다.
Linux Spectre 문서는 여러 Intel·AMD·Arm·IBM·Apple 계열을 포함한 광범위한 high-performance processor가 영향을 받을 수 있다고 설명하지만, 정확한 상태는 vendor 정보와 실행 중인 system의 vulnerability report로 확인하라고 안내한다. Meltdown도 모든 Intel·AMD·Arm CPU가 동일하게 취약하다고 일반화하면 안 된다. model별 advisory를 확인한다.
완화책은 공격 variant별로 다르다
Meltdown의 대표적인 OS 완화는 PTI다. User mode에서 사용하는 page table과 kernel mode page table을 더 강하게 분리해 speculative path가 접근할 수 있는 kernel mapping을 줄인다.
Spectre Variant 1은 취약한 code path를 찾아 bounds clipping과 speculation barrier를 적용하는 방식이 중심이다. 모든 conditional branch에 하나의 system-wide switch를 적용하는 문제는 아니다.
Spectre Variant 2에는 CPU와 세대에 따라 여러 수단이 조합된다.
- retpoline은 indirect branch의 speculative path를 안전한 loop에 가둔다.
- IBRS·eIBRS는 indirect branch prediction 사용 범위를 제한한다.
- IBPB는 security domain 전환 시 branch prediction state 격리에 사용된다.
- STIBP는 같은 physical core의 sibling thread 사이 영향을 줄인다.
- microcode update가 필요한 기능도 있다.
최신 kernel은 CPU capability와 microcode를 보고 기본 완화를 선택한다. 오래된 글의 특정 boot option을 그대로 적용하기보다 배포판과 cloud provider의 현재 security advisory를 먼저 확인해야 한다.
Linux에서는 실행 중인 상태를 직접 확인한다
grep . /sys/devices/system/cpu/vulnerabilities/meltdown \
/sys/devices/system/cpu/vulnerabilities/spectre_v1 \
/sys/devices/system/cpu/vulnerabilities/spectre_v2
결과는 단순한 Vulnerable·Not affected뿐 아니라 Mitigation과 활성화된 기법을 함께 보여 줄 수 있다. Virtual machine에서는 guest가 보는 CPU feature와 host의 실제 완화가 다를 수 있으므로 cloud provider advisory도 확인한다.
운영 순서는 다음처럼 잡는 편이 안전하다.
- CPU model, kernel, firmware·microcode와 hypervisor version을 기록한다.
- kernel sysfs status와 vendor advisory를 함께 확인한다.
- OS·firmware·microcode의 supported update를 적용한다.
- reboot가 필요한 update인지 확인하고 status를 다시 읽는다.
- 보안 경계를 유지한 상태에서 workload latency와 throughput을 측정한다.
SMT와 보안은 variant별로 판단한다
Sibling logical processor는 physical core의 cache와 prediction resource 일부를 공유한다. Linux Spectre 문서는 Spectre Variant 2가 sibling thread를 공격 경로로 사용할 수 있으며 STIBP·IBPB 등의 완화가 관련될 수 있다고 설명한다.
그러나 Hyper-Threading 자체가 Meltdown·Spectre의 원인이라고 말하면 부정확하다. L1TF, MDS, TAA와 일부 cross-thread attack은 별도의 완화와 SMT 판단이 필요하다. SMT 비활성화는 throughput 손실을 만들 수 있고 모든 variant의 유일한 해결책도 아니다. Threat model, multi-tenant 경계, kernel status와 vendor guidance를 보고 결정한다.
논리 CPU와 공유 자원의 구조는 Hyper-Threading과 SMT, cache와 memory hierarchy는 CPU와 메모리 차이에서 이어서 볼 수 있다.
성능 영향은 workload에서 측정한다
PTI, retpoline과 branch prediction control은 syscall·context switch·virtualization 비중에 따라 비용이 다르다. “몇 퍼센트 느려진다”는 숫자를 모든 서버에 적용할 수 없다.
완화를 끄고 빠른 결과만 비교하면 security boundary가 달라져 같은 조건의 benchmark가 아니다. 먼저 요구하는 threat model과 완화 상태를 고정하고, representative traffic에서 throughput, p50·p99 latency, CPU time과 context switch를 비교한다. 변경 전후 sysfs status도 결과와 함께 보관한다.
핵심 정리
Meltdown과 Spectre는 transient execution의 흔적을 이용하지만 공격 경계와 완화책이 다르다. Meltdown은 Rogue Data Cache Load와 page table isolation, Spectre는 branch prediction을 악용하는 여러 variant와 code·compiler·microcode 완화가 핵심이다. CPU 이름만 보고 단정하지 말고 실행 중인 kernel status와 vendor advisory를 함께 확인해야 한다.
참고 자료
'배움과 성장 > 시스템·성능' 카테고리의 다른 글
| macOS에서 smartctl·lspci·ethtool 대신 무엇을 쓸까 (3) | 2024.09.20 |
|---|---|
| macOS에서 free 대신 메모리 확인하기: vm_stat·memory_pressure·top (1) | 2024.09.19 |
| Hyper-Threading과 SMT: 논리 CPU·공유 자원·성능 측정 (1) | 2024.09.19 |
| macOS Hardware 정보 확인: system_profiler·sysctl·ioreg 안전하게 쓰기 (0) | 2024.09.19 |
| 스풀링이란: 이메일 큐와 인쇄 큐가 작업을 버퍼링하는 방식 (4) | 2024.08.15 |
댓글