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.

Comments

Microcode

[bblount]

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!

Some more details

[macemoneta]

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

Re:Some more details

[ibentmywookie]

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.

Re:Intel secrecy

[tlhIngan]

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

[account_deleted]

Comment removed based on user account deletion

It is quite common for some instructions

[EmbeddedJanitor]

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

[MikeBabcock]

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.

CPU's are Emulators

[Effugas]

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.

Re:my 1.9432534656 cents worth...

[mrsteveman1]

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:This is a possibility

[be-fan]

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

correct

[r00t]

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]

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

[Tyger]

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!

Re:Ugh, I hated that bug.

[Wavicle]

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.

Re:Patch for Linux... when?

[cowbutt]

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

[someone300]

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.