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.
If they're releasing the patch so quietly, how will anyone know to apply it?
If my call is important, why am I talking to a recording?
There is no indication that Apple users are affected.
What, magical pixie faries fixed the Intels in Macs? How could they not be 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!
With two such large, trustworthy, open, and reliable organizations involved, which have always looked after the general well being of the industry because what's good us is good for them, do we really need to worry ?
How many Pentium designers does it take to screw in a light bulb? 1.94
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.
Kwisatz Haderach
Sell the spice to CHOAM
This Mahdi took Shaddam's Throne
Mac OSX does not make use of the new x86 BNDOVR opcode, unlike Windows which is dependent on it.
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...
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] of Hax0r/Crax0r Wet Dreams?
Seriously - how can you hope to maintain the illusion of Virtual Machines if you can write to the microcode?
Comment removed based on user account deletion
The real "Libtards" are the Libertarians!
True story:
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.
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.
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.
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.
After reading this thread its amazing to me how many Slashdot readers don't know how microcode works, making broad statements about how patching a processor is impossible without an EEPROM burner, or using a DOS boot disk.
that this neither comes with a silver platter, or chilled champagne. I know when this realization dawned on me, my monocle popped out and rolled under my desk. My gentleman's gentleman, Wheatley, has noted his displeasure with your oversight while remedying the situation.
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...
Intel was just waxing nostalgic and wanted to remember the good only days.
http://en.wikipedia.org/wiki/Pentium_FDIV_bug
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
Everybody publishes errata.
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.
The truth shall set you free!
. 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...
What's up with the Moderators? I constantly see posts that say the exact opposite thing both modded Informative or Insightful. We need a category "Incorrect". If the Moderators don't know the correct answer they should refrain from moderating either Insightful or Informative. It may be informing but the post is informing people with incorrect information.
Good grief, put two and two together. No information about what the patch does, it's a Microsoft update, and Apple and Linux aren't affected. It's the DRM, stupid! -- (borrowed from the Bill Clinton 1992 campaign).
3 things about computers: they're alive, they're self-aware, and they hate your guts.
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.
Blah I say. Blah. This is old news. I first read about it over a month ago when Dell shipped a "critical update" for some of their laptops for this issue. Check out this HP advisory from a couple weeks ago:
D ocument.jsp?objectID=c01038053
http://h20000.www2.hp.com/bizsupport/TechSupport/
Dell released an update for PE2950 servers around the same time.
So again I say, Blah.
*YAWN*
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.
Normally a microcode update is flashed into the motherboard with a BIOS update. That is damn close to being the same thing. Not too many people upgrade their BIOS, and fewer still would consider downgrading. Not too many people replace motherboards separately from CPUs, especially these days with a new CPU socket shape being invented every other day.
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)
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.
The FDIV bug and associated fallout shortly preceded Intel's introduction of the microcode update facility. I don't think the two issues are unrelated.
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.
No, the phrase 'genuineintel' is used, because that's how Intel chips identify themselves using the CPUID opcode.
Some drink at the fountain of knowledge. Others just gargle.
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).
Of course they're related. I remember Intel announcing the whole idea of the microcode update was to avoid another bug like that.