LWN: Comments on "Taming STIBP"

Trust...

john.carter — Thu, 20 Dec 2018 00:26:14 +0000

>Also, remember that we have very limited support for comprehending the trust relationship between any software threads running on a CPU core. We largely don't know if they trust each other or not.

Hmm.

I would sort of expect if ThreadA has access to /proc/pidThreadB/mem

It's trusted. (ie. it needn't rely on fancy attacks)

If is hasn't, it's not trusted.

Taming STIBP

hmh — Thu, 06 Dec 2018 09:59:45 +0000

That's how I understood it as well, but...

While it is likely to be true for "enhanced IBRS" (the one you leave always on, and which doesn't exist quite yet), for the current crop of processors that are way too prone to leak fleeting images of a future past, IMHO it is a IBRS property better tested before being trusted to exist.

After all, it is all about ghosts, and ghosts are tricky ;-)

Taming STIBP

flussence — Wed, 05 Dec 2018 21:41:18 +0000

Linus was not in the habit of calling people idiots. Bad ideas and corporations, sure.

He had to stop because, among other reasons, actual idiots were misinterpreting it as celebrity endorsement of their misanthropic, diseased attitudes toward other people.

Taming STIBP

raistlin — Wed, 05 Dec 2018 18:37:46 +0000

Yep. Or, if one does not use retpoline, and uses IBRS instead (e.g., on future hardware where that may be faster, or as Xen does already, in some cases), that --I mean setting IBRS when entering ring 0-- prevents BTB updates done in ring 3 to affect branches in context with more privilege (like ring 0). Or so I've understood. :-D

Taming STIBP

KaiRo — Tue, 04 Dec 2018 17:24:47 +0000

I do not, as IMHO calling anyone an idiot (or stupid, or similar) is simply unacceptable between decent human beings. Calling a product of their work idiotic or saying they behave stupidly or something in that manner is still bad behavior but somewhat better, it usually can and should be said with as precise but less strong words. People themselves should never be attacked, it's enough to criticize (hopefully constructively) their actual work that you take issue with.

"Go really slow"

ncm — Mon, 03 Dec 2018 15:09:07 +0000

... and, since older CPUs are slowed, people are motivated to replace them with new. If you can't make new CPUs faster than the old ones, sometimes it suffices to make the old CPUs slower than the new ones.

The cynicism is dizzying.

Merged

corbet — Sat, 01 Dec 2018 22:28:47 +0000

This work has now been merged for the 4.20-rc5 release.

Taming STIBP

hmh — Sat, 01 Dec 2018 19:29:54 +0000

Thanks, that explains everything!

Taming STIBP

pbonzini — Sat, 01 Dec 2018 09:55:11 +0000

Ring 0 is not using the indirect branch predictor on affected processors, all indirect branches are patched at runtime to use retpolines instead.

Taming STIBP

hmh — Fri, 30 Nov 2018 17:40:35 +0000

I am probably worring over nothing, but when you have one SMT running in kernel mode (ring 0), and a sibling SMT running userspace code (ring 3), wouldn't STIBP be required to avoid the side-channel, since the BPB is shared?

Or is the BPB engineered in such a way that one ring cannot pollute/train/alias BPB entries for a different ring?

Taming STIBP

anselm — Fri, 30 Nov 2018 11:12:16 +0000

The question really is, is it permisible to call someone "idiot" when you think it is deserved?

I don't think people actually deserve being called “idiots” if they write ill-advised code. I've done that for sure, you've probably done it on occasion, even Linus Torvalds has probably done it once or twice. If it happens, by all means call our code bad, or even idiotic if you must. But don't call us idiots. Certainly not over the Internet. If you want to call me an idiot, do it to my face or don't do it at all.

Taming STIBP

dgm — Fri, 30 Nov 2018 08:40:26 +0000

Absolutely. The parent comment insinuated that Linus was in fact calling everybody an idiot, all the time. This is, of course, false.

The question really is, is it permisible to call someone "idiot" when you think it is deserved? If it is not, then what we are effectively doing is censoring the word "idiot". Censoring words is an idiotic (sorry, I mean much less than adequate), way to proceed, because people will find ways to "politely" be as much offensive.

Better than censoring, we should promote communication styles that add to the *content* of the conversation.

Taming STIBP

unixbhaskar — Fri, 30 Nov 2018 05:47:43 +0000

" Linus calling anyone an idiot"

I am sorry and think you are hindsight and missing the context of those calling in the past. There is no point spreading the FUD, please don't.

No, I am not in favor of abusing people in any form or anybody doing it publicly, but there was some context before that calling, please do care to read those, which led to that outburst.

Taming STIBP

mangix — Fri, 30 Nov 2018 02:22:19 +0000

Unfortunately I miss Linus calling people idiots.

Taming STIBP

Sesse — Thu, 29 Nov 2018 23:43:18 +0000

So now we have a (sort-of) solution to the slowdowns, and it did not involve Linus calling anyone an idiot.

I will say the kernel is progressing on two fronts. Two thumbs up.

Taming STIBP

pbonzini — Thu, 29 Nov 2018 19:38:03 +0000

The factdl that this patch made it through the maintainers is probably a late effect of the secrecy that covered all the Spectre/Meltdown work one year ago. It was not documented, but still known, that IBRS and STIBP were, at least for some processors, a bigger hammer than what the documentation suggested.

"Go really slow"

iabervon — Thu, 29 Nov 2018 17:37:26 +0000

I assume this is like most ISA additions: new CPUs implement them efficiently, so they're faster than the alternatives, while old CPUs implement them correctly, so programs function. It's just that the new CPUs that can split the BPB by thread and run fast with STIBP don't exist at all yet.

"Go really slow"

hansendc — Thu, 29 Nov 2018 17:03:58 +0000

Remember, this is all about the *indirect* branch predictor (The I in STIBP is "Indirect"). STIBP does not disable all branch prediction. Also, the impact can vary drastically based on the microarchitecture. A processor that has hardware mitigations for Spectre v2 might enumerate support for STIBP and allow it to be enabled, but have negligible additional overhead.

Also, remember that we have very limited support for comprehending the trust relationship between any software threads running on a CPU core. We largely don't know if they trust each other or not.

So, no this isn't about obscure workloads. It's about mixing normal workloads with sensitive ones that we want to protect.

"Go really slow"

epa — Thu, 29 Nov 2018 16:17:41 +0000

Why would anyone want to enable this "go really slow" mode (disabling branch prediction) rather than just getting the "go slightly slower" effect of disabling hyperthreading? What exactly is Intel's envisaged use for it?

Are there some obscure workloads where hyperthreading gives a big speedup, but branch prediction doesn't really matter, and moreover the hyperthreaded tasks on the same CPU don't trust each other?