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.

Is it a patch for DRM?

[Anonymous Coward]

Smells like Digital Rights Management to me.
You never know given the vague wording of the patch.

Linux may not be affected

[laing]

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?

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

microcode update buggy for real-time applications

[Anonymous Coward]

BEWARE: There is a bug in this microcode update that causes problems in some realtime video and audio applications, for instance, Pro Tools [digidesign.com].

At least, HP's new BIOS have this issue. Caused a major headache tracking this one down. Has something to do with erratic time values being returned when calls are made at high resolutions (for instance near 30 milliseconds...)

Waxing nostalgic

[Enderandrew]

Intel was just waxing nostalgic and wanted to remember the good only days.

http://en.wikipedia.org/wiki/Pentium_FDIV_bug [wikipedia.org]

Re:Heh

[Technician]

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.

Is everyone here blind?

[pallmall1]

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

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.

Blah - Old News

[FuegoFuerte]

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:

http://h20000.www2.hp.com/bizsupport/TechSupport/D ocument.jsp?objectID=c01038053 [hp.com]

Dell released an update for PE2950 servers around the same time.

So again I say, Blah.

*YAWN*

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