Flaws In Intel Processors Quietly Patched 311
Nom du Keyboard writes "According to this article in The Inquirer and this Microsoft Knowledge Base article, a fix for some significant problems in many of Intel's most recent processors has been quietly released — by whom is not clear. Patches are available on Microsoft's site. Affected processors include Core 2 Duo E4000/E6000, Core 2 Quad Q6600, Core 2 Xtreme X6800, XC6700, and XC6800. Details on just what has been fixed are scanty (it's called a 'reliability update'), however, it's probably more important than either Intel or Microsoft is openly admitting." There is no indication that Apple users are affected.
Microcode (Score:5, Informative)
How could this not affect Intel Macs? They use the same machine instructions that everyone else does!
Some more details (Score:5, Informative)
Two months ago, Intel introduced microcode updates for all systems with an Intel® Core(TM) 2 Duo processor [ibm.com]. According to an HP Tech Support Document [hp.com]:
While the implications of the issue are difficult to quantify, any of the following symptoms can occur:
* The system may stop responding to keyboard or mouse input.
* A system operating in a Microsoft Windows environment may generate a blue screen.
* A system operating in a Linux environment may generate a kernel panic.
This was the first I had heard of this; probably a good time to check for BIOS or microcode [urbanmyth.org] updates."
The HP link also indicates the nature of the problem, which should not be OS specific:
This Intel microcode update addresses an improper Translation Lookaside Buffer (TLB) invalidation that may result in unpredictable system behavior such as system hangs or incorrect data.
Re:Intel secrecy (Score:5, Informative)
Yeah, because going to the processor's documentation page [intel.com] is hard to find. (Look under "specification update"). For the desktop Core2Duo processors, there are 59 pages [intel.com](PDF) of errata documentation. Updated May 2007...
Comment removed (Score:5, Informative)
Re:Dell told me "Windows only" (Score:4, Informative)
It is quite common for some instructions (Score:5, Informative)
Typically it is only sequences of instructions that would trigger these bugs. In other words, the CPU has to be in a certain state to trigger the bug. Some OSs will never get in that state. The bugs are surely something like this because otherwise crashes would be far more common than we see.
The reason why I mention cache handlers is because those are notoriously tricky and have proven buggy before. The Core Duo 2 CPUs need new cache handlers to handle the dual (and more) cores and thus this area is more likely to be buggy.
Re:Some more details (Score:5, Informative)
For those that are wondering, the Translation Lookaside Buffer is what is used to map Virtual Addresses to physical page addresses. The TLB is a cache of recent translations between Virtual and Physical addresses. So what could happen with incorrect invalidation is that the WRONG physical page could be resolved and bogus data accessed by the operating system.
More here [wikipedia.org].
Re:Intel Macs not affected? (Score:5, Informative)
Incorrect. Microcode on Intel processors can be updated live by software. This has been possible for ages. For information on how this can be done in Linux for example, see here [urbanmyth.org].
May not affect Macs, or just not tested (Score:2, Informative)
For this PARTICULAR microcode issue, OSX _may_ do something interesting with it, and so not be affected. Or, they simply never tested/validated it, and so Apple has no patch.
CPU's are Emulators (Score:5, Informative)
Intel processors don't directly execute instructions anymore. They translate x86 into a series of other operations -- an internal code, if you will. Sometimes there are bugs in the code that's generated. Microcode patches address those bugs.
Re:my 1.9432534656 cents worth... (Score:5, Informative)
And for what its worth it doesn't patch anything, it loads into the processor at boot. Delete the microcode file or remove the OS and the processor will be just as you bought it.
Just be glad they were smart enough to use such a system where the processor can be updated while running and temporarily, allowing you to revert back to its purchased state.
Re:Heh (Score:4, Informative)
Re:Dell told me "Windows only" (Score:3, Informative)
My only complaint is the satisfaction survey they send you after the issue is resolved (not kidding).
Re:This is a possibility (Score:4, Informative)
Re:This is a possibility (Score:5, Informative)
Actually, compilers try to avoid micro-coded instructions like the plague. On most x86 processors, micro-coded instructions can only issue out of a single issue slot at a fixed rate, and hence their use drastically lowers performance. Modern compilers generally treat the x86 like a RISC with a weird condition register and fancier addressing modes.
Comment removed (Score:3, Informative)
Re:Linux may not be affected (Score:2, Informative)
And we're not all Gentoo-style rice, er, I mean D-I-Y-ers who just have to build everything for ourselves.
In fact, these days I would expect that most Linux users are unlikely to build software for themselves very often, if at all.
correct (Score:5, Informative)
The problem is some sort of atomic operation sequence. Somebody let slip a reference to the bug on a mailing list today, without any real details. Probably the details are still under NDA.
Re:Looks like an OS update (Score:3, Informative)
Re:my 1.9432534656 cents worth... (Score:3, Informative)
It's actually easier to just use an SRAM to hold microcode patches than to incorporate flash memory or other non-volatile reprogrammable storage on the die. Flash requires a special type of transistor, and fuses generally can't be unblown once they're blown (meaning you'd be very limited in how many patches you could ever apply to a given chip).
Re:Intel Macs not affected? (Score:2, Informative)
Re:Intel Macs not affected? (Score:3, Informative)
To Joe Public, a wireless router would be all hardware. But to Joe Hacker, a wireless router would be mainly software.
The manufacturer of one of my DVD drives released firmware updates that allowed it to support dual layer DVDs - over time they added better support and more features.
Re:Intel Macs not affected? (Score:4, Informative)
E4000 - doesn't exist
E6000 - doesn't exist
Q6600 - k, this one does exist
X6800 - this one exists too
XC6700 - doesn't exist
XC6800 - doesn't exist
Of course, they probably meant E4000 and E6000 series, and maybe they meant QX6700 and QX6800...
I guess it was the inquirer's [216.239.51.104] fault [theinquirer.net]. But they probably could have just said "all Core 2 Duos, Extremes, and Quads."
Re:my 1.9432534656 cents worth... (Score:1, Informative)
That is not true. There is a processor microcode update RAM in the processor, and it can be loaded with microcode updates by the BIOS.
This has been out for Linux for months.. (Score:2, Informative)
These updates can also be loaded into your BIOS too so they're loaded prior to OS startup; it's just that it's usually a lot easier to update OS installations than reflashing lots of different BIOS variants. However, I suspect this is exactly what Apple have done -- they've incorporated this microcode update into their EFI updates and/or will include this version in the next round of updates.
About the only surprising thing is that Micosoft have actually wrapped it up and released it. Usually they don't bother unless they've actually had issues that are fixed by microcode updates.
Linux not affected (Score:3, Informative)
Re:Heh (Score:5, Informative)
It's historically been 3 volumes, but these days they have volume 2A, 2B, 3A, 3B, plus there is the optimization reference, and some changes and notes.
Have a blast!
Errata (Score:4, Informative)
For June 2007 it lists 3 new errata:
AH106
A memory access may get a wrong memory type following a #GP due to WRMSR to an MTRR mask.
AH107
PMI while LBR freeze enabled may result in old/out-of-date LBR information
AH5P
VTPR may lead to a system hang
However, the document states that there are no fixes available. So it's probably not what MS/Intel is addressing here.
Re:Ugh, I hated that bug. (Score:5, Informative)
1) The Pentium FDIV bug produced an incorrect answer in 1 in 9 billion double precision floating point divides. It did not affect integer divides.
2) The answer always contained at least 14 correct significant bits (usually more, but an error in the 15th significant bit was the worst case). The means that single precision calculations were almost invariably correct.
3) Any hack to solve the problem would have been hundreds of times slower than just living with a small error in so few calculations.
4) All games today get by just fine using single precision floats for rendering.
5) It took a guy (Thomas Nicely) with a Ph.D. doing heavy research in computational number theory to find it, yet you found it while working on a game in QuickBasic.
I think Nicely said it best in his FDIV flaw FAQ: and also:
Re:Linux may not be affected (Score:1, Informative)
Re:Updating microcode from within a VM (Score:2, Informative)
AI88. Microcode Updates Performed During VMX Non-root Operation Could Result in Unexpected Behavior
Problem: When Intel® Virtualization Technology is enabled, microcode updates are allowed only during VMX root operations. Attempts to apply microcode updates while in VMX non-root operation should be silently ignored. Due to this erratum, the processor may allow microcode updates during VMX nonroot operations if not explicitly prevented by the host software. Implication: Microcode updates performed in non-root operation may result in unexpected system behavior.
Workaround: Host software should intercept and prevent loads to IA32_BIOS_UPDT_TRIG MSR (79H) during VMX non-root operations. There are two mechanism that can be used (1) Enabling MSR access protection in the VM-execution controls or (2) Enabling selective MSR protection of IA32_BIOS_UPDT_TRIG MSR. Status: For the steppings affected, see the Summary Tables of Changes.
Re:Patch for Linux... when? (Score:5, Informative)
b) If you're running a Red Hat-derived distro, watch out for updates to the kernel-utils package, which provides microcode_ctl and /etc/firmware/microcode.dat. It might also be worth checking Tigran's site [urbanmyth.org] a bit more regularly. I note that his page includes a microcode.dat which is about 7 months newer than that currently provided by CentOS 4.5's kernel-utils package.
Re:my 1.9432534656 cents worth... (Score:2, Informative)
The number of times flash memory can be reprogrammed means your PC will be in a landfill site long before the flash breaks.
Re:Ooops, I'm the blind one (Score:3, Informative)
No, the phrase 'genuineintel' is used, because that's how Intel chips identify themselves [wikipedia.org] using the CPUID opcode.
Re:Intel Macs not affected? (Score:5, Informative)
As far as I know, all OSes do this.
Re:correct (Score:5, Informative)
The problem is some sort of atomic operation sequence. Somebody let slip a reference to the bug on a mailing list today, without any real details. Probably the details are still under NDA.
I did some digging around, and it actually looks like this is a patch for a bug in the Translation Lookaside Buffer (TLB) that was discovered back in April. Microsoft has released a patch for people running current versions of Windows (Vista, XP, and server 2003) but if you're running anything else then you will have to get a new BIOS update to resolve the issue. If you check the major hardware vendors web sites (HP, IBM, etc) the are offering patches to their system ROMs regardless of the OS.
I know that it's popular on Slashdot to claim that Linux isn't vulnerable to the same bugs that Microsoft operating systems are, but when it comes to processor bugs (errata, in Intel-speak) that's simply not the case. Linux does make use of the TLBs. Every modern OS does. If you look at the hardware vendors' web sites, you will see that they specifically state that the bug could lead to a BSOD on Windows or a kernel panic on Linux.
Re:Ooops, I'm the blind one (Score:4, Informative)
The bug in question is the bug in the TLB that was discovered back in April. Here's HP's page [hp.com] on it. I think that the only reason it's news today is because Microsoft has either just released or re-released a patch to fix the issue on Windows boxes.
What counts as "hardware" anyway? (Score:3, Informative)
(Disclaimer; I am not an expert on the subject matter, take the following with a pinch of salt).
Consider this; do you really have x86 CPU "hardware" in your Intel-based PC? This depends on how you define "hardware".
As far as I'm aware, all modern Intel "x86" CPUs (Pentium Pro/Pentium II onwards) have a RISC core. They have to convert the long and irregular (i.e. nothing like RISC) x86 code into the native RISC instruction set via microcode. So it could reasonably be argued that the CPUs aren't actually executing the x86 instructions themselves in hardware.
Of course, all this is transparent to the user; as far as they are concerned, the CPU *is* "hardware", and I'm not sure if any of this is even visible from a system-designer's point of view (i.e. the processor is- I'd assume- still a "black box" for this purpose).
Anyway, I assume they did this because- even with the overhead of translation and the added complexity- it would still have made optimising the design much easier. Generally speaking, this is one of the major benefits of RISC design; x86's CISC instructions (i.e. long, complex and irregular) would have presented a major headache to Intel's engineers.
It's notable that the older Pentium-I had a CISC core; so internally the chip was *very* different from the Pentium Pro/P-II. I assume this means that it *was* based around the x86 instruction set to some extent, although I don't know how much- if any- conversion or translation of instructions via microcode was involved. I suspect that because the core hardware would have been based round the x86 instructions themselves and less reliant on microcode, fixing bugs (etc) via microcode would have been far harder- if it was possible at all.
OLD CPU microcode is old (Score:2, Informative)
Re:In Soviet Russia ... (Score:2, Informative)
Re:Some more details (Score:2, Informative)