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

[Zola Bridges via llvm-dev]

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/20200310/b6f557e5/attachment.html>