LWN: Comments on "Taming STIBP" https://lwn.net/Articles/773118/ This is a special feed containing comments posted to the individual LWN article titled "Taming STIBP". en-us Tue, 21 Oct 2025 18:56:55 +0000 Tue, 21 Oct 2025 18:56:55 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net Trust... https://lwn.net/Articles/775268/ https://lwn.net/Articles/775268/ john.carter <div class="FormattedComment"> <font class="QuotedText">&gt;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.</font><br> <p> Hmm.<br> <p> I would sort of expect if ThreadA has access to /proc/pidThreadB/mem <br> <p> It's trusted. (ie. it needn't rely on fancy attacks)<br> <p> If is hasn't, it's not trusted.<br> <p> <p> </div> Thu, 20 Dec 2018 00:26:14 +0000 Taming STIBP https://lwn.net/Articles/774039/ https://lwn.net/Articles/774039/ hmh <div class="FormattedComment"> That's how I understood it as well, but...<br> <p> 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.<br> <p> After all, it is all about ghosts, and ghosts are tricky ;-)<br> </div> Thu, 06 Dec 2018 09:59:45 +0000 Taming STIBP https://lwn.net/Articles/774005/ https://lwn.net/Articles/774005/ flussence <div class="FormattedComment"> Linus was not in the habit of calling people idiots. Bad ideas and corporations, sure.<br> <p> He had to stop because, among other reasons, actual idiots were misinterpreting it as celebrity endorsement of their misanthropic, diseased attitudes toward other people.<br> </div> Wed, 05 Dec 2018 21:41:18 +0000 Taming STIBP https://lwn.net/Articles/773979/ https://lwn.net/Articles/773979/ raistlin <div class="FormattedComment"> 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<br> </div> Wed, 05 Dec 2018 18:37:46 +0000 Taming STIBP https://lwn.net/Articles/773830/ https://lwn.net/Articles/773830/ KaiRo <div class="FormattedComment"> 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.<br> </div> Tue, 04 Dec 2018 17:24:47 +0000 "Go really slow" https://lwn.net/Articles/773616/ https://lwn.net/Articles/773616/ ncm <div class="FormattedComment"> ... 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.<br> <p> The cynicism is dizzying.<br> </div> Mon, 03 Dec 2018 15:09:07 +0000 Merged https://lwn.net/Articles/773506/ https://lwn.net/Articles/773506/ corbet This work has now been merged for the 4.20-rc5 release. Sat, 01 Dec 2018 22:28:47 +0000 Taming STIBP https://lwn.net/Articles/773503/ https://lwn.net/Articles/773503/ hmh <div class="FormattedComment"> Thanks, that explains everything!<br> </div> Sat, 01 Dec 2018 19:29:54 +0000 Taming STIBP https://lwn.net/Articles/773487/ https://lwn.net/Articles/773487/ pbonzini <div class="FormattedComment"> Ring 0 is not using the indirect branch predictor on affected processors, all indirect branches are patched at runtime to use retpolines instead.<br> </div> Sat, 01 Dec 2018 09:55:11 +0000 Taming STIBP https://lwn.net/Articles/773410/ https://lwn.net/Articles/773410/ hmh <div class="FormattedComment"> 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?<br> <p> Or is the BPB engineered in such a way that one ring cannot pollute/train/alias BPB entries for a different ring?<br> </div> Fri, 30 Nov 2018 17:40:35 +0000 Taming STIBP https://lwn.net/Articles/773390/ https://lwn.net/Articles/773390/ anselm <blockquote><em>The question really is, is it permisible to call someone "idiot" when you think it is deserved?</em></blockquote> <p> 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 <em>code</em> bad, or even idiotic if you must. But don't call <em>us</em> 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. </p> Fri, 30 Nov 2018 11:12:16 +0000 Taming STIBP https://lwn.net/Articles/773377/ https://lwn.net/Articles/773377/ dgm <div class="FormattedComment"> Absolutely. The parent comment insinuated that Linus was in fact calling everybody an idiot, all the time. This is, of course, false.<br> <p> 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.<br> <p> Better than censoring, we should promote communication styles that add to the *content* of the conversation.<br> </div> Fri, 30 Nov 2018 08:40:26 +0000 Taming STIBP https://lwn.net/Articles/773376/ https://lwn.net/Articles/773376/ unixbhaskar <div class="FormattedComment"> " Linus calling anyone an idiot" <br> <p> 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.<br> <p> 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. <br> <p> <p> </div> Fri, 30 Nov 2018 05:47:43 +0000 Taming STIBP https://lwn.net/Articles/773371/ https://lwn.net/Articles/773371/ mangix <div class="FormattedComment"> Unfortunately I miss Linus calling people idiots.<br> </div> Fri, 30 Nov 2018 02:22:19 +0000 Taming STIBP https://lwn.net/Articles/773362/ https://lwn.net/Articles/773362/ Sesse <div class="FormattedComment"> So now we have a (sort-of) solution to the slowdowns, and it did not involve Linus calling anyone an idiot.<br> <p> I will say the kernel is progressing on two fronts. Two thumbs up.<br> </div> Thu, 29 Nov 2018 23:43:18 +0000 Taming STIBP https://lwn.net/Articles/773340/ https://lwn.net/Articles/773340/ pbonzini <div class="FormattedComment"> 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.<br> <p> </div> Thu, 29 Nov 2018 19:38:03 +0000 "Go really slow" https://lwn.net/Articles/773329/ https://lwn.net/Articles/773329/ iabervon <div class="FormattedComment"> 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.<br> </div> Thu, 29 Nov 2018 17:37:26 +0000 "Go really slow" https://lwn.net/Articles/773320/ https://lwn.net/Articles/773320/ hansendc <div class="FormattedComment"> 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.<br> <p> 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.<br> <p> So, no this isn't about obscure workloads. It's about mixing normal workloads with sensitive ones that we want to protect.<br> </div> Thu, 29 Nov 2018 17:03:58 +0000 "Go really slow" https://lwn.net/Articles/773317/ https://lwn.net/Articles/773317/ epa <div class="FormattedComment"> 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?<br> <p> 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?<br> </div> Thu, 29 Nov 2018 16:17:41 +0000