Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Flaws In Intel Processors Quietly Patched

kdawson posted about 7 years ago | from the probably-broke-drm dept.

Intel 311

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.

cancel ×

311 comments

my 1.9432534656 cents worth... (5, Funny)

ross.w (87751) | about 7 years ago | (#19658603)

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

Re:my 1.9432534656 cents worth... (2, Insightful)

Jah-Wren Ryel (80510) | about 7 years ago | (#19658807)

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.

Re:my 1.9432534656 cents worth... (0, Troll)

SpaceLifeForm (228190) | about 7 years ago | (#19659243)

You mean, in the next tuesday windows update. So, Microsoft is now providing BIOS upgrades instead of the motherboard manufacturer.

Is there anyone out there that trusts this process?

No thanks, but I'll not even put GNU/Linux on a machine with a motherboard that has been raped right up the BIOS.

Re:my 1.9432534656 cents worth... (0)

Anonymous Coward | about 7 years ago | (#19658809)

Today I read news of this patch on Slashdot, The Inquirer, The Register, and Digg.
LOL @Very Quiet. Not a single computer enthusiast will know about its existence.

Re:my 1.9432534656 cents worth... (3, Insightful)

jd (1658) | about 7 years ago | (#19658933)

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:my 1.9432534656 cents worth... (4, Informative)

mrsteveman1 (1010381) | about 7 years ago | (#19659035)

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.

Heh (0)

Anonymous Coward | about 7 years ago | (#19658629)

Debian AMD64: Check. AMD X2: Check. Clear

Re:Heh (1)

Technician (215283) | about 7 years ago | (#19659009)

Debian AMD64: Check. AMD X2: Check. Clear

Last time I heard, Intel publishes errata sheets unlike many other suppliers. Microsoft may have a fix or patch simply becasue the data is known and published.

With your chips, do you prefer open or closed?

The advantage is bugs can be fixed.

Here is a forum on Conroe errata.

http://www.abxzone.com/forums/general-intel-platfo rm-discussions/105033-intels-conroe-has-67-errata- bugs.html [abxzone.com]

Does AMD publish this?

Re:Heh (3, Informative)

be-fan (61476) | about 7 years ago | (#19659051)

Everybody publishes errata. AMD's are at: http://www.amd.com/us-en/assets/content_type/white _papers_and_tech_docs/25759.pdf [amd.com] (starting on page 12)

Re:Heh (2, Interesting)

Technician (215283) | about 7 years ago | (#19659123)

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.

Intel Macs not affected? (5, Insightful)

Anonymous Coward | about 7 years ago | (#19658631)

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? (3, Funny)

Anonymous Coward | about 7 years ago | (#19658661)

Something to do with the unicorn semen and pink elephant droppings.

Re:Intel Macs not affected? (0)

Anonymous Coward | about 7 years ago | (#19659019)

That gave me a big laugh :-)

However, How would I apply the patch if I run linux? :-)
If the patch is released via Windows Update, how will I get the patch? Seems weird.

Re:Intel Macs not affected? (4, Insightful)

shird (566377) | about 7 years ago | (#19658663)

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? (0)

Anonymous Coward | about 7 years ago | (#19658707)

After R'ingTFA I noticed its a microcode update, so probably not a OS workaround. But it could still be that MacOS doesn't trigger the bug.

Re:Intel Macs not affected? (4, Interesting)

jd (1658) | about 7 years ago | (#19658991)

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? (-1, Troll)

Anonymous Coward | about 7 years ago | (#19658767)

No shit sherlock. A software patch cannot (physically) alter the hardware so it _has_ to be a workaround in the OS.

Re:Intel Macs not affected? (4, Informative)

Bottlemaster (449635) | about 7 years ago | (#19658849)

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? (0)

Anonymous Coward | about 7 years ago | (#19658947)

they can have their microcode updated, but only with a dedicated bridged-bus eeprom burner ($15,000 or so).

Re:Intel Macs not affected? (1)

cpotoso (606303) | about 7 years ago | (#19658959)

I do not think you're right: when I boot linux (an old RH8) I see a part of the boot message saying "applying microcode patch" (or something like that).

Re:Intel Macs not affected? (4, Informative)

MikeBabcock (65886) | about 7 years ago | (#19658961)

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? (1)

X0563511 (793323) | about 7 years ago | (#19659015)

Yes but you are not changing anything in hardware...

Re:Intel Macs not affected? (2, Insightful)

be-fan (61476) | about 7 years ago | (#19659083)

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

Re:Intel Macs not affected? (0)

Anonymous Coward | about 7 years ago | (#19659237)

It's a fucking JOKE - DUMBASS.

Remember when you wanted to upgrade your mac and all you could do is throw it out and replace it? Or were you too busy being serious at ITT and pretending that they were teaching something important?

Linux users too... (1)

EmbeddedJanitor (597831) | about 7 years ago | (#19658671)

If it is a MS patch how will it fix an OS-independent CPU bug?

Linux may not be affected (3, Interesting)

laing (303349) | about 7 years ago | (#19658885)

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:Linux may not be affected (1)

kestasjk (933987) | about 7 years ago | (#19659151)

It speaks badly about GCC's reluctance to use MMX/SSE instructions.

Re:Intel Macs not affected? (1)

jmv (93421) | about 7 years ago | (#19658677)

If they really are not affected (remains to be seen), it could possibly be either because 1) Apple shipped with a batch that isn't affected or 2) OS X isn't doing things that can trigger the bug.

Re:Intel Macs not affected? (1)

RuBLed (995686) | about 7 years ago | (#19658681)

Either that or Apple has released theirs more quietly...

Re:Intel Macs not affected? (1)

JimDaGeek (983925) | about 7 years ago | (#19658979)

Maybe... I recently got an Apple update that took Tiger from 10.4.9 to 10.4.10 on my Intel Macbook and Intel iMac. Maybe this release had the patch?

Re:Intel Macs not affected? (4, Funny)

Kingrames (858416) | about 7 years ago | (#19658693)

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

Re:Intel Macs not affected? (1, Funny)

Anonymous Coward | about 7 years ago | (#19658699)

Macs are primarily for decoration. No one actually uses them for computing.

Re:Intel Macs not affected? (1)

syzler (748241) | about 7 years ago | (#19658745)

What, magical pixie faries fixed the Intels in Macs? How could they not be affected?

The bug may be limited to systems that use BIOS which would mean that systems that use EFI would not be vulnerable. This would explain why Intel Macs, which use EFI, are not vulnerable.

From the article:

In the mobile world, people with the Core 2 Duo T5000 and T7000 need to visit Microsoft's site, while the server guys will want to use motherboard BIOSes if they do not rely on Microsoft Windows operating systems.

Why Mac OSX not affected (5, Funny)

Anonymous Coward | about 7 years ago | (#19658753)

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

Re:Intel Macs not affected? (1)

R.Mo_Robert (737913) | about 7 years ago | (#19658799)

Well, it only affects two models of the Core 2 Duos, which is the only processor that Apple uses for all its Intel Macs except the Xserve (Xeon) and the Mac mini (first-generation Core Duo, which is not affected). So, assuming Apple didn't use either the E4000 or the E6000 Core 2 Duo processors, that would explain why they are not affected.

However, I do think the situation is interesting when we look at the Xserve, since they use Xeons. The article notes several affected models of them, which it says is just about every model ever made in the second-generation of Core processors. That kinda makes you wonder.

But if this issue is so easily fixed with a software patch ... whose fault was it? (Apple also recently released a security update, but I don't think that had anything to do with this, since they seemed to be just Webcore/Webkit issues and it was issued for both PowerPC and Intel.)

Re:Intel Macs not affected? (1)

Penguin Follower (576525) | about 7 years ago | (#19658899)

Well, it only affects two models of the Core 2 Duos, which is the only processor that Apple uses for all its Intel Macs except the Xserve (Xeon) and the Mac mini (first-generation Core Duo, which is not affected).

Well, I am sure I won't be the only person to point this out, but Apple does not use the Core 2 Duos in the MacPro towers, either. They use Xeons.

Re:Intel Macs not affected? (1)

DaveWick79 (939388) | about 7 years ago | (#19658919)

The article is stupid because it's the Inquirer, but they mean the Entire E4000 and E6000 series. What they really mean to say is that every single Core 2 Duo processor is affected.

It Just Works (1)

sssssss27 (1117705) | about 7 years ago | (#19659037)

Haven't you seen the commercials? It just works don't ask questions.

Of course they are not affected (0, Funny)

Anonymous Coward | about 7 years ago | (#19659063)

If they were, it would be called the iPatch.

Re:Intel Macs not affected? (3, Insightful)

crayz (1056) | about 7 years ago | (#19659159)

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

Is everyone here blind? (2, Interesting)

pallmall1 (882819) | about 7 years ago | (#19659299)

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

Intel secrecy (1)

jimmydevice (699057) | about 7 years ago | (#19658637)

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.

Re:Intel secrecy (4, Informative)

tlhIngan (30335) | about 7 years ago | (#19658813)

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.... (5, Funny)

Anonymous Coward | about 7 years ago | (#19659111)

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.

Is it a patch for DRM? (1, Interesting)

Anonymous Coward | about 7 years ago | (#19658647)

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

Microcode (5, Informative)

bblount (976092) | about 7 years ago | (#19658679)

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!

This is a possibility (1)

EmbeddedJanitor (597831) | about 7 years ago | (#19658697)

Microcode bugs will only bite you if you execute certain instruction sequences that trigger them.

Perhaps this only happens on MS and not on Macs.

Re:This is a possibility (1)

bblount (976092) | about 7 years ago | (#19658719)

You are certinaly correct in that, but it seems quite unlikely that there are instructions that no other OS is taking advantage of.

Re:This is a possibility (0)

Anonymous Coward | about 7 years ago | (#19658791)

its not a single instruction. Its an instruction _sequence_

It is quite common for some instructions (4, Informative)

EmbeddedJanitor (597831) | about 7 years ago | (#19658905)

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 (1)

larry bagina (561269) | about 7 years ago | (#19659003)

many of the old krufty 8086 era CISC instructions are implemented in microcode. Modern compilers won't generate them, but windows still supports 16-bit DOS programs that may use them. Heck, windows still has 16-bit compatibility code. OS X (and linux, freebsd, solaris, etc) are modern, 32 bit clean, so they aren't affected.

Re:This is a possibility (0)

Anonymous Coward | about 7 years ago | (#19659045)

Except that the 64 bit versions of the various MS operating systems removed the 16-bit compatibility code. So if the problem was 16 bit apps, the x64 OSes wouldn't need it.

I suspect the problem affects Macs as well; it is known to affect Linux as well as MS, so I doubt Macs are immune. But who knows, maybe Apple pushed out the patch themselves as part of a larger update a while ago. This microcode problem has been known and fixed in the BIOS for many machines since early April; given Apple's control of the hardware they may have
A) Done a BIOS update during a patch push
B) Had the OS perform the microcode update on each boot

Re:This is a possibility (3, Informative)

be-fan (61476) | about 7 years ago | (#19659113)

It's actually quite likely. CPU errata tend to effect corner cases. Eg: CPU returns wrong data if you read from an I/O port while servicing a TLB miss (or something like that). These bugs tend to be highly timing and sequence dependent, and its very likely that no two OSs use exactly the same sequence that triggers the bug.

Re:This is a possibility (1)

jmitchel!jmitchel.co (254506) | about 7 years ago | (#19658733)

Then again, maybe Apple just hasn't released a patch for this yet. Dell calls this an URGENT update for the BIOS. Good bet that both MacOS and Linux are actually affected.

Re:This is a possibility (0)

Anonymous Coward | about 7 years ago | (#19658835)

Hmm.. seems like people have a vague idea of what's going on, but the bottom line is that if a processor has a bug in its microcode, it will affect users on every OS, probably most or all of them. The codebase of modern operating systems and their associated userlands is far too vast to assume that *any* microcode will not be exercised. However, any _compiler_ worth its salt will try to use every bit of microcode it can to optimize for a given architecture or microarchitecture, so you can bet your ass that someone (more likely thousands of someones) have written programs which will trigger this bug (or whatever you want to call the defect that triggered this patch). All that said, the chances of this being more of a showstopper than even the relatively minor FDIV bug are remote, at best. This is due to a multitude of factors; Intel's newfound paranoia in verifying their chips through simulation, formal methods, and emulation, the number of users who seem to be coasting along just fine on all these processors, etc..

Re:This is a possibility (4, Informative)

be-fan (61476) | about 7 years ago | (#19659137)

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

flash the CPU Microcode - YIKES! (2, Insightful)

mosel-saar-ruwer (732341) | about 7 years ago | (#19658827)


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! (0)

Anonymous Coward | about 7 years ago | (#19658893)

It's not so much flashing... and it would be pointless to do it from DOS. Microcode updates don't persist between boots. The patch would have to be applied on start-up every time.

That said, I don't know the security implications. It would be a little unnerving if one could punch through a VM that way.

Re:flash the CPU Microcode - YIKES! (4, Insightful)

andreyw (798182) | about 7 years ago | (#19658901)

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:flash the CPU Microcode - YIKES! (2, Insightful)

timmarhy (659436) | about 7 years ago | (#19659183)

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

Re:Microcode (2, Insightful)

suv4x4 (956391) | about 7 years ago | (#19659007)

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:Microcode (0)

Anonymous Coward | about 7 years ago | (#19659017)

because they know that Macs aren't used for crunching numbers.

Oh come on, it's nothing (5, Funny)

Anonymous Coward | about 7 years ago | (#19658691)

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... (5, Funny)

jollyreaper (513215) | about 7 years ago | (#19658721)

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.

Ugh, I hated that bug. (-1, Troll)

CrazyJim1 (809850) | about 7 years ago | (#19658871)

I remember trying to make a MMORPG before UO came out, and I was using quick basic. Yes it is impossible to make a MMORPG in quick basic unless you have a hack to do winsock, yet it is possible to make a huge RPG because you can store info on the harddrive and use it like virtual memory :)

Anyway when you're new to coding, you don't like to see stuff like division errors. You get so trained to thinking the computer is right that you feel you screwed up. Anyway I created a hack to make the division come out right when I learned that the chip itself was flawed... I was also relieved because I thought I was coding wrong.

Re:ah, time to dig up the bluewave tagline file... (3, Funny)

minion (162631) | about 7 years ago | (#19658889)

Man, it was just last week I finally decided to clear out all pre-95 taglines from my BlueWave ONELINER.TXT file. Doh!
 
I do have these gems still though:
 
Win2k: "It's not so much that it's only 65,000 bugs, it's just that they stopped at 65,535 to prevent an overflow."
 
Sun believes the only place for 63,000 bugs is a rain forest.
 

Re:ah, time to dig up the bluewave tagline file... (1)

Enderandrew (866215) | about 7 years ago | (#19659071)

That takes me back.

"If Windows were an ice cream, it would be hoggin' dos!"

I miss my BBS'in days.

Some more details (5, Informative)

macemoneta (154740) | about 7 years ago | (#19658773)

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 (4, Informative)

ibentmywookie (819547) | about 7 years ago | (#19658935)

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 (4, Interesting)

SpaceLifeForm (228190) | about 7 years ago | (#19659367)

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

Kingrames (858416) | about 7 years ago | (#19658975)

"* A system operating in a Microsoft Windows environment may generate a blue screen."

So this is a "sky is blue" type of error then?

Re:Some more details (1)

Bacon Bits (926911) | about 7 years ago | (#19659199)

Yes, it looks like MS is releasing this to cover systems that aren't expected to get BIOS updates or to be used in lieu of a BIOS update.

Still seems odd to me, but the quietness of the issue doesn't encourage any suspicion for me.

MS often releases non-security and non-critical updates in a graduated manner:
First, you must call PSS to be able to download the patch. MS just wants to be sure the patch fixes the problem. You're a beta tester.
Next, they release the patch for public download. Affected users will find or be directed to the KB article and apply the update.
Finally, if enough people download the update, they release it to Windows Update for general download.

Most updates that make it to stage 2 are rolled into the next Service Pack, as are all the updates from the last stage.

More useful information on the update (possibly) (0)

Anonymous Coward | about 7 years ago | (#19658777)

There was a microcode update released as part of system BIOSes a couple months back; this may be a workaround for people who cannot or will not update their system BIOS.

The most complete information I could find was posted as part of HP's BIOS update: http://h20000.www2.hp.com/bizsupport/TechSupport/D ocument.jsp?objectID=c01020735&dimid=908755463&dic id=alr_apr07&jumpid=em_alerts/us/apr07/all/xbu/ema ilsubid/mrm/mcc/loc/rbu_category/alerts [hp.com]

Looks like the primary problem is system stability, though I suspect imaginative people could probably find a security vulnerability with the TLB.

Dell told me "Windows only" (1)

whoever57 (658626) | about 7 years ago | (#19658789)

My company was contacted by Dell about a month ago regarding our rack mount server that uses a 5100-series CPU. However, they told me it only affects Windows.

Re:Dell told me "Windows only" (1)

DaveWick79 (939388) | about 7 years ago | (#19658841)

That's because Dell is pretty much only "Windows only". Why should they care about anything else?

Re:Dell told me "Windows only" (3, Informative)

whoever57 (658626) | about 7 years ago | (#19658869)

That's because Dell is pretty much only "Windows only". Why should they care about anything else?
You do know that Dell offers Red Hat Linux on most if not all servers, don't you?

Re:Dell told me "Windows only" (1)

DaveWick79 (939388) | about 7 years ago | (#19658993)

You're right, I wasn't really thinking server. I was thinking more about the non-existent Linux 'support' they have on the workstation/desktop side. I've never had to contact server support for linux so I don't know how well or if they give a rat's arse about those customers.

Re:Dell told me "Windows only" (2, Informative)

ArbitraryConstant (763964) | about 7 years ago | (#19659057)

My dealings with Dell on the server side have been pretty satisfactory, even running Slackware or OpenBSD.

My only complaint is the satisfaction survey they send you after the issue is resolved (not kidding).

the next big thing in operating systems (1)

uepuejq (1095319) | about 7 years ago | (#19658823)

maybe they're working on testing a system for installing software to processors. why build a machine to do it when you can test it in theory on tons of free machines? maybe microsoft and intel are working on the next big shift in our software and processors. modern processors are gaining cores rapidly, why not have these cores programmed to execute specific operations?

Big freaking deal (0)

Anonymous Coward | about 7 years ago | (#19658833)

Microcode updates get released all the time. XP SP2 shipped with around 100 microcode patches for various processors, and that wasn't even all the updates available. The update driver had a limited catalog so only the most popular updates could be included. I don't know how many updates ship with Vista but there had to have been dozens more over the last few years.

quietly ... (1)

barra.ponto (879488) | about 7 years ago | (#19658851)

> has been quietly released...

One of the files in the update is called Update-bf.mum. That's why they're keeping it quiet :-)

Of course Apple users aren't affected... (0)

Anonymous Coward | about 7 years ago | (#19658859)

Because Macs don't have bugs.... ever.... ... ... ...
They have "error codes". 32767 to be exact.

Looks like an OS update (1)

DaveWick79 (939388) | about 7 years ago | (#19658887)

Patches distributed by Microsoft, for microsoft products. Seems like an MS problem rather than an Intel issue, which kind of makes the title of this article misleading.
However, this sounds very similar to the issue with Prescott CPU's and XP SP2, where an installation on a system with a CPU below stepping 8 would hard freeze on restart after the initial setup. In that case the fix was a BIOS update OR disabling L1 and L2 cache.

Re:Looks like an OS update (1)

ihavnoid (749312) | about 7 years ago | (#19659039)

Not exactly. They said it is a microcode update, which updates the processor, not the operating system.

The reason it only affects Microsoft Windows may be because only Windows triggers that processor bug, and other operating systems doesn't. Of course, there can be software workarounds (rewrite Windows to bypass the bug), but why rewrite code when Intel already released their 'patch' for their microprocessor?

FYI, 'microcode' is simple code (not x86, an internal format) that runs inside the processor. Normally, simple instructions gets translated into a single 'internal operation', but if the instruction is complex, the internal 'microcode engine' kicks in, and runs the microcode that mimics the instruction's behavior. What's amazing, is that a microcode fix can eliminate so many kind of bugs (sometimes, by disabling hardwired logic and replacing it with microcode).

Actually, Both Intel and AMD releases microcode updates frequently, fixing thousands of bugs even after product release.

PS : I don't work for any of the companies mentioned above, so details may vary.

Re:Looks like an OS update (1)

jorghis (1000092) | about 7 years ago | (#19659067)

I work at a company that makes operating systems. It is not uncommon for us to issue workarounds when hardware problems are found with processors. Just because MS is issuing a patch doesnt mean that it is their fault.

Re:Looks like an OS update (1)

DaveWick79 (939388) | about 7 years ago | (#19659323)

So apparently MS has a dll (or in XP's case, a .sys) file that has the capability of identifying a given processor and writing microcode updates to it. In one respect, I can see how this can be useful; on the other respect, if it ever got hacked we could be left with a whole lot of junk CPU's that couldn't be booted from.

Fixed for nVidia 680i with P28 BIOS (0)

Anonymous Coward | about 7 years ago | (#19658909)

Assuming this is the same microcode update that I think it is, anyone on a nVidia 680i motherboard who has kept up with the BIOS releases (namely, P28) has already fixed this.

Intel price cuts? (1)

sumdumass (711423) | about 7 years ago | (#19658931)

I would be interesting to find how long Intel knew about this and if it had anything to do with rushing to market to compete with AMD and their recent price cuts.

It's sort of chicken and eggish when talking hamburger, but is the defect because of the price cuts to compete or is the price cuts because of the flaw? Or is it totally unrelated with either and I'm just throwing balls at the side of the barn and missing?

I am wondering though, doe this mean I would have a CPU that doesn't do everything it was supposed to do before the patch and flaw was know? I mean does the patch limit the processor or screw with it's abilities in anyway other then stopping errors? I'm dieing to know.

May not affect Macs, or just not tested (3, Informative)

Gothmolly (148874) | about 7 years ago | (#19658995)

It might NOT affect Macs, because of the way the OSX kernel handles specific failures. Remember when the F00F bug came out, Linus himself quickly came up with a Linux patch that mapped it over to (IIRC) a page fault, which then was handled separately. DOS machines just died.

For this PARTICULAR microcode issue, OSX _may_ do something interesting with it, and so not be affected. Or, they simply never tested/validated it, and so Apple has no patch.

CPU's are Emulators (4, Informative)

Effugas (2378) | about 7 years ago | (#19659005)

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.

microcode update buggy for real-time applications (1, Interesting)

Anonymous Coward | about 7 years ago | (#19659077)

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

Slashdot readers and microcode (4, Insightful)

mrsteveman1 (1010381) | about 7 years ago | (#19659095)

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:Slashdot readers and microcode (2, Funny)

zakeria (1031430) | about 7 years ago | (#19659223)

second that; perhaps they just ignore anything that begins with micro----

Re:Slashdot readers and microcode (2, Informative)

DigiShaman (671371) | about 7 years ago | (#19659261)

Microcode is included with all modern BIOS updates. As such, when you update your BIOS revision, you might get a newer microcode update to included. This microcode get's loaded on POST (Power On Self Test).

As others have pointed out, it resides in RAM (or would that be CPU cache?). So the update must loaded each time you power on the system.

Quiet? (1)

frizz (91565) | about 7 years ago | (#19659281)

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.


News of this errata fix is posted on The Inquirer, in a Microsoft Knowledge Base article, and now Slashdot. I wouldn't call this "quietly released."

The reason MAC's are not effected... (0, Troll)

Tibor the Hun (143056) | about 7 years ago | (#19659283)

Is because they have such small user base, naturally. ;)

Asleep at the wheel (4, Insightful)

edwardpickman (965122) | about 7 years ago | (#19659285)

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 (0, Offtopic)

mrsteveman1 (1010381) | about 7 years ago | (#19659315)

I agree, a "-1 incorrect" mod is required at this point.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...