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

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.

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: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: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?

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

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.

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.

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)]

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

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.

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.