A few days ago, a post by Theo de Raadt analyzed the newly publicized Intel Core 2 bugs. And in just a couple of days quite a few different opinions (see http://blogs.zdnet.com/Ou/?p=559, and http://undeadly.org/cgi?action=article&sid=20070630105416) emerged. In this post, I will try to analyze from my point of view.
First of all, I don’t think that the errata in the Core 2 series are as bad as the Pentium FDIV bug found back in 1994, because non of these bugs affect the accuracy of any calculations. But on the other hand there are altogether 105 bugs, and a few of them can be quite significant depending on how you view it.
Here is the break down according to the current status of these bugs:
Fixed: 4 Plan Fix: 31 No Fix: 70
Clearly, given the large number of “No Fix” bugs, it should’ve caused some concerns first. After a closer look at each individual bugs, however, it seems that very few bugs listed are critical enough to raise any significant concerns. For example, among the 105 bugs, 16 are related to monitoring (well, monitoring is important but it does not affect the performance of a CPU), and a few only affects kernel debugging (which the majority of us do not do anyway).
There are a few more significant bugs. AI33, for example, can cause unexpected instruction execution results and AI155, using memory type aliasing with memory types WB/WT may lead to unpredictable behavior. In theory, these types of design errors can lead to potential execution of un-authorized userland code. However, most of the hardware level interactions are done by the kernel and are shielded from the user code so I would doubt that these kinds of bugs can be easily exploited as they may not even be possible to be reached in userland code.
So, personally, I think that the effects of these bugs on the Core 2 family processors are probably low.