Stuffing the return stack buffer [LWN.net]

Stuffing the return stack buffer

Posted Jul 24, 2022 10:56 UTC (Sun) by fw (subscriber, #26023)
Parent article: Stuffing the return stack buffer

Huh. Why doesn't the CPU execute the conditional branch in shlq $5, PER_CPU_VAR(__x86_call_depth); jz 1f speculatively, defeating the mitigation?

Stuffing the return stack buffer

Posted Jul 24, 2022 16:06 UTC (Sun) by mss (subscriber, #138799) [Link] (7 responses)

jz 1f is not an indirect branch.

Stuffing the return stack buffer

Posted Jul 24, 2022 17:12 UTC (Sun) by izbyshev (subscriber, #107996) [Link] (6 responses)

But it's directly followed by ret on the fallthrough path. If the speculation window could be arbitrarily large, I don't see what would prevent CPU from simply bypassing the RSB stuffing code by taking the fallthrough path N times where N is the size of the RSB, and then still using the attacker-controlled indirect branch predictor. So it seems that this mitigation relies on a certain upper bound on the size of the speculation window.

Stuffing the return stack buffer

Posted Jul 24, 2022 17:18 UTC (Sun) by izbyshev (subscriber, #107996) [Link] (5 responses)

And indeed, quoting the patch:

+ * The shift count might cause this to be off by one in either direction,
+ * but there is still a cushion vs. the RSB depth. The algorithm does not
+ * claim to be perfect and it can be speculated around by the CPU, but it
+ * is considered that it obfuscates the problem enough to make exploitation
+ * extremly difficult.

Stuffing the return stack buffer

Posted Jul 24, 2022 17:44 UTC (Sun) by Paf (subscriber, #91811) [Link] (1 responses)

Which seems fine, since if the CPU designers were involved, it’s probably ok for existing CPUs and fixed in future, right?

Stuffing the return stack buffer

Posted Jul 24, 2022 18:14 UTC (Sun) by izbyshev (subscriber, #107996) [Link]

I can't find any indications of Intel CPU designers being involved in this mitigation, but from what I could understand, the newest CPUs are not affected, so, indeed, the mitigation has to work only on a known set of CPUs.

Stuffing the return stack buffer

Posted Jul 26, 2022 0:24 UTC (Tue) by developer122 (guest, #152928) [Link] (2 responses)

In other words, "it's fixed until we discover otherwise"

Stuffing the return stack buffer

Posted Jul 26, 2022 13:47 UTC (Tue) by mss (subscriber, #138799) [Link] (1 responses)

Some knowledgeable people already say that:

Retpoline is not safe on Skylake-era CPUs, and we knew this before the Spectre/Meltdown embargo broke in Jan '18.

RSB stuffing relies on retpolines for Spectre v2 mitigation.

Stuffing the return stack buffer

Posted Jul 26, 2022 14:47 UTC (Tue) by izbyshev (subscriber, #107996) [Link]

> RSB stuffing relies on retpolines for Spectre v2 mitigation.

FWIW, it's vice versa: retpolines rely on RSB stuffing to make them less broken on Skylake.

But yeah, the general sentiment of that email is that apparently retpolines would be unsafe on Skylake even if RSB stuffing were added in all cases when the RSB might become empty.