Legit Reviews

I think Intel is doing ok to show the public its vulnerabilities. Theo tears them up quite a bit in the following diatribe, and there are some neat / useful links for those of use with Core 2 / Conroe CPUs.

I think my X6800 is the best CPU I've ever used - its certainly the fastest.

List: openbsd-misc
Subject: Intel Core 2
From: Theo de Raadt <deraadt () cvs ! openbsd ! org>
Date: 2007-06-27 17:08:16
Message-ID: 200706271708.l5RH8GkK024621 () cvs ! openbsd ! org [Download message RAW]

Various developers are busy implementing 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/proces ... 327914.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/200 ... 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).

And this is what Linus Torvalds said about it:

Name: Linus Torvalds ([email protected]) 6/27/07

Matt Sayler ([email protected]) on 6/27/07 wrote:
>
>How significant were the TLB handling changes?

I'd say: "Totally insignificant".

The biggest problem is that Intel should just have
documented the TLB behavior better. The Core 2 changes
are kind of gray area, and the old documentation simply
didn't talk about the higher-level page table structures
and the caching rules for them.

So that part is just a good clarification, and while it
could be called a "bug" just because older CPU's didn't
do that caching, I don't think it's an errata per se.

Of course, if you depended on it not happening (and a
lot of people did), it's painful. But it really does make
the architecture definition better and clearer.

(I don't think Linux needed any software changes at all for
the TLB semantics clarification, although that was largely
just due to luck - we had mis-used the TLB earlier, and
fixing that software bug we rewrote the page table handling
to be more robust, which means that the spec update from
Intel didn't affect us at all, afaik).

>In general, do Core2 chips seem to be more or less buggy
>than previous iterations? Are errata par for the course
>as we approach billion-transistor commodity MPUs?

Pretty much all CPU's have always had errata, and the
commodity CPU's usually have much fewer of them than the
boutique ones.

So this has nothing to do with billion-transistor MPU's,
or about commodity. CPU's always have bugs. And embedded
(or vendor-specific) CPU's tend to actually have more of
them, since they are often easier to work around by just
saying "don't do that, then".

So Intel and AMD actually tend to fix the bugs a lot more
aggressively than you'd see for some single-vendor thing,
simply because they don't control the stack the way other
architectures generally do.

I'd expect other CPU's to generally have more errata
than most commodity x86 chips.

Linus

Source: http://www.realworldtech.com/forums/ind ... 4&roomid=2

I cant see the big companies using Cloverton & Kentsfield chips if there was major problems with the C2D architecture! They get alot more info from Intel regarding errata than the public does. Intel have been totally upfront about their errata, and this one is actually old news! Most large vendors already have Bios updates out.

Me thinks Theo de Raadt is an AMD fanboy

kenc51 wrote:Me thinks Theo de Raadt is an AMD fanboy

Yeah, I think he is talking out of turn here. He know quite a bit about porting to various archs, and about OS design, but to insinuate that Core 2 /Conroe / Woodcrest is somehow inferior to (alpha/arm/hppa/m68k/mips/powerpc/ppc64/sh3/sparc/sparc64) in terms of bugs is ludicrous. As Torvalds said, errata is on all ASICs/CPUs, Intel happens to be more forthcoming about it, thats a good thing.

Being an AMD fanboi right now must hurt. Don't get me wrong, AMD's (well actually Digital's EV7 bug) Hypertransport is really great, and a nice scalable bus arch w/ NUMA, and I like AMD, but for a home/gaming/encoding box right now, give me a break - Conroe/Woodcrest blows it away Check out spec.org's CPU2006 for how much whoop-ass Conroe busts out.

I compile Xilinx FPGAs - and let me tell you map/par runs much faster on woodcrest than on the opteron gear right now.

All this being said, I laugh a bit when I think of OpenBSD's inferior SMP and performance in general, and he is getting esoteric about hardware features he doesn't even know how to utilize yet so he complains.

mickrussom wrote:

kenc51 wrote:Me thinks Theo de Raadt is an AMD fanboy

Yeah, I think he is talking out of turn here. He know quite a bit about porting to various archs, and about OS design, but to insinuate that Core 2 /Conroe / Woodcrest is somehow inferior to (alpha/arm/hppa/m68k/mips/powerpc/ppc64/sh3/sparc/sparc64) in terms of bugs is ludicrous. As Torvalds said, errata is on all ASICs/CPUs, Intel happens to be more forthcoming about it, thats a good thing.

Being an AMD fanboi right now must hurt. Don't get me wrong, AMD's (well actually Digital's EV7 bug) Hypertransport is really great, and a nice scalable bus arch w/ NUMA, and I like AMD, but for a home/gaming/encoding box right now, give me a break - Conroe/Woodcrest blows it away Check out spec.org's CPU2006 for how much whoop-ass Conroe busts out.

I compile Xilinx FPGAs - and let me tell you map/par runs much faster on woodcrest than on the opteron gear right now.

All this being said, I laugh a bit when I think of OpenBSD's inferior SMP and performance in general, and he is getting esoteric about hardware features he doesn't even know how to utilize yet so he complains.

LOL
Id also love to see how many MAJOR changes were made to the original BSD. I doubt theres many, prolly only what was essential, they only added support for Linux programs a while back..........Sure the BSDs are good for one thing and one thing only, be it a file server, firewall or web server. Try running multiple servers on the one box

Someone is bound to post here and say its stable and secure! But what good is that when its limited to what it can do?
Linux FTW even with all its problems, it still works. Ive ran a linux box with dozens of servers/cron jobs going and it was still able to work well as a workstation at the same time!

kenc51 wrote:Linux FTW even with all its problems, it still works.

I think the whole BSD is dying troll is becoming truth. Embedded applications are going from VXworks to embedded Linux, and the cost of resisting Linux is too high to be practical. I see it every day in the software as a hardware appliance market. Cisco apparently switched to a Linux kernel for PIX / ASA OS 8.0 .

As much as I like BSD, its coherent userland/libraries/compiler/kernel, its becoming a bit of a liability. Just the other day, I discovered the FreeBSD 6.2 (-p5) wont dump to the swap when SMP is turned on on both an Intel and AMD box. Posting to the right places hasn't gotten me any answers. Frustrating. And the equivalent of lm_sensors on FreeBSD (mbmon and healthd) suck. Oh, and UFS+S sucks when compared to EXT3/XFS and ZFS. It will take forever to get rid of UFS+S. Also, Vinum and volume management in FreeBSD is very poor right now.

Now with OpenBSD, I think the main reasons that they are good are PF and OpenSSH, but would I expect any performance from a Core2/Conroe dual core there? No. Apparently *BSD, and particularly OpenBSD target for good performance on a Pentium 133 machine with 1 CPU.

To be fair, OpenBSD writes a lot of drivers for various things, and gleans stuff out of NetBSD, but its arcane.

If NetBSD, OpenBSD and FreeBSD were to co-ordinate and work together, then the sum total of the three might be interesting but at this point, save maybe FreeBSD, they are university projects.