From an OpenBSD mailing list:

From View message header detail Theo de Raadt

Sent Wednesday, June 27, 2007 10:08 am

To misc@cvs.openbsd.org

Cc

Bcc

Subject Intel Core 2

Various developers are busy implimenting workarounds for serious bugs

in Intel's Core 2 cpu.

These processors are buggy as hell, and some of these bugs don't just

cause development/debugging problems, but will *ASSUREDLY* be

exploitable from userland code.

As is typical, BIOS vendors will be very late providing workarounds /

fixes for these processors bugs. Some bugs are unfixable and cannot

be worked around. Intel only provides detailed fixes to BIOS vendors

and large operating system groups. Open Source operating systems are

largely left in the cold.

Full (current) errata from Intel:

http://download.intel.com/design/processor/specupdt/31327914.pdf

- We bet there are many more errata not yet announced -- every month

this file gets larger.

- Intel understates the impact of these erraata very significantly.

Almost all operating systems will run into these bugs.

- Basically the MMU simply does not operate as specified/implimented

in previous generations of x86 hardware. It is not just buggy, but

Intel has gone further and defined "new ways to handle page tables"

(see page 58).

- Some of these bugs are along the lines of "buffer overflow"; where

a write-protect or non-execute bit for a page table entry is ignored.

Others are floating point instruction non-coherencies, or memory

corruptions -- outside of the range of permitted writing for the

process -- running common instruction sequences.

- All of this is just unbelievable to many of us.

An easier summary document for some people to read:

http://www.geek.com/images/geeknews/2006Jan/core_duo_errata__2006_01_21__full.gif

Note that some errata like AI65, AI79, AI43, AI39, AI90, AI99 scare

the hell out of us. Some of these are things that cannot be fixed in

running code, and some are things that every operating system will do

until about mid-2008, because that is how the MMU has always been

managed on all generations of Intel/AMD/whoeverelse hardware. Now

Intel is telling people to manage the MMU's TLB flushes in a new and

different way. Yet even if we do so, some of the errata listed are

unaffected by doing so.

As I said before, hiding in this list are 20-30 bugs that cannot be

worked around by operating systems, and will be potentially

exploitable. I would bet a lot of money that at least 2-3 of them

are.

For instance, AI90 is exploitable on some operating systems (but not

OpenBSD running default binaries).

At this time, I cannot recommend purchase of any machines based on the

Intel Core 2 until these issues are dealt with (which I suspect will

take more than a year). Intel must be come more transparent.

(While here, I would like to say that AMD is becoming less helpful day

by day towards open source operating systems too, perhaps because

their serious errata lists are growing rapidly too).

I tried to download the M$oft update for 32-bit Windows XP Pro. They wanted several levels of validation, and also required that I permanently install a "GenuineAdvantage" code module. Turns out, my copy of XP is a "volume key" product. Upgrades are not permitted. I must pay approx US$145 in order to obtain a new key with upgrade potential from M$oft. In other words, as a Windows user, I cannot repair my Intel bug without first sending-off US$145 to M$oft. BTW, shouldn't this be considered a "material & workmanship" issue? Shouldn't Intel be req'd to pay M$oft for the corrective work? Where are the accursed class-action attys when I really need one? Keep a weather eye open for my Core Duo motherboard and processor on Ebay. I've just decided to replace my system with a dual Opteron box. Running Red Hat.

So your complaining cos u cant update your dodgey copy of XP to fix a problem that isn't even effecting u ? U have lost the plot mate. And people who write microsoft with a $ are sad. U dont even have to down load the patch from microsoft. Good luck with Red Hat.

...I just put my new PC together and have been having pretty random problems with it. Random restarts and lockups were happening every half hour and errors in the event log seemed to indicate that it was a problem with page files. Interesting when something like this comes along just as you were scratching your head as to what was going on.

My mobo will be an intel let them patch it

I will then use it the same as always if they do

it's a little silly to worry about these things in

advance they simply have to be fixed download

the latest bios and flash it to bios chip my current

computer has had six revisions I never paid for any

of them but I got them just the same. No it's never

easy for the kernel guys to work around all the

stupid errata but they will anyway.

Explains my random issues. Couldn't figure out why my vista box would not shutdown after some specific assembler code I worked on (involving a lot of "official" cpu code, page swaps and dma). I even loaded up fedora and it'd cause lovely spinlocks (just as annoying as a vista lockup, less that CPU)

Most of the time, it only effects 64 bit oses, because the PIII's extended microcode is what causes the bugs. If your os always align all memory access (linux and windows compilers do that by default), then the page and cache coherency problems won't be a real problem. The fpu should be left untouched in 64 bit mode or it's state saved by hand, this is why the new windows vista just dropped support for it altogether, but in linux it might be a problem. The third group of problems come from the msr/debug register/performance counter range which only disturbs those who want to actually debug something on the system, not those who just run the software.

Btw, it would be better to just turn off all the damaged subsystems and sell these cpus as normal 32 bit only core 2 duo-s where most of the problems would never surface. Fortunately, the rest of the intel cpus are not effected and users running the 32 bit versions of their os of choice won't see much difference at all. (for these cpus, it's better to stick to using winxp with no more than 2Gb of ram and the problems just disappear)

Microsoft are not offering a "BIOS Update" on their site. This implies that the file Microsoft use, permenently alters your machine's BIOS.

Microsoft Microcode updates patch the microcode at runtime, the patch is cleared at power off, and reapplied at system power up.

You would have thought a tech site would know this.. I Expect this level of misinformation at the Inquirer, but not here..

i thort my computer was overheating when it was left at full load for a few minutes and randomly restarting, now i think it could be this problem. i have an e6750 engineering sample and there must be a reason as to why intel havent gone into full production with them. other than that my comp goes like stink its a c2d at 3.3ghz with an fsb of 1650mhz, 3gigs of 1ghz mem, two 8800 gts in sli all in an asus striker extreme :) not bad for someone who doesnt have a job lol

Clock down the processor by .001 Ghz. Been reading plenty on the OC community and for some wonderful reason, Core 2's don't like even numbers. My E6420 runs at 3.199Ghz in most cases. However, from what others here have been saying, if you're running a 64bit OS, than go get it. It's explaining the random but not unrecoverable exception errors I've been running into running x64.

I am from Intel, and I thought I would give you our perspective. Months ago, we addressed a processor issue by providing a BIOS update for our customers that in no way affects system performance. We publicly documented this as an erratum in April. All processors from all companies have errata, and Intel has a well-known errata communication process to inform our customers and the public. Keep in mind the probability of encountering this issue is low. Specification Updates for the affected processors are available at http://developer.intel.com. We feel we’ve resolved the issue and were open about it with customers and then publicly publishing it, but this is a good venue for ideas on how we could do better or more. I am interested in any constructive comments...