Theo de Raadt Details Intel Core 2 Bugs

Eukariote writes "Recently, Intel patched bugs in its Core 2 processors. Details were scarce; soothing words were spoken to the effect that a BIOS update is all that is required. OpenBSD founder Theo de Raadt has now provided more details and analysis on outstanding, fixed, and non-fixable Core 2 bugs. Some choice quotes: 'Some of these bugs... will *ASSUREDLY* be exploitable from userland code... 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.'"

Intel chips

[supersnail (106701)]

.. not intel compatable.

Ask for your money back folks!

Good stuff.

[AltGrendel (175092)]

I always find Mr. De Raadt's comments an interesting read. He's like a geek version of Harlan Ellison.

Re:Good stuff.

[Lisandro (799651)]

Same here. The guy might seem like a bit of an asshole sometimes, but he surely knows what he's talking about. Some of the things he points out are plain unbelievable:

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.

It will be interesting to see what Intel has to say about this.

Re:Good stuff.

[suv4x4 (956391)]

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.

It will be interesting to see what Intel has to say about this.

Yea! Damn, where's the Intel Opinion Center exactly when you need it!

Shock Felt Round the World

[N8F8 (4562)]

Coming from the government sector, this kind of issue isn't going to be taken lightly. I work at a DoD facility and all our machines were just refreshed with Core 2 Duo machines. It is already almost impossible to get new software approved, if this causes the same paranoia for basic commodity hardware we're really gonna feel some pain.

Quantum effects?

[DFDumont (19326)]

My favorite errata in the list is AI22, Sequential Code Fetch to Non-canonical Address May have Nondeterministic Results. Basically the chip decides that all of the high oreder bits should be '1', instead of '0' - for no apparent reason as its not consistent.
Did anyone notice these chips are using the 65nm process?
At what point do the shear quantum affects overcome the deterministic EE rules that are used to design the chips? I don't know, but wikipedia defines a nanoparticle as one with at least one dimension less than 100nm. http://en.wikipedia.org/wiki/Nanoparticle [wikipedia.org]
Given that definition every transistor's source, drain and gate are nanoparticles. And we expect them to behave classically why?

Linus doesn't think it's a big deal.

[davebert (98040)]

Link [realworldtech.com]

Re:Yay AMD

[BosstonesOwn (794949)]

I don't think that is a good thing either. It looks like AMD may be doing this as well.

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

Re:Yay AMD

[TheRaven64 (641858)]

SPARC is doing very well for certain categories of workload, although mainly web-app types at the moment. Most computers sold these days have some form of ARM chip[1], which is a nice, low-power architecture, but lacks floating point. This isn't a huge problem, since a lot of ARM designs (particularly those from TI) have a DSP on die which can seriously out-perform a general purpose CPU for a lot of FPU-heavy workloads.

For general-purpose usage, the most interesting design I've seen recently is the PWRficient from P.A. Semi. It's a nice dual-core 64-bit PowerPC, with low power usage, similar performance to IBM's PowerPC 970 series. It has a lot of nice stuff on-die (crypto, a really shiny DMA architecture, etc).

For a complete round-up of current alternatives, take a look at this article [informit.com] and the next two in the series.

[1] They are generally marketed as 'cell phones' or similar, rather than 'computers'.

Re:Yay AMD

[Tony Hoyle (11698)]

You'd be surprised - there are all sorts of gotchas on different platforms... different OS library support, different word length, different byte orders, alignment issues, etc. then at the OS level you have path separators (/,\,.,:,whatever plus existence of drives eg SYS$SYSTEM:[00000] is a path on VMS, C:\ is a path on Windows - and not all filesystems support paths in the sense Unix does anyway, Character set assumptions (you can't assume the platform supports utf8, or even ASCII), Case sensitivity, Character set sensitivity, etc.

No code (except assembler) is CPU specific.. you can compile an average (well written) C app on pretty much anything with a C compiler, but it's often unknowningly architecture /OS specific - until you've been through the pain of translating to an entirely different OS (HPUX is fun, VMS is even more fun, or for *lots* of fun try OS/360) it's difficult to know - and that goes for any language, including Java (which mitigates some of the issues but by no means all of them.. not to mention the jvm isn't available on many platforms).

Re:Yay AMD

[Idaho (12907)]

Except that if you read what Theo has to say, he doesn't have kind words for AMD either.

Wake me up when Theo has kind words to say about basically anything at all, now *that* would be news!

Unfortunately he's likely also right on most accounts though :(

Re:Yay AMD

[Bill, Shooter of Bul (629286)]

He does have kind words about open bsd. ... Sometimes.

Re:Summary sucks, someone please provide better on

[Aladrin (926209)]

Sure:

Some of the bugs are so dangerous that it doesn't matter WHAT operating system you're running, code could be written that could attack the entire system. It would still be OS-specific code, but since the exploit is in the hardware, it's a LOT harder to prevent the attack, if it's even possible.

Some of the bugs are unfixable, as well. (I assume they mean without physcially replacing the chip with a 'fixed' one that doesn't exist yet.)

VHDL for voting machines

[martyros (588782)]

So perhaps the NY law requiring software for voting machines to be held in escrow should include the chip layout as well...

Re:Summary sucks, someone please provide better on

[swillden (191260)]

Some of the bugs are so dangerous that it doesn't matter WHAT operating system you're running, code could be written that could attack the entire system. It would still be OS-specific code, but since the exploit is in the hardware, it's a LOT harder to prevent the attack, if it's even possible.

Here's a little more detail, based on my (very incomplete) understanding of the issues:

It appears that Intel has made changes to the way the memory management unit in the processor works, plus there are also some bugs that affect memory management. So what does that mean?

• Theo mentions changes in how TLB flushes must be handled. Translation Lookaside Buffers (TLBs) are tables where operating systems cache information used to quickly determine what physical memory page corresponds to a given virtual memory page. Each running process has it's own address space (meaning the data at address, say, 1000, is different for each process) and operating systems have to be able to quickly translate these virtual addresses to addresses within the physically-available RAM. The authoritative data on the mapping is in a set of data structures called the "page table", but the processors provide a mechanism for creating and managing TLBs which act as a high-performance cache of part of the page table data. Failing to properly flush the TLBs during a context switch (putting one process to sleep and activating another) might result in the new process' virtual memory mapping being done incorrectly. From a security perspective, this could give one process access to memory owned by another.
• Another issue mentioned is the possibility that No-Execute bits may be ignored. The OS can set the No-Execute (NX) bit on a page of memory that it knows to be pure data that should not be executed. The processor will refuse to execute code from any memory page with NX set. This makes most buffer overflow attacks impossible, because the normal buffer overflow attack involves getting a bit of malicious code shoved into a stack-based buffer as well as overflowing the buffer to overwrite a return address so that the CPU will jump to and execute the malicious code. Obviously, if the processor sometimes ignores NX bits, the buffer overflow attacks become possible again.
• Theo also mentions possibly-ignored Write-Protect (WP) bits. The OS can mark memory pages as read-only. This is used for all sorts of things related to security. One of the biggest is preventing processes from writing to the memory in which shared libraries are loaded. If my process could overwrite, say, the C library code implementing "printf", other processes that call this function would execute my code. Some of them will be running as root, so I can execute code with root permissions. Modern operating systems do lots of data-sharing between processes, some of it completely non-writable, other parts of it "copy on write". Copy-on-write pages are implemented by setting the WP bit and then catching the page fault generated by the CPU when a process tries to write the page. The fault handler quickly copies the page in question, allows the write to hit the copy, and reswizzles the page table so the virtual page of the writing process points to the new copy. WP bits being ignored would also break this, so lots of cases where data is "opportunistically" shared would become really and truly shared, allowing one process to corrupt data used by another.

There are other issues as well... but these are a good sample, and should give an idea of what kind of bad stuff these CPU bugs/changes can make possible.

Re:Summary sucks, someone please provide better on

[Hurga (265993)]

can someone at slashdot please provide an "english" translation of the problems and how dangerous they are to normal users?

"We don't have the complete picture yet, but things look bad"

Hanno

Re:Summary sucks, someone please provide better on

[TheRaven64 (641858)]

I don't know why Theo posted that link, because it is about the Core, not the Core 2. They are two completely different micro-architectures. The Core was a slightly tweaked Pentium M (which is basically a P6 with extra vector instructions and the NetBurst branch predictor), while the Core 2 is a completely new micro-architecture. If you compare the errata in the two links, you will see that they are quite different.

Re:How hard is it to get right?

[ardor (673957)]

Actually we are talking about VHDL. The "million transistors" argument is just as appropiate as saying "software is so large, it has so many ones and zeros". Development does not happen at this low stage.

Re:How hard is it to get right?

[imgod2u (812837)]

Yes and no. There are limitations to HDL's (and Intel, last I heard, was all Verilog). For one, it is *very* difficult, if not impossible in certain situations, to describe asynchronous signals. With something as complicated as a microprocessor that is so aggressively designed for both power and speed, I would guess that they didn't go with a completely synchronous design (hell, no one does anymore). Locally synchronous, globally asynchronous design has been in use for a while. It helps when you want to be able to shut off, or slow down, only parts of the chip that aren't being used very much.

It is not possible to describe such things (let alone voltage islands, voltage scaling) in an HDL language and they must either be a special feature built into synthesis (with an extra set of constraints) or done by hand at the transistor/gate level.

Then there's the point of verification. Every software release since about the mid-1990's has almost been immediately followed by patches. Just because it's "1's and 0's" does not mean that it doesn't get harder to detect corner cases as complexity grows. And it's much more difficult if you have to simulate on a cycle-accurate model (boot-up for an operating system, in simulation, would take a day on a nice cluster on something as big as the Core 2).

Then there's post-synthesis/layout issues. Timing analysis do best on sequential logic (completely synchronous). When you throw in clock gating, multiple voltage islands, dynamic voltage scaling (meaning dynamic gate delays), not to mention the plethora of other techniques that those folks might be doing, what you see in simulation at the RTL level will not match what you see in reality. First rule they ever teach in any ASIC design class is never trust simulation.

The point is that abstraction, like how it's "vhdl", does not mean that it's not difficult to get right and even sometimes impossible to be certain.

Re:How hard is it to get right?

[SatanicPuppy (611928)]

What is a bug but an undocumented feature?

Re:How hard is it to get right?

[Anonymous Brave Guy (457657)]

Any sufficiently advanced undocumented feature is indistinguishable from a bug. :-)

Re:How hard is it to get right?

[TheGratefulNet (143330)]

AMD64 doesn't like FreeBSD 6.2 at all

% uname -a
FreeBSD myhost.grateful.net 6.2-STABLE FreeBSD 6.2-STABLE #0: Mon May 28 09:52:28 PDT 2007 [e-mail]:/usr/obj/usr/src/sys/AMD64 i386

granted, I'm using 32bit mode - but I've been running 6.2 for as long as its been out and my 'always on' freebsd box. what issues are you seeing? this is my production box - but I don't see any problems with bsd. in fact, I also have 6.2 running with an old amd64 3000+ that was a mobile chip and had to have cpufreq enabled just to move it off its default 800mhz and up to the 2.mumble ghz that its supposed to clock at. works fine.

I have seen some hardware devices not behave well but often its not a well designed piece of hardware or its just not meant for server style loads (cheap consumer onboard sata sometimes times out and usb2.0 always times out if you give it enough load).

I can't speak to amd64 USING 64bit mode, but 32bit mode works as well as (or better) than linux on headless style computing.

Re:How hard is it to get right?

[suv4x4 (956391)]

% uname -a
FreeBSD myhost.grateful.net 6.2-STABLE FreeBSD 6.2-STABLE #0: Mon May 28 09:52:28 PDT 2007 [e-mail]:/usr/obj/usr/src/sys/AMD64 i386

Wait... this works in Slashdot's text area?

% uname -a

% uname -a

Damn it :(

Re:Time for RISC?

[Viv (54519)]

The market resoundingly rejected that idea when Intel tried to hoist IA64 on it.

Re:Intentional?

[Slashcrap (869349)]

There seem to be intentional modifications in there.

Unprovable conjecture. Why would Intel make this public if they were?

Could that be a backdoor and a good reason for countries like China to develop their own CPUs?

Are you the same freak that posted on KernelTrap about how every CPU since the 486 has been bugged by the NSA and can be monitored by satellites? If so, please carry out the recommended course of action that I detailed to you on that occasion. Namely that you set fire to yourself outside the UN building in order to draw attention to your cause. Thanks in advance.