[llvm-dev] Spectre V1 Mitigation - Internals?

[Praveen Velliengiri via llvm-dev]

Hi all,

I understand how the speculative information flow attack works. I'm trying
get my head around the spectre v1 mitigation of LLVM.
In the design document here :
https://llvm.org/docs/SpeculativeLoadHardening.html#speculative-load-hardening.
<https://llvm.org/docs/SpeculativeLoadHardening.html#speculative-load-hardening>

Example:

void leak(int data);void example(int* pointer1, int* pointer2) {
  if (condition)
    leak(*pointer1);
  else
    leak(*pointer2);}

After the applying the mitigation the code resembles like:

void leak(int data);
void example(int* pointer1, int* pointer2) {
  uintptr_t predicate_state = all_ones_mask;
  if (condition) {
    predicate_state = !condition ? all_zeros_mask : predicate_state;
    pointer1 &= predicate_state;
    leak(*pointer1);
  } else {
    int value2 = *pointer2 & predicate_state;
    leak(value2);
  }
}

Let's assume that the branch is mispredicted and if body is taken. The
value predicate_state mask is depend on the "result of the condition"
but which is not yet available hence

speculative execution. My question whether the value of
predicate_state is also guessed by the processor? If it is correct,
then the value of predicate_state will be
predicate_state, if the processor mis-predicts the condition as true.
Is my assumption is correct? i.e predicate_state = ! 1 ?
all_zeros_mask : predicate_state, where processor predicts
condition as true.

Or Whether the execution stalls at "predicate_state = !condition ?
all_zeros_mask : predicate_state until the result of condition became
available? If this is true, why we have to

harden the pointers in the first place, because after the condition is
actually computed, the processors will revert back right the execution
trace of mis-prediction.

I know that I'm missing something fundamental here, I would highly
appreciate your help on this? Please let me know if you more info!

Cheeers,

Praveen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190916/bbcbbe51/attachment.html>