CPU게이트

최근 수정 시각:

파일:나무위키+상위문서.png   상위 문서: 보안 취약점

파일:나무위키+관련문서.png   관련 문서: 인텔

주의. 사건·사고 관련 내용을 설명합니다.

이 문서는 실제로 일어난 사건·사고의 자세한 내용과 설명을 포함하고 있습니다. 특정 사건사고 문서는 유머성 서술과 비하의 표현이 제한되며, 사실관계를 작성할 때에는 출처를 반드시 표시해야 합니다.

틀 적용 시 해당 사건·사고에 맞는 분류도 달아 주시기 바랍니다. 분류 목록은 분류:사건사고 문서에서 확인하실 수 있습니다.

1. 개요2. 알려지게 된 과정
2.1. 연구진 공식 Q&A
3. 취약점 상세 정보
3.1. 멜트다운
3.1.1. CPU 마이크로아키텍처3.1.2. CPU 아키텍처3.1.3. 커널 값을 읽어내는 프로그램
3.1.3.1. 프로그램에 대한 간단한 설명3.1.3.2. 조금 더 기술적인 설명
3.1.4. AMD CPU에 멜트다운 취약점이 존재하지 않는 이유3.1.5. 차기 인텔 하드웨어의 해결책 예상3.1.6. 운영체제를 통한 임시방편3.1.7. 심각성
3.2. 스펙터3.3. 인텔 AMT 관련 추가 보안 문제
4. 해당 버그에 취약한 하드웨어5. 취약점에 대한 대응
5.1. 인텔5.2. AMD5.3. OS5.4. 웹 브라우저, 그 외
6. 사용자가 할 수 있는 대처법
6.1. 취약 여부 확인6.2. 바이오스 업데이트6.3. 윈도우6.4. macOS6.5. 리눅스
7. 사건 여파
7.1. 보안 패치 후 하드웨어 성능 하락7.2. 패치 자체의 문제
8. 이후 전개9. 외부 링크

1. 개요[편집]

2018년이 시작되자마자 세계 IT업계에 떨어진 핵폭탄
인텔 사상 최악의 위기

특정 CPU 아키텍처에서 발견된 몇 가지 중대한 보안 취약점 때문에 발생한 사건. 2018년 1월 3일 구글에서 최초로 발표하였다.

구글 프로젝트 제로의 얀 호른 수석연구원과 오스트리아 그라츠 공과대학, 그리고 업계 보안전문가들이 처음 발견했다. 얼마 전인 2017년 말에 인텔 관리 엔진 관련 보안 버그가 있었다. 이것도 보안 시스템을 무시하고 시스템을 망가뜨릴 수 있는 치명적인 버그였는데 불과 몇 개월만에 훨씬 위험한 버그가 잇달아 터져서 IT업계 전체가 비상 사태다. 흔한 보안 이슈가 아니라 게이트 소리를 듣는 대사건이다.

특히 인텔 CPU의 경우, 현역으로 사용 가능한 대부분의 제품[1]이 버그의 위험에 노출되어 50년 역사의 인텔 창업 이래 최악의 위기라는 우려도 나오는 상황이다. 또한 버그 보완 패치의 부작용으로 시스템 콜 성능이 심각하게 저하되어 더 큰 논란이 벌어지고 있다.

2. 알려지게 된 과정[편집]

사실 원래 이 버그는 구글의 사이버 보안 연구원 John Horn이 2017년경 메뉴얼을 보다가 발견하여, 마이크로소프트리눅스 개발진 등에게 알려 보안 패치 등 필요한 조치를 취한 뒤, 2018년 1월 9일 공개할 예정이었다. 하지만 리눅스 패치를 지켜보던 사람들이 낌새를 눈치채, 2018년 새해 즈음에 공개적으로 '무슨 버그인지는 정확히 모르겠지만 인텔 CPU에 심각한 버그가 있다'는 사실이 개발자들 사이에 알려지게 된다. 이 때문에 구글에서는 예정보다 빠른 1월 3일에 이 내용을 발표했다.

이 대응 패치 작업은 어마어마한 엠바고가 걸린 상태에서 비밀리에 진행되었는데[2], 리눅스 개발자들이 개발하는 과정에서 커널 핵심부를 건드려야 하기 때문에 할 작업이 많은 데다 그다지 필요 없을 기능들을 추가하기 위해 허겁지겁 일하고, 주고받는 이메일에 CC로 인텔, 구글, 아마존의 관계자들의 메일 주소가 달려 있고, 코드 주석엔 무언가 검열되어 있고, 인텔 CPU가 위험하다는 플래그가 존재하는 것을 보고 수상한 낌새를 눈치채 작업이 마무리 단계에 이른 시점에 예정보다 일찍 공개되었다.

레딧에서 처음 알려진 버그의 내용은 다음과 같았다. 번역 출처 원문 출처

  • 해당 버그는 인텔의 몇 세대에 걸친 버그입니다. 인텔 한정으로, AMD는 영향없는 것으로 보입니다. (다만 현재 커널 패치에서는 AMD를 수정사항에서 제외하는 항목이 머지되지 않은 상태. 즉 현 커널 패치에서는 같이 성능이 떨어질 것으로 예상됨.)

  • 해당 버그는 리눅스뿐만 아니라 Windows, macOS 모두에 영향을 줍니다.

  • 해당 버그는 엠바고로 인해 아직 전모가 밝혀지지는 않았습니다.

  • 해당 버그는 인텔 CPU의 버그로 인해 커널 메모리 정보가 유저 공간으로 유출될 수 있는 결함입니다.

  • 해당 버그로 인해 크게 공개되지는 않았지만 데이터 센터/클라우드 업체 등에서는 상당한 물밑작업이 진행되었을 것으로 예상됩니다.

  • 해당 버그의 수정으로 인해 발생하는 성능 손실은 각 OS와 기타에 따라 다르지만 대략 5~30% 정도로 알려져 있습니다.

  • 해당 버그에 대응하는 리눅스 커널 패치는 이미 릴리즈 되었습니다.

  • PCID 기능이 적용된 신형 인텔 CPU에서는 해당 버그의 커널 패치로 인한 성능 저하가 완화되는 것으로 알려져 있습니다.

  • 해당 버그에 대응하는 리눅스 커널 패치를 적용하고 테스트 해 보니….

  1. 파일시스템 I/O쪽은 성능이 반토막이 납니다.

  2. 컴파일러 벤치마크 중 initial setup 항목에서 15% 정도 성능이 저하됩니다.

  3. 커널 컴파일, 인코딩 등은 큰 영향이 없는 것으로 나타납니다.

  4. SQL 같은 DB 관련 벤치에서도 15% 정도 성능이 저하됩니다.

  5. 데이터 스트럭처 서버라는 것에서 6% 정도 깨집니다.

  6. 게임은 영향이 거의 없습니다.[3][4]


위에 나온 테스트 결과는 이곳에서 확인이 가능하다. 작업별 테스트 결과 게임 테스트 결과

위 내용 대로라면 현재의 모든 인텔 코어 i 시리즈 및 i 시리즈 기반 제온이 해당 보안 버그에 노출되어 있으며, 이를 운영 체제에서 SW적으로 수정할 경우 최대 30%까지도 성능 하락이 생길 수 있다고 한다.[5]

구글이나 아마존 등의 대형 IT 업체들 역시 이 문제를 피해가기 어려운 상황이라고 한다.

밝혀진 바로는 무려 약 22년여간 발매된 거의 모든 인텔 CPU들이 해당된다.

2.1. 연구진 공식 Q&A[편집]

이하 문답은 이 버그를 발견한 연구진이 게시한 짧은 Q&A의 일부분을 번역한 것이다. 원문은 이곳에서 볼 수 있다.

  • 내가 이 버그의 영향을 받을까요?

    • 틀림없이 그렇습니다.

  • 누군가가 멜트다운이나 스펙터를 써서 나를 공격[6]했는지 알 수 있나요?

    • 아마도 못 할 겁니다. 이 공격은 기존 방식의 로그 파일에 흔적을 남기지 않습니다.

  • 제 백신이 이 공격을 감지하거나 방어할 수 있나요?

    • 이론적으로는 가능하지만, 현실적으로는 어렵습니다. 일반적인 악성코드와 달리 멜트다운과 스펙터는 정상적인 프로그램과 구별하기가 어렵습니다. 다만 악성코드가 발견된 이후에는 코드를 비교함으로써 알려진 공격 방식을 이용하는 악성코드를 탐지할 수 있을 수 있습니다.

  • 어떤 것이 유출될까요?

    • 만약 당신의 시스템이 영향을 받는다면, 우리의 개념 실증 코드[7]로 당신 컴퓨터의 메모리의 내용을 읽을 수 있습니다. 여기에는 시스템에 저장된 암호와 중요한 데이터가 포함되어 있을 수 있죠.

  • 멜트다운이나 스펙터가 이미 다른 곳에서 악용되었던 적이 있을까요?

    • 우리도 모릅니다.

3. 취약점 상세 정보[편집]

파일:meltdown-text.png

파일:spectre-text.png

Meltdown
멜트다운
CVE-2017-5754

Spectre
스펙터[8]
CVE-2017-5715
CVE-2017-5753

그라츠 공과대학이 개설한 안내 사이트


관련 정보

현대 CPU에서 사용하는 최적화 기법인 비순차적 실행(out-of-order execution)과 추측 실행(speculative execution)의 결과로 나타나는 프로세서의 상태 변화에 대한 부채널 공격이다. 세 가지 유형(Variant)이 존재한다.

  • 유형 1: 경계검사 우회 (bounds check bypass, CVE-2017-5753)

  • 유형 2: 분기표적 주입 (branch target injection, CVE-2017-5715)

  • 유형 3: 불량데이터캐시 적재 (rogue data cache load, CVE-2017-5754)


유형 1과 2에 스펙터, 유형 3에 멜트다운이라는 이름이 붙었다. 간단히 요약하자면, '멜트다운'은 유저 프로그램이 운영체제 권한 영역을 훔쳐보는 취약점이고, '스펙터'는 한 유저 프로그램이 다른 유저 프로그램 메모리를 훔쳐보는 취약점이다.

CPU 명령어는 사용자에게는 순차적으로 실행되는 것처럼 보이지만, 내부적으로는 최적화를 위해 뒤쪽 명령어를 미리 실행한다든지 조건에 따라 분기되는 부분에서 가정을 세워 실행하는 등의 최적화를 수행한다. 이렇게 미리 계산한 값이 맞을 경우 해당 값을 실제로 적용해 사용자에게 보여주고, 틀리다면 해당 계산을 파기하는데 두 가지 취약점은 실제로는 실행되지 않는 파기된 계산에서 정보를 누출하는 공격을 수행한다.

이름에서 볼 수 있듯, 멜트다운이 훨씬 더 심각한 결함이다. 애초에 운영체제의 보안 자체가 철저하게 박살난다 해서 멜트다운이다. 스펙터는 이보단 덜 심각하고 구현하기도 어렵지만, 반대로 막는 것도 어렵다는 유령 같은 특징과 추측 실행(speculative execution)의 어감을 살려 스펙터라는 이름이 붙었다. 현재, 멜트다운은 거의 대부분의 인텔 프로세서와 ARM Cortex-A시리즈 기종[9]에서만 발생한다고 알려져 있다. 하지만 스펙터는 여러 명령어를 동시에 실행하는 최적화가 적용된 거의 대부분의 현대 프로세서에 적용되는 취약점이다. [10]

더 요약하자면:

1) 멜트다운과 스펙터, 총 2가지의 결함을 통한 3+1가지 공격코드(유형 1,2,3,3a)가 존재함.
1-2) 유형 1,2가 스펙터이고, 3,3a가 멜트다운
2) 멜트다운과 스펙터 취약점 중 더 심각한 것은 전자, 해당 결함은 인텔 CPU(유형 3)와 일부 ARM Cortex 제품군(유형 3a)에서만 발생.
3) 스펙터 취약점은 인텔, AMD, ARM 프로세서에서 발견.
4) 업데이트는 2가지 버그 다 수정하는데, 멜트다운 취약점 해결 과정에서 성능저하가 크게 발생.

자세한 내용은 Google Project Zero 블로그(영문)또는 공식 홈페이지에서 취약점 보고서 파일을 다운로드하여 알 수 있다.

3.1. 멜트다운[편집]

파일:나무위키:넘겨주기50px.png
이 문단은 멜트다운(보안 취약점)(으)로 검색해서 들어올 수 있습니다.

파일:intelbug.gif

멜트다운 데모. 메모리에 입력되는 비밀번호가 CPU에 정보 입력 즉시 노출되고 있다.[11][원본]


현재까지 나온 모든 보안 정책들을 무력화시키고 운영 체제 심장부의 메모리를 마음대로 읽을 수 있게 하는 초대형 하드웨어 취약점.

관심법
원리 일부 요약(본문 및 CBear 베플.)


멜트다운을 설명하기 위해서 CPU의 아키텍처와 마이크로아키텍처 두 가지에서 최소한의 정보를 서술하겠다. 참고로 CPU의 아키텍처와 마이크로아키텍처의 구분은 사용자(혹은 운영체제)가 기대하는 CPU의 동작 방식이 전자고 이를 실현하기 위한 구체적인 전략이 후자라고 보면 된다. 먼저 CPU 마이크로아키텍처를 설명하고 아키텍처를 설명하겠다.

3.1.1. CPU 마이크로아키텍처[편집]

  1. 명령어 (instruction)
    CPU의 동작은 할 일을 적어놓은 명령어가 수행되면서 동작한다. 3개의 명령어를 순차적으로 예를 들어보면, '(1) x라는 값을 읽고, (2) x에 1을 더하고, (3) x를 y에 저장해라' 같은 것들이다.

  2. 파이프라인(Pipeline)
    파이프라인은 CPU가 하나의 명령어를 처리하는 과정도 너무 복잡하고 많기 때문에, 이를 잘게 쪼개서 여러가지 작은 단계로 나누어 처리하는 방식이다. 파이프라인 단계는여러가지 나누는 방법이 있지만 대체로 크게 다음과 같이 8단계로 나눌 수 있으며, 거의 모든 명령어는 다음의 단계들을 하나씩 차례대로 밟아나가서 수행이 완료된다.

    1. 호출 (Fetch): 실행할 명령어를 주메모리에서 가져온다.

    2. 해독 (Decode): 명령어가 어떤 것인지 해독한다.

    3. 재명명 (Rename): 명령어가 쓸 물리 레지스터를 할당 한다. 가령 레지스터 eax에 값을 저장하는 명령어라면, 실행이 완료할 때까지 사용자에게 노출되지 않는 물리 레지스터에 값을 저장하고, 명령어가 최종적으로 완료되면 그때가 돼서야 값을 노출시킨다.

    4. 작업 지명 (Dispatch): 명령어가 재정렬 버퍼 (Re-Order Buffer, ROB) 의 맨 뒤에 들어간다. 다음 단계인 송출 (Issue) -> 실행 (Execute) -> 회신 (Writeback) 까지는 나중에 온 명령어가 먼저' 수행될 수 있는데 (Out-of-order execution), 최종적으로 명령어가 나갈 때는 원래 순서를 지켜서 유저는 순서가 바뀐 것을 알아챌 수 없게 하기 위해 ROB 맨 뒤에 명령어를 넣는다.

    5. 송출 (Issue): 명령어가 실행 (Execute) 단계에 필요한 자원이 준비되면 보낸다. 가령 레지스터 eax에 1을 더하는 명령어라면 일단 eax의 최신 값을 만들어내는 이전 명령어가 아래의 회신 단계를 완료할 필요가 있다.

    6. 실행 (Execute): 명령어를 실제로 수행한다. 가령 계산이나 주메모리에서 값을 읽어오거나 하는 것들이 이때 수행된다.

    7. 회신 (Writeback): 전송완료신호를 보내는 것. 만들어낸 결과값을 재명명 단계에 할당 받은 물리 레지스터에 저장한다. 이 값을 기다리던 명령어들에게 알려주는 것도 덤이다.

    8. 완료 (Commit): 사용자에게 노출되지 않는 물리 레지스터를 이제 사용자에게 노출시킨다.

    여기서 주목할 점은 완료를 하기 전에는 아직 사용자에게 명령어 수행의 결과가 노출되지 않았다는 것이다. 모종의 이유로 어떤 명령어 수행을 취소해야 하면, 가장 오래된 잘못 수행된 명령어부터 시작해서 이후 모든 명령어를 파이프라인에서 지워버리게 된다.!! 결과론적으로 버릴 명령어 수행에 에너지를 허비했기 때문에 이런 상황은 애초에 피하는 게 좋지만, 그럼에도 피할 수 없는 이유는 아래 추측 실행 (Speculative execution)에 설명한다.

  3. Cache (캐시)
    주메모리에서 값을 읽는 동작은 CPU의 명령어 처리 속도에 비하면 한참 느리다. 따라서 이 갭을 줄이기 위해 매우 빠르지만 작은 저장 공간이 CPU에 있는데, 이를 캐시라고 한다. 캐시는 공간이 작기 때문에 새로운 값을 읽어들이려면 기존 값을 다시 원래 위치로 돌려보내야 하는데, 주로 가장 오래된 값을 돌려보내는 방식을 취한다. 이는 최근에 접근한 값을 또 접근할 가능성이 높은 프로그램의 성질을 이용한 것이다.(참조지역성. Principle of locality) 또 한 값을 읽으면 그 근처의 값을 읽을 확률이 높은 점을 활용하기 위해, 어떤 값을 캐시로 가져올 때 주변의 값도 같이 가져온다. (역시 참조지역성의 원리) 이렇게 캐시에 값이 들어오는 덩어리를 캐시 라인이라고 하며, 보통 64바이트의 크기를 가진다. 구체적으로 메모리 주소를 64로 나눴을 때 몫이 같은 데이터들은 한 캐시 라인을 구성하게 된다.

  4. 분기 예측 (Branch prediction)
    분기 (Branch) 명령어는 어떤 조건이 맞으면 다음에 실행할 명령어의 위치를 임의로 지정할 수 있게 해준다. 이는 같은 명령어들을 반복해서 실행하거나 조건에 따라 다른 일을 하고 싶을 때 사용하는 매우 기본적인 명령어다. 다만 분기 (Branch) 명령어는 파이프라인에서 한가지 성능상 문제를 일으키는데, (1) 분기 (Branch) 가 가리키는 주소로 이동할지 말지', 그리고 (2) 이동하는 주소가 어디인지 알아내는 것은 해독 (Decode) 이나 실행 (Execute) 단계에 와서야 가능하다는 것이다. 다음 명령어 위치를 마냥 기다리자니 파이프라인의 호출 (Fetch) 단계가 잠시 놀게 된다. 이를 막고자 다음 명령어 위치를 예측하는 기법을 사용하는데 이것이 분기 예측 (Branch prediction) 이다. 당연히 가리키는 주소로 갈지 말지의 방향 예측과, 가리키는 주소 자체의 예측 두 가지가 함께 이루어진다.

  5. 비순차적 명령어 처리 (Out-of-Order Execution, OoOE)
    비순차적 명령어 처리 (OoOE)는 파이프라인의 송출 (Issue) -> 실행 (Execute) -> 회신 (Writeback) 단계에 한해서 늦게 온 명령어가 일찍 온 명령어를 새치기할 수 있는 기술이다. 앞에 온 명령어의 처리가 수행될 수 없지만 뒤에 온 명령어는 수행 가능한 경우가 나올 수 있는데, 그러면 CPU를 놀게 하기보다 뒤에 나온 명령어를 먼저 처리하자는 거다. 물론 아무 때나 막 할 수는 없고 이렇게 순서를 바꿔도 사용자가 보는 값이 비순차적 명령어 처리 (OoOE) 를 하지 않았을 때와 같을 경우만 할 수 있다. 이러한 까다로운 조건 체크 때문에 비순차적 명령어 처리 (OoOE) 를 달면 속도야 많이 빨라지지만 칩이 커지고 전기도 훨씬 더 먹게 된다. 그래서 초창기엔 휴대기기용 CPU엔 비순차적 명령어 처리 (OoOE) 가 없었다가 최근에야 최적화를 거치고 사용되기 시작했다.

  6. 추측 실행 (Speculative execution)
    파이프라인 단계에서 이미 설명했듯이, 완료 (Commit) 단계 전에는 아직 명령어 수행을 취소할 수 있다. 그러므로, 어떤 명령어가 특정 파이프라인 단계에 필요한 정보가 없어서 진행이 막혔을 때, 필요한 정보를 예측해서 높은 확률로 맞춘다면 틀렸을 때의 다소 큰 손해를 넘어서는 이익을 취할 수 있다. 고성능의 CPU는 이러한 예측에 기반한 갖가지 기술들을 적극 활용하고 있다.
    가령 명령어들을 반복 실행하는 소위 반복문이라는 게 있다고 하자. 이 반복문의 맨 마지막 명령어는 종결 조건이 맞지 않는 동안은 반복문의 맨 처음 명령어로 점프하도록 만들어져 있는데, 결과적으로 마지막 반복 말고는 항상 맨 처음 명령어로 점프하기에 높은 확률로 점프를 한다는 예측이 맞게 된다. 이렇게 예측을 하면 굳이 마지막 명령어를 실행 (Execute) 할 필요도 없이 다음 명령어를 호출 (Fetch) 할 수 있고, 기다리는 시간을 줄여서 성능을 대폭 상승시킨다. 다만 맨 마지막 반복에서조차도 마지막 명령어는 반복을 더 하려고 예측이 틀리게 된다. 예측이 틀린지 아는 시점은 명령어의 해독 (Decode) 혹은 실행 (Execute) 단계 수행 직후이며, 틀렸다면 틀린 명령어의 완료 (Commit) 단계 때 자기 자신과 이후 호출 (Fetch) 된 모든 명령어를 파이프라인에서 지우게 된다.

3.1.2. CPU 아키텍처[편집]

  1. 커널 / 유저 프로세스: 컴퓨터를 켰을 때 돌아가는 운영체제를 또 다른 말로 커널이라고 하며, 커널 이외에 돌아가는 프로그램 하나 하나는 유저 프로세스라 한다.

  2. 보호 링 (protection ring): 운영체제는 컴퓨터의 모든 값을 읽고 쓰고 할 수 있다. 그런데 운영체제에서 돌아가는 유저 프로세스들도 마찬가지면 무슨 일이 벌어질까? 유저 프로세스에 버그가 있거나 악성 코드가 있을 경우 컴퓨터 내의 아무 값이나 읽고 쓸 수 있는 심각한 문제가 발생한다. 따라서 운영체제는 CPU에서 제공된 보호 링이라는 것을 써서 (1) 커널 수준과 (2) 유저 수준을 나누게 된다.
    결과적으로 CPU가 유저 프로세스를 실행하는 동안은 유저 수준에 있게 되며, 유저 프로세스가 커널에 적법한 방법을 통해 (syscall 혹은 systemcall 이라 한다) 도움을 요청 (가령 파일 읽고 쓰기는 커널의 도움으로 이뤄진다) 하고, CPU는 커널 수준으로 변환하고 커널 코드를 실행하게 된다.

  3. 가상메모리 (virtual memory) / 페이지 테이블 (page table): 모든 유저 프로세스들이 주메모리의 공간들을 직접 할당 받는다면 어떤 일이 벌어질까? 컴퓨터 환경에 따라서 유저 프로세스가 가정해야 하는 메모리의 주소와 사용 가능한 용량이 자꾸 바뀌게 될 것이다. 프로그래머 입장에서 이러한 현상은 큰 골칫덩어리이며, 따라서 유저 프로세스 각각은 처음 시작할 때 텅 비어있는 똑같은 크기의 가상 메모리를 받게 된다.
    가상 메모리의 접근은 결국에는 실제 메모리의 접근으로 이어지는데, 각 유저 프로세스의 가상 메모리 주소로부터 실제 메모리 주소로의 매핑을 저장한 데이터 구조를 페이지 테이블이라고 하며, 각 유저 프로세스마다 독립된 페이지 테이블이 존재하게 된다.

  4. 콘텍스트 스위칭 (context switching): 컴퓨터에는 수많은 프로세스들이 동시에 돌고 있다. 그러나 CPU는 논리적으로 한 코어(굳이 논리라고 하는 것은 SMT 기술 때문)에 한 프로세스만 돌리고 있을 수 있다. 그래서 CPU는 한 프로세스를 어느 정도 돌리다가 다른 프로세스로 전환해서 돌리려고 하는데, 이를 콘텍스트 스위칭이라고 한다. 유저 프로세스가 바뀌면 가상 메모리 공간도 바뀌어야 하므로, 페이지 테이블도 유저 프로세스에 맞게 같이 바뀌게 된다. 사실 커널도 하나의 프로세스와 비슷한 거라서 유저 수준에서 커널 수준으로 갈 때도 콘텍스트 스위칭이 일어나게 된다.

  5. 페이지 테이블 항목 (page table entry)의 보호 비트 (protection bit):
    최신의 커널에는 재미있는 최적화가 있는데, 유저 프로세스의 가상 메모리의 특정 주소는 커널 데이터를 담고 있다는 것이다. 이러면 유저 프로세스가 syscall을 호출해서 커널의 도움을 받으러 갈 때 페이지 테이블을 커널 것으로 교체할 필요가 없다. 그래서 파일을 읽고 쓰거나 네트워크 송수신이 더 빠르게 처리될 수 있다. 그런데 이렇게 되면 유저 프로세스가 커널 데이터를 마구 읽을 수 있지 않을까? 이를 위해 페이지 테이블은 실제 메모리 주소와 함께 보호 비트란 것도 달고 있다. 보호 비트는 여러가지가 있지만 여기서 중요한 것은 이 실제 메모리 주소는 커널 수준만 읽을 수 있다같은 표식이다. CPU에서 유저 수준에서 유저 프로세스를 돌리다가 메모리 값을 읽는 명령어를 처리하려는데, 이 표식을 발견하면 해당 명령어는 규칙을 위반한 것이므로 실제로는 실행되지 않는다.

3.1.3. 커널 값을 읽어내는 프로그램[편집]

이 프로그램의 작동방식을 이해하는 것은 일반인에게 중요하지 않다. 중요한 것은 보안패치 잘 하고 가능하면 AMD 계열의 CPU로 시스템을 변경하는 것이다. 5. 취약점에 대한 대응 문단과 6. 사용자가 할 수 있는 대처법을 참고하자.

위에 서술되어있듯 이 프로그램은 CPU의 아키텍쳐에 대한 다수의 전공지식을 이용한다. 컴퓨터공학과 학부 아키텍처(컴퓨터 구조) 수업에서 파이프라인까지 배우면 보통 종강이다. 즉, 여기만 해도 학부 2~3학년 수업의 한 학기 분량의 지식이 전제가 된다. 여기에 OS의 메모리 관리에 대한 이해가 필요한데, 계층구조 자체에 대한 이해는 쉽지만 강의 내용은 거의 한 달 가까이 필요하다. 여기에 추가로 Typecasting을 이해해야 하는데, 일반인에게는 별로 필요하지도 않은 C언어나 어셈블리 언어 등 중-하위권의 프로그래밍 언어에 대한 실습이 필요하다. 심지어 이 문단에 대한 전공자들의 오해 및 전공자들이 서술한 내용상의 오류도 계속해서 발견되고 있다. [14] 즉, 지금 전공자들도 헷갈려하는 마당에 일반인들을 이해시켜야 하는 상황인데 이해에는 최소한 학부 전공 수업 한 학기 분량 이상의 사전지식이 필요하다. 독자여러분께서 설명에 어렵거나 복잡한 요소가 있더라도 이런 사정이 있다는 것을 양해해 주셨으면 한다. 괜히 20년 동안 엔지니어들이 이걸 못 찾아낸 게 아니다.

따라서 최소한의 내용만을 설명하는 부분과 전공자를 위해 약간의 기법이 추가된 설명 두 가지를 첨부한다. 이해가 안 되는 것은 정상이니, 이해하지 못 했다고 좌절하지 말자. 버츠와 스위너톤-다이어 추측호지 추측의 내용을 이해 못 했다고 좌절할 필요가 없듯이. 나도 뭔 소린지 모른다

3.1.3.1. 프로그램에 대한 간단한 설명[편집]

설명을 위해 CPU의 구조에 대한 최소한의 지식이 필요하다. 첫째. CPU 안에는 '레지스터'라는 것이 있다. CPU는 일을 할 때 임시로 숫자를 여기에 적어둔다. 둘째. RAM이 있다. 각종 프로그램들은 여기에 자신이 필요한 정보를 적어둔다. 셋째. 캐시가 있다. 캐시는 RAM에 비해서는 매우 빠르게 정보를 넣었다 뺐다 할 수 있다.

RAM에는 여러 칸이 있으며 프로그램은 각 칸의 번호를 바탕으로 RAM에 숫자를 적어넣거나 읽어온다. 호텔을 생각하면 된다. 1번 방에 철수가, 2번 방에 영이가, 3번 방에 민수가 있다. 2번 방에 누가 있는지 알고 싶으면 호텔 데스크에 '2번 방, 누구?' 이렇게 질문하면 데스크는 '영이'라고 답할 것이다. 3번방의 민수를 퇴실시키고 싶다면 '3번 방, 퇴실' 이라고 데스크에 명령하면 된다. 대략 이런 방식으로 프로그램은 RAM에다가 숫자를 저장하거나 읽어내기 위해 CPU에 명령을 내린다. 다만, 이 때 RAM은 너무 느리기에 중간에 캐시라는 임시저장소를 둔다. 캐시의 세부사항에 대해서는 여기에서 서술하지 않는다.

당신이 키보드로 무엇을 입력했는지 훔쳐내려는 해커가 있다고 생각해보자. 키보드로 무엇을 입력했는지 알아내면 은행 거래 비밀번호 등 중요한 정보를 탈취해낼 수 있다. 해커의 목적이 키보드 입력값의 탈취라는 전제 하에 다음의 사항을 생각해 보자.

컴퓨터는 모든 것을 숫자로 처리한다. 가령 ASCII코드를 전제할 때 컴퓨터는 'a'라는 문자를 97로 이해하고 'b'라는 문자를 98로 이해한다. 우리가 키보드로 'a'를 칠 때, 컴퓨터는 메모리의 100번째 방에 숫자 '97'을 적어넣는다고 치자. 원칙적으로는 OS의 핵심부분인 커널 이외에는 메모리의 100번 방에 무슨 내용이 들어가 있는지 아무도 알 수 없다.[15] 해커는 이 100번째 방의 내용을 노리고자 '메모리의 100번째 방을 읽어서 나한테 보내라'라고 CPU에게 명령을 내리지만, CPU는 명령을 거부한다. 이게 정상이다. 만약 CPU가 아무한테나 100번째 방의 내용을 보내준다면 가능하다면 비밀번호 등 우리가 키보드로 친 내용들이 유출될 것이다. 그러나 멜트다운 버그를 이용하면 이 100번째 방의 내용을 알 수 있다.

100번째 방의 내용을 읽어내기 위해 해커는 두 개의 명령을 CPU에게 연속해서 전달한다. 첫 번째는 '메모리의 100번 방에 있는 내용을 레지스터 al로 복사해라' 이며 두 번째는 '1000+al을 계산한 다음 RAM에서 그 방에 있는 숫자를 가져다 줘'이다. 즉 100번 방의 내용 -> al -> 1000+al을 통해 해커는 100번 방의 내용을 알아내려고 하는 것이다. 만약 1000+al이 1097이라면, 'a'가 97인 점을 이용하여 해커는 키보드에서 'a'가 입력되었다는 것을 알아낼 수 있다.1000+al이 1098이라면 해커는 'b'가 입력되었다는 것을 알 수 있다.

즉, 해커가 시킨 일을 하기 위해 CPU는 다음의 일을 해야 한다.
1. 100번 방에서 숫자를 꺼낸다.
2. 100번 방에서 꺼낸 숫자를 레지스터 al에 임시로 저장한다.
3. al에 저장된 숫자와 1000을 더한다. (여기에서는 1097로 가정하자)
4. 3에서 더한 결과에 해당하는 RAM의 숫자를 꺼낸다. (즉, 1097번 방의 자료를 꺼낸다.)
5. 꺼낸 숫자를 해커에게 전달한다.

그런데 애당초 100번 방에 있는 숫자를 해커가 꺼내라고 한 1번부터 잘못되어있다. 숫자를 꺼낸 것 자체가 잘못인데, 2, 3, 4, 5번을 할 수가 없다. CPU는 메모리의 100번 방에 있는 내용을 al로 복사하지도, 1000+al을 계산해서 RAM의 방 번호를 찾아 내용을 가져다 주지도 않는다.

문제는 CPU의 파이프라인 구조에 있다. 해커가 100번방의 숫자를 꺼내라고 했을 때, CPU는 실제로는 100번 방의 숫자를 꺼낸다. 그리고 RAM의 1097번 방의 숫자도 꺼낸다. 즉, 실제로 CPU는 해커가 시킨 일을 다 한다. 단지 보여주지 않을 뿐이다. 예전까지는 해커한테 보여주지만 않으면 괜찮다고 생각했다. CPU가 일을 다 하고 보여주지만 않으니, CPU가 일한 흔적을 찾아 100번 방의 숫자를 알아내자라는 것이 멜트다운 버그의 핵심 아이디어이다.

해커는 앞서 간단히 언급한 캐시를 이용한다(캐시는 램보다 속도가 훨씬 빠른 메모리이다). CPU가 RAM의 1097번 방에 있는 정보를 꺼낼 때, 1097번 방의 정보는 자동으로 캐시에 기록된다. RAM에 있는 정보를 캐시로 베껴 써 두면 나중에 다시 볼 때 이를 빠르게 볼 수 있기 때문이다.[16] CPU는 해커에게 RAM에서 일껏 1097번 방의 자료를 꺼내오고는 해커에게 보여주지는 않는다. 하지만 어쨌든 1097번 방의 자료를 꺼내왔기에 1097번 방의 정보는 캐시에 들어가 있다. CPU가 RAM을 읽으면 무조건 이 정보는 캐시에 기록되기 때문이다.

이제 해커는 RAM의 1000번 방 부터 하나씩 방을 검색하기 시작한다. 1000번 이후의 모든 방들은 캐시에 없기 때문에, 램에서 읽어와야 하므로 읽는 데 시간이 꽤 오래 걸린다. 하지만 1097번 방은 캐시에 있기 때문에, 읽는 데 시간이 적게 걸린다. 해커는 RAM의 1000번 방 이후의 방을 읽을 때마다 읽는 데 걸린 시간을 측정한다. 1097번 방을 읽을 때 시간이 적게 걸리는 것을 잡아내면, 해커는 CPU가 나한테 보여주지는 않았지만, 실제로는 1097번 방을 읽었다는 것을 알게 된다. 이를 근거로 al에 원래는 97이 들어가야 했다는 것을 알 수 있고 우리가 키보드로 'a'를 쳤다는 것을 알 수 있다.

읽어도 이해가 안 간다면 정상이다. (...) 정 이해가 안 간다면, 종이에 여러 칸으로 된 세 무리의 방을 그리고 옆에 숫자를 적자. 그리고 이 숫자를 적어가고 움직여 보면서 이 설명을 읽어본다면 좀 이해가 될 수 있을지도 모른다.

사실 이 문제는 인식론적으로도 이해하기 까다롭다. 반사실 가정문의 사용에 능숙해야 하는데, 반사실 가정문[17]은 인간이 이해하기 가장 어려운 종류의 문제 중 하나이다. 학부생들이 다익스트라 알고리즘을 이해하지 못하고 걍 외워버리는 이유도 반사실 가정문 때문이다.

3.1.3.2. 조금 더 기술적인 설명[편집]

아 편하다
기술적으로 완벽한 설명을 위해서는 시스템의 비트 상황이나 캐시구조 등 하드웨어의 세부사항까지 이해해야 한다. 2018년 1월 18일 오후 12시 현재까지 제안된 설명 중 반론을 받지 않은 설명은 단 하나도 없으므로, 여기에서는 대략적인 개요만을 설명한다. 캐시와 타입캐스팅을 어떻게 활용하는지 확인하는 용도로 사용하면 적절하며 그 이상으로 정확하지는 않다.[18] 이 설명은 OS와 메모리 구조, CPU 파이프라인에 대한 전공지식이 있다는 것을 전제로 한다.

공격 프로그램은 커널의 특정 메모리 주소를 읽기 위해 다음의 변수 및 배열을 설정한다.

1. ka : 값을 읽어올 커널의 메모리 주소.
2. ua1 : L1 캐시 크기 만큼의 배열
3. ua2 : 256 크기 만큼의 배열. [19]

코드의 실행순서는 다음과 같다.
A. ka에 원하는 주소를 세팅한다.
B. ua1의 모든 값을 읽는다.
C. ka의 값을 읽어서 레지스터 al에 저장한다.
D. ua2[al]의 값을 읽는다.
E. 아무 것도 하지 않는 명령어를 적당히 깔아둔다.
F. ua2에서 캐시로 값이 들어온 주소를 알아낸다.

자세한 설명은 다음과 같다.

첫째. B에서 ua1의 값을 모두 읽었기에, L1 캐시는 ua1의 정보로 가득 차 있다. 따라서 이 시점에서 ua2의 정보는 캐시에 없다는 것이 보장된다.
둘째. C는 항상 실행이 취소된다. 사용자 프로세스가 커널 정보를 읽는 것이기 때문에 보호비트가 발동된다.
셋째. C가 실행이 취소되기 전, C, D는 파이프라인의 execute state를 지난다. 즉, CPU는 ua2[al]의 값을 읽는다. 단지 commit 하지 않을 뿐이다. [20]
넷째. 컴퓨터에서 array에 접근할 때에는 보통 간접적인 방식으로 접근한다. C언어에서 tmp_arr[10]이라고 적는 경우를 생각해 보자. 실제로는 tmp_arr이 가리키는 주소에서 10을 더하는 방식으로 주소를 계산한다. ua2[al]을 읽을 때에도 마찬가지로 계산한다.
다섯째. D는 execute state를 지났으므로, CPU는 실제로 ua2[al]을 읽는다. 따라서 이 값이 ua2 배열 중 유일하게 캐시에 올라와 있다. al이 97 즉, 'a'라면 ua2[97]만 캐시에 올라와 있고 나머지는 캐시에 없다.
여섯째. F단계에서 해커는 ua2[0]~ua2[255]까지를 랜덤하게 읽어본다. 읽을 때마다 읽기 시간을 측정한다. 다른 모든 값은 캐시에 없으니 읽는 데 시간이 걸리지만, ua2[97]은 캐시에 올라와 있으니 읽기 시간이 빠르다. 이를 근거로 ka값이 가리키는 주소에 97이 들어있다는 것을 있다. [21][22]
일곱째. E에서 아무 것도 하지 않는 명령어를 적당히 깔아두는 이유는 F가 실행취소되거나 재시도 되는 것을 막기 위함이다.

3.1.4. AMD CPU에 멜트다운 취약점이 존재하지 않는 이유[편집]

이 사달이 난 이유는 D단계가 잘못된 것을 꽤 일찍 알았는데도 실행 취소가 시작된 시점이 완료 (Commit) 단계여서 이미 뒤의 명령어들이 실행되어 버렸기 때문이다. AMD는 D단계와 같은 보호 비트 위반을 발견하는 즉시 실행 취소를 시작했거나, 보호 비트 위반으로 읽어낸 eax와 같은 값을 읽는 명령어들은 송출 (Issue) 단계를 지나지 못하게 막았을 것이다.

다만 AMD가 해당 보안 이슈를 알아서 막았다기보단, 마이크로아키텍처 설계에 있어서 인텔과 다른 전략을 취해서 우연히 피했을 것으로 추정된다. 일단 CPU 아키텍트 인재 풀이 그리 크지도 않고 회사도 생각보다 자주 옮겨다닌다. 그러므로 불과 몇 년 전까지는 아무도 이 문제를 몰랐을 가능성이 매우 높다.[23]

왜 두 가지 방식으로 갈렸는지는 다음과 같이 추측해볼 수 있다. 먼저 AMD의 빠른 예외 처리 방식을 쓰면, 아무래도 파이프라인 안에서 적절한 취소 시그널을 보내는 로직이 복잡해지겠지만 쓸데없는 명령어에 허비하는 에너지를 줄일 수가 있다. 반면 인텔 방식은 쓸데없는 명령어에 허비하는 에너지가 늘겠지만 예외 처리의 로직이 단순화되어 평상시의 에너지 효율이 증가하고 그 외 TSX와 같은 더 복잡한 기술의 도입이 쉬워진다. 즉 보안 문제만 빼고 보면 어느 하나가 우위에 있는 게 아니란 소리다.문제는 보안문제가 기존 인텔쪽 장점을 다 씹어먹어서 문제지

3.1.5. 차기 인텔 하드웨어의 해결책 예상[편집]

AMD와 마찬가지로 보호 비트 위반과 같은 예외(exception)를 처리하기 시작하는 시기를 완료(Commit) 단계가 아닌 실행(Execute) 단계 즈음으로 대폭 앞당길 가능성이 높다.

추측 실행(Speculative execution)을 제거하면 어떻겠냐고 하는 사람도 있는데, 사실상 불가능한 소리다. 이유는 다음과 같다.

  1. 우선 추측 실행(Speculative execution) 없이 중단(interrupt)을 지원하려면 가끔 일어나는 중단(interrupt) 처리를 위해 끔찍한 성능 감소를 감수해야 한다. 중단(interrupt)은 외부 장치의 핸들링이나 내부 명령어의 예외(exception) 처리를 운영체제가 미리 등록한 별도의 코드로 실행할 수 있게 하는 필수적인 기능이다. 문제는 중단(interrupt) 발생이 대부분 명령어에서 일어날 수 있다는 것이다. 결과적으로 대부분 명령어는 잠재적인 분기 명령어가 되며, 따라서 추측 실행(Speculative execution) 없이는 명령어 대다수가 실행(Execute) 단계가 완수해서 중단(interrupt) 발생 여부를 확인하고 나서야 다음에 호출(Fetch)할 명령어를 알려줄 수 있게 된다. 이는 결코 받아들일 수 없는 사태이므로, 중단(interrupt)은 매우 드물게 일어나는 점에 착안해 중단(interrupt)은 항상 일어나지 않는다고 예측해도 거진 다 맞게 되고 성능도 대폭 향상된다. 한 마디로 잘 일어나지도 않을 일을 확인한다고 전 공장이 매번 올스톱하는 것과 같다. 그럴 바에는 그냥 공장을 계속 돌리다가 문제 생긴 제품을 폐기하는 것이 이득이다.

  2. 다음으로 분기 예측(branch prediction)은 안 쓰면 바보다.

    • 분기 예측은 분기(branch)명령어가 "파이프라인이 호출(Fetch) 단계에서 자꾸 쉬게 만드는 문제"를 해결하기 위해 도입된 것이다. 파이프라인을 안 쓰는 CPU는 없다고 감히 단언할 수 있다.[24]

    • 각종 추측 실행(Speculative execution) 기능의 제거가 빈번한 저전력 CPU도, 프로그램이 대부분의 시간을 반복문에서 보내는 특성상 분기 예측(branch prediction)이 맞을 확률은 매우 높은 편이다. 에너지적인 관점에서 아주 간단한 분기 예측(branch prediction)이라도 하면 전력을 약간 더 써서 성능을 대폭 올리니 결과적으로 에너지 효율적이게 된다.

    • 비순차적 명령어 처리(OoOE)를 버린 저전력 CPU는 명령어의 실행 취소가 매우 간단하여, 분기 예측(branch prediction) 실패에 대한 댓가마저도 훨씬 적다.

  3. 마지막으로 비순차적 명령어 처리(OoOE)의 경우 현재도 저전력 CPU에서는 안 쓰기도 하므로 분기 예측(branch prediction)과 달리 버린다는 옵션이 있긴 하지만, 고성능 CPU 시장에서는 비순차적 명령어 처리(OoOE)로 인한 성능 향상이 상당해서 어림도 없는 소리다. 게다가 비순차적 명령어 처리(OoOE)를 버리면 물리 코어를 여러 논리 코어로 불리는 SMT기술도 제대로 실현 불가능하다.[25] SMT의 핵심 아이디어는 비순차적 명령어 처리(OoOE)가 한 프로그램 안에서 병렬로 실행 가능한 일련의 명령어 스트림을 찾던 것을 확장해서 서로 다른 프로세스(혹은 스레드)의 명령어 스트림을 한 물리 코어 안에 섞어서 실행하는 것이기 때문이다.


다만 위는 SMT가 양날의 검이며 항상 성능향상 시켜주지는 않는다는 말이고, OoOE 자체는 성능을 확실히 향상시켜준다. 저걸 걷어내면 아톰이나 J시리즈 계열 정도의 성능밖엔 안 나올 가능성이 높다. 물론 저런 놈들은 15W 이하로 동작하므로 실제 데스크톱용으로 90W쯤으로 TDP를 올려 설계하면 그것들보다는 성능향상이 되겠지만 넷버스트 아키텍쳐 시절 수준의 전성비가 다시 강림할 가능성이 크다.

3.1.6. 운영체제를 통한 임시방편[편집]

CPU 아키텍처 설명 중 맨 마지막에 최신의 커널에는 재미있는 최적화가 있는데, 유저 프로세스의 가상 메모리의 특정 주소는 커널 데이터를 담고 있다는 것이다.를 멜트다운 버그를 해결하기 위해 없애버렸다. 이는 임시방편이다. 즉 보호 비트에 의존해서 유저와 커널의 가상 메모리 공간을 합치던 최적화를 포기하고, 다시 두 메모리 공간을 분리해 버린 것이다. 따라서 유저 프로세스에서 커널 기능을 사용할 때마다 페이지 테이블이 교체되는 작업이 추가로 필요해진다. 결과적으로 구체적인 정도의 차이는 있을지언정, 파일을 읽고 쓰거나 네트워크 송수신을 하는 소위 입력/출력(Input/Output, I/O)을 포함해 커널의 메모리 권한으로만 가능한 작업들의 성능이 하락할 수밖에 없다.

3.1.7. 심각성[편집]

커널 권한을 가지고 있지 않은 프로그램에서 커널 메모리를 읽을 수 있다는 것 자체가 매우 높은 수준의 보안 결함이다. 커널 메모리에는 시스템 운영과 관련된 정보가 저장되므로 시스템의 보안 약점을 공격할 때 시스템에서 탈취한 정보를 활용해서 좀 더 효율적인 공격이 가능할 수 있다. 또한 현대의 OS는 시스템에 설치된 장치를 이용할 때 기본적으로 커널이 장치 제어 권한을 독점하고 디바이스 드라이버를 통해 장치를 제어하며, 일반 사용자 수준의 프로그램은 장치를 직접 제어할 수 없고 커널에 장치 이용을 요청하고 결과를 받는 식으로 작동하는데, 이 과정에서 커널을 통하는 데이터 또한 유출될 수 있다. 위에 나온 키보드 입력을 보여주는 프로그램이 괜히 나온 것이 아니다.

다만 멜트다운 취약점 자체만으로는 커널 메모리의 읽기만 가능하고 쓰기는 불가능하므로, 직접 시스템에 파괴적인 행동을 하거나 랜섬웨어 등 악성코드를 심는 것은 불가능하며, 취약점을 이용하기 위해서는 어떤 식으로든 다른 방법을 통해 먼저 시스템에서 공격하는 코드를 실행하도록 해야 한다. 이것이 그리 쉬운 일은 아니지만, 불가능한 것도 아닌 것이, 웹 브라우저에서 자바스크립트를 이용하면 잠재적으로 멜트다운 취약점을 이용할 가능성이 있는 것으로 밝혀져서 급히 패치가 나왔으며, 2017년의 워너크라이 랜섬웨어 대란에서 볼 수 있듯이 OS에 이미 알려졌거나 또는 아직 알려지지 않은 다른 보안 취약점이 있을 수 있고 여기에 멜트다운 취약점 또한 악용하는 코드가 나올 수 있다.

또다른 문제로는 멜트다운 취약점을 이용할 때 특별한 징조를 보이거나 흔적을 남기지 않는다는 것이다. 일반적으로 보안 취약성을 악용하는 코드는 이용하는 명령 자체가 시스템에 기록이 남기 쉬운 명령을 이용하거나 권한을 얻는 과정 등 기존에 시스템에서 이용하던 동작을 이용하던 과정에서 취약점을 이용하고 이 과정에서 흔적을 남기거나, 또는 특정 보안 취약성에 맞게 작동하는 과정에서 코드 및 명령어 자체가 특정한 패턴을 보이는 경우가 많다. 하지만 멜트다운 취약점은 훨씬 범용적인 명령어 및 동작을 통해서 이용이 가능하다. 따라서 작동의 감지도 어려울 뿐 아니라 해당 코드가 공격 코드인지 판단하는 것도 어렵다.

하드웨어에 취약성이 있기 때문에 기본적으로 현재 나와 있는 모든 OS에서는 일단 멜트다운 취약점을 이용할 수 있다고 봐도 된다는 것도 문제다. 일반적으로 보안 취약점은 특정 하드웨어/OS/버전에서만 이용할 수 있고 다른 환경에서는 통하지 않는 경우가 많은 반면, 이번 멜트다운 취약점은 방비책을 마련해 두거나 우연히 이용할 수 없는 구조인 시스템에서만 안 통하고 다른 환경에서는 통할 가능성이 높다. 물론 인텔 시스템 및 일부 ARM에만 적용된다고 할 수도 있는데 인텔 시스템이 점유율이 좀 높아서...

또한 멜트다운 취약점의 원인이 하드웨어 구조적 결함이라 업데이트같은 소프트웨어적 해결책으로 완전한 해결을 보장할 수 없는 것도 문제다. 이는 그 어떤 소프트웨어이든 하드웨어 위에서 구동되는 이상 어쩔 수 없는 한계다. 실제로 소프트웨어적인 패치는 모든 멜트다운 공격을 막을 수 없다는 전문가 의견이 있다. 즉 실질적으로 멜트다운 취약점을 이용하지 못할 정도로 업데이트가 가능할 수도 있지만, 그렇게 되지 않을 가능성도 있는 것이다. 설령 공격의 난이도가 높아도 취약점 공격의 대가가 크다면 이용의 어려움이고 뭐고 없이 달라들 수도 있는 것이고. 이 문서에 서술된 '멜트다운' 취약점에 한정한다면 OS의 최적화 과정을 포기해서 커널과 유저의 페이지 테이블을 분리하는 정도로도 충분한 방어가 가능하지만, 이건 CPU 자체의 한계를 해결한 것이 아니라 그 약점이 악용될 가능성 중 하나를 막은(혹은 어렵게 한) 것에 불과하다. 즉, 구조적으로 하드웨어 차원에서 해당 문제의 근본적인 해결이 되지 않는 한 해당 취약점을 악용할 가능성은 남아 있을 수 있다. 그리고 이런 경로 모두를 실제 악용 전에 미리 발견하는 것이나, 설령 발견하더라도 소프트웨어적인 해결책을 찾아내는 것은 현실적으로 거의 불가능하다.

인텔 CPU 사용시 설령 성능저하가 있더라도 OS가 이 문제를 틀어막아주지 않으면 안되는 이유다. 따라서 기존의 보안 문제하고는 차원이 다르게 범용성 높은 취약점이다. 다만 커널의 어느 값이나 쉽게 읽을 수 있을 뿐 어디를 읽어야 하는지 알아내는 과정에는 상당한 삽질이 필요하므로, 당장 개인 사용자를 타겟 삼아서 취약점을 악용하는 사례는 나오지 않을 가능성이 높다. 문제는 큰 기업과 기관들. 이런 곳들을 대상으로는 삽질로라도 이런 취약점 공격을 시도하려는 자들이 있을 수 있고 문제가 발생한다면 간단한 수준에서 끝나지 않게 된다. 물론 NAS(인텔 아톰칩과 ARM칩을 쓰는 기기들이 있다.)같은 개인 서버 역시 피해를 받을 가능성을 배제할 수 없다. 생각보다 많은 사람들이 개인 서버를 가지고 있다. 특히 시스템 구성에 상당한 차이가 있을 수 있는 일반 서버 PC가 아닌 별도의 장비 형태인 경우, 특정 취약점이 동일 모델에 모두 적용되는 상황이 벌어질 수도 있다. 예를 들어 A사의 B라는 NAS는 모조리 뚫리는 일이 벌어지지 말라는 법은 없다.

만약 패치로 보안 문제를 완화하는데 실패할 경우, 결국 CPU를 완전히 바꿔야하는데 인텔의 경우에는, 2011[26]년부터 생산되는 거의 모든 인텔 CPU가 해당되어서, 현재로선 다른 인텔 CPU로 교체라는 선택지는 사실상 존재하지 않는다. 이렇게 되면 결국 인텔의 CPU를 AMD의 ZEN 아키텍처 기반 CPU로 옮기는 것 외엔 방법이 없어, 개인과 기업 등에서는 상당히 심각한 시간적, 금전적 피해를 보게 될 것이다. 서버 하나 구입해서 끝나는 것이 아니라 하드웨어 자체의 가격도 문제지만 운영 소프트웨어의 가격이나 시스템 설치, 구축, 이전 등에서 걸리는 시간과 서비스 중단에 의한 손해 등 많은 것이 걸리기 때문이다. 멜트다운 버그에 취약한 CPU 중에는 교체가 불가능한 제품도 많아, 기기 자체를 교체하는수 밖에 없어 개인과 기업 등의 피해가 더욱 커질 것이다.[27] 이미 지금도 보안 우려 때문에 인텔 제품에 대한 신뢰성이 급락하고 있으며, 기업은 물론이고, 개인까지 곳곳에서 집단으로 인텔을 상대로 소송을 걸고 있는 상황인데 만약 패치로 해결이 불가능한 것으로 판명이 난다면 지금과는 비교도 안 될 훨씬 심각한 상황이 될 것이다.

멜트다운 버그에 취약한 CPU를 사용하는 전자 기기가 PC와 서버뿐만 아니라 휴대폰, 태블릿, 스마트 TV, IoT 디바이스 등도 있기 때문에 현대인이라면 멜트다운 버그와 그로 인해 발생할 수 있는 피해에서 자유롭기 어렵다는 것도 상당히 심각한 문제이다.

사실 일반 사용자보다는 기업쪽에서 보다 심각한 문제이나, 현대 정보화 사회에서 보안이 무력화되면 다음의 문제들이 생겨날 수 있다.

  • 은행 계좌는 일단 털리고 시작한다.

  • SNS 계정 등을 털어서 당신을 사칭하며 범죄를 포함한 각종 못된 짓을 벌인다.

  • 당신의 계정을 경유하여 보안 프로토콜을 우회, 침투가 불가능했던 다른 시스템을 해킹한다.

  • 금융공동망 등 국가 기간망을 교란시키거나 전력거래소를 해킹해 전국적인 블랙아웃을 일으킨다.

  • 병원의 환자감시장치를 해킹해(정확히는 환자감시장치를 모니터링하는 중앙관제실 서버를 해킹) 환자를 살해한다.

  • 경찰 전산망을 해킹해 무고한 사람을 중범죄자로 만들 수 있다.

  • 화학플랜트의 제어기를 교란시켜 독극물을 유출시킨다.


물론 보안 프로토콜은 사람을 완전히 배제하고 돌아가는 시스템이 아니기 때문에[28] 해커 한 명이 한 국가를 멸망까지 시키기는 좀 어렵지만 그것이 조직적으로 수행되면 위의 시나리오가 현실이 될 수도 있다. 현대의 보안 프로토콜은 비대칭키 기반 암호화 알고리즘을 사용하는데 이 암호화 알고리즘이 작동할 때에는 CPU에 특징적인 어떤 '흔적'이 발생한다.[29] 이 흔적을 추적하여 멜트다운 공격을 시도하면 암호화에 사용되는 개인키를 유출할 수 있고 개인키가 유출된 시스템은 그 이후의 모든 통신을 수신, 변조, 사칭할 수 있다. 물론 멜트다운 공격을 시도하려면 악성코드가 해당 CPU에서 실행돼야 하기 때문에 위에서 언급한 금융공동망같은 폐쇄 시스템은 멜트다운 공격에 직접적으로 노출되지 않는다. 문제는 클라우드 컴퓨팅에서 발생하는데, 클라우드 컴퓨팅에서는 한 물리 서버가 여러 개의 가상 서버를 호스팅하는 구조로 되어 있어서 한 가상 서버에서 멜트다운 공격을 시도해 다른 가상 서버의 데이터를 훔쳐볼 수 있다. 일단 구글에서는 구글 클라우드의 가상화 시스템의 특성상 멜트다운/스펙터 취약점을 이용하는 것이 불가능하다고 발표했지만 다른 곳도 안전하다는 보장은 없다.

3.2. 스펙터[편집]

파일:나무위키:넘겨주기50px.png
이 문단은 스펙터(보안 취약점)(으)로 검색해서 들어올 수 있습니다.

한편 스펙터(또는 스펙터 익스플로잇)은 멜트다운 버그와 비슷하게 추측 실행(speculative execution)으로 인해 일어나기는 하지만, 조금 덜 심각하다. 스펙터는 추측 실행을 할 때 다른 곳의 코드 실행[30](분기표적 주입 (branch target injection) 의 경우)이나 조건문(경계검사 우회 (bounds check bypass) 의 경우)을 실행한 뒤 잘못된 경우에 취소시키는데, 이때 비슷한 부작용이 발생하는 점을 악용하여 다른 프로그램의 메모리를 읽어들이는 것이다.

다만 메모리를 훔쳐볼 수만 있고 메모리에 기록할 수는 없으므로 그 자체만으로 직접 시스템에 파괴적인 행동을 하거나 랜섬웨어 등 악성코드를 심는 것은 불가능하다.[31] 또한 커널 영역 메모리에 접근 가능한 것은 아니므로 상대적으로 멜트다운보다는 시스템에 끼치는 영향은 좀 더 적을 것으로 보인다. 하지만 다른 프로세스의 메모리에 올라온 모든 정보를 해커가 읽을 수 있는 이상, 직접 각종 개인정보를 유출하여 이메일, 검색포털, 스팀, 배틀넷 등의 계정을 탈취하거나, 최악의 경우 은행 공인인증서 뱅킹 전자서명까지 죄다 털리고 현금이 인출되는 상황이 벌어지거나 하는 일이 벌어질 가능성은 있다. 게다가 이러한 일련의 공격을 막기 위해 데이터를 암호화하는 것도 그 암호의 복호화 키가 메모리에 있는 한 키 역시 같이 유출될테니 근본적인 해결책이 되지 않으며, 상술했듯이 공격을 수행하는 것 자체를 막는 것도 악성코드의 소행인지를 판단하기 어렵기 때문에 어려운 것도 문제다.

스펙터 버그의 경우 유저들의 프로그램간 메모리 스니핑이 일어나는 거긴 하지만, 기본적으로 대상 프로그램에서 문제가 존재하는 코드의 추측 실행이 되어야 하기 때문에, 실제 버그를 이용해 공격하려면 공격하려는 대상 프로그램을 세세하게 분석해야 되고, 프로그램이 돌아가는 CPU 아키텍쳐나 운영 체제에 대해서도 자세히 알아야 되고, 실제로는 취약점을 공격하긴 매우 어렵다. 단, 어느 코드에서나 문제가 존재할 가능성이 있기 때문에, 문제를 발견해 막기도 힘들다(그래서 이름이 유령, Spectre이다). 예를 들어 프로젝트 제로측에서는 리눅스 커널 상에서 실행되는 패킷 필터 JIT 컴파일러를 이용해 문제가 되는 코드를 커널 컨텍스트상에서 만들어 실행시켰다(...). 그래서 스펙터의 경우 긴급 보안 패치는 난이도를 훨씬 더 어렵게 만들어 놓은 것이다.

하지만 스펙터 취약점 또한 하드웨어 구조적 결함이라 업데이트같은 소프트웨어적 미봉책으로는 사실상 완전히 막을 수 없다. 스펙터 버그의 공동 발견자 중 한 명인 폴 코처(Paul Kocher)에 따르면, 스펙터 버그가 소프트웨어 패치로 해결되지 않는다고 한다. 멜트다운 버그가 긴급한 위기인 반면, 스펙터 버그는 모든 고성능 프로세서에 영향을 끼칠 수 있으며, 성능에 중점을 둔 설계가 이러한 버그에 취약하게 만들었다고 한다. 즉, 성능과 보안을 모두 얻으려던 업계의 갈망이 불가능하다는 것을 보여주는 사례가 스펙터 버그이며 새로운 설계의 프로세서가 나오기 전까지 존재할 것이라고 한다. 스펙터 버그는 수십년간 사용된 프로세서 설계에 존재하는 결함이기 때문이다.

스펙터 버그는 멜트다운 버그에 비해 심각성이 적다고 여겨지지만, 현대의 고성능 CPU 중에 스펙터 버그에 면역인 CPU가 존재하지 않고, 면역이 되기 위해서는 성능을 포기해야 하며[32], 어느 정도로 위험한지는 감도 안 잡히는 상황이고, 현재 상황으론 얼마나 완화될 수 있는지도 미지수인데 근본적인 해결법은 새로운 설계의 CPU 밖에 없어, 가볍게 여겨져서는 안될 것으로 보인다.

3.3. 인텔 AMT 관련 추가 보안 문제[편집]

엎친 데 덮친 격

원문 / 보도문 / 루리웹

핀란드의 보안 회사 F-Secure[33]에서 인텔의 일부 CPU에서 추가로 문제점을 발견했다. 멜트다운, 스펙터 보다 심각한 문제라고 한다. AMT기술은 현재 전세계 약 100만대의 기업용 컴퓨터에 사용되기 때문에 더 큰 파장이 일어날 것이라고 한다.[34] 예전에 있었던 ME 버그 + 멜트다운 + 스펙터 + AMT 취약점 까지 합하면... [35]

다만 AMT는 인텔의 기술이므로 AMD, ARM등 다른 기업의 CPU에는 영향이 없을 것으로 예상된다.

그리고 공격을 위해서는 공격 대상의 PC가 부팅 후 관리자 로그인만 되어있으면[36] 가능하며, 기본 설정에서는 해당 공격이 불가능하다. 다만 내부 보안이 허술할 경우 PC의 관리 콘솔 관리자 비밀번호를 기본값에서 변경하지 않고, 이후 PC에 허가받지 않은 사람이 접근하여 콘솔 설정을 해 놓는 일련의 상황이 가능할 수도 있다는 것이 문제. 링크

사실, 비슷한 부분에서 오류에 대해 17년 5월에 한번 공지가 있었고, 해당 내용 관련 윈도우 업그레이드는 17년에 이미 진행되었다. 지금 등장한 내용과 이때의 내용은 조금 다른 부분으로, AMT 관련 수정을 했다던 인텔이 다시한번 뚫림으로써, 상당한 타격이 예상된다. 이후 내용 추가바람.

4. 해당 버그에 취약한 하드웨어[편집]

스펙터 버그는 동시에 여러 명령어를 처리하는 CPU에서는 공통적으로 발생이 가능하다. 즉, 인텔, AMD, ARM 등 모두 해당된다. 현재까지 완전 면역으로 밝혀진 CPU는 명령어를 순차 처리하는 구형 저성능 CPU들만 존재하는 상황이다.# 그것도 모자라 지포스 드라이버까지 영향을 받는 게 밝혀졌다.#

멜트다운 버그에 공식 홈페이지의 취약한 CPU에서는 아이태니엄과 2013년 이전의 아톰 프로세서를 제외한 모바일, 데스크톱 기종을 불문하고 '1995년 이후 나온 비순차 처리를 이용하는 모든 인텔 프로세서는 잠재적으로 해당된다고 하며, 출시일이 2011년인 모델까지 거슬러 올라가며 테스트한 결과 멜트다운 취약성이 확인되었다고 하였다. 버그 공개 초기의 문서라서 그런지 여기에서는 AMD와 ARM은 확실하지 않다고 하였다.

인텔과 관련하여 해당되는 제품을 좀 더 자세하게 표로 만들면 다음과 같다.

인텔 CPU 제품군

세부 모델

펜티엄 제품군

Pentium Xxx XXXXX

셀러론 제품군

Celeron XXXXX

코어 제품군

Core Xxxx XXXXX

코어 2 제품군

Core 2 Xxxxxxx XXXXXX

코어 i7 제품군

Core i7-XXXXX

코어 i5 제품군

Core i5-XXXXX

코어 i3 제품군

Core i3-XXXXX

코어 X 제품군

Core i9-XXXXX

Core i7-XXXXX

Core i5-XXXXX

제온 제품군

Xeon XXXXX

제온 E 제품군

Xeon E7-XXXX

Xeon E5-XXXX

Xeon E3-XXXX

제온 Platinum 제품군

Xeon Platinum XXXX

제온 Gold 제품군

Xeon Gold XXXX

제온 Silver 제품군

Xeon Silver XXXX

제온 Bronze 제품군

Xeon Bronze XXXX

아톰 일부 제품군

2013년 이후 출시된 전 제품


P6 아키텍처 이후의 인텔 x86 기반 프로세서 거의 모든 멜트다운 버그에 취약하다. 테이블에 서술된 펜티엄 제품군은 P6 아키텍처 기반인 펜티엄 프로, 펜티엄 2부터 펜티엄 듀얼코어 시리즈[37]까지 해당되고, 셀러론 제품군은 펜티엄 제품군에 사용된 아키텍처에서 파생된 보급형 제품군이기 때문에 P6 아키텍처 기반의 초창기 셀러론 제품군부터 스카이레이크 아키텍처 기반의 현세대 셀러론 제품군까지 모두 해당된다. 2008년부터 2013년 이전에 출시된 본넬 아키텍처 기반의 아톰 프로세서는 비순차실행을 지원하지 않아 해당 사항이 없다. 또한 x86과 호환성이 없는 IA-64 기반의 아이태니엄 프로세서는 x86 아키텍처가 아니라서 해당 사항이 없다.

TECHARP에서도 영향 받는 제품 목록을 제공하고 있다.

1월 6일에는 애플(맥,아이폰,아이패드,애플 TV[38]), 닌텐도(스위치)가 3가지 공격 모두에 취약함이 밝혀졌다. 반면 AMD는 유형 2 (스펙터 - BTI), 유형 3 (멜트다운)는 해당하지 않고 유형 1 (스펙터 - BCB)은 긴급패치되었다. 참고[39]

닌텐도 스위치의 프로세서(테그라)를 생각하면 NVIDIA까지 불똥이 튈 수도 있는 상황이다. ARM도 점점 심각해지는 게, 유형 3a에 영향받는 '일부'의 목록이 길어지고 있다. 자체 아키텍처로 선회한 삼성 엑시노스, 퀄컴 스냅드래곤은 아직 문제점이 보고되지 않았다.[40]

일본 4gamer.net의 분석글, 해석

IBM의 IBM System Z, POWER 8(Big Endian and Little Endian)과 POWER 9 CPU(Little Endian)도 멜트다운 버그(CVE-2017-5754)와 스펙터 버그(CVE-2017-5715, CVE-2017-5753)에 취약하다.#

5. 취약점에 대한 대응[편집]

미국 국토안보부, 미국 국방부, FBI의 사이버보안 고문 기관인 CERT/CC는 소프트웨어가 아닌 CPU 아키텍처 자체의 결함이기 때문에 업데이트는 미봉책일 뿐이며, 보안 취약점이 발견된 인텔, AMD, ARM 등의 CPU의 교체가 필요하다는 권고안을 내렸다. 하지만 이 권고안은 다음날 철회되었으며 CERT/CC는 OS, CPU 마이크로코드, 애플리케이션을 업데이트를 하라는 새로운 권고안을 내렸다.
프로세서를 교체하는 것이 근본적인 해결책이지만, 추측 실행을 사용하지 않는 고성능 프로세서가 존재하지 않아 현재는 대체할 프로세서가 없기에 지금 당장 사용할 수 있는 해결책은 아니다. 때문에 CERT/CC가 권고안을 철회한 것으로 보인다.

CERT/CC와 동일하게 CPU 교체가 필요하다는 권고안을 내린, 미국 국토안보부 산하의 US-CERT도 해당 권고안을 철회하고 보안 패치를 받으라는 새로운 권고안을 내렸다. 또한 보안 취약점이 CPU 아키텍처에 있기 때문에, 패치가 모든 경우의 보안 취약점에 대한 해결책이 되지 못할 수도 있다고 덧붙였다. US-CERT가 권고안을 수정한 이유도 CERT/CC와 같은 것으로 보인다.

구글은 성능저하 없이 스펙터 취약점을 패치 가능한 리트폴린 (Retpoline) 을 공개했다.#

5.1. 인텔[편집]

2018년 1월 4일, 인텔의 공식 성명이 나왔다.

인텔은 악의적인 목적으로 사용되었을때 시스템에서 민감한 데이터를 탈취할 수 있는 소프트웨어 분석 방식에 관한 새로운 보안 연구에 대해서 인지하고 있습니다. 이번 보안 문제가 데이터를 손상, 수정, 삭제할 잠재력은 없습니다.[41] 보안 문제가 '버그'나 '결함'으로 인한 것으로 인텔 제품에만 존재한다는 것은 잘못되었으며, 인텔 CPU뿐만 아니라 다른 프로세서에서도 나타날 수 있습니다. 인텔은 이러한 보안 문제를 해결하기 위해 AMD, ARM, OS 회사 등과 함께 협력하며 제품과 소비자 보안을 위해 노력하고 있습니다. 보안 패치가 성능에 미치는 영향은 작업량에 따라 다르며, 일반적인 유저에게 있어선 큰 영향이 없을 것이며 시간에 따라 나아질 것입니다[원문]. 업데이트가 가능해지는 즉시 업데이트를 하시고, 업데이트를 하시기 전까지 악성 소프트웨어를 방지하는 보안 수칙을 따르십시오.


인텔은 자사 홈페이지에 보안 이슈에 대해 정리한 을 게시했다. 해당 글에서 인텔은 엔드 유저에게 업데이트가 가능해지는 즉시 업데이트를 할 것을 권장했다. 또한 보안 버그를 악용하는 악성 소프트웨어로부터 시스템을 보호하는데 도움이 되는 보안 수칙으로 다음과 같은 예시를 들었다.[43]

  • 컴퓨터 사용 환경을 통제할 것(Maintain control of your computing environment)

  • 펌웨어/드라이버 업데이트를 주기적으로 확인할 것(Regularly check for and apply available firmware/driver updates)

  • 하드웨어, 소프트웨어 방화벽을 사용할 것(Use hardware and software firewalls)

  • 사용하지 않는 서비스를 끌 것(Turn off unused services)

  • 적절한 사용자 권한을 유지할 것(Maintain appropriate user privileges)

  • 보안 소프트웨어를 최신 상태로 유지할 것(Keep security software up to date)

  • 알지 못하는 링크 클릭하지 말 것(Avoid clicking on unknown links)

  • 여러 사이트의 패스워드를 같은 것으로 사용하지 말 것(Avoid re-using passwords across sites)


인텔의 CEO 브라이언 크르자니치(Brian Krzanich)는 인터뷰에서 이번 보안 이슈는 해결 불가능한 문제가 아니기 때문에 리콜은 없을 것이라고 밝혔다.

2018년 1월 5일, 인텔은 두 개의 기사를 자사 홈페이지에 게시했다.

첫 번째 기사에서 인텔은 자사 시스템에서 멜트다운 버그와 스펙터 버그를 막을 수 있는 업데이트를 개발했으며, 배포하고 있다고 밝혔다. 인텔은 지난 5년간 출시된 대부분의 프로세서를 위한 업데이트를 이미 배포했으며, 다음주 말까지 지난 5년간 출시된 프로세서의 90% 이상을 위한 업데이트가 배포될 것이라고 밝혔다. 또한 많은 OS 회사, 공공 클라우드 서비스 제공 업체, 디바이스 제조사 등과 같은 업체들은 이미 제품과 서비스를 업데이트했다고 밝혔다.
성능 저하 이슈에 대해서는 작업량에 따라 다르며, 일반 유저들에게 있어선 큰 영향이 없을 것이며 시간에 따라 나아질 것이라는 기존 입장을 고수했다. 일부 특정한 작업량에서는 성능 저하가 다른 작업량에 비해 초기에는 높을 수 있지만, 테스트와 소프트웨어 업데이트의 개선 등으로 성능 저하를 완화시킬 것이라고 밝혔다.

두 번째 기사에서 인텔은 파트너사와 함께 멜트다운 버그와 스펙터 버그 보안 패치가 성능에 주는 영향을 측정하는 대규모 테스트를 진행하고 있다고 밝혔다. 또한 인텔은 성능 하락이 거의 없거나 전무하다고 밝힌 애플, 아마존, 구글, 마이크로소프트의 조사 결과를 인용했다. 인텔은 성능 저하는 작업량에 따라 다르며, 일반적인 유저들에게 있어선 큰 영향이 없을 것이며 시간에 따라 나아질 것이라는 기존 입장을 다시 한번 더 고수했다.

2018년 1월 9월, 인텔의 CEO 브라이언 크르자니치는 CES 2018 사전 기조연설을 멜트다운 버그와 스펙터 버그에 대한 언급으로 시작했다. 크르자니치는 여러 프로세서 아키텍처에 존재하는 업계의 보안 이슈를 해결하기 위해 수많은 기업들이 협력한 것은 정말 놀라웠다고 밝혔다. 크르자니치는 이어, 인텔이 보안 문제를 해결하기 위해 노력하고 있으며, OS 회사와 시스템 제조사의 업데이트를 가능한 빠르게 받는 것이 데이터를 안전하게 보호하는데 최선의 행동이라고 밝혔다. 또한 일주일 동안 5년간 출시된 프로세서와 제품의 90% 이상을 위한 업데이트가 배포되었으며 1월 말까지 나머지 제품을 위한 업데이트가 배포될 것이라고 밝혔다. 성능 저하는 작업량에 따라 매우 다르며, 일부 특정한 작업량에서는 성능 저하가 다른 작업량에 비해 높을 수 있지만, 업계와 노력해서 지속적으로 성능 저하를 최소화시킬 것이라고 밝혔다.[44]

해당 연설에서 크르자니치의 '수많은 기업들이 협력한 것은 정말 놀라웠다.'라는 발언이 자화자찬이 아니냐는 기사가 있다.[45] 또한 보안 이슈에 대한 사과가 없다는 점을 꼬집은 외신이 있다. 크르자니치의 발언은 자화자찬으로 들릴 수 있고, 사과가 전혀 없으며, 보안 문제가 완전히 해결되었다는 듯한 뉘앙스를 가져 커뮤니티의 반응이 매우 부정적이다.

2018년 1월 10일, 인텔은 보안 이슈에 관한 기사를 자사 홈페이지에 게시했다. 해당 기사에서 인텔은 현재까지 멜트다운 버그와 스펙터 버그를 이용한 어떠한 데이터 탈취도 발견되지 않았다고 밝혔다. 인텔은 12월 초에 OEM 파트너사에게 인텔 펌웨어 업데이트를 제공하기 시작했으며, 일주일 동안 5년간 출시된 프로세서와 제품의 90% 이상을 위한 업데이트가 배포되었으고, 1월 말까지 나머지 제품을 위한 업데이트가 배포될 것이라고 밝혔다.

인텔은 최근의 PC 성능 테스트에 근거하여, 일반적인 컴퓨터 사용자에게 큰 성능 저하가 없을 것이라고 밝혔다. 또한 일반적인 가정과 비즈니스 PC 사용자들은, 이메일 읽기나 서류 작성 혹은 디지털 사진을 엑세스 하는 것 같은 일반적인 작업에서 큰 성능 저하를 겪지 않을 것이라고 밝혔다. 인텔은 SYSmark 2014 SE 테스트에서 SSD와 8세대 코어 프로세서가 장착된 컴퓨터에서 6%나 그보다 적은 성능 저하를 보였고 SYSmark의 개별 테스트에서는 2%에서 14%의 성능 저하를 보였다고 밝혔다. 데이터 센터의 성능 저하는 현재 조사하고 있는 중이며 클라우드 서비스 등을 제공하는 여러 업계 파트너사의 조사에서는 성능 저하가 작거나 거의 없다는 결과가 나왔다고 밝혔다.

전반적인 성능 저하는 특정 작업량, 플랫폼 구성, 성능 완화 기술에 따라 다르다고 밝혔다. 또한 경우에 따라 여러 가지 성능 완화 옵션이 있으며, 각각 성능에 미치는 영향과 구현 세부사항이 다르다고 밝혔다. 더 많은 자세한 내용은 인텔의 백서와 구글의 "레트폴린(Retpoline)" 보안 솔루션 게시물에서 찾을 수 있다고 밝혔다. 인텔은 업계와 함께 성능 저하가 큰 경우를 해결하는 해결법을 계속해서 찾고 있다고 밝혔다.

2018년 1월 11일, 인텔은 클라이언트 시스템의 초기 성능 테스트 결과를 공개했다. 서버 플랫폼의 초기 성능 저하 테스트 데이터는 몇 일 뒤에 공개하겠다고 밝혔다.
윈도우 10과 SSD를 사용하는 8세대 인텔 코어 프로세서(카비레이크-R, 커피레이크) 플랫폼에서 성능 저하는 6퍼센트이며(SYSMark 2014 SE 벤치마크), 일부 경우에는 최대 10퍼센트의 성능 저하가 있을 수 있다고 밝혔다. 윈도우 10과 SSD를 사용하는 7세대 카비레이크-H 모바일 플랫폼에서는 8세대 인텔 코어 프로세서 플랫폼과 비슷한 약 7퍼센트의 성능 저하(SYSMark 2014 SE 벤치마크)가 있다고 밝혔다. 윈도우 10과 SSD를 사용하는 6세대 스카이레이크-S 플랫폼에서는 이보다 약간 더 높지만 7, 8세대 플랫폼과 비슷한 8퍼센트의 성능 저하(SYSMark 2014 SE 벤치마크)가 있었다고 밝혔다. 같은 6세대 플랫폼에서 윈도우 7을 사용했을때는 약 6퍼센트의 성능 저하(SYSMark 2014 SE 벤치마크)가 있었으며, HDD를 사용했을때는 이보다 성능 저하가 더 낮았다고 밝혔다.[46] 인텔은 추가 테스트를 수행할 때 마다 결과가 변경될 수 있다고 덧붙였다.

인텔은 광범위한 용도와 인텔 플랫폼의 성능 테스트 결과를 모으고 있으며, 다음주 안에 지난 5년간 출시된 모바일, 데스크탑 플랫폼의 데이터를 제공할 것이라고 밝혔다. 인텔은 업계 파트너사와 함께 성능 저하를 가능한 줄이기 위해 여러 해결책들을 만들고 있으며, 현재 출시된 제품 뿐 아니라 미래에 출시할 제품의 보안과 성능을 극대화하기 위해 노력하고 있다고 밝혔다.

2018년 1월 12일, 인텔 CEO 브라이언 크르자니치는 자사 홈페이지에 기술 업계 선두 기업을 위한 을 올렸다. 글에서 크르자니치는 1월 말까지 지난 5년간 출시된 제품의 업데이트를 마치고 그후에는 구형 제품의 업데이트를 배포하겠다고 말했다. 이어, 인텔 홈페이지에 지속적으로 보안 패치 진행 상황과 성능 데이터 등을 게시할 것이라고 말했다. 마지막으로, 모든 업계의 보안을 강화하기 위해 중요한 보안 취약점은 공개적으로 밝히고, 업계와 협력하며 사이드 채널 공격(side-channel attacks)을 방지하는 하드웨어 혁신을 업계와 공유할 것이며, 잠재적인 보안 위협 연구를 위한 연구에 기금을 지원할 것라고 말했다.

2018년 1월 12일, 인텔은 몇몇 시스템 특히 하스웰과 브로드웰 시스템에서 펌웨어 업데이트를 적용한 후 자주 재부팅 현상이 일어난다는 보고가 있었으며, 만약 이 문제가 개선된 펌웨어 업데이트를 필요로 한다면 제공할 것이라고 밝혔다.#

2018년 1월 21일, 리눅스의 아버지인 리누스 토르발스가 인텔이 내놓은 패치 내역을 검토하고 이에 대한 평가를 하였는데, 취약점 보완 상태를 선택적으로 취할 수(통보할 수) 있게 설정해둔 사실을 발견하였다#. 다시 말해서 멜트다운 보안 패치는 단순히 수정하는 것으로 끝나지만 '스펙터'의 경우 OS 에게 수정 사항을 활성화할 건지 말건지 OS에 선택권을 제공하고 있다는 뜻인데, 리누스는 해당 스펙터 패치가 성능 저하를 일으키기 때문에 벤치마크에서 이 것이 반영될 부분을 의식해서 켜고 끌 수 있게 남겨두었다고 말하면서 이번 패치를 쓰레기라고 비판하였다[47]. 즉, 인텔은 성능 저하가 없어야하는 스펙터 패치에서마저 성능 저하가 일어나고, 이를 숨기기 위해 벤치마크에는 OFF 상태에서 측정한 값을 결과랍시고 발표한 것이다. 이외에도 무한 재부팅 등 발견된 문제점이 한두가지가 아니었고, 결국 인텔은 자사가 직접 만든 스펙터 패치를 자사 제품 사용자들에게 사용하지 말라고 권고하는 상황까지 왔다.#

5.2. AMD[편집]

한편 AMD 측의 분석 결과 발표에 의하면, 구글 프로젝트 제로팀에서 언급해 준 취약점 중 스펙터 버그에 해당되는 "경계검사 우회(Bounds Check Bypass)" 변수는 OS/소프트웨어 업데이트로 해결이 되었으며 업데이트로 인한 성능 저하는 무시할 수 있는 수준이라 하였고, "분기표적 주입 (branch target injection)" 변수는 아키텍처 구조 상 문제 발생 가능성이 매우 낮으며, 아직까지 성공이 확인된 사례는 없다고 하였다. 그리고 멜트다운 버그에 해당되는 "불량데이터캐시 적재 (rogue data cache load)" 변수의 경우도 마찬가지로 아키텍처 구조의 차이(OoOE를 쓰지 않으므로)로 문제가 없다고 하였다.

  • 아직 공격 성공 사례는 없지만, 문제가 되는 추측 실행의 근본적인 원리는 AMD에도 해당되므로 선택적 마이크로코드 업데이트를 내놓기로 했다.[48] # (14번째 댓글 참고)


이것저것 피하면서 어떻게든 데미지 컨트롤부터 하려고 했던 인텔과 달리, 비전문가도 읽고 이해할 수 있도록 아주 깔끔한 해명을 해서 간만에 암드 PR이 일 잘했다는 칭찬이 나왔다. 이걸 암드가? 참고로 ARM홀딩스도 대응이 괜찮았다고 한다.

5.3. OS[편집]

리눅스 커널에는 패치가 적용된 상태다. 처음 멜트다운 취약점 해결 패치가 적용된 리눅스 커널은 아키텍처에 관계 없이 기본적으로 해당 보안 기능이 실행되기 때문에 성능저하를 막기 위해서는 커널 옵션에서 이 기능을 꺼 줘야 했으나,[49] 새 패치가 나오면서 인텔 CPU에서만 실행되도록 변경되었다.[50]

마이크로소프트에서 사태가 정말로 시급하기에[51], 원래 정기 업데이트로 예정한 날짜였던 1월 9일이 아닌, 한국 날짜 1월 4일 오전 6시에 윈도우 10에서만 긴급 업데이트를 실시하였다. 관련 기사 업데이트 내용 추가 설명[52]

이미 11월 경 MS측에서 해당 문제에 대한 확인이 진행되었다. 알렉스 이오네스쿠 트위터
맥의 경우 이미 베타테스트에서 해결된 상태다.
17년 12월 6일에 정식 보안 패치가 완료되었다.
파일:스크린샷 2018-01-05 오후 7.10.07.jpg
macOS High Sierra 10.13.2의 보안 콘텐츠, 보안 업데이트 2017-002 Sierra 및 보안 업데이트 2017-005 El Capitan에 관하여

5.4. 웹 브라우저, 그 외[편집]

기계어로 번역되는 자바스크립트를 통해 버그를 트리거할 수 있다는 점이 알려지면서 주요 브라우저들이 임시 방편을 적용했다. 브라우저 수준에서 취약점을 막긴 어렵지만, 공격이 나노초 단위의 정밀한 시계를 필요로 하기 때문에 우선 시계의 정밀도를 임시로 낮춰 놓은 것이다. (취약점이 여전히 남아 있지만 공격 속도를 수천배 이상 낮출 수 있다.) 각 브라우저 별 상황은 다음과 같다.[53]

  • 모질라 파이어폭스 57.0.4 (1월 4일 발표)

  • 네이버 웨일 v1.0.39.11 (1월 11일 발표)

  • 구글 크롬 64 (1월 23일 발표 예정)

    • 구글 크롬 63을 사용할 경우 chrome://flags/#enable-site-per-process에 들어가서 Strict site isolation을 사용하게 하면 문제를 미리 예방할 수 있다.

  • 윈도 7/8.1/10용 인터넷 익스플로러엣지 (1월 3일 발표)

    • 윈도 7/10에서는 자동 업데이트에 포함되어 있지만 윈도 8.1은 1월 6일 현재 자동으로 설치되는 월간 보안 업데이트가 없다. 월말까지는 KB4056898을 수동으로 설치해야 한다.

6. 사용자가 할 수 있는 대처법[편집]

6.1. 취약 여부 확인[편집]

윈도우에서는 MS에서 공개한 파워쉘 스크립트를 통해 확인할 수 있다. #
PowerShell을 관리자 권한으로 실행 후 아래 명령을 한줄 씩 차례대로 입력한다. 당연히 앞의 PS>는 빼고 입력해야한다. 중간에 모듈 설치를 물으면 Y를 입력한다.

PS> Install-Module SpeculationControl
PS> $SaveExecutionPolicy = Get-ExecutionPolicy
PS> Set-ExecutionPolicy RemoteSigned -Scope Currentuser
PS> Import-Module SpeculationControl
PS> Get-SpeculationControlSettings
PS> Set-ExecutionPolicy $SaveExecutionPolicy -Scope Currentuser

한줄이라도 붉은색 텍스트가 표시된다면 조치가 필요한 것이다. 취약하지 않거나 대응 조치가 완료되었다면 녹색 텍스트가 표시된다.

스펙터 멜트다운 CPU 체크 프로그램으로 테스트 해볼 수도 있다. 관련 기사 다운로드한 파일을 실행한 뒤 start security check 버튼을 누르면 된다.

6.2. 바이오스 업데이트[편집]

프로세서 제조사가 업데이트된 마이크로코드를 제공하고 메인보드 제조사가 그 마이크로코드를 탑재한 바이오스를 공개, 그리고 최종적으로 사용자가 그 바이오스를 자신의 메인보드에 업데이트해야한다. 최신 바이오스라고 해도 2018년 이전에 공개되었다면 취약점이 해결되지 않았을 확률이 높다. 스펙터 대응 바이오스는 2018년 1월 현재 소수 모델에 겨우 배포되기 시작했다. 쉽게 말해 구형 마더보드를 쓰고 있다면 안타깝게도 현재로서는 아예 대응 방법이 없다는 것이다.

인텔에서는 5년 내에 출시된 CPU에 대해서 업데이트를 제공하겠다고 발표#했으며 이후 취약점을 해결한 마이크로코드를 배포했다. 2013년 출시된 아이비브릿지 EP/EX 및 하스웰 이후 CPU들에 해당.#

참고로, 기가바이트의 GA-B150M-D3H 메인보드의 경우 1월 16일 CPU 마이크로코드를 업데이트한 새 버전의 BIOS가 올라왔는데, BIOS 업데이트 전에는 스펙터에 취약하고 멜트다운에는 안전하다는 결과가 나왔는데 (윈도 10 보안 패치는 적용한 상태) BIOS를 업데이트한 후 스펙터 멜트다운 CPU 체크 프로그램을 돌리니 스펙터와 멜트다운에 모두 안전하다는 결과가 나온다.

6.3. 윈도우[편집]

현재 하스웰 CPU에서 대응 패치 후 무한 재부팅에 걸리는 경우와 2~7세대 cpu의 내장그래픽을 사용하는 컴퓨터에서 재부팅이 발생하는 경우가 있다. 해당 시스템을 사용하는 사용자라면 주의.

자동 업데이트 기능을 켜놨다면 대개 알아서 해당 업데이트가 설치된다. 만약 설치가 되지 않을 경우 마이크로소프트 카탈로그 사이트에 들어가 자신에게 맞는 업데이트를 설치한 뒤, 재시작하면 된다. Win + R키를 눌러 실행 창을 띄운 뒤 Winver를 입력하면 창이 하나 뜨는데, 버전 xxxx라고 나온 번호가 자신의 버전이다.

윈도우 7

서비스 팩 1

다운로드

윈도우 8.1

Update 1

다운로드

윈도우 10

Threshold 1 (TH1) 버전 1507

다운로드

Threshold 2 (TH2) 버전 1511

다운로드

Redstone 1 (RS1) 버전 1607

다운로드

Redstone 2 (RS2) 버전 1703

다운로드

RedStone 3 (RS3) 버전 1709

다운로드

RedStone 4 (RS4) 버전 1803

기본 포함 예정


이외의 윈도우 운영체제는 여기서 받으면 된다. 윈도우 서버제품군은 일반버전이 있고, XP는 패치가 없으나 POS버전으로 쓰이는 XP 임베디드의 패치를 이용하는 방법이 있다고 한다. 키를 고쳐서 엠베디드 버전으로 인식하게 해 보안업데이트를 진행하는 건데, 다 되는 건 아닌지 일부 문제가 생겨 피시용을 어느 킷까지는 그걸 모른다 감으로 올리고 POS용 임베디드를 올리는 식으로 했다는 말도 있다.

위 사이트에 접속하여 자신의 윈도우 버전을 선택한 후 델타 업데이트와 누적 업데이트로 나뉘는데, 자신의 윈도우가 최신 업데이트 까지 된 상태라면 델타 업데이트를, 아니거나 확인하기 귀찮다면 누적 업데이트를 다운로드하여 설치하자.

참고로 업데이트 이후 일부 PC에서는 SPTD를 인식할 수 없는 오류가 발생해 DAEMON Tools를 비롯한 몇몇 가상 CD 이미지 파일 프로그램들을 사용할 수 없게 되는 경우도 있다.

6.4. macOS[편집]

Mac App Store에서 업데이트를 통해 High Sierra 10.13.2를 설치하면 된다. 자신의 OS 버전이 10.12 시에라이고 하이 시에라로 업데이트하고 싶지 않은 경우 2017-002 보안 업데이트를, 10.11 엘 캐피탄인 경우 2017-005 보안 업데이트를 설치하면 된다. 그 아래 버전은 보안 패치가 제공되지 않는다.

6.5. 리눅스[편집]

리눅스배포판 업데이트를 하면 된다. 애초에 이 버그는 이렇게 빨리 공개될 예정이 아니었고, 오픈소스인 리눅스 커널을 패치하던 중 수상한 패치 요약이 개발자들의 의심을 사는 바람[54]에 빨리 공개된 것이다. 즉, 리눅스에선 버그 발표보다 패치가 올라온 게 더 빨랐다. 물론 각종 Linux 배포판들이 새로운 커널을 공식 지원해서 업그레이드를 유도하고 설치하는 건 별개의 일이라 발표 전 미리 리눅스 서버들에 대비가 되어 있었다는 건 아니다.

7. 사건 여파[편집]

7.1. 보안 패치 후 하드웨어 성능 하락[편집]

하드웨어의 취약점이기 때문에 이를 OS와 커널 등 소프트웨어 수준에서 해결하려면 성능 하락이 발생하게 된다. 현시점에서 보안 버그 패치 시 성능 저하를 피할 수 있는 방법은 없다고 전문가들이 전했으며, 일부 유저들은 1월 9일 뒤에 상황을 보고 나서 더 논해보자는 신중론을 보이고 있다.

취약점이 공개되기 전 레딧에서 언급된 테스트 결과는 상당한 성능 하락을 보였기에 큰 논란이 되었다. 작업별 테스트 결과 게임 테스트 결과

역시 실제 패치가 진행되기 전 인사이더 패스트링 빌드로 올렸던 윈도우 10 RS4 17035로 테스트한 결과도 비슷했는데 읽기 속도도 감소했지만, 쓰기 속도의 경우 심각하게 감소했음을 확인 할 수 있다. 다만 이는 960 EVO 특유의 캐시 특성에 따른 결과일 확률이 높다. 캐시 메모리를 다 사용한 후 유동적으로 적용되기 때문에 값이 요동친다는 주장이며 이 말대로라면 패치 이전 값 역시 편차가 클 것이고 실제로 MLC인 950 Pro, 960 Pro로 측정했을 시 패치 이후 심각한 성능 하락은 없다. 위 유튜브 링크 중 950 Pro로 측정한 값이 있는데 실제로 16K에서 약간 하락한 것 빼곤 거의 차이가 없다. 또한 패치 RS4 17035 테스트의 경우는 보안패치 이외에 기능업데이트로 인한 영향일 수도 있다.같은 삼성의 850 EVO의 경우도 업데이트 전후로 읽기, 쓰기 속도가 모두 20% 가까이 하락한다는 벤치 결과가 있다. # 850 EVO 역시 TLC와 캐시 구조를 가진다. SATA 버전의 경우 일부 항목은 변화가 없는 경우도 많다.

다만, NVMe 형식의 SSD의 경우는 그보다 더 하락폭이 더 커졌으며, 성능이 높을수록 그 폭은 더 커진다.선 없이 보드에 직접 연결이 된 것도 이유 중 하나겠지만, SATA형식의 SSD와 비교해서 속도 자체가 더 빠르기 때문에 그 폭이 더 커진 것으로 추측된다.

패치 이후에는 다소 다른 결과가 나오기 시작했는데 가장 논란이 되었던 성능 하락을 확인하기 위한 유튜브에 올라온 업데이트후 진행된 벤치마크 결과 영상이다. # 전반적으로 1~2% 정도의 차이를 보이며 특정 벤치마크는 업데이트 후가 더 잘 나오기도 한다. 측정 편차에 의한 오차를 감안하면 일반사용에 있어서 크게 영향을 느끼기 어려울 것으로 판단된다. 단 개인마다 컴퓨터 사양의 차이가 있어 영상결과와 다를 수 있으며, 16K 영상의 쓰기, 읽기 속도가 약 10% 정도 하락한 것을 보면 대용량 미디어 정보를 관리하는 서버는 영향을 어느 정도 받을 듯 보인다.[55]

SSD보다 메모리를 벤치를 비교해야 된다는 얘기가 있다. #, #

레드햇 성능팀이 Red Hat Enterprise Linux 7을 기준으로 벤치마크한 결과를 공개했다. 요약하자면, 아래와 같다.

  • Measureable: 8~19% - Oracle OLTP, MariaDB, PostgreSQL, fio(Random IO to NvME)와 같은 buffered IO와 cached random memory access, OLTP DB 환경

  • Modest: 3~7% - DW성 업무(Analytics), Java VM, MongoDB 등

  • Small: 2~5% - HPC와 같은 CPU intensive 업무


IBM에 따르면, 성능 하락은 작업량과 시스템 환경에 다르다고 한다. 예를 들어 순수하게 메모리 기반 연산을 하고 최소한의 소프트웨어만 구동되는 텍스트 기반 환경에서는 큰 성능 하락이 없을 것이며, 많은 저장 장치와 네트워크가 연결이 되었으며 주로 정보 저장소로 사용되는 GUI 시스템에서는 큰 성능 하락이 있을 수 있다고 한다.

현재까진 게임 성능에는 가시적인 저하가 없는 것으로 확인되었다. 업데이트를 받아보고 즉시 벤치를 돌려본 유저들의 의견에 의하면 성능상으로 큰 차이는 없다는 언급이 대부분이다. 게임은 소프트웨어보조기억장치에 설치해 놓고 실시간으로 리소스를 읽어오는 방식인데 위의 서술대로 쓰기 속도가 저하된다고 해도 읽기가 대부분인[56] 게임엔 영향을 미치치 않을 수도 있다. 애초에 위와 같은 쓰기 속도 저하도 일반적인 것은 아니었지만.

하스웰부터 지원하는 INVPCID 기능으로 인해 이전 CPU들보다 성능 하락폭이 다소 줄어들었다고 한다. 그렇다고 성능하락이 없는 수준은 아니다.
MS의 설명에 따르면 스카이레이크 이전 세대의 경우 분기 예측을 아예 꺼버린다고 한다. 한마디로 기능 자체를 쓰지 못하는 셈.
구글과 아마존닷컴 측은 멜트다운, 스펙터 버그 패치로 인한 성능 저하 논란은 과장된 이야기이며, 자사의 서버나 클라우드 서비스도 이렇다 할 퍼포먼스 하락은 보이지 않는다고 언급했다.# 마이크로소프트는 자사의 Azure 서버가 보안 패치 이후 뚜렷한 성능 하락은 보이지 않는다고 밝혔다.# 애플은 보안 패치 이후, GeekBench 4나 Speedometer, JetStream, ARES-6같은 일반적인 웹 브라우징 벤치마크로 테스트했을 때, macOS와 iOS에서 주목할 만한 성능 하락은 보이지 않는다고 밝혔다.#

구글은 자사 보안 블로그를 통해 자체 개발한 보안 패치 기술, 레트폴린(Retpoline)을 공개했다. 해당 패치는 분기표적 주입 (branch target injection) 에 대한 패치이다. 구글에 따르면, 해당 기술이 해킹 위험을 없애면서도 CPU 성능 저하도 막을 수 있다고 한다. 구글은 해당 기술을 업계 파트너사와 공유할 것이며 성능에서 무시할 만한 영향을 준다고 발표했다.

에픽 게임즈에 따르면, 클라우드 서비스 서버에 멜트다운 대응을 위한 업데이트를 한 뒤, 클라우드 서비스 서버의 CPU 사용량이 크게 올라갔다고 한다.#, [CPU 게이트] 에픽게임즈, 보안 패치 후 “서버 CPU 점유율 올랐다”. 이로 인해, 로그인에 문제가 생기고, 서비스 불안정성이 발생했다고 한다. 에픽 게임즈가 사용하는 클라우드 서비스가 패치됨에 따라 다음주에 예상치 못한 문제가 발생할 수 있으며, 에픽 게임즈는 향후 문제를 막기 위해 클라우드 서비스 제공자와 협력하며 가능한 빠르게 발생하는 문제를 완화시키거나 해결하는 데 총력을 다할 것이라고 밝혔다.

MS의 수석부사장인 테리 마이어슨은 “인텔 보안 결함을 해결하려고 적용한 패치로 인해 특정 서버의 처리 속도가 상당히 느려졌다.”는 말과 함께 “패치 후 성능 저하문제가 인텔이 인정한 것보다 더 심각할 수 있다”는 말과 “일부 PC나 서버의 속도가 현저하게 떨어졌는데 특히 2015년형 PC로 윈도7이나 윈도8을 사용하는 소비자 대부분이 뚜렷한 성능저하를 느낄 것”이라고 지적했다.

해당 사태가 지속적으로 일어나자 인텔에서도 해당 문제를 인정하였다. 주요 시스템에서 6~7%정도의 하락이 있으며, 경우에 따라 10%이상 하락이 이루어진다고 하였다. 게다가 이 부분은 스카이레이크 이상의 cpu에서 일어나는 부분이라 그 이상 된 구형 cpu의 경우는 하락폭이 더 커진다.

인텔의 공식 벤치에서는 이렇게 되어 있다.
* 8세대 모바일 프로세셔 기반 시스템의 경우 종합점수 기준 적게는 1% 많게는 10%,세부점수 기준 최대 14% 하락
* 7세대 모바일 프로세셔 기반 시스템의 경우 종합점수 기준 적게는 1%에서 많게는 7%. 세부점수 기준 최대 14% 하락
* 6세대 데스크탑 프로세셔 기반 시스템의 경우 종합점수 기준 최대 10%, 세부점수 기준 최대 21% 하락. 경우에 따라 6% 성능 상승

서버쪽의 경우 데이터센터에서 상당한 성능 하락이 이루어졌다. 테스트 환경은 2소켓 인텔 제온 시스템(스카이레이크)인데 상당히 비싼 cpu이며, 고사양을 자랑하는 수준인데도 불구하고 정수와 부동소수점 처리량, 린팩, 스트림, 자바 테스트에서는 0~2%. 온라인 거래 처리 OLTP 벤치마크는 4% 하락했다. 스토리지 벤치마크는 구성에 따라서 몹시 다양한 결과를 보였는데, 100% 쓰기에선 CPU의 부담이 매우 커졌으며 이 경우엔 18%의 성능 하락하였다. 70% 읽기에 30% 쓰기에선 2% 줄어드는데 그쳤으며, 100% 읽기에서는 별 영향이 없었다. 그리고 SPDK (Storage Performance Development Kit) 테스트에서는 다양한 조합의 iSCSI 성능이 25% 정도 떨어졌습니다.

7.2. 패치 자체의 문제[편집]

i5 1세대 CPU(린필드)에서 패치 이후 지속적으로 컴퓨터가 강제 종료되는 현상이 일부 사용자에게서 발생한다고 한다. 또 하스웰 (4세대) 칩에서는 패치를 하면 강제 재부팅 현상이 발생한다고 한다.# PC가 무작위로 꺼졌다가 켜진다는 것이다. 12일 나온 WSJ 기사에 따르면, 인텔은 보안패치의 결함을 인정하고 일부 고객에게 (하스웰 사용자들) 패치를 설치하지 않도록 권고했다. 그러다가 인텔 코어 2 ~ 7세대 내장 그래픽 사용자는 재부팅 현상도 발생되기 시작하였다. 기사 그야말로 점입가경
결국 인텔은 패치 배포를 중단했다. 기사 추후 새로운 마이크코드 업데이트가 예정되어 있다.

한편 일부 구형 AMD 시스템(구형 애슬론에서 문제가 있었다고 한다)에서도 패치 이후 컴퓨터가 부트되지 않는 문제가 발생했다고 한다.# 이유는 일부 AMD 칩셋이 AMD가 제공한 문서대로 작동하지 않기 때문이었다고(...). MS와 AMD는 일단 이 패치를 AMD 시스템에서 받지 못하게 하였으며 며칠 후 해당 문제를 해결한 패치가 나왔다.

이외에도 메모리 관련 패치다 보니 산업용 임베디드 시스템에서 문제가 많다고 한다. 기사 최근에는 공장이라도 랜섬웨어 공격을 당하는 등 보안에서 안전 지대가 아니기 때문에 보안 패치가 필수가 되어가는 상황인데 이런 식으로 문제가 생기면 답이 없다(...).

8. 이후 전개[편집]

사건 전개도

  • 멜트다운 버그의 구조에 대해 잘 모르던 개인 사용자들에게는 대응 패치 이후 성능 저하 여부만 주목받았으나, 사실 멜트다운 버그의 핵심 부분은 보안 취약점이기 때문에 성능 저하는 어디까지나 덤에 가깝고, 보안 문제가 훨씬 더 심각하다.

  • 예상대로 개인 컴퓨터의 성능 저하는 심각하지 않았다 (일반적인 사용에서는 성능저하 0%). 반면, CPU를 많이 쓰는 서버에는 누적 성능 저하가 영향을 주고 있다.

  • 배터리 게이트의 애플처럼 인텔의 무성의한 대응이 사태를 더욱 악화시키고 있다.[57]

  • AMD가 이 문제에서 완전히 자유로운 것은 아니며, 또한 대다수의 모바일 CPU가 위협에 노출되어 있다.

  • CEO 브라이언 크르자니치를 포함한 인텔 전현직 고위 간부들은 작년 11월부터 12월까지 CEO의 경영권 보장 분의 주식 등을 제외한 본인들이 팔 수 있는 한계 안에서 모두 주식을 매각하였다. 특히 크르자니치는 엔지니어 출신인데 그동안 한 일이 가관이다. R&D 예산 대폭 삭감, 엔지니어 대량 해고, 기존의 상품을 조금씩 바꾸어 비싸게 팔아먹음, 엄청난 CPU 결함을 알고도 신제품 출시, 그리고 결함을 은폐하고 자신이 소유하고 있는 주식중에서 팔 수 있는 수준의 자사 주식은 다 팔아 먹음. 정작 이 사건이 알려지기 전인 2017년 12월 포브스에서 '사내 복지 잘하는 CEO 1위'로 선정되기도 했다.

  • 인텔은 혼자 죽기 싫어서 '모두 문제가 있다'는 식으로 물타기.

  • 인텔, CPU 보안 결함과 관련해 집단소송 피소.[58]

  • 구글, 인텔에 수 개월 전부터 이를 통보했으나 인텔 측에서 무시, 심지어 인텔의 CEO인 크르자니치 역시 이를 알고 있었음을 실토.

  • 닌텐도 스위치를 포함한 여러 콘솔 게임기들의 불법 복제 및 보안 체계 붕괴.[59]

  • 미국 상원 은행위원회 소속 상원의원 2명은 증권 거래 위원회와 법무부에 인텔 CEO 브라이언 크르자니치가 내부자 거래법을 위반했는지 조사해줄 것을 촉구했다.# 인텔은 모든 정부 조사와 수사에 협조하겠다고 밝혔다.


상황 초기에 비해 개인 사용자 사이에서의 성능 저하는 잠잠해졌지만, 맨 위에 있는 멜트다운 데모 동영상이 공개되자 보안 결함이 예상보다 훨씬 심각한 상황이었음이 알려졌다. 보안패치가 필수가 된 만큼 CPU의 성능 저하가 적다고 해도, 하나하나의 성능 저하가 누적될 만큼 여러개, 대량의 CPU를 사용하는 서버와, 클라우드 컴퓨팅 회사들이 큰 영향을 받을 것으로 보인다. 마이크로소프트, 구글, 바이두, 드롭박스 등 여러 회사들은 AMD EPYC 시리즈를 이미 여러 서버에 적용 중이며, 이번 보안 문제로 인해 인텔의 보안 관리 능력에 의심을 가진 회사가 늘어나 AMD의 서버 시장 점유율이 높아질 가능성이 있다. 근본적으로 하드웨어 문제라 멜트다운에 한정해서 현존하는 최선의 해결책은 AMD EPYC 시리즈로 옮기는 것밖에 없고[60], 성능도 DBMS 등의 몇몇 지표는 떨어지지만 전체적으로 크게 개선되었으며 심지어 가격도 제온이 더 비싸다.

현재 인텔의 핵심 인력은 은퇴하거나 퇴사[61] 혹은 사망한 지[62] 오래이고 R&D 조직이 망가졌다는 내부 소식이 있다(번역본). 최악의 경우 리콜 후 보상으로 인해 인텔이 엄청난 경영난을 겪을수도 있다.[63] 2018년 1월 4일 기사에 의하면 인텔은 멜트다운과 스펙터로 인한 리콜은 없다고 밝혔다.#[64]

인텔은 이번 이슈로 인해 하루 만에 주가가 7% 가까이 하락하였다. 한편 지난 석달 새에 인텔의 크르자니치 CEO를 포함한 주요 고위층 간부들이 주식을 매도해왔다는 사실이 보도되어 이미 간부들은 이 사실을 미리 알고 주가가 하락하기 전에 손을 턴 것이 아니냐는 의혹이 제기되고 있으며 사실일 경우 이는 모럴해저드, 노블리스 오블리주에 관한 중요한 문제다.[65] 때문에 현재 2명의 미국 상원의원이 증권 거래 위원회와 법무부에 인텔 CEO를 조사해줄 것을 촉구하고 있는 상황이다.

한편 인텔 측에서는 다른 CPU도 문제가 있다고 언급하였는데, 이는 사실이기는 하다. 하지만 스펙터 버그는 앞서 말한 특성상 활용 범위가 제한적이다. 멜트다운 취약점과 스펙터 버그는 엄연히 무게와 양상이 다른 버그임에도 모든 CPU의 동일 문제인 듯한 뉘앙스로 변명한 것은 물타기이다.

대부분의 인텔 CPU가 하드웨어적으로 문제점이 있다는 것이 드러나자 난리가 났으며 위에서 이야기하다시피 보안 패치는 근본적인 해결책이 되지 못한다. 그동안 인텔 CPU를 쓴 기기들은 취약점에 고스란히 노출될 수 밖에 없고, 소프트웨어 패치로 최대한 버티거나 AMD의 ZEN 아키텍처 기반 CPU로 갈아타는 것 외엔 별다른 방법이 없다. 다만 일반인의 경우 성능 상의 하락에 대해 크게 걱정할 부분이 없으나 각종 서버 등 기업용 제품의 경우 문제가 될 수 있다. CPU교체 이외에는 근본적인 해결책이 없어서 매우 난감한 상황.

인텔이 P6 아키텍처를 버리고 새로운 아키텍처를 만들어야 한다는 주장이 있지만 신빙성은 크지 않다. 예외처리 검사를 일찍 해서 실행 단계로 넘어가기 전에 명령을 버리는 방식으로 대응할 수 있다. 다만 확실한 것은 인텔의 후속작품이 나와야 알 수 있다.

구글 측에서 밝힌 보안 취약점 보고서에서 AMD는 스펙터 버그에만 해당하는 변수 1,2의 가능성만을 가지고 있다고 했으며, AMD도 아예 변수 3은 아키텍처가 달라 해당사항이 아니라 했고, 1은 이미 펌웨어 업데이트로 조정, 2는 자체실험 결과 발견되진 않았다고 했다. 실제로는 유형 1(스펙터)는 AMD 역시 라이젠을 포함하여 거의 모두 해당하고 유형 2(스펙터)는 발견되지 않았고 유형 3(멜트다운)은 AMD는 CPU 아키텍처가 달라 해당하지 않는다.

또한 이미 구글 측에서 이런 보안 취약성에 대한 연구결과를 인텔 측에 따로 제보하였음에도, 인텔에서는 별다른 조치를 취하지 않은 것으로 보인다. 프로젝트 제로 게시글에 따르면 각 CPU 벤더들의 반응은 다음과 같다.

  • AMD는 홈페이지에 각 취약점의 영향과 해결 방법을 공지하였다.#

  • ARM은 해당 취약점에 영향을 받는 칩셋과 해결 방법에 대한 페이지를 공개하였다.#

  • 인텔은 답변을 전혀 주지 않았다고 한다(No current statement provided at this time).

9. 외부 링크[편집]

[1] 명령어의 비순차적 실행을 지원하는 모든 제품[2] 당연하다. 이게 누설될 경우 그대로 제로 데이 공격의 빌미가 되어 버려 헬게이트 당첨이다.[3] 다만 시스템 콜을 많이 사용하는 게임(로딩이 빈번하게 발생하거나 네트워크를 통해 전송되는 정보가 많은 온라인 게임)은 영향을 받을 가능성이 있다.[4] 게임 서버들은 네트워크 및 파일시스템 I/O와 DB 입출력이 매우 빈번하므로 여기서 성능 저하가 있을 수 있다.[5] 패치 전후의 시스템 콜의 자체의 성능만 테스트한 결과 최대 70% 이상 성능이 떨어졌다는 테스트도 있다. 물론 실제 프로그램에서는 다른 작업을 같이 수행하기 때문에 이 정도로 성능 하락이 일어날 가능성은 없지만, 프로그램의 작동 방식 및 상황에 따라서 매우 큰 폭의 성능 하락이 일어날 가능은 열려 있다.[6] 원문은 익스플로잇(exploit), 컴퓨터 보안 업계에서 사용하는 용어로, 취약점 또는 이를 공격하는 것을 말한다. 단순하게 말하면 해킹.[7] 원문은 our proof-of-concept exploit. 발견한 버그를 활용하여 공격을 가할 수 있음을 보이는 실증 테스트용 코드를 의미한다.[8] 들고 있는 나뭇가지는 분기 예측 실행(branch-prediction execution)을 뜻한다.[9] A15, A57, A72, A75 단독으로만 봐도 100만 대 이상의 스마트폰이 취약점에 노출되어있는 상황이다. A57은 발열로 유명한 화룡 810과 808에 들어갔다. 삼성의 엑시노스 7(5433)에도 들어가긴 했으나 엑시노스의 경우 아키텍쳐를 다르게 설계했다고 알려져있기에 취약성의 여부는 아직까지 확인되지 않고 있다.[10] all modern processors capable of keeping many instructions in flight are potentially vulnerable[11] 해당 영상이 나오기 전엔 성능저하 때문에 업데이트를 고민하는 사람이 많았지만 시연 영상이 뜨자마자 대부분 태세전환했을 정도로 심각한 상황임을 보여주고 있다.[원본] #[13] 이는 애플의 모바일 기기에 들어간 칩셋들이 ARM의 명령어 셋을 취득해 변형한 후 쓰기 때문으로 보인다. 특히 CPU 보안 버그 3a에 포함되는 ARM Cortex-A72, Cortex-A57, Cortex-A15는 애플도 쓰고 있는 ARMv8-A에서 파생되어 나온 CPU들. 닌텐도 스위치의 경우도 테그라 X1의 빅 코어가 코어텍스 A57 기반이라 영향을 받는 것으로 추정.[14] 확실한 내용은 Variant 3 또는 3a의 코드를 확인한 사람이 추가바람. [15] 커널은 윈도우/맥OS/리눅스 등 운영체제의 핵심 부분을 이룬다. 그 자체로는 소프트웨어이지만, 물리적인 하드웨어와 다른 소프트웨어 사이의 연결을 담당한다. 하드웨어와 거의 직접적으로 연결되는 부분이기에 CPU나 메모리 등 하드웨어에서도 커널 소프트웨어의 동작을 돕기 위한 장치가 되어있다.[16] 자세한 것은 메모리 계층 구조 참조[17] 실제 사실과 반대되는 상황을 가정하는 것[18] 보다 좋은 설명을 하고싶다면 가급적 Variant 3 또는 3a 코드를 직접 읽은 사람이 '기술적으로 완벽한 설명' 문단을 새로 작성할 것을 권한다. 아울러 3.1.1~3.1.3 문단까지의 내용은 여러 차례 토론을 거쳐 합의된 것이기에 수정을 원할 시 토론을 거치는 것이 좋다.[19] 실제로는 캐시가 RAM에서 정보를 한 번에 가져오는 단위인 캐시라인을 고려해야 한다. 여기에서는 설명을 위해 단순화 시켰다. 사실 거기까진 나도 몰러.[20] C가 실행되지 않았는데 D가 실행될 수 있는 이유는 파이프라인 구조에서 성능향상을 위해 실행이 완료되지 않은 명령어의 정보를 다른 명령어에게 전달할 수 있기 때문이다.[21] CPU클락 카운터 등 정밀한 시계를 사용한다.[22] 읽기는 무작위로 해야한다. 순서대로 읽을 경우 CPU에서 이를 예측하고 ua2의 일부 내용을 캐시에 미리 올릴 수 있다.[23] 인텔의 전(前) CPU 아키텍트 프랑수아 피에노엘은 "이번 버그는 컴퓨터 과학의 새로운 발견이며, 발견되기 전에 몰랐다고 해서 과학자들을 비난할 수 없다."고 트위터에 을 올렸다.[24] 파이프라인을 안 쓰면 지독한 성능저하를 경험한다. 여담이지만 요새도 산업용으로 근근히 POS에서 보이는 1~3세대 아톰 CPU들과 잔존하는 486호환 CPU들은 분기예측이 없다.[25] "비순차적 명령어 처리 (OoOE) 없이도 SMT 잘만 쓰는 AMD는 뭐냐?"고 반문할 수도 있는데, 비록 SMT라고 뭉뚱그려 일컫지만 세부 구현은 인텔과 자못 다르다.[26] "컴퓨터 과학의 새로운 발견"이라는 피아노엘의 지적을 다시 한 번 음미해보자. 10년 가까운 기간동안 수 만명의 엔지니어 중 누구도 이 사실을 몰랐다[27] 현재로썬 교체자체가 불가능하다. 거의 모든 인텔 CPU에 문제가 있는데 미국 CERT/CC에선 처음엔 하드웨어 교체가 필요하다고 했지만 다음날에 철회하고 소프트웨어 패치로 버티는 방식으로 바꿨는데 여기에는 현재 나와있는 대부분의 인텔 CPU가 영향을 받는 것도 원인이 있는 것으로 보인다. 스펙터 취약점까지 고려하면 자유로운 CPU가 없는 것도 문제고.[28] 예를 들어 전력거래소를 해킹해 전국 화력발전소에 동시에 셧다운 명령을 전송한다 해도 각 발전소에서 근무하는 직원이 수동 조작으로 셧다운 명령을 취소할 수 있다.[29] 기업용 CPU는 암/복호화를 위한 전용 하드웨어 로직을 갖고 있다. 이 로직이 작동한 흔적을 추적하는 것이다.[30] 함수 호출 뿐 아니라 더 일반적으로 jmp와 같은 점프를 뜻한다.[31] 이 부분은 멜트다운도 동일하다.[32] 당장 성능으로 까이는 베이트레일 이전의 인텔 아톰 시리즈만 봐도 알 수 있다. 순차적 처리만 지원해서 상술했듯 두 취약점이 없다.[33] 여담으로 이 회사는 샤오미社의 홍미 노트에서 중국 정부의 백도어를 발견했던 회사이다.[34] 기업용 PC 및 노트북에 사용되는 vPro 테크놀러지에 AMT가 포함되어 있다.[35] 근데 AMT도 인텔ME 계열이다.[36] 해당 문제 설명에서 PC에 물리적 접근이 필요하다는 말이 이것 때문이다. 처음부터 부팅 시의 셋업까지 원격으로 가능한 경우는 거의 없고, 설정에서 풀어 놓아야 한다.[37] 코어 아키텍처 기반의 E 시리즈와 웨스트미어 아키텍처 기반부터 현재까지의 G 시리즈가 이에 해당된다.[38] 애플 워치는 원천적으로 멜트다운과 스팩터 모두에 영향을 받지 않으며, 나머지 기기들은 17년 12월 6일에 멜트다운 버그 패치를 받았다.[39] 표와 번역 내용에 오류가 있으니 주의.[40] 단 자체 아키텍처로 변경하기 전의 모델은 똑같이 영향을 받는다.[41] 맞는 말이긴 하다. 문제는 메모리의 암호를 유출 가능함으로써 그 암호로 다시 내부 시스템을 위에서 말한 데이터를 손상, 수정, 삭제를 할 가능성은 열려있다.[원문] Contrary to some reports, any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time[43] 내용을 보면 알겠듯이 범용적인 보안 지침 안내이다. 이걸 안 지켜서 사달이 난 것이 불과 몇 개월 전에 벌어진 워너크라이 사태.[44] 연설문 전체는 여기에서 볼 수 있다.[45] 해당 기사에서 자화자찬 논란이 일고 있다고 했지만, 해외의 반응을 보면 보안 이슈와 사과가 없다는 것에 더 논란이 일고 있다. 이후 인텔 홈페이지에 올라온 기사를 보면, 크르자니치가 이러한 표현을 사용한 것은 자화자찬이라기보다는 보안 이슈를 발견해주고, 해결하기 위해 협력해준 업계에게 감사를 표하기 위해 사용한 것으로 보인다.[46] 더 자세한 내용은 여기에서 볼 수 있다.[47] As it is, the patches are COMPLETE AND UTTER GARBAGE[48] AMD will make optional microcode updates available to our customers and partners for Ryzen and EPYC processors starting this week. We expect to make updates available for our previous generation products over the coming weeks. These software updates will be provided by system providers and OS vendors; please check with your supplier for the latest information on the available option for your configuration and requirements. 출처는 위에 적힌 발표 링크[49] 출처[50] 어떤 인텔 엔지니어가 그냥 모든 CPU에 패치가 적용되게 만들었다가 리누스 토르발스한테 걸려서 메일로 구수한 쌍욕을 얻어먹기도 했다. 쌍욕 먹어도 할 말 없는 문제다. 자사의 문제점을 해결하는 패치로 타사의 제품까지 성능을 낮췄으니.[51] 윈텔이라는 말이 있을 정도로 Microsoft Windows와 인텔은 서로 떼어놓을 수 없는 관계다.[52] 당시 마이크로소프트는 다른 운영체제는 1월 9일에 패치가 나올 거라고 했는데 이건 자동 업데이트 기준이었던 모양으로, 1월 4일에 다른 운영체제도 수동 업데이트는 나왔다. 1월 9일엔 윈도우 10 이외의 운영체제도 자동 업데이트로 업데이트가 된다.[53] 브라우저도 CPU 보안결함 대응 나섰다[54] 버그를 모르는 사람이 보기엔 합리적인 근거 없이 I/O 성능을 대폭 깎아먹는 패치가 올라온 것이니 의심할 수밖에 없다.[55] 물론 서버환경에 IO만 영향을 주는 것은 아니기에 클라이언트 사용자 기준에선 체감이 없을 가능성도 있다.[56] 세이브, 스크린샷, 설정 변경 등 소수 기능은 쓰기를 이용하지만 이러한 작업은 전체적인 게임 진행 중 매우 일부분만 차지하기 때문에 별 상관이 없다.[57] 왜 그렇냐면, 이 버그도 대응이 무성의하지만 그 직전에 일어난 인텔 관리 엔진 관련 보안 버그도 굉장히 무성의한 대응으로 일관 중이고, 이 문제도 현재진행형이다. 레노버, HP: 아이고 두야...[58] IT거인 큰코 다치나..인텔에 소비자 줄소송, 애플엔 벌써 26건[59] 특히 닌텐도 스위치는 최근 엔비디아 테그라 칩셋에 의한 보안이 뚫려 PSP의 커펌 문제가 재발할 가능성이 매우 높아져 심각한 문제가 될 수도 있다. 반면 플레이스테이션 4(Pro 포함), 엑스박스 원(X 포함)은 AMD의 CPU를 쓰기 때문에 영향이 적다. 결국 스위치는 15일에 에뮬 소식이 들려왔다. 다만 gpu 연산이나 3d 렌더링이 아직이기에 게임을 돌리려면 시간이 더 필요하다고 한다.[60] 스펙터는 인텔이나 AMD, ARM 등 현대에 쓰이는 거의 모든 프로세서가 가진 문제점이라 현재로써는 사실상 회피가 불가능하다. 물론 소프트웨어 업데이트가 진행되기는 하지만 하드웨어적 결함인 만큼 완벽한 해결은 불가능.[61] 인텔의 엔지니어 프랑수아 피에노엘[62] 인텔의 전 CEO 폴 오텔리니[63] 한 전문가에 따르면, 리콜 비용이 약 270억 달러 이상, 한화로 약 29조 원 이상될 것이라고 한다.[64] 사실 리콜 자체가 불가능하다고 보는 것이 더 적절하다. 95년 이후 생산된 대부분의 CPU에 보안 결함이 있는 상황에서 리콜을 해도 보상해 줄 CPU가 없기 때문. 인텔 내에서 멜트다운 버그가 없는 CPU는 기껏해야 (베이트레일 이전의) 아톰 시리즈 정도밖에 없는데, 써본 사람은 알겠지만 속도가 나무늘보 수준이다(...).[65] 인텔 CEO·전직 CFO, 3개월간 보유주식 '매도'..보안결함 알았나