[llvm-dev] [RFC] Speculative Execution Side Effect Suppression for Mitigating Load Value Injection

[Zola Bridges via llvm-dev]

Hi everyone,

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
   it?
      - https://reviews.llvm.org/D75939
      - Should Scott's approach be upstreamed? Are there any concerns about
   upstreaming it?
      - https://reviews.llvm.org/D75937
      - http://lists.llvm.org/pipermail/llvm-dev/2020-March/139842.html
      - 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
mitigations.

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.

Thanks!

Zola Bridges


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:
>
>
> https://software.intel.com/security-software-guidance/software-guidance/load-value-injection
>
> Deep dive on Load Value Injection:
>
>
> https://software.intel.com/security-software-guidance/insights/deep-dive-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:
> http://lists.llvm.org/pipermail/llvm-dev/2020-March/139842.html
>
> 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
>
>    -
>
>    https://reviews.llvm.org/D75941
>    -
>
>    https://reviews.llvm.org/D75942
>    -
>
>    https://reviews.llvm.org/D75944
>
>
> I'd like to request comments, feedback, and discussion.
>
> Beyond that, we would also like guidance on whether to upstream this pass.
>
> Thanks,
>
> 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...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200318/d9f2348b/attachment.html>