LWN: Comments on "Stuffing the return stack buffer"

Stuffing the return stack buffer

immibis — Tue, 02 Aug 2022 17:13:27 +0000

"have the time dimension part of the ISA" is a rather pretentious way of saying "add an instruction to flush cached microarchitectural state"

Stuffing the return stack buffer

smitty_one_each — Fri, 29 Jul 2022 13:48:23 +0000

https://www.hyrumslaw.com/ tells us that someone, somewhere, is making use off all of these behavioral aspects of the chip.

And that is disquieting.

Stuffing the return stack buffer

izbyshev — Wed, 27 Jul 2022 20:53:36 +0000

> CPU designer often put in "chicken bits" for disabling new microarchitectural features, in case they turn out to be buggy.

Yeah, like this one :)

Stuffing the return stack buffer

anton — Wed, 27 Jul 2022 15:01:52 +0000

Actually it is somewhat surprising. CPU designer often put in "chicken bits" for disabling new microarchitectural features, in case they turn out to be buggy. You can then still sell the CPU instead of having to scrap it. And some of these chicken bits have been known to be used over the years (and probably many more were used before the CPUs were released, and the public never heard of them).

But when they designed this fallback from the return stack buffer to the history-based indirect branch predictor into Skylake, they apparently did not put a chicken bit for that in, probably because history-based indirect branch prediction had been present in Intel CPUs for many generations.

Stuffing the return stack buffer

izbyshev — Tue, 26 Jul 2022 14:47:10 +0000

> 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.

Stuffing the return stack buffer

mss — Tue, 26 Jul 2022 13:47:13 +0000

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

developer122 — Tue, 26 Jul 2022 00:24:05 +0000

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

Stuffing the return stack buffer

Paf — Sun, 24 Jul 2022 23:03:24 +0000

I mean, they talk about how to make that specific operation more efficient and it could be worse, but …….. yes.

Stuffing the return stack buffer

kenmoffat — Sun, 24 Jul 2022 20:24:39 +0000

So yes, not exactly the same vulnerability, but the same mitigation.

Stuffing the return stack buffer

Sesse — Sun, 24 Jul 2022 20:19:35 +0000

So all your syscalls are now basically as expensive as you can possibly make them?

Stuffing the return stack buffer

izbyshev — Sun, 24 Jul 2022 18:14:24 +0000

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

Paf — Sun, 24 Jul 2022 17:44:50 +0000

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

izbyshev — Sun, 24 Jul 2022 17:18:48 +0000

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

izbyshev — Sun, 24 Jul 2022 17:12:00 +0000

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

mss — Sun, 24 Jul 2022 16:06:35 +0000

jz 1f is not an indirect branch.

Stuffing the return stack buffer

izbyshev — Sun, 24 Jul 2022 14:36:07 +0000

I guess it does, and that's why "safety margin of four calls" mentioned in the article is needed.

Stuffing the return stack buffer

mss — Sun, 24 Jul 2022 14:13:59 +0000

The Intel affected CPU model page says that Ice Lake models are not affected by INTEL-SA-00702.

eIBRS parts had their own vulnerability in March (the relevant paper is here), which apparently can also be used to mount Retbleed-style attacks.

Stuffing the return stack buffer

kenmoffat — Sun, 24 Jul 2022 11:45:49 +0000

I've been told that Ice Lake and later, except Alder Lake are vulnerable, and that the mitigation will also run on Alder Lake until new firmware is applied. See INTEL-SA-00702

Stuffing the return stack buffer

fw — Sun, 24 Jul 2022 10:56:31 +0000

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

petkan — Sun, 24 Jul 2022 06:42:51 +0000

... and of course big "F*** you, Intel" for making 3/4 of all machines that i own a rather expensive paperweight.

Stuffing the return stack buffer

petkan — Sun, 24 Jul 2022 06:33:00 +0000

If you need _real_ security it just better to not use _any_ sort of computer. ;)

Stuffing the return stack buffer

developer122 — Sun, 24 Jul 2022 00:32:04 +0000

Microcode is not all-powerful. Certain key mechanisms must be hardwired for performance reasons.

Stuffing the return stack buffer

kenmoffat — Sat, 23 Jul 2022 21:42:00 +0000

My understanding is that on intel (AMD retbleed is a different vulnerability), anything before Skylake is not affected. Certainly, my haswell claims to be not vulnerable. And recent intel (gen 10 and later) are apparently also ok, so this seems to be only for generations 6 to 9.

Stuffing the return stack buffer

jhoblitt — Sat, 23 Jul 2022 19:13:51 +0000

That isn't surprising... even if a heroic microcode fix was possible, there is obviously a strong financial incentive to push customers towards purchasing new chips (which already have a, presumably, well validated mitigation).

I genuinely appreciate the effort and wizardry going into this problem. I suspect many are in the position of considering risk and evaluating which hosts need retbleed mitigation... and which subset of those can't afford a 1/3 loss of capacity.

It is looking like the ultimate solution is either to buy more hardware to compensate for increased kernel overhead or to upgrade to Intel "12th" gen or newer cpus with eIBRS support? Either option is difficult with the current unprecedented lead times on IT equipment.

Of course, I accepted delivery of 5 pallets of zen3 based servers immediately prior to the public retbleed disclosure.

Stuffing the return stack buffer

epa — Sat, 23 Jul 2022 16:26:59 +0000

...or somehow you arrange for all the cores sharing a cache to be running code from the same protection domain at the same time. When one context switches to a different user or to the kernel, they all must.

Stuffing the return stack buffer

Paf — Sat, 23 Jul 2022 14:47:11 +0000

Specifically, at context switches. So this looks to be only truly applicable on a system where cores are entirely independent or there’s just one core. This looks like a very limited mitigation and not much applicable to the larger cores we work with. It also relies on knowing what “all micro architecture state” is - part of the steady march of these issues has been people finding things that weren’t previously recognized as “state” worthy of protecting.

Stuffing the return stack buffer

tglx — Sat, 23 Jul 2022 14:42:36 +0000

Exactly zero. If that would be feasible we would not discuss such a workaround at all.

Stuffing the return stack buffer

Paf — Sat, 23 Jul 2022 14:41:47 +0000

“ We show that the addition of a single-instruction extension to the RISC-V ISA, that flushes microarchitectural state,”

That doesn’t sound like including the time domain…? It’s just flushing all state at certain transitions?

Stuffing the return stack buffer

jhoblitt — Sat, 23 Jul 2022 14:15:21 +0000

What are the odds that a microcode update could disable falling back on "other heuristics" when the RSB is exhausted?

Stuffing the return stack buffer

mss — Sat, 23 Jul 2022 13:23:29 +0000

Current CPUs are far faster than an Ivy Bridge CPU from a decade ago, even when the necessary mitigations for speculative execution vulnerabilities are enabled.

And these mitigations can always be disabled if not applicable to one's threat model.

Stuffing the return stack buffer

felixfix — Sat, 23 Jul 2022 03:39:39 +0000

Holy mackerel! There is nothing new under the sun!

Waaaay back when, late 1970s, I worked on Datapoint 2200/5500/6600 8 bit computers, Datapoint's extension of the basic 8008 into Z80 level, but different: no IX IY regs, had system/user modes, other differences.

It also had a 16 level hardware stack with no overflow or underflow detection or warning.

Its only interrupt was every millisecond whether you wanted it or not. Everything was polled.

We threw in a push, push, pop, pop, to force always using 3 levels of stack, because none of our interrupt code was supposed to use more than two levels, and user code was expected to never use more than 13 levels.

Deja vu all over again!

Stuffing the return stack buffer

scientes — Sat, 23 Jul 2022 00:40:00 +0000

The real another way is to have the time dimension part of the ISA:

Prevention of Microarchitectural Covert Channels on an Open-Source 64-bit RISC-V Core

Such as with this suggested new instruction, part of seL4 development.

Stuffing the return stack buffer

developer122 — Fri, 22 Jul 2022 22:11:09 +0000

That T430 thinkpad is feeling like a really great investment right about now.

Stuffing the return stack buffer

alonz — Fri, 22 Jul 2022 18:27:01 +0000

I like that last sentence ("all we can do right now is to speculate about that"). Yeah, look where speculation has brought us…