Transient Execution Attacks entry need to be reframed (2.2.1)
Closed this issue · 3 comments
In the 2.2.1 table, the entry on transient attacks needs to be modified.
A transient attack exploit relies on two quite distinct vulnerabilities :
- The transient phase, where transient states leave traces in the microarchitecture.
- The covert channel phase that exfiltrate the relevant traces.
With this in mind, fence.t only help with covert channels.
And "RISC-V systems are not expected to be vulnerable to those." -> this claim needs to be removed : there is nothing that make RISC-V less susceptible to such attacks than other ISAs.
I am raising the issue rather than proposing a pull request since I am not sure how to rephrase this in this framework.
Thanks for your comments. The idea behind describing TEAs as a Chained Logical attacks was precisely because of the two points that you raised. There are multiple mechanisms in play in order for an attack to be successful. Therefore, it is a chained attack.
Regarding your second point, I agree with you. In fact, we should expect that most RISC-V systems will be susceptible to some kind of TEAs.
About fence.t. As you correctly pointed out, fence.t breaks the receiving end of the communication channel employed in a TEA and is not a panacea against the full spectrum of possible attacks. However, I and others in the group are of the opinion that most attacks can be resolved in the microarchitecture and we expect that designers will deal with them at that level. Moreover, fence.t may not protect against remote Spectre-PHT (NetSpectre for example) attacks if the programmer doesn't execute the instruction in the correct place. fence.t is mentioned as a possible extension that RISC-V may offer in the future. Again, it is not meant to be interpreted as a full solution.
👍
I totally agree with your answer.
Thanks.
I changed to: "Fence.t, or similar future extensions, could at least partially mitigate against Spectre v1."
I rephrased to "Known (documented) attacks, except Spectre v1, are specific to particular
micro-architectures. Micro-architecture for RISC-V systems is implementation specific, but must not introduce such vulnerabilities.
+
This is an evolving area of research. "
The first part basically says that apart from v1, "don't do what Intel did" (avoid issues that can be solved at micro-architecture level).
The second part says "who knows what the someone comes up with next".
And the "RVI mitigations" says "there are none, but future extensions like fence.t might help".
"Mitigation" in this section does not mean "solves the problem". It simply means "something that could reduce the impact."