[Cryptography] Speculation considered harmful?

[Arnold Reinhold]

Most  discussions of the Spectre vulnerabilities have centered on how to keep speculative execution from revealing contents of kernel memory without paying a big cost in performance. It might be worth exploring other directions including safer storage of secrets now kept in kernel memory and adding hardware to detect such attacks.

An ideal solution might be storing secrets in special hardware that would not be subject to Spectre attacks, perhaps in a cryptographic coprocessor or even a memory module off the I2C or SPI bus. 

Short of that, it might be worth considering storage of the relatively small amount of secret kernel data in ways that are harder to recover via Spectre probing, perhaps by secret splitting or encryption. This could be done entirely in software. One might xor the secret data with one or more blocks of random bits, perhaps selected pseudorandomly from a larger array of random bits. if this storage arrangement is refreshed with new random bits periodically, at intervals less than the time needed to recover enough kernel bits via Spectre attacks, the likelihood of successful secret recovery might be significantly reduced. The kernel could refrain from ceding control to user processes durning the brief intervals when secret data is decoded for use. An attacker who knew all the details of the kernel program and its layout could concentrate on recovering just the bits needed to unwind the process, but some randomization of memory during boot could make this difficult in practice

An attack detection solution in hardware might use a counter that is incremented every time a speculative branch attempts access beyond memory bounds. A high enough count would trigger an interrupt, based on a programmable threshold, that could allow the offending process to be identified and suspended, or some other way of mitigating the attack, say by turning off speculative execution for that process.  

Sending a bit to a counter at a bounds violation shouldn’t slow down speculative execution at all, unlike other mitigations. There would have to be some allowance for occasional bound violations due to normal execution, say by measuring the interval between such interrupts, so a very slow attack could still be possible,. But combined with dynamic secret splitting in software, as above, a detection scheme might render recovering secrets infeasible. And a speculative execution memory violation counter could be implemented fairly easily in most architectures. 

Arnold Reinhold