[Cryptography] Speculation considered harmful?

John Gilmore gnu at toad.com
Thu Jan 4 19:07:44 EST 2018


> There's only one slight problem: you can't unring a bell: you can't
> "unlearn"/"forget" a bit that you learned during the gathering
> phase.  Or more precisely, you can't force a party to the
> transaction to forget such bits.

Not true.

The attack succeeds by doing a speculative load, which faults, but
which actually picks up the addressed data anyway -- and then uses
that data for a future operation (which leaves some visible trace).

The obvious place to fix that is: When a load faults, don't pick up
the addressed data.  Every architecture that has memory-mapped I/O
ports already has to deal with this; the permissions check has to
happen BEFORE committing the transaction, else memory-mapped registers
that change upon being read, will be touchable by unprivileged code.

If the CPU knows the physical memory address of the page being
addressed, then it also knows the permission bits; they are in
exactly the same page-table entry.  And it can't do the memory access
without knowing the physical memory address.

There's a second place you could fix this, if you can't do the
obvious.  Speculatively loaded data values also carry alongside them,
indications about faults (so that if the execution path commits,
rather than being nullified, the CPU will take the fault).  If a
speculative execution tries to use (as an input) a data value WHICH
COMES WITH A FAULT, then stop speculating.  This would solve the data
leak that occurs when the data value is used to calculate an address
of a subsequent access (thus altering the cache in a way that can be
detected).

Indications are that AMD got this right in their implementations, and
Intel got it wrong.  ARM seems to be more of a mixed bag.

	John

PS: I did architectural validation for some early SPARC processors,
and we found and fixed all sorts of stuff like this -- in simulation,
before we shipped the chips.

PPS: The branch target buffer exploit is different; not sure about
that one yet.


More information about the cryptography mailing list