[llvm-bugs] [Bug 46202] speculative load hardening is insecure

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=46202

Chandler Carruth <chandlerc at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|NEW                         |RESOLVED

--- Comment #5 from Chandler Carruth <chandlerc at gmail.com> ---
At least as described in the bug report, this is not a bug in SLH.

Here is a cleaned up version of the asm, focusing on that instead of the C
code, but others seem to believe the C code matches my analysis as well:
```
mov rax, rsp // load predicate bit from stack pointer
sar rax, 63 // initialize mask (0xF...F if left−most bit of rax is 1)
movzx edx, [A + rdi] // load A[y]
or edx, eax // mask A[y]
mov x, edx // assignment to x
mov esi, size // load size
cmp rsi, rdi // compare size and y
jbe ELSE // jump if out−of−bound
THEN:
cmovbe rax, −1 // set mask to −1 if out−of−bound mov cl, [B + rdx] // load B[x]
or cl, al // mask B[x]
mov temp, cl // assignment to temp
jmp END
ELSE:
cmova rax, −1 // set mask to −1 if in−bound
END:
shl rax, 47
or rsp, rax // store predicate bit on stack pointer ret
```

The claim is that the data loaded with "load A[y]" above (line 3) is masked
prior to the conditional branch "compare size and y" (line 8) and thus will not
mask mispeculation of that conditional branch. That is correct, but misses the
point.

The load of `A[y]` occurs *before* the bounds check. Either this is a bug in
the software, or the load is safe. There is no speculative execution issue here
either way.

Once the load has completed (non-speculatively, or architecturally), SLH *will
not* mitigate side channels by design. We call this out in the design document
for SLH:
https://llvm.org/docs/SpeculativeLoadHardening.html
(under "Limitations of this approach:" bullet #3)

For now, closing as WAI.

However, if you have something different that you believe to be a *real*
vulnerability in SLH, *DO NOT REPORT IT HERE*. That will zero-day impacted
parties. Please follow a responsible disclosure process.

1) Report it in a *confidential* manner.
2) Provide a reasonable window for impacted parties to patch or mitigate.

For #2: To be extremely clear, one day is *unacceptable*. I would recommend the
Project Zero timeframe (90 days) at a minimum:
https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-faq.html

For #1: Some folks in the LLVM community are working on a dedicated email
address for LLVM, we don't yet have one. Feel free to email myself and Zola
directly for SLH or Spectre related issues. We may bring in other people if
needed. For other issues, I'd suggest sending an email or filing a bug
*without* details and asking who you should contact to report the issue.

-Chandler

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200604/86667aa4/attachment.html>