系统与基础设施danluu.com
严重的 Intel CPU 漏洞（2016）
Serious Intel CPU bugs (2016)
2016 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Dan Luu 整理 Intel CPU 历史上严重的硬件缺陷与勘误，并分析验证团队在进度和竞争压力下如何妥协。评论补充了内部文化、具体 bug 的修复状态，以及高保证处理器作为对照。
为什么经久不衰：它把 CPU 硬件 bug 从孤立勘误提升为验证文化、竞争压力和复杂度共同作用的系统性问题，今天读仍能解释为何 CPU 勘误层出不穷。
HN 评论精选
内部人证实验证被进度压垮，官僚流程和追热点文化削弱工程质量。
作为前 Intel 员工，这与我的经历高度吻合。我没在验证部门（其实是随 Altera 加入的），但“速度”绝对是口头禅，高层面对复杂挑战时纯粹是恐慌。进度延误完全不被容忍，所以验证中的问题成了生存威胁，项目很容易被砍。另外公司规模大，质量和完整性“达成”的方式极其官僚，很少反映真正的工程基础。Intel 最大挑战就是目前没有“大赢”，不是强领导力和专注，而是从一个风口跳到另一个（VR 死了，汽车万岁）。
slivym查看英文原文
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. Intel's biggest challenge is simply that it's not 'winning big' at the moment and rather than strong leadership and focus the company just jumps from fad to fad failing at each (VR is dead, long live automotive).
竞争压力导致赶工，而 CPU bug 会累积，形成长期系统性风险。
评论引用文章说：“我们需要更快。Intel 的验证比竞争对手慢得多……我们不能永远活在 90 年代初 FDIV bug 的阴影下。”竞争压力可能让公司新产品比旧产品更差（这里是不稳定），例如三星手机爆炸。我记得三星想赶在 iPhone 前发布，测试压力类似。不是所有冒险都灾难——99/100 可能表现好。但 Intel 的 bug 会累积叠加到未来产品开发，所以追赶竞争的小胜可能导致下一次大战的 massive failure。想象竞争对手也一样，结果双方产品随时间更不稳定。
bwang29查看英文原文
Quote from article "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". Competition pressure could make a company's new product worse than (in this case, less stable than) their previous products, e.x. Samsung phone explosion. I still remembered the story was Samsung wanting to release their phone ahead of iPhone and I would imagine the testing went through a similar stressful time as Intel. Of course not all cases of taking such risks would lead to disasters - just imagine Intel rushes on releasing new chips ahead of competition and 99 out of 100 times it ended up performing well. But a unique character in Intel's case is these bugs, unlike a faulty battery design, are accumulative and additive to future product development, which means a few small wins in catching up with your competitor could also lead to massive failures in some next major battle. Now imagine Intel's competitors are going through the exact same scenario. One possible outcome is both Intel and its competitors' products become less stable and more buggy over time, and until everyone's stuff seems to be broken they probably never have time to fix them.
复杂度上升使 bug 增多；部分 Intel bug 已微码修复，AMD 问题未解，有效缓解是关键。
Denverton 比“简单”Atom 复杂得多（C3958 单线程约 i5-7500 一半，多线程两倍），Avoton 也不差。随着复杂度增长，这些微架构 bug 增加不奇怪。Skylake/Kaby 超线程 bug 已通过微码修复，现在安全。AMD Ryzen segfault 仍未缓解；Phoronix 因拿到筛选 RMA 替换就宣布修复，但当前生产处理器仍有报告。Ryzen 高地址 bug 不算大事，这类 bug 常被补丁。Dan 忽略了一点：这类 bug 一直很多，只要有有效缓解就没事。PTI 补丁使系统调用变慢（约两倍）。
paulmd查看英文原文
Denverton is much more complex than a "simple" Atom (performance of a C3958 is up to about half of an i5-7500 in single-thread, twice the total multi-thread performance). Avoton is really no slouch either. It's really not surprising that the incidence of bugs is increasing on those uarchs as the complexity grows. The Skylake/Kaby hyperthread bug has been fixed in microcode and is no longer applicable. It's perfectly safe to run HT on these processors now. The AMD Ryzen segfault remains unmitigated at this point in time. Phoronix rushed to declare the bug fixed because they got a binned RMA replacement but there are plenty of reports of it occurring in current-production processors to at least a moderate degree, roughly proportionate with ASIC/litho quality. It's unclear what the scope is w/r/t Epyc since Epyc is on a different stepping but also hasn't really ramped yet either. The early Epyc processors were essentially engineering samples (on the order of hundreds to single-digit thousands of samples) with no real (public) visibility into any binning that might be taking place. The Ryzen high-address bug is no big deal, that's the kind of thing that gets patched all the time (like the Skylake HT bug). That's one thing Dan is glossing over here - there are tons of these bugs all the time and as long as there is an effective mitigation available it's no big deal. The PTI patch can be viewed as making syscalls take somewhat longer (about double iirc). Gamers and compute-oriented workloads won't be hurt hardly at all. The average mixed-workload case sees 5% performance loss, not ideal but it's not critical either. Losing 30% is real bad though, and that's what you will get on IO-heavy workloads that context-switch into the kernel a lot. The only real mitigation there appears to be right now is to give up hyperconvergence for now and harden up those DB/NAS servers that are going to be pushing a lot of IO so that you know there won't be hostile code running on them. That will allow you to safely disable PTI and sidestep the performance hit. Of course, Epyc was not that good at running databases in the first place, so you still might be better off sucking it up and running Intel even with the PTI patch. It will probably depend on your actual workload and the relative amount of IO vs processing.
验证复杂度持续上升，高保证处理器证明简化设计可减少勘误，但商业大厂不这么做。
老新闻说 Kris Kaspersky：在 Intel 这类全定制设计中可能继续恶化，因为复杂度上升而建模验证难度没降。另一方面看看 Verisoft 的 VAMP、Sandia 的 SSP、Rockwell-Collins 的 AAMP7G 等高保证处理器，测试无错，大量验证。它们比 Intel 简单，这是故意的，因为芯片复杂度有上限。可扩展方法到更大 SOC，但大厂商没做，有安全影响不会消失。
nickpsecurity查看英文原文
Old news says Kris Kaspersky: http://cs.dartmouth.edu/~sergey/cs258/2010/D2T1%20-%20Kris%20Kaspersky%20-%20Remote%20Code%20Execution%20Through%20Intel%20CPU%20Bugs.pdf Will likely continue to get worse in full-custom designs like Intel's since complexity keeps going up but ease of modeling and verification doesn't. On the other end, look up VAMP from Verisoft, SSP from Sandia, or AAMP7G from Rockwell-Collins if you want to see what high-assurance processors look like. They ran error-free during testing IIRC with a ton of validation. Sandia SSP was first-pass. In any case, they're all kind of simple compared to Intel's stuff. That's on purpose given there's an upper limit to how much complexity you can squeeze into a chip without significant errata. One can expand such methods to larger SOC's but that's not what big vendors are doing [out of necessity]. And that has security implications that aren't going away.
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选