OpenBSD Journal

Theo on the latest Intel issues

Contributed by Paul 'WEiRD' de Weerd on from the the gift that keeps on giving dept.

Theo de Raadt (deraadt@) posted to the tech@ mailing list with some background on how the latest discovered Intel CPU issues relate to OpenBSD.

Date: Wed, 15 Aug 2018 00:31:16 -0600
From: Theo de Raadt [elided]
Subject: CVE-2018-3615, CVE-2018-3620, CVE-2018-3646

These 3 issues all relate to a bug in Intel cpus

The cpu will speculatively honour invalid PTE against data in the
on-core L1 cache.  Memory disclosure occurs into the wrong context.

These 3 issues (CVE-2018-3615, CVE-2018-3620, CVE-2018-3646) together
are the currently public artifacts of this one bug.
There may be more artifacts of this on the way, perhaps combined with
other past and not yet known mistakes.

CVE-2018-3620 matters for the host OS.  We have reviewed our pmap module
and it appears like we never invalidate a PTE by clearing the 'valid'
bit alone, we always clear the PTE to 0 entirely.  Page 0 of physical
memory is unused.  As well, we don't support Wine (which has VA 0 / PA 0
issues); we don't support 32-bit emulation in 64-bit mode which makes
things trickier, and we have SMT disabled by default which reduces the
risk patterns further.

CVE-2018-3646 relates to the same bug, but considers the cross-domain
impact upon entering VMs, which obviously run in different security
domains.  A patch should arrive soon to flush the L1 cache before
vmenter, so that an incorrectly accessed PTE can't read data from
another domain.  Another aspect of the risk in this area goes away if
SMT is disabled, so keep it disabled!

CVE-2018-3615 (Foreshadow) is by receiving the most press which is
amazing considering it is by far the most boring of the 3, since very
few few people give a rats ass about SGX -- who cares if SGX is broken
when the cpu can't run your OS safely? Some convincing press agencies
were hired I guess, and have performed a masterful job of distracting.

We had some idea this class of problem was coming, through hints we
received from others and an extremely cynical perspective that has
developed.  We believe Intel cpus do almost no security checks up-front,
but defer checks until instruction retire.  As a result we believe
similar issues will be coming in the future.

We asked repeatedly, but Intel provided no advance notice.  We did not
even receive replies to our requests for dialogue.

On a side note, AMD cpus are not vulnerable to this problem.  Currently
it is believed their address translation layer works according to spec.

Further reading here (, and here (

(Comments are closed)

  1. By Janne Johansson (jj) on

    Why, why, miss dyn-linkable PIE,
    drove my intel to the socket but the socket was dry,
    and the good old old admins were drinking and cryi'n,
    singing "this'll be the day that it dies..
    This'll be the day security dies.."

  2. By chas (chas) on

    On a related note, the AMD Athon X4 845 and 950 top these price/performance ratings:

    The FX-9590 was at the top of the list when I checked last month. I'm thinking that it's time to upgrade to something more secure.

    1. By Chris Cappuccio (chriscappuccio) on

      There's no guarantee that AMD is better

      1. By Daniel Cizinsky (d.c.) on

        at least you would have a kind of diversity. But what's worse, where can you buy a (hw) supported server with AMD? Well, importing server to EU via USA and pay 10 times price of an Intel for no service support is not really an option.


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]