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.

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

[Jah-Wren Ryel]

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.

flash the CPU Microcode - YIKES!

[mosel-saar-ruwer]

Uhh, you can flash the CPU Microcode from within a Microsoft OS?!? [Other than DOS?!?]

Wouldn't this pose like the Mother of All Possible Challenges to the Black Hat community - how to right a worm that could flash CPU's, thereby rendering nearly limitless power over every possible sandboxing or anti-virus countermeasure?

Kinda the Helen of Troy [or Anne Boleyn [sho.com]] of Hax0r/Crax0r Wet Dreams?

Seriously - how can you hope to maintain the illusion of Virtual Machines if you can write to the microcode?

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.

Re:my 1.9432534656 cents worth...

[jd]

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

[suv4x4]

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

Question is, how come you patch microcode hardware flaw with a software patch - is this affecting performance? Possibly.

About the Macs not being affected: that was funny. Given how secretive the MS/Intel patches are, and we know Apple is totally open about stuff like that, right?

Re:Intel Macs not affected?

[be-fan]

Since microcode isn't hardware, fixing it shouldn't require any changes to the hardware.

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.

Re:Intel Macs not affected?

[crayz]

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

Re:flash the CPU Microcode - YIKES!

[timmarhy]

1. blackbox does not make it saver 2. so what if it doesn't survive a boot, just reprogram it with your hacked code every boot

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

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.

yes, but...

[r00t]

Normally a microcode update is flashed into the motherboard with a BIOS update. That is damn close to being the same thing. Not too many people upgrade their BIOS, and fewer still would consider downgrading. Not too many people replace motherboards separately from CPUs, especially these days with a new CPU socket shape being invented every other day.

Re:In Soviet Russia ...

[cowbutt]

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

[Anonymous Coward]

Feed the microcode file to the Linux microcode update driver and be happy!

Re:flash the CPU Microcode - YIKES!

[GauteL]

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

That can't be right.

[goombah99]

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

[Joe U]

Intel has a microcode update architecture. Basically, you can patch the CPU microcode into RAM on the CPU. It's been around since the Pentium bug that caused a recall.

Re:Intel Macs not affected?

[yppiz]

jd [slashdot.org] writes, in the parent post [slashdot.org], "PGCC was rejected utterly by the GCC developers ... it typically produced greatly superior code for Intel-specific processors."

I really wish gcc developers would choose performance over, well, whatever it is that they went for here.

Two years ago, I compared C compilers for the AMD64 using the stream benchmark (I was developing an application that had similar performance characteristics to stream). The compiled code that gcc generated was, if I remember correctly, 30% slower than code generated by two closed-source compilers. In looking at the assembly, the chief difference was that the closed-source compilers were aware of the AMD64 series caches, and generated code that would disable or enable the caches as appropriate, resulting in much higher write speeds. gcc's code, on the other hand, appeared to be entirely unaware of the AMD64's capabilities, even with AMD64-specific command line flags enabled.

If anyone in the gcc community is working on an Intel or AMD64-oriented performance fork, I would love to hear about it.