Our commenters will be more useful than I will on this post, but:

Theo de Raadt on Intel CORE 2:

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.

Errata he calls out specifically:

AI65

When the temperature reaches an invalid temperature the CPU does not generate a Thermal interrupt even if a programmed threshold is crossed.

I don’t see how this is a security concern; maybe he meant AI56, which gives unpredictable behavior if you change the attributes of a PTE without fixing up the TLB; AI64 involves system management mode and AI67 involves VTX.

AI79

During a series of REP (repeat) store instructions a store may try to dispatch to memory prior to the actual completion of the instruction. This behavior depends on the execution order of the instructions, the timing of a speculative jump and the timing of an uncacheable memory store. […] When this erratum occurs, the processor may live lock and/or result in a system hang.

Unless the behavior depends on system memory inaccessible to userland, this could imply userland crasher exploit.

AI43

When a logical processor writes to a non-dirty page, and another logical- processor either writes to the same non-dirty page or explicitly sets the dirty bit in the corresponding page table entry, complex interaction with internal processor activity may cause unpredictable system behavior […] and hang.

Two userland processes on two different cores can race each other and hang the system?

AI39

When request for data from Core 1 results in a L1 cache miss, the request is sent to the L2 cache. If this request hits a modified line in the L1 data cache of Core 2, certain internal conditions may cause incorrect data to be returned to the Core 1.

Where the word “incorrect data” is errata code for “Zuul’s return as the Sta-Puft Marshmellow Man” —- two cores race each other, and a process gets the wrong cache line.

AI90

If code segment limit is set close to the end of a code page, then due to this erratum the memory page Access bit (A bit) may be set for the subsequent page prior to general protection fault on code segment limit. […] a non-accessed page which is present in memory and follows a page that contains the code segment limit may be tagged as accessed.

Theo says this is exploitable on operating systems other than OBSD; the A bit signals the VM system that a page has been accessed by the hardware.

AI99

Code #PF (Page Fault exception) is normally handled in lower priority order relative to both code #DB (Debug Exception) and code Segment Limit Violation #GP (General Protection Fault). Due to this erratum, code #PF may be handled incorrectly, if all of the following conditions are met:

• A PDE (Page Directory Entry) is modified without invalidating the corresponding TLB (Translation Look-aside Buffer) entry

• Code execution transitions to a different code page such that both:

  • The target linear address corresponds to the modified PDE

  • The PTE (Page Table Entry) for the target linear address has an A (Accessed) bit that is clear

• One of the following simultaneous exception conditions is present following the code transition:

  • Code #DB and code #PF

  • Code Segment Limit Violation #GP and code #PF

Software may observe either incorrect processing of code #PF before code Segment Limit Violation #GP or processing of code #PF in lieu of code #DB.

We’ll have more to say about chip errata this month.