2015년에 드러난 심각한 Intel CPU 버그 사례들을 살펴보고, CPU 복잡도 증가와 검증 노력 변화로 인해 앞으로도 유사한 문제가 더 자주 나타날 수 있는 이유를 논한다.
2015년은 Intel에게 꽤 좋은 해였다. 분기 실적 발표는 매 분기 기대치를 웃돌았다. 계속해서 진지한 서버 시장에서는 사실상 유일한 선택지이며, 이 시장은 기하급수적으로 성장하고 있다. 두 крупней한 클라우드 업체의 실적 발표를 보면 AWS와 Azure는 각각 80%, 100% 성장했다. 이러한 성장은 데스크톱 시장의 지속적인 감소로 Intel이 입은 피해를 사실상 상쇄했다. 한동안은 클라우드 업체들이 연산을 FPGA로 옮겨 Intel 세금을 피할 수도 있다고 보였지만, Intel은 진지한 FPGA 업체 둘 중 하나를 인수했고, 공정(fab) 우위까지 더해져 고급형 서버 CPU 시장을 지배해온 것과 같은 방식으로 고급형 FPGA 시장도 지배할 위치에 있어 보인다. 또한 반경쟁적 관행에 대한 벌금이 14.5억 달러로 결론났는데, 이는 그 반경쟁적 관행으로 얻은 이익에 비해 훨씬 적었다1.
하지만 엔지니어링/버그 측면에서는 그리 좋아 보이지 않았다. 꽤 심각한 CPU 버그들을 여러 건 보았고, 앞으로도 더 많이 보게 될 것으로 보인다. 나는 Intel 버그를 일일이 추적하지 않는다. 다만 영향이 커서 아는 사람들이 패치를 넣느라 허둥대는 수준으로 심각한 것들은 귀에 들어오는데, 그럼에도 올해는 4분기 한 분기 동안에만 두 건의 심각한 버그 이야기를 들었다. 첫 번째는 Ben Serebrin과 Jan Beulic이 발견한 버그로, 게스트 VM이 특정 방식으로 fault를 일으키면 CPU가 마이크로코드의 무한 루프에 걸려 멈추게 되어, 어떤 VM이든 호스트를 DoS할 수 있었다.
대형 클라우드 업체들은 이 버그를 Google 엔지니어가 발견했고, Google이 공개하기 전에 경쟁사들과 지식을 공유하기로 결정했다는 점에서 운이 매우 좋았다. 블랙햇들은 주요 서비스를 무너뜨리기 위해 많은 시간을 쓴다. 나는 실제로 내가 일하는 회사를 공격하는 데 시간을 쓰는 사람들의 끈기와 영리함에 꽤 감탄한다. 예컨대 우리 인프라 깊숙한 곳에서 DPC에서 실행되는 코드 한 조각이 어떤 해시 충돌 때문에 느려질 수 있는 취약점을 갖고 있다면, 누군가는 그것을 찾아내서 악용한다. 그것이 일어나려면 길고 난해한 사건 순서가 필요하더라도 말이다. 만약 이 CPU 마이크로코드 hang가 이런 블랙햇들 중 하나에게 발견되었다면, 가장 불편한 시점에 대부분의 클라우드 호스팅 서비스에 큰 피해가 났을 것이다2.
Serebrin/Beulic 버그가 발견된 직후, 한 무리의 사람들이 벤치마킹 및 번인에 흔히 쓰이는 도구인 prime95를 실행하면 시스템 전체가 멈춘다는 사실을 발견했다. 이에 대한 Intel의 답변은 다음과 같았다:
Intel has identified an issue that potentially affects the 6th Gen Intel® Core™ family of products. This issue only occurs under certain complex workload conditions, like those that may be encountered when running applications like Prime95. In those cases, the processor may hang or cause unpredictable system behavior.
이 답변은 실제로 무슨 일이 일어나는지에 대해 거의 아무것도 알려주지 않는다. errata 목록을 보면 이런 식이 전형적이며, 보통은 버그를 트리거하는 데 사용된 애플리케이션 이름조차 언급하지 않는다. 예를 들어, 현재의 errata 목록 중 하나에는 다음 같은 항목이 있다.
이미 보았듯이 “예기치 않은 시스템 동작”은 우리가 완전히 끝장이라는 뜻일 수도 있다. 머신 체크도 좋지 않다. Windows에서는 블루스크린을, Linux에서는 커널 패닉을 유발한다. 페이지 폴트에서 잘못된 주소가 나오는 것은 단순한 크래시보다 잠재적으로 더 나쁘며, 목록을 파고들면 그 밖에도 무서운 버그를 많이 찾을 수 있다.
그리고 Intel errata 목록에는 다음과 같은 면책 조항이 있다는 점을 기억하라:
Errata remain in the specification update throughout the product's lifecycle, or until a particular stepping is no longer commercially available. Under these circumstances, errata removed from the specification update are archived and available upon request.
특정 stepping(하드웨어의 포인트 릴리스에 해당)의 생산을 중단하면, Intel은 errata를 목록에서 제거할 권리를 보유하며, Intel에게 충분히 중요한 고객이 아니면 구형 stepping에 어떤 errata가 있는지 알아낼 수 없게 된다.
어쨌든 2015년으로 돌아가자. 지난 분기(4분기) 동안에만 Intel CPU에서 적어도 두 건의 심각한 버그를 보았고3, 숨어 있는 버그가 더 있을 가능성은 거의 확실하다. 예전에 Intel 호환 CPU를 만드는 회사에서 일했을 때, 우리는 Intel CPU에 대해 꽤 많은 테스트와 특성화(characterization)를 했다. 학교를 막 졸업했고 CPU는 기본적으로 잘 동작한다고 생각하던 나로서는, 우리가 찾아낼 수 있었던 버그의 수가 놀라웠다. 나는 특성화 및 경쟁 분석 쪽에서 일한 적이 없는데도, 그저 일을 하며 당연해 보이지 않는 것들을 확인하려고 파고드는 과정에서 개인적으로만도 여러 Intel CPU 버그를 발견했다. 내가 보기엔 당연하지 않은 것들이 때로는 Intel 엔지니어들에게도 당연하지 않은 것인 듯하다.
더 많은 서비스가 클라우드로 이동하고 시스템 hang 및 리셋 취약점의 영향이 커지면서, 더 많은 블랙햇이 CPU 버그를 찾는 데 시간을 투자하게 될 것이다. 사람들이 이런 버그를 찾는 것이 생각보다 훨씬 쉽다는 사실을 깨닫게 되면, 이런 일이 더 많이 생길 것으로 예상해야 한다. 한때는 CPU 패밀리에서 1년에 버그가 한 건 정도였고, 심각한 버그는 몇 년에 한 번, 심지어 10년에 한 번꼴이기도 했지만, 우리는 이미 그 시기를 지나왔다. 일부는 “예기치 않은 시스템 동작”이 단지 계산을 재시작하게 만드는 성가신 버그 분류에서, AWS 계정만 있으면 누구나 랜덤한 클라우드 호스팅 서비스를 공격할 수 있는 공격 벡터로 바뀌었기 때문이다. 하지만 더 큰 이유는 CPU가 더 복잡해져 효과적으로 테스트하고 감사(audit)하기가 더 어려워진 반면, Intel이 검증(validation) 노력을 줄이고 있는 것으로 보이기 때문이다. 아이러니하게도 보안을 돕기 위해 존재하는 하드웨어 가상화가 있는데, 가상화가 너무 복잡해서4 하드웨어 가상화 구현이 원래라면 존재하지 않았을 “예기치 않은 시스템 동작” 버그를 노출시킬 가능성이 있다.
그렇다고 희망이 없다는 뜻은 아니다. 원칙적으로는, 한 코어의 hang 버그가 시스템 전체를 크래시시키지 않도록 CPU를 설계하는 것이 가능하다. 다만 그걸 모든 레벨에서 해내려면 꽤 많은 작업이 필요하다(캐시 디렉터리, 언코어(uncore) 등은 코어가 멈춘 상태에서도 동작하도록 수정되어야 하고, OS 스케줄러도 마찬가지다). 이전에는 중요해 보이지 않았기 때문에 아무도 그 일을 하지 않았다.
소프트웨어 쪽 사람들은 이런 것들이 (때때로) 패치될 수 있으니 중요하지 않다고 말하곤 한다. 하지만 많은 기기들은 결코 패치를 받지 못하며, 이는 하드웨어 보안 버그가 기기의 수명 전체 동안 취약점을 남긴다는 뜻이다. 그리고 소비자를 신경 쓰지 않더라도, 심각한 버그는 CPU 벤더에게도 매우 나쁘다. 내가 일했던 회사에서 한 번은 검증을 빠져나간 버그가 출하 후에 발견된 적이 있었다. 한 OEM은 그 뒤로 5년 정도 우리와 대화조차 하지 않았고, 계속 거래를 유지한 다른 OEM들도 마이크로코드 패치가 적용된 부품을 재-자격(재-퀄리파이)해야 했으며, 그것이 얼마나 비싼지 확실히 알려줬다. Intel은 영향력이 커서 OEM들이 버그 하나 때문에 그냥 등을 돌릴 수는 없지만, 정치적 자본이 무한하지는 않으며, 심각한 버그는 패치 가능하더라도 정치적 자본을 소모한다.
그렇다고 버그를 0으로 만들자고 말하는 것은 아니다. 개발 속도와 버그율 사이에는 언제나 트레이드오프가 있고, 최적점은 아마도 0 버그가 아닐 것이다. 하지만 우리는 이제 보안상 의미를 갖는 심각한 버그를 नियमित적으로 보고 있으며, 이는 트레이드오프를 크게 바꾼다. FDIV 버그 같은 경우에는 수치해석 코드를 돌리지 않는 특정 사용자가 영향을 받을 확률이 통계적으로 낮다고 주장할 수 있지만, 보안 버그는 다르다. 공격자는 랜덤 코드를 실행하지 않으므로, 단지 어떤 조건이 발생할 가능성이 낮다고 말할 수 없다.
이 글을 쓴 뒤, 자신이 전 Intel 직원이라고 주장하는 사람이 “특권적 접근 권한이 있어도 너는 전혀 모른다”고 말했고, reddit의 شبه-익명 댓글러가 다음 댓글을 남겼다:
As someone who worked in an Intel Validation group for SOCs until mid-2014 or so I can tell you, yes, you will see more CPU bugs from Intel than you have in the past from the post-FDIV-bug era until recently.
Why?
Let me set the scene: It's late in 2013. Intel is frantic about losing the mobile CPU wars to ARM. Meetings with all the validation groups. Head honcho in charge of Validation says something to the effect of: "We need to move faster. Validation at Intel is taking much longer than it does for our competition. We need to do whatever we can to reduce those times... we can't live forever in the shadow of the early 90's FDIV bug, we need to move on. Our competition is moving much faster than we are" - I'm paraphrasing. Many of the engineers in the room could remember the FDIV bug and the ensuing problems caused for Intel 20 years prior. Many of us were aghast that someone highly placed would suggest we needed to cut corners in validation - that wasn't explicitly said, of course, but that was the implicit message. That meeting there in late 2013 signaled a sea change at Intel to many of us who were there. And it didn't seem like it was going to be a good kind of sea change. Some of us chose to get out while the getting was good. As someone who worked in an Intel Validation group for SOCs until mid-2014 or so I can tell you, yes, you will see more CPU bugs from Intel than you have in the past from the post-FDIV-bug era until recently.
나는 개인적으로 아는 다른 출처로는 이 이야기를 확인하지 못했다. 다만 또 다른 익명 댓글러가 “나는 2013년 중반에 INTC를 떠났다. 검증(validation)에서. 이것은… 내 경험과 비교해 정확하다”고 말했다. 또 다른 익명 인물(내가 아는 사람)은 그 연설을 듣진 못했지만, 그 즈음 “velocity”가 유행어가 되었고, 경영진이 ARM과 경쟁하려면 Intel에 더 많은 “velocity”가 필요하다는 이야기를 많이 했다고 했는데, 이는 실제 연설의 존재까지는 아니더라도 그 정서를 뒷받침하는 것으로 보인다.
또한 정형 기법(formal methods) 쪽 사람들에게서도, 첫 댓글에 언급된 시기 전후로 정형 검증(formal verification) 인력의 이탈이 있었다는 이야기를 들었다. 들은 이야기 중 하나는, 사람들이 자신들이 중복 인력(redundant)이 될까 걱정해서 떠났다는 것이다. 당시 조기 퇴직 패키지가 거론되고 있었고, 많은 사람들이 감원을 강하게 의심했다고 한다. 또 다른 이야기는, ARM과의 모바일 전투에 Intel이 집중하면서 상황이 매우 이상해졌고, 더 나빠지기 전에 떠나고 싶어 했다는 것이다. 다만 이게 의미가 있는지 말하기는 어렵다. Apple이 더 좋은 보상 패키지와 덜 기능장애적인 조직을 약속하며 Intel에서 많은 사람을 빼가고 있기 때문이다.
버그에 대한 익명 제보도 받았다. HPC에서 일하는 한 사람은 Haswell 부품을 고를 때, 12코어 초과 변형에서 성능이 급격히 떨어질 것이라는 이야기를 들었다고 했다. 실제로 12코어와 16코어 시스템을 모두 구축해 보니, 다양한 워크로드에서 12코어 시스템이 눈에 띄게 더 좋은 성능을 보였다. 코어당 성능이 더 좋다는 게 아니라 절대 성능이 더 좋았다는 뜻이다. 코어를 4개 더 추가했더니 병렬 워크로드 성능이 감소했다! 이는 단일 소켓과 듀얼 소켓 벤치마크 모두에서 사실이었다.
또한 Intel이 아직도 해결하지 못한 것으로 보이는 유휴/저활동 시의 미스터리한 hang 버그도 있다.
그리고 저전력 상태를 비활성화하지 않으면 Linux를 멈추게 하는 이 Broadwell 버그도 있다.
물론 Intel만 버그가 있는 것은 아니다. Robert Swiecki가 발견한 이 AMD 버그는 VM이 호스트를 크래시시킬 수 있을 뿐만 아니라, VM이 호스트를 장악할 수도 있게 한다.
최근의 버그나 검증/밸리데이션에 대한 이야기들을 내가 다 들었을 거라고는 생각하지 않는다. 다른 보고가 있다면 보내달라.
여러 사람이 스토리지 장치와 스위치에서 이상한 고장률을 관찰했다. 이는 Intel Atom 버그와 관련이 있는 것으로 보인다. 나는 이것이 흥미롭다고 생각한다. Atom은 비교적 단순한 칩이어서, 검증하기도 비교적 단순한 칩이기 때문이다. 1세대 Atom이 출시되었을 때 Intel 내부 사람들은 동작하는 양산 칩을 출하하기 위해 칩 내부 스핀(spin)이 얼마나 적게 필요했는지 자랑스러워했던 것으로 기억하는데, 이는 칩의 단순함 덕분에 가능했던 일이다. 현대 Atom은 더 복잡하긴 하지만, 그렇다고 그 정도로 더 복잡한 것은 아니다.
Intel Skylake와 Kaby Lake에는 하이퍼스레딩 버그가 너무 심각해서 Debian이 사용자가 버그를 피하기 위해 하이퍼스레딩을 비활성화하라고 권고할 정도인 문제가 있는데, 이는 “애플리케이션 및 시스템 오동작, 데이터 손상, 데이터 손실 같은 가짜(spurious) 오류”를 유발할 수 있다.
AMD 쪽에서는, 최근 Intel CPU 버그 못지않게 심각할 수 있는 버그가 있을지도 모른다. 링크된 스레드를 읽어보면 AMD 담당자가 사람들이 SMT를 끄고, OPCache Control을 끄고, LLC 설정을 바꿔서 심각한 크래시 버그를 완화하거나 범위를 좁혀보라고 요청하는 것을 볼 수 있다. 다른 스레드에서는 “u-op cache crc mismatch”와 함께 #MC 예외를 보고하는 사람도 찾을 수 있다.
AMD는 포럼에서 이것들이 고립된 이슈라고 답했지만, phoronix는 여러 오픈소스 프로그램을 컴파일하는 스트레스 테스트를 돌려 크래시를 재현할 수 있었다. 그들은 컴파일을 한 시간 시도하는 동안 53개의 세그폴트를 얻을 수 있었다고 보고했다.
일부 FreeBSD 사람들도 겉보기에는 무관한 크래시를 관찰했고, 높은 주소에서 코드를 실행한 다음 인터럽트를 발생시키는 방식으로 재현을 만들 수 있었다. 이는 hang 또는 크래시로 이어질 수 있다. 이것이 처음 보고된 Ryzen 이슈들과 무관해 보이는 이유는, 이것이 SMT를 꺼도 쉽게 재현되기 때문이다.
Matt Dillon은 DragonflyBSD가 트리거하는 AMD 버그를 발견했고, 이를 고치기 위한 아주 작은 패치를 커밋했다:
There is a bug in Ryzen related to the kernel iretq'ing into a high user %rip address near the end of the user address space (top of user stack). This is a temporary workaround for the issue.
The original %rip for sigtramp was 0x00007fffffffffe0. Moving it down to fa0 wasn't sufficient. Moving it down to f00 moved the bug from nearly instant to taking a few hours to reproduce. Moving it down to be0 it took a day to reproduce. Moving it down to 0x00007ffffffffba0 (this commit) survived the overnight test.
이는 추측 실행(speculative execution)과 사이드 채널 공격을 결합해 특권 정보를 사용자 프로세스로 누출시키는 흥미로운 공격 클래스다. 적어도 일부 공격은 브라우저의 javascript에서 수행될 수 있는 것으로 보인다.
최근 Intel의 검증에 대한 태도와 관련해 앞의 업데이트들에 나온 코멘트에 관해서는, 또 다른 전 Intel 직원이라고 주장하는 사람이 위의 진술을 뒷받침했다:
As a former Intel employee this aligns closely with my experience. I didn't work in validation (actually joined as part of Altera) but velocity is an absolute buzzword and the senior management's approach to complex challenges is sheer panic. Slips in schedules are not tolerated at all - so problems in validation are an existential threat, your project can easily just be canned. Also, because of the size of the company the ways in which quality and completeness are 'acheived' is hugely bureaucratic and rarely reflect true engineering fundamentals.
이 글을 쓴 지 10년이 다 되어가지만 심각한 CPU 버그는 계속 나온다. 예를 들어 최근에는 RAD tools가 다음 문제를 발견했다:
Intel Processor Instability Causing Oodle Decompression Failures
We believe that this is a hardware problem which affects primarily Intel 13900K and 14900K processors, less likely 13700, 14700 and other related processors as well. Only a small fraction of those processors will exhibit this behavior. The problem seems to be caused by a combination of BIOS settings and the high clock rates and power usage of these processors, leading to system instability and unpredictable behavior under heavy load ... Any programs which heavily use the processor on many threads may cause crashes or unpredictable behavior. There have been crashes seen in RealBench, CineBench, Prime95, Handbrake, Visual Studio, and more. This problem can also show up as a GPU error message, such as spurious "out of video memory" errors, even though it is caused by the CPU.
이를 설정(configuration) 버그라고 주장할 수도 있지만, 일반 사용자 관점에서 관찰되는 것은 자신의 CPU가 크래시를 일으킨다는 사실뿐이다. 그리고 현실적으로 Intel은 자사 CPU가 이런 설정을 가진 시스템에 출하되고 있다는 것을 알고 있다. 완화책에는 다음과 같은 설정을 바꾸는 일들이 포함된다: "SVID behavior" → "Intel fail safe", "Long duration power limit" → 125W보다 높게 설정되어 있다면 125W로 낮추기(ARK의 "Processor Base Power"), "Short duration power limit" → 253W보다 높게 설정되어 있다면 253W로 낮추기(13900/14900 CPU의 경우. 다른 CPU는 다른 한계! ARK의 "Maximum Turbo Power"), 등.
만약 Intel이 이 이슈로 인해 CPU가 크래시하지 않게 하고 싶었다면, 이런 설정과 다른 일부 설정들도 강제할 수 있었고 그래야 했다. 하지만 대신 BIOS 설정에 맡겼고, 결과는 지금과 같다.
역사적으로 Intel은 AMD보다 검증(verification), 밸리데이션(validation), 테스트에 훨씬 더 진지했고, 이는 결과물에서 드러났다. 한때(열성 사이트들이 AMD에 열광하던 K7 시절) Google은 AMD 사용을 중단했고, AMD CPU가 너무 버그가 많고 디버그하기 어려운 문제를 너무 많이 일으켰다는 이유로 AMD CPU 구매를 사실상 금지했다. 하지만 시간이 지나며 Intel이 할당하는 상대적 검증/밸리데이션/테스트 노력 수준은 낮아졌고, Intel은 정말 심각한 버그 발생률에서 AMD를 거의 따라잡았거나 어쩌면 따라잡은 듯하다. AMD, ARM, Nvidia로부터 매우 강한 압박을 받고 있는 Intel의 현재 시장 지위를 고려하면, Intel이 가까운 미래에 이를 되돌릴 가능성은 낮아 보인다. Nvidia는 역사적으로 AMD나 Intel보다 훨씬 버그가 많았으니, Intel이 가장 버그가 많은 주요 칩 제조사가 되기까지는 아직 갈 길이 꽤 남아 있다. Nvidia가 Intel에 대한 가장 큰 위협 중 하나이며, Intel이 과거 더 버그가 많던 경쟁사의 위협에 어떻게 대응했는지 생각해보면, 앞으로 10년 동안 더 높은 비율로 나쁜 버그가 나올 것이라 예상하는 편이 타당해 보인다.
특정 버그의 맥락에서, 여러 이유로 전통적이고 보수적인 CPU 제조사라기보다는 “빠르게 움직이고 부숴가며(move fast and break things)” 같은 소프트웨어 회사처럼 운영하라는 압력이 엄청나다. CPU를 제조할 때 얼마나 빠르게 동작할지는 꽤 무작위적이며, 테스트해보는 것 외에 얼마나 빠를지 신뢰할 수 있게 알 방법이 없기 때문에, CPU 회사들은 CPU에 대해 일련의 테스트를 돌려 어느 속도로 동작할 수 있는지 확인한다. 이 테스트 시간은 꽤 비싸므로, CPU가 어느 속도로 동작 가능한지를 올바르게 판별할 수 있는 최소한의 테스트 세트를 찾기 위해 많은 노력이 들어간다. 여기서 비용을 줄이는 쉬운 방법 하나는, 더 작은 테스트 세트가 해당 속도로의 동작을 완전히 보장하지 못하더라도 테스트를 더 적게 돌리는 것이다.
또 다른 요인은, 명목상 더 빠르다고 판매되는 CPU는 더 비싸게 팔 수 있다는 점이다. 그래서 CPU를 가능한 한 한계에 가깝게 밀어붙이려는 압력도 존재한다. 전반적으로 이 마진이 줄어들었다는 것을 볼 수 있는 한 가지 방법은 CPU 오버클로킹 가능성을 보는 것이다. 사람들은 prime95, stresstest 같은 몇 가지 테스트를 돌려 부품이 크래시하지 않으면 오버클록된 CPU에 만족하곤 한다. 하지만 이는 사용자가 던질 수 있는 모든 것을 CPU가 באמת 처리할 수 있는지 판별하기엔 턱없이 부족하다. 실제로 CPU를 진지하게 테스트하려고 하면(우리는 Intel 경쟁사에서 일할 때 정기적으로 이런 일을 했다), Intel과 다른 CPU 회사들은 자사 CPU의 주장 속도를 실제로 가능한 속도 대비 너무 한계까지 끌어올려 왔고, 그 결과 때때로 판매되는 CPU가 자신의 능력을 넘어선 상태로 밀어붙여진 경우가 생긴다.
오버클로킹에 관해 RAD의 Fabian Giesen은 이렇게 썼다:
This stuff is not sanctioned and will count as overclocking if you try to RMA it but it's sold as a major feature of the platform and review sites test with it on.
Daniel Gibson은 이렇게 답했다:
hmm on my mainboard (ASUS ROG Strix B550-A Gaming -clearly gaming hardware, but middle price range) I had to explicitly enable the XMP/EXPO profile for the DDR4-RAM to run at full speed - which is DDR4-3200, officially supported by the CPU (Ryzen 5950X). Otherwise it ran at DDR4-2400 speed, I think? Or was it 2133? I forgot, at least significantly lower
이에 Fabian은 이렇게 덧붙였다:
Correct. Fun fact: turning on EXPO technically voids your warranty ... t's great; both the CPU and the RAM list it as supported but it's officially not.
One might call it a racket, if one were inclined to such incisive language.
Intel은 과거에는 이런 종류의 “공식적으로 비공식 지원”을 하지 않았다. 더 일반적으로 말하면, 역사적으로 CPU 제조사들은 의도된 사용에서 크래시와 데이터 손상이 무시할 수 없을 정도의 위험을 갖는 부품을 (가능하다면) 출하하는 것을 매우 꺼렸다. 하지만 이런 버그는 점점 더 많이 발생하고 있다. 어떤 것들은 위 RAD 보고서처럼 누군가가 보고서를 공개하면서 꽤 대중적으로 알려지기도 한다. 또 어떤 것들은 거대 기업이 CPU 제조사에 조용히 보고하고, 어떤 형태로든 NDA 합의를 맺은 뒤 그 대기업은 교체 CPU를 받고 Intel이나 다른 제조사는 해당 이슈에 대한 펌웨어 수정본을 조용히 출하하는 식으로 넘어가기도 한다. 그리고 이런 것들 중 일부는, 가끔 발생하는 데이터 손상이나 크래시를 “잡힌 것”으로 간주하지 않는다면, 실제로는 전혀 잡히지 않는 경우도 분명히 있을 것이다.
코멘트/수정/토론에 대해 Leah Hanson, Jeff Ligouri, Derek Slager, Ralph Corderoy, Joe Wilder, Nate Martin, Hari Angepat, JonLuca De Caro, Jeff Fowler, 그리고 다수의 익명 제보자들에게 감사를 전한다.
