[libre-riscv-dev] Spectre mitigation stratagies
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Wed Jan 16 15:13:15 GMT 2019
Ok so Jacob and I discussed this offlist, we concur that the simplest
option is a speculation "fence" instruction, that is called on a transition
from trusted to untrusted execution, and that interrupts, system calls and
exceptions will automatically clear out the processor state to a known good
quiescent one.
Also that issues such as shared divide units across multiple cores, and
LD/ST caches still have to be dealt with, ensuring that no state may be
leaked across cores.
The FENCE instruction will basically wait for outstanding instructions to
complete up to the current PC, committing all results to the register file,
cancelling all "nameless" register bypasses, clearing out all speculative
instructions, and the Dependency Matrix.
With clearing the Dependency Matrix being so drastic, and being quite easy
to reestablish, an additional FENCE is recommended: one that prevents
speculation and "nameless" bypasses for a short duration (10-16
instructions). The idea being to call it a few instructions before an
upcoming system call.
Preventing speculation that is to be cancelled in only a few cycles time
ensures that power is not wasted.
A cooperative solution of calling a speculation FENCE instruction is an
easy solution, albeit one that will require significant software
integration. Luckily many strategic weakpoints will be fairly easy to
identify as they are likely to be using well known software patterns:
openssl usage, PAM, and SE/Linux are just a few key strategic security
points that will be easy to identify and add in a call to the relevant
FENCE instructions.
The alternatives are a mess, or extremely resource hungry (either in
hardware or software), and not guaranteed to work in all cases, as more
attack vectors nay be discovered in the future.
L.
--
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
More information about the libre-riscv-dev
mailing list