[PATCH] D41761: Introduce llvm.nospeculateload intrinsic

[Kristof Beyls via Phabricator via llvm-commits]

kristof.beyls added a subscriber: eli.friedman.
kristof.beyls added a comment.

In https://reviews.llvm.org/D41761#990166, @efriedma wrote:

> In https://reviews.llvm.org/D41761#989799, @efriedma wrote:
>
> > > How can two variant-1 attacks be "different" enough that a speculationsafeload would protect against one but not the other, when both exploit the same load operation
> >
> > Sorry, wasn't quite clear.  There are two speculated loads for a variant-1 attack: the load that reads the secret, and the load that leaks the secret to the user.  The first load has to be speculation-safe to stop the attack; whether the second is speculation-safe is irrelevant, at least in the proposals so far.  That isn't really a fundamental problem, just an illustration that reasoning about these attacks is tricky.
>
>
> Wait, no, this isn't right.  It is actually possible to attack a speculationsafeload, at least in theory.
>
> In general, the logic behind the "soft" speculation barriers being proposed is that they block execution if a speculation check fails.  But given that the speculation check is itself computed speculatively, you have to ensure that not only is the result correct in the normal sense, but also that it's correct when computed speculatively.  And as I showed earlier, IR transforms can turn an arbitrary value into a speculatively-uninitialized value.  Therefore, the speculation check can spuriously succeed, and the speculation barrier doesn't reliably prevent speculation.


I've found the last sentence a bit cryptic. Even though I think I understand what you're pointing out here, I would like to clarify my understanding is correct with the following example (using the SecureBoundedOffset API @gromer proposed):

  if (Wednesday) {
     limit = 2;
  } else {
     limit = 3;
  }
  
  if (a < 0 || a >= limit)
     return;
  
  a = SecureBoundedOffset(a, limit);
  v = b[a];

With `limit` itself potentially having a value based on misspeculation (e.g. what happens when Wednesday is true, and a==2, and both if statements get mispredicted)?
I hope this is an example of what you were referring to @eli.friedman? Or did I misunderstand? 
If so, I think there are ways to use the intrinsic multiple times to protect against this - but I'm not sure that's how you envision the use of the intrinsic, @gromer?


https://reviews.llvm.org/D41761