[llvm-dev] [RFC] Speculative Execution Side Effect Suppression for Mitigating Load Value Injection
Zola Bridges via llvm-dev
llvm-dev at lists.llvm.org
Wed Mar 18 14:03:52 PDT 2020
Scott and I have been working to make our patches upstreamable. I'd like to
hear more feedback.
I would only upstream my patches if the community felt it would be
beneficial/desirable. It would be nice to have more discussion to make it
easier to make a decision within the next week or two.
What are your thoughts on the following topics?
- Should SESES be upstreamed? Are there any concerns about upstreaming
- Should Scott's approach be upstreamed? Are there any concerns about
- Are there reasons to upstream both approaches?
- Are there reasons against upstreaming both approaches?
I'm particularly interested in hearing from folks who may use one of these
For example, Jethro from Fortanix provided feedback (in the #backends
Discord channel) that he would be most interested in seeing Scott approach
upstreamed due to the performance advantage.
On Tue, Mar 10, 2020 at 10:23 AM Zola Bridges <zbrid at google.com> wrote:
> Hi everyone,
> Some Intel processors have a newly disclosed vulnerability named Load
> Value Injection.
> One pager on Load Value Injection:
> Deep dive on Load Value Injection:
> I wrote this compiler pass that can be used as a last resort mitigation.
> This pass is based on ideas from Chandler Carruth and Intel. This pass is
> primarily intended to share with the community as a basis for
> experimentation and may not be production ready. We are open to upstreaming
> this pass if there is interest from the community. It can be removed if it
> becomes a maintenance burden.
> Intel has also created a mitigation that they have shared:
> We look forward to sharing information and ideas about both.
> The documentation in this email lists the performance I saw for variants
> of the mitigation that are potential optimizations for Load Value
> Injection. The flags can be used to turn on optimization techniques for
> different builds. They are turned off by default. Each variant is not
> guaranteed to be as secure as the full mitigation.
> Here is a link to the first patch: https://reviews.llvm.org/D75939
> Here is a link to the documentation patch: https://reviews.llvm.org/D75940
> Links to other related patches
> I'd like to request comments, feedback, and discussion.
> Beyond that, we would also like guidance on whether to upstream this pass.
> Zola Bridges
> From the documentation: Overview of the mitigation
> As the name suggests, the "speculative execution side effect suppression"
> mitigation aims to prevent any effects of speculative execution from
> escaping into the microarchitectural domain where they could be observed,
> thereby closing off side channel information leaks.
> In the case of Load Value Injection, we assume that speculative loads from
> memory (due to explicit memory access instructions or control flow
> instructions like RET) may receive injected data due to address aliasing,
> and we ensure these injected values are not allowed to steer later
> speculative memory accesses to impact cache contents.
> The mitigation is implemented as a compiler pass that inserts a
> speculation barrier (LFENCE) just before:
> Each memory read instruction
> Each memory write instruction
> The first branch instruction in a group of terminators at the end of a
> basic block
> This is something of a last-resort mitigation: it is expected to have
> extreme performance implications and it may not be a complete mitigation
> because it relies on enumerating specific side channel mechanisms. However,
> it is applicable to more variants and styles of gadgets that can reach
> speculative execution side channels than just traditional Spectre Variant 1
> gadgets which speculative load hardening (SLH) targets much more narrowly
> but more efficiently.
> While there is a slight risk that this mitigation will be ineffective
> against future side channels, we believe there is still significant value
> in closing two side channel classes that are most actively exploited today:
> control-flow based (branch predictor or icache) and cache timing. Control
> flow side channels are closed by preventing speculative execution into
> conditionals and indirect branches. Cache timing side channels are closed
> by preventing speculative execution of reads and writes.
> We believe this mitigation will be most useful in situations where code is
> handling extremely sensitive secrets that must not leak, and where a hit to
> performance is tolerable in service of that overriding goal. As we've
> mentioned, the original target of this mitigation was the threat of LVI
> against SGX enclaves instrumenting critically important secrets.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev