PDA

View Full Version : Theo de Raadt talks about some serious bugs in Intel Core 2


Frisch
07-04-2007, 03:00 AM
This is an article, first of all dealing with some serious bugs in Core 2, but it also applies to AMD's growing errata list.

Some words for AMD

(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 some words for Intel about 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.

SaFrOuT
07-04-2007, 03:05 AM
ouch

Shintai
07-04-2007, 03:09 AM
Theo is a nutcase. And nobody agrees with him.
He also completely misses the point that AMD and Intel CPUs are actually those with the least erratas. CPUs like sparc and Power got a massive amount more.

Theo actually says, that we cant buy any CPU, since all CPUs are faulty.

Linus also says: Totally insignificant.

And we already got this thread:
http://www.xtremesystems.org/forums/showthread.php?t=149421

Frisch
07-04-2007, 03:18 AM
Theo is a nutcase. And nobody agrees with him.
He also completely misses the point that AMD and Intel CPUs are actually those with the least erratas. CPUs like sparc and Power got a massive amount more.

Theo actually says, that we cant buy any CPU, since all CPUs are faulty.

Linus also says: Totally insignificant.

And we already got this thread:
http://www.xtremesystems.org/forums/showthread.php?t=149421

The point of a point of view, is to get a clearer picture of things.

And as such, Theo states some views, and thereby gets an answer like yours.

Shintai
07-04-2007, 03:20 AM
I trust this person abit more. And Theo was also one of the Hyperthreading exploit people. Yet there was none.
And note Theo´s little PR gimmick...OpenBSD is not affected with default binaries.

Name: Linus Torvalds (torvalds@osdl.org) 6/27/07

Matt Sayler (sayler@thewalrus.org) 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

nemrod
07-04-2007, 03:48 AM
http://www.dailytech.com/Linus+Torvalds+on+Core+2+Duo+Errata+Totally+Insign ificant/article7897.htm

saaya
07-04-2007, 09:58 AM
like there has ever been a bugfree cpu... :rolleyes:
if the latest cpus are so damn buggy how come nobody is having problems with them?

i think hes just making a lot of noise hoping to create some bad feedback which then makes intel and amd try to do more testing and work more closely with everybody to fix bugs. but its not gonna work...

Reznik Akime
07-04-2007, 01:53 PM
if the latest cpus are so damn buggy how come nobody is having problems with them?

I was pondering the exact same thing. The Core line seems to be burning arse without taking a second glance back, yet there are severe bugs in the design?

Where this true, I ponder how much faster they could potentially be where the bugs not there.

That is if they were even truly affecting performance.

BrowncoatGR
07-04-2007, 02:36 PM
Reznik noone said they were affecting performance just security.

Shintai
07-04-2007, 02:59 PM
Theo used to complain about a theoretical exploit using SMT on P4s that never turned out to do anything.

xsbb
07-05-2007, 06:40 AM
like there has ever been a bugfree cpu... :rolleyes:
if the latest cpus are so damn buggy how come nobody is having problems with them?

i think hes just making a lot of noise hoping to create some bad feedback which then makes intel and amd try to do more testing and work more closely with everybody to fix bugs. but its not gonna work...

well said

uOpt
07-05-2007, 11:16 AM
The core issue here is the MMU bugs. They look pretty ugly and as Theo correctly remarks we probably haven't seen all of it.

The MMU malfunctioning means that you get to see and manipulate memory regions that don't be long to you (e.g. the current process). It can leads to compromising kernel level pages or page belonging to important security programs such as login daemons. Even readonly access is bad since you can snatch private keys - which means snatch everything.

The big question is whether such MMU bugs are fixable by microcode at all. I wouldn't take that for granted at all. It is one thing to change the microcode for some obscure addressing mode for some normal userlevel instruction - which is translated by microcode into some arithmetic and a more basic addressing mode.

With the MMU I could easily imagine it is not drive by downloadable microcode at all. Since the x86 architecture has hardware page table walk you can't insert OS code to fix it up either (ignoring TLB hits here which I think as probably safe).

saaya
07-06-2007, 12:49 AM
doesnt this mean that trusted computing (read: locking out the owner of the pc from direct access to the hardware) can be compromised even when enabled?

hooray then! :D

uOpt
07-06-2007, 10:04 AM
doesnt this mean that trusted computing (read: locking out the owner of the pc from direct access to the hardware) can be compromised even when enabled?

hooray then! :D

No, the hard kinds of trusted computing involve encryption on a device level that does not use main RAM, hence it is not affected by MMU bugs.