인텔 시피유 버그 에 대하 여 기술 분석 - Hardware - Neuromancer . kr 
 인텔 시피유 버그 에 대하 여 기술 분석 
 hephaex 2018 - 01 - 09 05 : 46 : 18 UTC # 1 
 취약점 1 : 시피유 명령 의 분기 예측 메커니즘 을 악용 할 수 있 다 . 
 이번 취약점 은 기본 적 으로 투기 실행 과 관련 이 있 다 . 파이프 라인 화 된 실행 유닛 을 가진 CPU 는 “ 명령어 처리 가 끝난 후 ” 다음 명령 을 읽 는 다면 실행 시간 이 지연 이 발생 하 게 된다 . 따라서 기본 적 으로 명령어 를 처리 하 는 동안 다른 다음 명령 과 다음 다음 명령 을 점점 미리 읽 기 ( pre - fetch ) 한다 . 
 이것 을 파이프라인 을 이용 한 패치 , 또는 디 코딩 처리 라고 한다 . 일반 적 으로 프로그램 은 반복 된 실행 을 하 는 부분 이 있 게 되 고 어딘가 에서 분기 가 들어가 게 된다 . 분기 의 경우 “ 명령 의 실행 결과 에서 분기 할 주소 가 결정 된다 . ” 그래서 프로세서 가 파이프 라인 를 사용 하 지 않 는 다면 문제 가 되 지 않 는다 . 하지만 실행 속도 를 효과 적 으로 빠르 게 만다는 파이프 라인 을 사용 하 지 안 는 시피유 는 거의 없 다고 보 면 된다 . 즉 파이프 라인 화 되 어 있 으면 , 결과 가 나올 때 까지 아무것 도 하 지 않 고 기다리 는 것 은 시간 낭비 가 된다 . 그래서 “ 분기 결과 를 미리 예측 하 여 두 고 그 분기 결과 에 따라 다음 명령 을 실행 하 는 ” 과정 으로 파이프 라인 이용 을 효과 적 으로 할 수 있 도록 실행 처리 를 구현 한다 . 
 이 를 위해서 는 분기 결과 를 정확 하 게 예측 해야 만 한다 . 시피유 제조사 는 각사 마다 분기 예측 메커니즘 에 주력 하 고 있 으며 , 분기 명령 이 있 다면 , 그 직후 의 명령 에 관해서 는 투기 실행 이 라는 방법 을 주로 사용 한다 . 분기 예측 을 통해서 여기 의 명령 이 실행 될 것 이 다 라고 예측 하 여 먼저 실행 하 는 것 이 다 . 여기 서 판단 이 잘못 되 면 그때 까지 투기 적 으로 실행 했 던 결과 를 버리 고 새로운 명령 을 다시 읽 는 데 서 시작 된다 . 취약점 1 ( Variant 1 ) 은 이 투기 실행 을 악용 한 것 이 다 . 
 원래 의 프로그램 이 본래 허용 된 범위 를 초과 하 여 메모리 액세스 하 려고 한 것 이 라고 한다 . 물론 이것 은 CPU 의 검사 기구 에 걸리 는 위해 도중 에 멈추 는 것 ( 결과 적 으로 실행 되 지 않 습니다 ) 하지만 투기 실행 메커니즘 덕분 에 " 허용 되 는 메모리 범위 를 초과 했 는지 " 확인 까지 는 투기 메모리 액세스 를 수행 하 게 된다 . 이렇게 되 면 “ 본래 허용 되 지 않 는 메모리 주소 에 데이터 가 데이터 캐시 에 로드 되 어 버리 게 된다 . ” 게다가 이 때 " 로드 되 었 는지 여부 는 ? 읽 기 속도 를 측정 하 여 추정 할 수 있 다 . 본래 액세스 메모리 영역 이 므로 페이지 오류 가 발생 했 다면 당연히 캐시 액세스 의 경우 보다 늦 어 지 기 때문 이 다 . 
 취약점 2 : 분기 된 메모리 주소 를 추정 할 수 있 다 . 
 다음 은 Variant 2 이 다 . 방금 전 분기 예측 한다는 말 을 했 지만 , 분기 예측 시 사용 되 는 것 이 BTB ( Branch Target Buffer ) 이 다 . 이것 은 자주 이용 되 는 분기 대해서 는 그 때 분기 대상 주소 를 저장 하 는 것 이 더욱 신속 한 분기 예측 을 수행 할 수 있 도록 하 자는 것 이 다 . 문제 는 이 BTB 는 하나 밖 에 없 다 , 즉 OS 의 내부 에서 사용 하 는 분기 주소 도 응용 프로그램 에서 사용 하 는 분기 주소 도 동일시 되 어 저장 되 어 있 다 . BTB 의 구조 자체 는 공개 되 어 있 지 않 지만 , Google 의 Zero Project 는 Haswell 의 구조 를 연구 하 고 Indirect Branch , 간접 분기 의 경우 에 동일 한 물리 적 CPU 에 속하 는 스레드 가 다른 하나 의 스레드 에 영향 을 미치 는 하 는 것 을 발견 했 다 . 이 를 이용 하 여 다른 스레드 에 할당 된 메모리 주소 를 추정 할 수 있 는 것 으로 밝혀 되 었 다 . 
 Variant 1 / 2 대해서 는 확실히 문제 가 있 지만 , 엄격 한 것 은 아니 다 . 어디 까지 나 다른 프로세스 에 할당 된 메모리 주소 를 추정 할 수 있 다는 수준 의 것 밖 에 없 기 때문 이 다 . 
 취약점 그 3 : 잘 못 된 캐시 액세스 가 가능 하 다 . 
 이 에 대해 Variant 3 은 좀 더 심각 하 다 . Variant 3 은 Variant 1 의 연장 에 있 다 . Meltdown 에 관한 논문 은 다음 과 같 은 샘플 코드 에서 이 를 설명 하 고 있 다 . 
 4 mov al , byte [ rcx ] ( rcx 에 표시 된 주소 의 내용 1 Byte 를 al 레지스터 에 저장 ) 
 5 shl rax , 0 xc ( rax 레지스터 의 내용 을 12 bit 오른쪽 시프트 ) 
 6 jz retry ( shl 의 처리 결과 가 0 이 되 면 retry : 로 이동 
 7 mov rbx , qword [ rbx + rax ] ( rbx 에 rbx + rax 주소 의 내용 을 포함 ) 
 지금 샘플 코드 는 일반 사용 자 메모리 주소 에서 작동 하 고 있 다 . 행 번호 4 “ mov al , byte [ rcx ] ” ( rcx 레지스터 에 표시 된 주소 의 데이터 1 byte 를 al 레지스터 에 로드 ) 를 실시 한 경우 권한 위반 ( 커널 공간 의 주소 에 액세스 한 ) 에서 예외 처리 로 이동 하 게 된다 . 단 , 예외 처리 에 날 전 에 실제로 4 - 7 의 처리 가 CPU 내부 에서 실행 되 어 그 결과 캐시 는 rcx 에서 나타난 어드레스 에서 시작 하 는 데이터 가 받 아 들여 진다는 것 이 다 . 일단 캐시 로 옮겨 버리 면 후 캐시 내용 을 다시 가져 다시 것 으로 , 본래 보호 되 어야 커널 주소 가 그대로 읽힌다 . 
 실제로 Meltdown 팀 은 이 기술 을 이용 하 여 암호 를 읽 는 데 모를 공개 했 다 . Variant 1 / 2 에 비해 이 Variant 3 의 영향 은 매우 크 다 . 이것 이 가능 한 이유 는 CPU 내부 의 Page Table ( 가상 메모리 의 주소 와 물리 메모리 주소 의 대응 을 기록 한 테이블 ) 이 OS 커널 과 사용자 프로세스 용 으로 함께 되 어 있 는 것 이 원인 이 다 . 먼저 목록 으로 돌 아 오 면 rcx 커널 주소 를 지정 하 면 해당 주소 를 Page Table 로 변환 할 수 없 는 경우 물리 적 메모리 의 주소 를 모르 기 때문 에 캐시 에 원래 캡처 수 없 게 된다 . 대책 으로 는 OS 커널 위한 PTE 와 사용자 프로세스 를 위한 Page Table 을 분리 하 기 만 하 면 된다 . 이 기술 은 KPTI ( Kernel Page - Table Isolation ) 라고 한다 . 원래 Linux 에서 는 KASLR ( Kernel Address Space Layout Randomization ) 라는 만일 커널 에 액세스 되 어도 영향 을 적 게 줄이 는 기술 이 2014 년 경 부터 구현 되 어 있 으며 , 이 를 더욱 개량 한 KAISER ( Kernel Address Isolation to have Side - channels Efficiently Removed ) 는 PTE 를 분리 하 는 대책 을 세운 것 이 2017 년 에 준비 되 어 있 었 다 . 이번 Meltdown 에 대한 대책 으로서 이 KAISER 를 기반 으로 한 것 이 KPTI 패치 로 제공 되 고 있 다 . 또한 Windows 와 Android , macOS 등 에 대해서 도 마찬가지 로 OS 커널 과 사용자 프로세스 용 으로 Page Table 을 분리 하 면 대책 수 있 는 것 은 이미 패치 가 준비 되 었 다 . 이 KPTI 대책 을 하 면 안전 성 은 확보 할 수 있 는 원인 으로 Variant 1 / 2 에 대해서 도 동시 에 패치 가 제공 되 는데 , 예 를 들 어 AMD 는 Variant 2 는 인텔 의 것 과 BTB 의 구조 가 다른 데 다 지금 공격 당한 사례 도 없 기 때문 에 거의 위험 0 하 다고 하 고 있 다 . 
 순수 하 게 계산 만 하 고 있 는 분 은 대부분 성능 이 저하 가 크 지 않 지만 I / O 를 많이 행하 는 경우 에 는 성능 저하 가 현저 하 게 나오 게 된다 . Postgresql 에서 의 성능 저하 도 HDD 를 만큼 돌리 는 SQL 데이터베이스 에서 의 결과 라는 것 을 생각 하 면 확실히 의미 있 는 성능 차이 가 보 고 되 었 다 . 지금 이 영향 을 받 는 것 은 인텔 의 비 순차 실행 을 지원 하 는 , Out - of - Order 기계 , 즉 펜티엄 이후 의 전부 ( Atom 대해서 는 이전 것 은 괜찮 겠 지만 , 비 순차 실행 을 지원 하 는 Silvermont 이후 에 도 위험 성 이 있 다 . ) , ARM 의 Cortex - A 75 가 현재 대상 이 되 었 다 . 다만 ARM 의 경우 아키텍처 라이선스 를 받 아 공급 업체 독자 적 으로 구현 한 제품 도 많 기 때문 에 향후 대상 이 늘어날 가능 성 도 있 다 . 또한 이번 에 는 나와 있 지 않 지만 , IBM 의 Power 와 MIPS 또는 IBM / NXP 의 PowerPC 등 도 잠재 적 으로 이번 취약점 을 가지 고 있 을 가능 성 이 있 는 것 으로 각 벤더 의 보고서 를 기다려 봐야 한다 .