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.
my 1.9432534656 cents worth... (Score:5, Funny)
Re: (Score:3, Insightful)
Re:my 1.9432534656 cents worth... (Score:5, Insightful)
Re:my 1.9432534656 cents worth... (Score:4, Funny)
Exactly, and I think Windows has adequately demonstrated that you can't trust it.
Re:In Soviet Russia ... (Score:4, Insightful)
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:4, Insightful)
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: (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 gi
yes, but... (Score:3, Insightful)
Intel Macs not affected? (Score:5, Insightful)
What, magical pixie faries fixed the Intels in Macs? How could they not be affected?
Re: (Score:3, Funny)
Something to do with the unicorn semen and pink elephant droppings.
Re:Intel Macs not affected? (Score:5, Insightful)
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: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:Intel Macs not affected? (Score:5, Interesting)
There are several known TLB issues that are rather serious which all OSs have to have workarounds for. The most serious issue is that reducing the access permissions in a page table entry (such as turning off the valid bit or making the entry read-only) on one cpu can race another cpu's TLB trying to access that same entry. The race can cut an instruction into two pieces on the other cpu and (if e.g. a read-modify-write instruction) result in fireworks. All modern operating systems have to synchronize page table invalidations across all cpus that might be using the page table in question. So, e.g. in a heavily threaded environment if a page table is shared across three cpus invalidations made in that page table requires all three cpus operating systems to synchronize (usually with an IPI) to guarentee that none of them are accessing memory governed by the page table entry being changed. Kernel virtual memory is even worse, since that is shared by all cpus, which is why its better to just keep a cache of mapped memory instead of constantly mapping and unmapping pages in KVM.
There are also serious issues with global pages and mixed TLB entries when switching from small pages to large pages, issues when operating in compatibility modes, issues when using address wrapping. Most of these issues only occur with absurd code sequences, such as an instruction which wraps the address space (which will never occur in real life so can be ignored as long as the issue does not cause a failure in the security model). 90% of the errata is not an issue in a nominally running environment.
-Matt
Comment removed (Score:5, Informative)
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].
Re: (Score:2)
Re: (Score:3, Insightful)
Re: (Score:2, Informative)
What counts as "hardware" anyway? (Score:3, Informative)
Since microcode isn't hardware, fixing it shouldn't require any changes to the hardware.
This is true; however, microcode *does* blur the line between software and hardware.
(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 instru
Re: (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:5, Informative)
As far as I know, all OSes do this.
Re:Intel Macs not affected? (Score:5, Interesting)
If anyone wants to place their machine at grave risk, I'd be interested to know what happens if you are running a Windows machine in one virtual container and Linux in another, then patch the microcode from Windows. How does it affect Linux? Do kernel tests, say in the LTP or one of the other testing kits, suddenly succeed where they'd otherwise fail, or vice versa?
Likewise, if you use IE in WINE and pull the patch down, purely in a Linux environment, does it disrupt Linux, benefit it, or have no impact whatsoever?
If we knew this, we should be able to figure out more what the defect actually is and what the patch does to correct it, as we can track what Linux is doing at the time something different happens.
That can't be right. (Score:4, Insightful)
Re: (Score:3, Insightful)
I really wish gcc developers would choose performance over, well, whatever it is that they went for here.
Two years ago, I compared C compilers for the AMD64 using the stream benchmark (I was developing an application that had similar performance characteristics to stream). The compiled code that gcc generated was, if I remember correctly, 30% slower t
Linux users too... (Score:2)
Linux may not be affected (Score:4, Interesting)
I ran an AMD Athlon in an Asus MB as a Linux server for 4 years with no trouble (other than noticing that mplayer didn't work right). A few years after I decomissioned the MB, I decided to set it up as an XP box for my 4 year old. I was very surprised to discover that it just would not work right. After some troubleshooting, I found that the CPU had a bug in some of the MMX instructions. By this time it was too late to exchange the chip for a functional one so I just threw it away and bought another one from eBay. My 4 year old is happy with his computer.
Re: (Score:2)
Re: (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.
Re: (Score:2)
Re:Intel Macs not affected? (Score:5, Funny)
I swear, our servers have been behaving more strangely since the guy in the next rack over installed a few Mac Mini's; maybe the RDFG's emmit gamma rays from their embedded naked singularity...
Re: (Score:2)
Re: (Score:2)
Re:Intel Macs not affected? (Score:4, Funny)
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."
Why Mac OSX not affected (Score:5, Funny)
Re: (Score:2)
Well, it only affects two models of the Core 2 Duos, which is the only processor that Apple uses for all its Intel Macs except the Xserve (Xeon) and the Mac mini (first-generation Core Duo, which is not affected). So, assuming Apple didn't use either the E4000 or the E6000 Core 2 Duo processors, that would explain why they are not affected.
However, I do think the situation is interesting when we look at the Xserve, since they use Xeons. The article notes several affected models of them, which it says is ju
Re: (Score:2)
Well, I am sure I won't be the only person to point this out, but Apple does not use the Core 2 Duos in the MacPro towers, either. They use Xeons.
Re: (Score:2)
Re:Intel Macs not affected? (Score:4, Insightful)
Is everyone here blind? (Score:3, Interesting)
Ooops, I'm the blind one (Score:2)
Given the level of secrecy that Intel and Microsoft are givi
Re:Ooops, I'm the blind one (Score:5, Insightful)
And given that I have no evidence either way, it must be the fairies. What kind of an argument is that? If they were being so secretive to hide the nature of the patches, why would they go and label them in the fricking file names?
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?
I think you've had the tinfoil hat on a little bit too long.
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.
Re: (Score:3, Informative)
No, the phrase 'genuineintel' is used, because that's how Intel chips identify themselves [wikipedia.org] using the CPUID opcode.
Re: (Score:2)
Re: (Score:2)
Install Intel in a PC, you've got problems.
Install Intel in a Mac and... Boom! No problems.
And you want an iPhone.
Microcode (Score:5, Informative)
How could this not affect Intel Macs? They use the same machine instructions that everyone else does!
This is a possibility (Score:2)
Perhaps this only happens on MS and not on Macs.
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: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.
flash the CPU Microcode - YIKES! (Score:3, Insightful)
Uhh, you can flash the CPU Microcode from within a Microsoft OS?!? [Other than DOS?!?]
Wouldn't this pose like the Mother of All Possible Challenges to the Black Hat community - how to right a worm that could flash CPU's, thereby rendering nearly limitless power over every possible sandboxing or anti-virus countermeasure?
Kinda the Helen of Troy [or Anne Boleyn [sho.com]] of Hax0r/Crax0r Wet Dreams?
Seriously - how can you hope to maintain the illusion of Virtual Machines if you can write to the microcode?
Re:flash the CPU Microcode - YIKES! (Score:5, Insightful)
Re: (Score:3, Insightful)
Re:flash the CPU Microcode - YIKES! (Score:4, Insightful)
Which makes it no worse than any other hack, virus or worm. You can already take complete control over the computer without resorting to microcode.
If it had been permanent and survived reboots, then a complete format and reinstall would not remove the hack. That would have been scary indeed, but luckily that is not the case.
Re: (Score:3, Insightful)
Question is, how come you patch microcode hardware flaw with a software patch - is this affecting performance? Possibly.
About the Macs not being affected: that was funny. Given how secretive the MS/Intel patches are, and we know Apple is totally open about stuff like that, right?
Oh come on, it's nothing (Score:5, Funny)
ah, time to dig up the bluewave tagline file... (Score:5, Funny)
Pentiums and Deodorants - When being close is all that matters
Highlander Pentium: There can be only 1.0101002913491!
Talking Barbie and the Pentium-90 agree! "Math is hard!"
"Go forth and multiply... divide only if not on a Pentium..."
"I am Pentium of Borg--prepare to be approximated"
Pentium: Making tomorrow's mistakes today
Pentium slogan: Why Do You Think It's Called *Floating* Point?
Pentium slogan: Nearly 300 correct opcodes!
Yeah, I know that Intel bashing is old, that's why I used old jokes.
Re:ah, time to dig up the bluewave tagline file... (Score:4, Funny)
I do have these gems still though:
Win2k: "It's not so much that it's only 65,000 bugs, it's just that they stopped at 65,535 to prevent an overflow."
Sun believes the only place for 63,000 bugs is a rain forest.
Re: (Score:2)
"If Windows were an ice cream, it would be hoggin' dos!"
I miss my BBS'in days.
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:
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: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:Some more details (Score:5, Interesting)
Re: (Score:2)
So this is a "sky is blue" type of error then?
Re: (Score:2)
Still seems odd to me, but the quietness of the issue doesn't encourage any suspicion for me.
MS often releases non-security and non-critical updates in a graduated manner:
First, you must call PSS to be able to download the patch. MS just wants to be sure the patch fixes the problem. You're a beta tester.
Next, they release the patch for public download. Affected users wi
Linux not affected (Score:3, Informative)
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.
This recent posting to the Linux Kernel Mailing List [google.co.uk] by Andi Kleen states that Linux is not affected.
Dell told me "Windows only" (Score:2)
Re: (Score:2)
Re:Dell told me "Windows only" (Score:4, Informative)
Re: (Score:2)
Re: (Score:3, Informative)
My only complaint is the satisfaction survey they send you after the issue is resolved (not kidding).
Re: (Score:2)
Looks like an OS update (Score:2)
However, this sounds very similar to the issue with Prescott CPU's and XP SP2, where an installation on a system with a CPU below stepping 8 would hard freeze on restart after the initial setup. In that case the fix was a BIOS update OR disabling L1 and L2 cache.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Informative)
Intel price cuts? (Score:2)
It's sort of chicken and eggish when talking hamburger, but is the defect because of the price cuts to compete or is the price cuts because of the flaw? Or is it totally unrelated with either and I'm just throwing balls at the side of the barn and missing?
I am wondering though, doe this mean I would have a CPU that doesn't do everything it was supp
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.
Slashdot readers and microcode (Score:5, Insightful)
Re: (Score:3, Informative)
Waxing nostalgic (Score:3, Interesting)
http://en.wikipedia.org/wiki/Pentium_FDIV_bug [wikipedia.org]
Asleep at the wheel (Score:5, Insightful)
Re:Asleep at the wheel (Score:5, Funny)
This is a serious problem for Java and
What this patch fails to realize is the problems with the instruction listed on Intel's website. A similar bug in all x86 chips manufactured since 2004 (yes, really!) requires that most compilers have to work around it. (The patch in BCB wasn't ready until late 2005, which is what lead to a 15% drop in their market share.) It has become a problem in real-world applications requiring time-critical code. It may not mean much to most "high-level" programmers, but SOME of us still get into the assembly code every now and then. It's a real nightmare, and it's not something that you expect from a company like Intel.
I refer you to the errata at http://docs.intel.com/kb2004/hwbugs/knownissues.h
See what I mean? It totally looks like I know what I'm saying, but it's a complete fabrication. If I didn't put these lines bookmarking it as just plain dumbassedness, then I'd probably get modded up for it. Hell, I'll probably STILL get modded up. Some lazy mods (myself included) treat the mod points like a hot potato, or leprosy.
I think this post is funny, but then again, it's well past my bed-time.
Blah - Old News (Score:3, Interesting)
http://h20000.www2.hp.com/bizsupport/TechSupport/
Dell released an update for PE2950 servers around the same time.
So again I say, Blah.
*YAWN*
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: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...
Sir, you will no doubt be shocked to learn.... (Score:5, Funny)
Re: (Score:2)
Last time I heard, Intel publishes errata sheets unlike many other suppliers. Microsoft may have a fix or patch simply becasue the data is known and published.
With your chips, do you prefer open or closed?
The advantage is bugs can be fixed.
Here is a forum on Conroe errata.
http://www.abxzone.com/forums/general-intel-platfo rm-discussions/105033-intels-conroe-has-67-errata- bugs.html [abxzone.com]
Does AMD publish this?
Re:Heh (Score:4, Informative)
Re: (Score:3, Interesting)
Things have changed for the better. I am not a programmer so I don't pay attention to errata. I remember that published and unpublished errata was an issue at about the time the Pentium 90 floating point bug was discovered. Since that major voluntary recall, Intel has taken steps to make CPU's patchable so minor bugs can be fixed. This patch is a good example of that working.
Re: (Score:2)
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!
I think I know that one (Score:2)
The BIOS hack uses SMM/SMI (system management mode) to emulate one clock chip by using a different one. (eeew)
It causes massive problems for real-time code.
Re:microcode update buggy for real-time applicatio (Score:2)