[PATCH] D80964: [X86] Add an Unoptimized Load Value Injection (LVI) Load Hardening Pass

[Zola Bridges via Phabricator via llvm-commits]

zbrid added inline comments.


================
Comment at: llvm/lib/Target/X86/X86TargetMachine.cpp:503
+  else
+    addPass(createX86LoadValueInjectionLoadHardeningUnoptimizedPass());
 }
----------------
>>! In D80964#2077811, @sconstab wrote:
> 
> My understanding of SESES is that it inserts an `LFENCE` before each transmitter, whereas this pass inserts an `LFENCE` after each load. They are slightly different threat models; SESES is more strict. For example, SESES would mitigate the following vulnerability, whereas the LVI hardening will not:
> ```
> uint64_t maybe_secret = *ptr;                           // architectural load
> __mm_lfence();
> if (is_secret) {                                        // suppose `is_secret == true` but branch mispredicts
>     // do something constant-time with `maybe_secret`
> } else {
>     return byte_array[maybe_secret * 4096];             // speculatively leak the secret
> }
> ```
> 
> I'm not opposed to merging the two approaches. But I am also not sure how to justify it.

Hi Scott, 

I'd like to push back on this submitted change. From what I can tell, using the SESES pass here would result in less code to maintain while fulfilling the goals of this change. That seems to be sufficient justification in a large codebases such as LLVM, though I'm open to arguments to the contrary.

Is there a reason to prefer this specific, newly implemented approach over the SESES model in this situation? I can't immediately see any benefit to adding another pass here that does largely the same thing (if in a less strict manner). I may be missing something, so please let me know if I am.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80964/new/

https://reviews.llvm.org/D80964