Discussion about Core 2 Duo Bugs

Open Source developers have recently started a discussion about certain bugs in Intel's latest Core 2 Duo processors. The discussion focuses on whether these bugs could be potential security risks, because they could possibly be used as weaknesses for malware.

According to Intel, there are currently no security risks; but the manufacturer still recommends installing the latest microcode updates on its processors – in other words to keep the BIOS updated and to install patches for operating systems when new microcode versions for the existing processors are released. The ability to update the microcode in x86 processors has been implemented to correct possible bugs. Theoretically, the microcode can also teach a processor new commands.

Microsoft recently released an update for several Windows versions after PC manufacturers issued BIOS updates for computers with Core 2 Duo processors.

According to a discussion between Linux developers on the Linux Kernel mailing list (LKML), the latest Linux distributions include microcode updates in their internet updates. The latest microcode version 1.17, which is supposed to prevent the above-mentioned issue, is not yet included in any current distributions (but can be found here: Intel Microcode Update Utility for Linux).

Theo de Raadt, founder of the OpenBSD and OpenSSH projects, and known for his outspoken approach, launched the discussion about the importance of the Core 2 Duo bug in a posting on the openbsd-misc mailing list, in which he severely criticized Intel. He mentioned possible security problems, but didn't describe concrete attack vectors (Raadt also criticized AMD in the same post). Actually Intel does not really explain which of the numerous Core 2 Duo bugs the microcode update fixed.

Linus Torvalds posted in the forum at RealWorldTech on the questionable Core 2 Duo bugs and stated that he felt they were "totally insignificant" for the latest Linux versions.

There have been many discussions about the importance of processor bugs. The FDIV Pentium Bug is probably the most legendary in this respect. Intel spent hundreds of millions of dollars on the recall 12 years ago. Since then, Intel has documented all CPU bugs publicly and has since recalled one chip set and another processor. AMD processors are also plagued every now and then with bugs.

Torvalds, who used to work for microprocessor developer Transmeta, stated that the bugs in the x86 line of processors by AMD and Intel are the subject of overly exaggerated attention. He argues that all processors have bugs and that the bugs are much better documented for the commonly used desktop processors because of the large pool of developers and operating systems using them. For other special purpose processors, only a small group of developers is usually informed of problems.

Because all microprocessors have bugs, hardware developers and programmers receive instructions from the manufacturer on how they can circumvent these bugs. Documentation of the bugs is more and less public and fast, depending on the manufacturer. Intel has its Specification Updates, and AMD has its Revision Guides. Some of the CPU bugs, which Intel euphemistically calls "errata", can be eliminated by changing the CPU initialization (by updating the BIOS), some through a microcode update (through the BIOS or operating system), while some processor companies correct them in steppings, which are new, optimized releases of the CPU kernels. CPU bugs rarely occur in real world code, which is why the processor manufacturers typically only find them during lab tests under the most extreme conditions.

It is difficult to assess the importance of the latest Core 2 Duo bug. The discussion in the Open Source community was ignited by the "Specification Clarification AI1," in which Intel explains how operating systems should handle the TLB Invalidation, which is accomplished by the rejection of data in certain buffers, i.e. the Translation Look-Aside Buffers (TLB).

One of the bugs that Theo de Raadt listed as being potentially critical is Erratum AI99, Updating Code Page Directory Attributes without TLB Invalidation May Result in Improper Handling of Code #PF. Page Fault exceptions (#PF) play an important role in No Execute memory protection (NX, which is called Data Execution Prevention/DEP by Microsoft, Enhanced Virus Protection/EVP by AMD and Execute Disable by Intel). The problem is that Core 2 processors handle #PF with a lower priority than Debug Exceptions (#DB) or a General Protection Fault (#GP). That means the #PF is sometimes incorrectly processed – however, according to Intel, this only happens when the following three conditions occur together:

• A Page Directory Entry (PDE) is changed without invalidating the matching TLB entry
• code execution is switched to another code page, and simultaneously
  - the address of the new code page corresponds to the modified PDE
  - and the accessed bit (A) of the page table entry (PTE) in the main memory address is zero
• After the code page is changed, one or two specific exception combinations occur, namely either
  - #DB and #PF
  - or a code segment limit violation (i.e., #GP) and #PF

It is quite unlikely that all three events concur. Additionally an exploit that takes advantage of this weakness would have to run with high privileges. De Raadt also mentioned Errata AI65, AI79, AI43, AI39, and AI90 in the latest Specification Update Number 14. Intel does not give a detailed description of the effects of the bugs, but apparently some of them can also weaken NX memory page markup.

32-bit Linux distributions generally don't use hardware memory protection units such as NX, because you need a PAE-enabled kernel that must be installed manually. Plus, there are also software tricks that are supposed to protect you from these attacks like NX memory page markup (such as PaX). The NX function only protects you against certain kinds of attacks anyway.

(ju)