[PATCH] D49433: [x86/SLH] Add the design document for Speculative Load Hardening, a Spectre v1 mitigation.

[Chandler Carruth via Phabricator via llvm-commits]

chandlerc marked 4 inline comments as done.
chandlerc added a comment.

Thanks all. Most fixes applied.

I'm gonna land so we at least have a draft and we can incrementally follow up on it.

I've responded to the deeper questions below.



================
Comment at: llvm/docs/SpeculativeLoadHardening.md:506
+when the register pressure is sufficient to make it worth spilling to memory
+and reloading.
+
----------------
efriedma wrote:
> Does spilling the register to memory potentially introduce new issues?  The program could use a speculative buffer overflow to clobber it, like in variant 1.1.
Yes.

This is a particularly hard mechanism to use to bypass the mitigation though... You need to find:
1) A store that can clobber register slots on the stack
2) That comes after you enter speculative execution and taint the poison
3) And after that taint gets spilled to the stack
4) And that comes before the taint is loaded back

It isn't clear to me that this happens much if at all. I would be fine reserving a register (all hot code i have seen does not ever spill this because it is needed so often) except for the compatibility problems with reserving a register in the ABI.

Maybe we should work within the code generator to provide a stronger guarantee around minimizing / avoiding register spills.


================
Comment at: llvm/docs/SpeculativeLoadHardening.md:528
+and an all-zero mask along correct paths. Other options become less appealing
+such as multiplying by zero or one, or multiple shift instructions. For reasons
+we elaborate on below, we end up suggesting you use `or` with an all-ones mask,
----------------
sidney13 wrote:
> I get multiplying by zero to clear bits, but did you really mean to include multiplying by one?
I have no idea what I was thinking....


================
Comment at: llvm/docs/SpeculativeLoadHardening.md:980
+
+## Alternative Mitigation Strategies
+
----------------
echristo wrote:
> You have alternatives above and alternatives here. It's a little complicated figuring out which alternatives you mean where. Thoughts on coalescing in some way? I don't have anything specific.
The intent was to discuss alternatives *within* the framework of SLH above, and here to discuss alternatives to the overall approach. Not super clear though as currently written. I've tweaked the heading, but yeah, I think this may need more thought...


Repository:
  rL LLVM

https://reviews.llvm.org/D49433