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.

my 1.9432534656 cents worth...

[ross.w (87751)]

If they're releasing the patch so quietly, how will anyone know to apply it?

Re:

[Jah-Wren Ryel (80510)]

If they're releasing the patch so quietly, how will anyone know to apply it?

It's probably a microcode update that your BIOS loads on boot. So, chances are it will be inconspicuously available as part of the next BIOS patch for most systems.

Re:my 1.9432534656 cents worth...

[Poltras (680608)]

It's not like windows couldn't mess with your machine anyway. If you don't trust your operating system, how can you trust your whole system.

Re:my 1.9432534656 cents worth...

[naasking (94116)]

It's not like windows couldn't mess with your machine anyway. If you don't trust your operating system, how can you trust your whole system.

Exactly, and I think Windows has adequately demonstrated that you can't trust it.

Re:In Soviet Russia ...

[cowbutt (21077)]

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.

Re:Patch for Linux... when?

[cowbutt (21077)]

a) Presumably recent versions of Windows include equivalent functionality to Tigran Aivazian's microcode_ctl for Linux, which allows the CPU microcode to be updated from firmware files once the OS has booted. (The usual way is that the BIOS ships with a set of updated microcode firmwares for various supported CPUs and loads them during the pre-boot phase of startup).

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...

[jd (1658)]

What worries me is the idea of Microsoft Update mucking with the processor in the first place. And what is Genuine Disadvantage going to think of patching a non-Microsoft product anyway?

Re:my 1.9432534656 cents worth...

[mrsteveman1 (1010381)]

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.

Intel Macs not affected?

[by Anonymous Coward]

There is no indication that Apple users are affected.

What, magical pixie faries fixed the Intels in Macs? How could they not be affected?

Re:

[by Anonymous Coward]

Something to do with the unicorn semen and pink elephant droppings.

Re:Intel Macs not affected?

[shird (566377)]

I would guess the bug affects some Ring0 OS type of service/instruction (such as switching in and out of protected mode, paging, faults etc) which MacOS doesn't use. Hence the patch is part of the OS. I speculate that its a workaround in the OS rather than a patch to the actual CPU.

correct

[r00t (33219)]

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.

Re:correct

[ocbwilg (259828)]

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.

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?

[m.dillon (147925)]

I couldn't find an exact errata reference but it looks like a ring 0 issue to me too, which means that the OS either doesn't trigger the conditions required or the OS can work around the problem. Some such issues can be fixed in microcode, some have to be dealt with by the operating system.

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

Re:Intel Macs not affected?

[Bottlemaster (449635)]

A software patch cannot (physically) alter the hardware so it _has_ to be a workaround in the OS.

You forgot that modern Intel and AMD processors can have their microcode updated. It's perfectly possible that this patch fixes the actual problem and is not just a workaround.

Re:Intel Macs not affected?

[MikeBabcock (65886)]

they can have their microcode updated, but only with a dedicated bridged-bus eeprom burner ($15,000 or so).

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:Intel Macs not affected?

[someone300 (891284)]

The microcode needs to be updated every boot. It's volatile and resets when you turn off the system. See http://urbanmyth.org/microcode/ [urbanmyth.org]

As far as I know, all OSes do this.

Re:Intel Macs not affected?

[jd (1658)]

Depends on the instruction(s) inflicted. Based on the limited information available, it could be anything from a mode that's unused outside of Windows to an instruction that the compiler used for Mac OS/X simply never generates. (A sub-optimal instruction, for example, would be skipped by any decent optimizing compiler as the same thing could be done in superior ways.)

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.

[goombah99 (560566)]

Depends on the instruction(s) inflicted. Based on the limited information available, it could be ....an instruction that the compiler used for Mac OS/X simply never generates. (A sub-optimal instruction, for example, would be skipped by any decent optimizing compiler as the same thing could be done in superior ways.)

That makes no sense. Apple can't know what compiler third party used to compile some piece of software. For that matter someone might have handcoded it. Your theory that it could be some mode not used in mac-os makes more sense since the OS might possibly prevent certain modes from being accessed by any non-apple software.

Re:Intel Macs not affected?

[Kingrames (858416)]

It's not that they're not affected. It's that apple fanboys won't admit to it.

Re:Intel Macs not affected?

[ben there... (946946)]

This sounds like it doesn't affect much of anyone with a real, existing Core 2 Duo, at least according to the summary...

Affected processors include Core 2 Duo E4000/E6000, Core 2 Quad Q6600, Core 2 Xtreme X6800, XC6700, and XC6800.

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

[by Anonymous Coward]

Mac OSX does not make use of the new x86 BNDOVR opcode, unlike Windows which is dependent on it.

Re:Intel Macs not affected?

[crayz (1056)]

It's funny that everyone is asking where the Apple patch is. How about: where's the Linux patch?

Linux may not be affected

[laing (303349)]

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.

Re:Intel Macs not affected?

[Fweeky (41046)]

3) The on-board reality distortion field generator resolves the problem. At the expense of making nearby computers lacking such devices somewhat *less* reliable, of course.

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:Ooops, I'm the blind one

[afaik_ianal (918433)]

Given the level of secrecy that Intel and Microsoft are giving to the nature of the bug, I still think that DRM is the true culprit.

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

[ocbwilg (259828)]

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 [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.

Microcode

[bblount (976092)]

This patch affects the microcode, which are the underlying machine instructions: http://en.wikipedia.org/wiki/Microcode [wikipedia.org]

How could this not affect Intel Macs? They use the same machine instructions that everyone else does!

Re:flash the CPU Microcode - YIKES!

[andreyw (798182)]

Uh, read the fine documentation. Microcode updates don't survice power-off. Nevermind that the microcode is a blackbox format, dependent on the chip and likely with a bajillion signatures the silicon checks.

Re:flash the CPU Microcode - YIKES!

[GauteL (29207)]

"so what if it doesn't survive a boot, just reprogram it with your hacked code every boot"

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.

It is quite common for some instructions

[EmbeddedJanitor (597831)]

There are a whole set of instructions to do with cache handling and other OS-centric things that will often be used differently on diferent OSs and it could be one of these. This sort of bug would only manifest itself in certain OSs and in certain ways.

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

[be-fan (61476)]

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.

Re:This is a possibility

[be-fan (61476)]

. 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.

Oh come on, it's nothing

[by Anonymous Coward]

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 ?

ah, time to dig up the bluewave tagline file...

[jollyreaper (513215)]

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.

Re:ah, time to dig up the bluewave tagline file...

[minion (162631)]

Man, it was just last week I finally decided to clear out all pre-95 taglines from my BlueWave ONELINER.TXT file. Doh!
 
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:Ugh, I hated that bug.

[Wavicle (181176)]

Oh did you?

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:

Bear in mind, however, that the likelihood is 1000 to 1000000 times
greater that any erroneous results obtained on a Pentium are due to
software errors, rather than any error in the CPU.

and also:

Over a period of five years, no person was ever able to collect a
reward offered for exhibiting (other than with a code artificially
contrived to demonstrate the error), on either of two workplace
systems intentionally left with flawed CPUs installed, an error
caused by the flaw.

Some more details

[macemoneta (154740)]

I had submitted some additional details in a rejected submission:

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

[ibentmywookie (819547)]

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

[SpaceLifeForm (228190)]

From an exploit point of view, this is better than a buffer overflow. Load some data page with some magic, force the bug to occur. Lots of fun.

CPU's are Emulators

[Effugas (2378)]

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.

Slashdot readers and microcode

[mrsteveman1 (1010381)]

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.

Asleep at the wheel

[edwardpickman (965122)]

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.

Re:Asleep at the wheel

[Beardo the Bearded (321478)]

It's how you Karma Whore. Observe:

This is a serious problem for Java and .NET as well, since both of those virtual machines have to translate this incorrect opcode into the correct functionality.

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.ht ml [intel.com]

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.

Errata

[oglueck (235089)]

Intel has released an errata document [intel.com].
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

[tlhIngan (30335)]

It's hard to get the errata for intel's processors when your a post SI test engineer, working for intel. Marketing seems to keep a tight fist on bad news.

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....

[by Anonymous Coward]

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.

Re:Dell told me "Windows only"

[whoever57 (658626)]

That's because Dell is pretty much only "Windows only". Why should they care about anything else?

You do know that Dell offers Red Hat Linux on most if not all servers, don't you?

Re:Heh

[be-fan (61476)]

Everybody publishes errata. AMD's are at: http://www.amd.com/us-en/assets/content_type/white _papers_and_tech_docs/25759.pdf [amd.com] (starting on page 12)

Re:Heh

[Tyger (126248)]

You can download the software developers manual for Intel's line of processors [intel.com], 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!