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

[via llvm-bugs]

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

            Bug ID: 46202
           Summary: speculative load hardening is insecure
           Product: new-bugs
           Version: 10.0
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: mp at cs.stanford.edu
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org

Created attachment 23577
  --> https://bugs.llvm.org/attachment.cgi?id=23577&action=edit
c and asm files

The way SLH is applied in order to mask values that are loaded from memory is
insecure.

Take the code in the c attachment.
a high-level summary of that code is :

void get (int y) x = A[y];
if (y < size)
temp = B[x];

Compiling it with Clang 10 with -x86-speculative-load-hardening flag enabled
emits the code in the asm attachment, whose simplification is :

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 masking of A[y] is ineffective, so when its content is accessed during
speculation, it is not masked.
This leads to speculative leaks, i.e., the SLH countermeasure is ineffective.

A longer detail of this bug can be found here, see Section V (please access it
after Friday June 5th, new version is being uploaded)
https://arxiv.org/pdf/1910.08607.pdf

In short, SLH currently masks the output of memory instructions.
The fix is to mask the input of memory operations and not the output.
Concretely, a good fix is discussed in a longer technical work of Blade: 
https://arxiv.org/pdf/2005.00294.pdf

-- 
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/8390a04d/attachment.html>