[Cryptography] Speculation considered harmful?

[Richard Clayton]

In message <a110f2c2-8845-0cc2-de8f-da1106eda0e6 at symas.com>, Howard Chu
<hyc at symas.com> writes
>Henry Baker wrote:
>
>> I don't have a clean solution to this "forgetting" problem, and I doubt that 
>>anyone else does, either.
>
>Eh. In the context of Spectre, the CPU knows which cachelines it loaded in a 
>speculative fetch. It should simply mark them invalid when unrolling the 
>speculation.

that just means you need to change the detection code to test for invalid rather
than valid -- what you actually need to do is to unroll back to the non-
speculative state (so that some type of parallelism might address this, as does
the removal of high precision clocks [the browser approach]) ...

... but note that there are other side effects that you might be able to test
for -- the recent work merely used high precision cache timing because it is
straightforward to implement; and they are fully aware that there may be other
approaches.  From the Spectre paper:

     More broadly, potential countermeasures limited to the memory cache are
     likely to be insufficient, since there are other ways that speculative
     execution can leak information. For example, timing effects from memory bus
     contention, DRAM row address selection status, availability of virtual
     registers, ALU activity, and the state of the branch predictor itself need
     to be considered. Of course, speculative execution will also affect
     conventional side channels, such as power and EM.

Expect to see more types of attack (and probably soon)

-- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20180106/a7e5555a/attachment.sig>