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

my 1.9432534656 cents worth...

[ross.w]

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

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:my 1.9432534656 cents worth...

[Poltras]

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?

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

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.

Re:Intel Macs not affected?

[Kingrames]

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

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.

Re:Intel Macs not affected?

[jd]

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.

Re:Intel Macs not affected?

[Fweeky]

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

Re:Intel Macs not affected?

[m.dillon]

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

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!

Oh come on, it's nothing

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

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.

Why Mac OSX not affected

[Anonymous Coward]

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

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:Some more details

[SpaceLifeForm]

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.

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

Re:flash the CPU Microcode - YIKES!

[andreyw]

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]

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.

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.

Slashdot readers and microcode

[mrsteveman1]

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.

Sir, you will no doubt be shocked to learn....

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

Asleep at the wheel

[edwardpickman]

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]

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

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.

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

[afaik_ianal]

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