Slashdot Mirror
Flaws In Intel Processors Quietly Patched
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.
This patch affects the microcode, which are the underlying machine instructions: http://en.wikipedia.org/wiki/Microcode
How could this not affect Intel Macs? They use the same machine instructions that everyone else does!
Two months ago, Intel introduced microcode updates for all systems with an Intel® Core(TM) 2 Duo processor. According to an HP Tech Support Document:
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 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.
Can You Say Linux? I Knew That You Could.
Yeah, because going to the processor's documentation page is hard to find. (Look under "specification update"). For the desktop Core2Duo processors, there are 59 pages(PDF) of errata documentation. Updated May 2007...
Comment removed based on user account deletion
The real "Libtards" are the Libertarians!
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.
Engineering is the art of compromise.
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.
- Michael T. Babcock (Yes, I blog)
It might NOT affect Macs, because of the way the OSX kernel handles specific failures. Remember when the F00F bug came out, Linus himself quickly came up with a Linux patch that mapped it over to (IIRC) a page fault, which then was handled separately. DOS machines just died.
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.
I want to delete my account but Slashdot doesn't allow it.
So here's the deal.
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.
Unless Intel has an update mechanism I'm not aware of, this is a Microcode update, and this is how they are always released.
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.
Everybody publishes errata. AMD's are at: http://www.amd.com/us-en/assets/content_type/white _papers_and_tech_docs/25759.pdf (starting on page 12)
A deep unwavering belief is a sure sign you're missing something...
My dealings with Dell on the server side have been pretty satisfactory, even running Slackware or OpenBSD.
My only complaint is the satisfaction survey they send you after the issue is resolved (not kidding).
I rarely criticize things I don't care about.
It's actually quite likely. CPU errata tend to effect corner cases. Eg: CPU returns wrong data if you read from an I/O port while servicing a TLB miss (or something like that). These bugs tend to be highly timing and sequence dependent, and its very likely that no two OSs use exactly the same sequence that triggers the bug.
A deep unwavering belief is a sure sign you're missing something...
. However, any _compiler_ worth its salt will try to use every bit of microcode it can to optimize for a given architecture or microarchitecture
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.
A deep unwavering belief is a sure sign you're missing something...
Microcode is included with all modern BIOS updates. As such, when you update your BIOS revision, you might get a newer microcode update to included. This microcode get's loaded on POST (Power On Self Test).
As others have pointed out, it resides in RAM (or would that be CPU cache?). So the update must loaded each time you power on the system.
Life is not for the lazy.
No it doesn't. Many (possibly most?) Linux distributions by default target non-MMX processors for the sake of wider compatibility.
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.
The Linux kernel is not currently affected, though some multi-processor apps with homegrown assembly might be.
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.
Linux has it too (microcode updates have been available since the Pentium Pro days). The microcode update is soft though, the original microcode is restored on a reboot. The best fix would be a relevant BIOS update which loads the patched microcode much earlier.
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.
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).
My server
Actually, it requires a significant number of elementary particles in the hardware, mostly electrons, to change state in one way or another. :-p
Uh, almost everything has software nowadays, and that includes most x86 CPUs (microcode).
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.
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 fault. But they probably could have just said "all Core 2 Duos, Extremes, and Quads."
the processors microcode has nothing to do with the bios
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.
Well, Intel does release these every so often -- the fact that Intel released updated microcode is hardly news. How these patches work is that Intel releases the Microcode. OS suppliers then take that Microcode and incorporate it into their OS's microcode update facility -- it's already released for Linux for crying out loud! The odds are that Apple have included this Microcode update, it's just been rolled into one of the other updates that nobody's noticed yet.
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.
You can download the software developers manual for Intel's line of processors, which covers pretty much everything you ever needed to know, lots you probably didn't, and then some.
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!
Intel has released an errata document.
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.
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:
Education is a better safeguard of liberty than a standing army.
Edward Everett (1794 - 1865)
Nowadays GCC can use SSE/SSE2 for floating-point math if you ask it to (it's quicker than x87 code, but doesn't support 80-bit extended precision). There's also the vector extensions you encountered, and there's a new vectorizer that can automatically convert code into parallel operations.
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.
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 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.
Neither NOR or NAND flash uses fuses. Fuses were used in the PROM technology from the 70's and 80's. (Though perhaps you were speaking figuratively.)
The number of times flash memory can be reprogrammed means your PC will be in a landfill site long before the flash breaks.
No, the phrase 'genuineintel' is used, because that's how Intel chips identify themselves using the CPUID opcode.
The microcode needs to be updated every boot. It's volatile and resets when you turn off the system. See http://urbanmyth.org/microcode/
As far as I know, all OSes do this.
Isn't it more plausible that the file names have the word "genuine" in them because like many patches, they're only available to activated windows boxes, and that it's just some random bug in the microcode being fixed?
The bug in question is the bug in the TLB that was discovered back in April. Here's HP's page 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.
(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.
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
Here is a story from April 29th.. Which actually tells you WHAT the microcode fixes http://www.rage3d.com/board/showthread.php?threadi d=33889730
I don't need to test my programs.. I have an error correcting modem.
Of course they're related. I remember Intel announcing the whole idea of the microcode update was to avoid another bug like that.