Hacker News Reader

Comment by BLO716 | Hacker News Reader

The growing pains of silicon development date back to the Intel line of Pentium FDIV bug issues. Not surprised it occurred, just surprised it took so long to come to fruition. I can only think its the lack of hardware engineers savvy enough to exploit such an issue, since the abstractions from hardware are so far removed from us general populous software developers.

Any thoughts on the above?

View on HN

For the uninitiated, are such ‘unpatchable’ hardware flaws prevalent and/or debilitating to a greater or lesser degree in other processors (Intel, AMD, Apple AX processors)? Or has Apple "dropped the ball" compared with other chip designers?

You can look up some other major events such as spectre/meltdown which also used hardware side channels and speculative execution, or rowhammer which affects RAM.

Interesting! Were the unit testing procedures used in the hardware design and simulation processes themselves flawed? Reading up on these I have not yet been able to elucidate any forensic insight into the original chip design.

Unit testing isn't really the issue here, spectre / meltdown / rowhammer are pretty fundamental design problems.

meltdown / rowhammer are pretty fundamental design problems, spectre is even a pretty fundamental logic problem. It hasn't been comprehensively fixed in HW and probably will never be because it directly contradicts the need for reasonable perf on multicore CPUs (at the intersection between speculative/OOO execution and cache coherency, and both are needed for reasonable perfs). Rowhammer is also hard to comprehensively fix for physics reasons, but hopefully some dedicated mitigations plus ECC are good enough for not ultra-critical applications; some people think more could be done that could practically fix it, but I don't know if they have managed to convince the industry (and get some value from their patents in the process). So of the three, only meltdown could be really fixed by a quick iteration of processor design (and it is also workaround by the OS on old affected models, at a performance cost)

All the modern CPUs have a long list of at least several dozens of design defects, most of which are never corrected.

Such lists were initially published as "Errata Lists", but now many manufacturers use less honest names, e.g. Intel uses "Specification Update" and AMD uses "Revision Guide".

Some defects may become manifest only when the hardware is used in certain ways, which may be avoided by the motherboard manufacturers, maybe at the price of reduced performance.

Many uncorrected defects affect only various testing or performance monitoring features. Many other uncorrected defects affect only privileged programs, so the resolution "Won't Fix" is justified by saying that all the popular operating systems have been tested and they have not been seen to trigger the bug. (For someone who develops their own operating system it is mandatory to read all the errata lists, because obviously their OS will not be used by Intel and AMD for testing the new CPUs.)

When the defects can affect user programs, in many cases it is possible to implement workarounds with microcode updates included in BIOS or operating systems, possibly with the price of reduced performance. Only when no microcode workaround is possible and the bug can be triggered by user programs, leading to crashes or incorrect results, then the defect is scheduled for being corrected in a new revision of the CPU. Most of these defects that are corrected are discovered during the testing of the engineering samples, before the official launch of the CPU, which uses the latest revision, with only the known defects that either do not affect non-privileged programs or have microcode workarounds.

> then the defect is scheduled for being corrected in a new revision of the CPU

Note that Intel very rarely issue new revisions of existing models nowadays. Probably creating new masks is too expensive. They simply include some fixes in new models. Probably likewise for all vendors for high-perf but non-critical applications. And probably they all try to let the microcode cover more things via chicken bits or other methods, to avoid the risk of having to do catastrophic recalls.

Reply on news.ycombinator.com