하버드에서 발행한 글에서, 존에게 불운하게도 브랜치들이 사탄과 양자역학과 거래를 맺어서 미래 세대 프로세서에 해로운 마법을 걸었음이라는 재치 있는 비유를 들며, 이 마법은 '스케일링으로 인한 전압 누수'나 '낭비되는 열 증가' 같은 이름으로 남았음
James Mickens의 글이 항상 재미있음이라는 감상과 함께, 보안을 담당하는 Mossad가 HTTPS 같은 걸 신경 안 쓴다는 농담을 인용하며, 그들은 데이터가 필요하면 아예 드론으로 핸드폰을 우라늄 모조품으로 바꿔치기하고 결국은 당신의 소지품을 유품 세일에서 사와서 직접 사진을 본다는 유쾌한 상상
수많은 행렬에 대해 언급한 부분이 약간의 희망을 보여줌이라는 의견과, 존의 동생이 그 행렬들에 사람처럼 말하도록 가르친 방법을 찾아냈다고 이야기함
연구자 블로그와 논문 링크 공유
위 링크를 대학 보도자료에서 연구자 블로그 포스트로 바꿨음이라는 피드백을 남김
새 취약점의 영향에 대해, 연구자가 CPU 전체 메모리 내용을 반복적으로 읽을 수 있어 초당 5,000바이트 속도도 가능하다고 설명하며, 결국 공격이 성공할 경우 CPU의 모든 정보가 유출될 수 있음
블로그 링크로 제목 URL을 바꿔주면 좋겠다는 바람을 전함
브랜치 예측자 동작에 대해 정리함
브랜치 명령이 끝난 후에 예측자 상태 업데이트가 일어날 수 있음
파이프라인 내에서 결과 커밋과 예측 커밋이 다름
권한 변환 명령어도 예측 상태 대기 없이 파이프라인에서 진행되므로, 권한 수준이 일관되지 않으면 문제 생길 수 있음
파이프라인에서 ‘현재 권한 레벨’이 단일하지 않을 수 있다는 점이 어려운 부분임
Kaveh Razavi 교수가 자신의 학교에서 하드웨어 보안 코스를 가르쳤었고 그 과정이 정말 멋졌음이라는 반가움
몇 년 전 해당 과정과 맬웨어 관련 또 다른 강의를 확인하려 했으나 공개 정보가 거의 없었음, 공식 강의 녹화본이나 노트가 온라인에 있는지 궁금하다는 질문을 남김
Training Solo 공격과 이번 취약점의 관계를 아는 사람이 있는지 궁금하다고 질문
칩셋 마이크로코드 패치에 대한 설명에서 윈도우만 언급하는 것에 의문을 가짐, 리눅스 사용자는 어떻게 되는지 질문함
리눅스 커널도 오래 전부터 마이크로코드 로딩을 지원하고 있지만, 인텔에서 마이크로코드 파일을 배포해야 각 배포본이 업데이트할 수 있음, 시스템 업데이트에 포함되어야 한다는 설명
인텔이 리눅스용 마이크로코드 업데이트를 github에 공개하고 있으니 각 배포본은 자동으로 거기서 받아서 배포가 이뤄짐, 해당 취약점이 실제로 패치됐는지는 전문가가 아니라서 잘 모르겠음이라는 설명
인텔 공식 보안 권고 링크를 공유
AMD CPU에도 비슷한 취약점이 있는지 궁금하다는 의견과, 분기 예측과 같은 기술적 메커니즘이 CPU 보안 취약점의 근본 원인임을 지적하며 AMD는 어떻게 이런 취약점을 피하고 있는지 궁금함
연구자 블로그 요약으로, 이번 Branch Privilege Injection 취약점은 AMD, ARM 시스템에는 영향을 끼치지 않는다는 답을 전함
AMD가 이런 문제를 완전히 피해간 게 아님이라는 요지와, 스펙터·멜트다운처럼 취약점마다 범위가 다르고 이번 건은 인텔 한정이지만, AMD도 같은 계열의 취약점(예: 스펙터)에는 노출된 적 있음
약간 꼼꼼한 설명으로, 스펙 으로 추론 실행 자체가 취약점이 아니라 현대 CPU에서 필수적 메커니즘임을 강조, 내부의 결함이 발견되기 어려울 정도로 복잡해서, AMD와 ARM에도 유사한 버그가 있을 가능성 있음이라는 의견, 완전한 고치는 방법은 현대 시스템에서 코드의 격리가 불가능하다는 현실을 인정해야 하고, 이는 일부 대기업 비즈니스 모델에는 치명적임이라는 우려
이 취약점의 대책으로, 브랜치 예측 업데이트 시점에 권한 레벨을 스냅샷처럼 저장하고 그 값을 함께 전달하면 소프트웨어에서 겪는 문제와 비슷하게 해결될 것 같음
CPU 분기 예측기가 버퍼 경계와 코드의 권한 정보를 바로 확인할 수 있다면 예방이 쉬웠을 텐데, 이런 정보는 포인터에 중요한 정보를 추가하는 작업이 필요함을 유쾌하게 지적함
이슈의 범위를 더 명확하게 이해해야 한다는 의견이나, 스펙 으로 추론 실행을 통한 취약점 공격에는 실제로 엄청난 사전 준비가 필요하고 직접 코드 실행 권한이 있지 않으면 큰 의미 없음, 브라우저에서 임의의 JS 코드로 임의의 정보 유출은 불가능함, 자신은 성능 향상을 위해 모든 완화책을 비활성화함
CHERI 아키텍처를 추천함
포인터 구조만 바꾼다고 될 일이 아님을 지적하며, 진짜로 하드웨어에서 각 메모리 접근에 주소 경계 정보를 부여하는 과거의 x86 세그먼트 방식(80286)을 언급, 그러한 시스템도 소프트웨어가 경계 정보를 정확히 다루어야 했지만 결국 동일한 한계를 가졌음
지금 시점에서 모든 주요 운영체제에 해당 취약점에 대한 패치(혹은 관련 마이크로코드)가 적용되는지 확인 질문
Hacker News 의견
하버드에서 발행한 글에서, 존에게 불운하게도 브랜치들이 사탄과 양자역학과 거래를 맺어서 미래 세대 프로세서에 해로운 마법을 걸었음이라는 재치 있는 비유를 들며, 이 마법은 '스케일링으로 인한 전압 누수'나 '낭비되는 열 증가' 같은 이름으로 남았음
James Mickens의 글이 항상 재미있음이라는 감상과 함께, 보안을 담당하는 Mossad가 HTTPS 같은 걸 신경 안 쓴다는 농담을 인용하며, 그들은 데이터가 필요하면 아예 드론으로 핸드폰을 우라늄 모조품으로 바꿔치기하고 결국은 당신의 소지품을 유품 세일에서 사와서 직접 사진을 본다는 유쾌한 상상
수많은 행렬에 대해 언급한 부분이 약간의 희망을 보여줌이라는 의견과, 존의 동생이 그 행렬들에 사람처럼 말하도록 가르친 방법을 찾아냈다고 이야기함
연구자 블로그와 논문 링크 공유
위 링크를 대학 보도자료에서 연구자 블로그 포스트로 바꿨음이라는 피드백을 남김
새 취약점의 영향에 대해, 연구자가 CPU 전체 메모리 내용을 반복적으로 읽을 수 있어 초당 5,000바이트 속도도 가능하다고 설명하며, 결국 공격이 성공할 경우 CPU의 모든 정보가 유출될 수 있음
블로그 링크로 제목 URL을 바꿔주면 좋겠다는 바람을 전함
브랜치 예측자 동작에 대해 정리함
Kaveh Razavi 교수가 자신의 학교에서 하드웨어 보안 코스를 가르쳤었고 그 과정이 정말 멋졌음이라는 반가움
몇 년 전 해당 과정과 맬웨어 관련 또 다른 강의를 확인하려 했으나 공개 정보가 거의 없었음, 공식 강의 녹화본이나 노트가 온라인에 있는지 궁금하다는 질문을 남김
Training Solo 공격과 이번 취약점의 관계를 아는 사람이 있는지 궁금하다고 질문
칩셋 마이크로코드 패치에 대한 설명에서 윈도우만 언급하는 것에 의문을 가짐, 리눅스 사용자는 어떻게 되는지 질문함
리눅스 커널도 오래 전부터 마이크로코드 로딩을 지원하고 있지만, 인텔에서 마이크로코드 파일을 배포해야 각 배포본이 업데이트할 수 있음, 시스템 업데이트에 포함되어야 한다는 설명
인텔이 리눅스용 마이크로코드 업데이트를 github에 공개하고 있으니 각 배포본은 자동으로 거기서 받아서 배포가 이뤄짐, 해당 취약점이 실제로 패치됐는지는 전문가가 아니라서 잘 모르겠음이라는 설명
인텔 공식 보안 권고 링크를 공유
AMD CPU에도 비슷한 취약점이 있는지 궁금하다는 의견과, 분기 예측과 같은 기술적 메커니즘이 CPU 보안 취약점의 근본 원인임을 지적하며 AMD는 어떻게 이런 취약점을 피하고 있는지 궁금함
연구자 블로그 요약으로, 이번 Branch Privilege Injection 취약점은 AMD, ARM 시스템에는 영향을 끼치지 않는다는 답을 전함
AMD가 이런 문제를 완전히 피해간 게 아님이라는 요지와, 스펙터·멜트다운처럼 취약점마다 범위가 다르고 이번 건은 인텔 한정이지만, AMD도 같은 계열의 취약점(예: 스펙터)에는 노출된 적 있음
약간 꼼꼼한 설명으로, 스펙 으로 추론 실행 자체가 취약점이 아니라 현대 CPU에서 필수적 메커니즘임을 강조, 내부의 결함이 발견되기 어려울 정도로 복잡해서, AMD와 ARM에도 유사한 버그가 있을 가능성 있음이라는 의견, 완전한 고치는 방법은 현대 시스템에서 코드의 격리가 불가능하다는 현실을 인정해야 하고, 이는 일부 대기업 비즈니스 모델에는 치명적임이라는 우려
이 취약점의 대책으로, 브랜치 예측 업데이트 시점에 권한 레벨을 스냅샷처럼 저장하고 그 값을 함께 전달하면 소프트웨어에서 겪는 문제와 비슷하게 해결될 것 같음
CPU 분기 예측기가 버퍼 경계와 코드의 권한 정보를 바로 확인할 수 있다면 예방이 쉬웠을 텐데, 이런 정보는 포인터에 중요한 정보를 추가하는 작업이 필요함을 유쾌하게 지적함
이슈의 범위를 더 명확하게 이해해야 한다는 의견이나, 스펙 으로 추론 실행을 통한 취약점 공격에는 실제로 엄청난 사전 준비가 필요하고 직접 코드 실행 권한이 있지 않으면 큰 의미 없음, 브라우저에서 임의의 JS 코드로 임의의 정보 유출은 불가능함, 자신은 성능 향상을 위해 모든 완화책을 비활성화함
CHERI 아키텍처를 추천함
포인터 구조만 바꾼다고 될 일이 아님을 지적하며, 진짜로 하드웨어에서 각 메모리 접근에 주소 경계 정보를 부여하는 과거의 x86 세그먼트 방식(80286)을 언급, 그러한 시스템도 소프트웨어가 경계 정보를 정확히 다루어야 했지만 결국 동일한 한계를 가졌음
지금 시점에서 모든 주요 운영체제에 해당 취약점에 대한 패치(혹은 관련 마이크로코드)가 적용되는지 확인 질문
예스라고 답함, 정보 해금일이 오늘(5월 13일)임