[PATCH] D41761: Introduce llvm.nospeculateload intrinsic

[Eli Friedman via Phabricator via llvm-commits]

efriedma added a comment.

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.


https://reviews.llvm.org/D41761