"Go really slow"

Posted Nov 29, 2018 16:17 UTC (Thu) by epa (subscriber, #39769)
Parent article: Taming STIBP

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?

"Go really slow"

Posted Nov 29, 2018 17:03 UTC (Thu) by hansendc (subscriber, #7363) [Link] (1 responses)

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.

Trust...

Posted Dec 20, 2018 0:26 UTC (Thu) by john.carter (guest, #123615) [Link]

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

"Go really slow"

Posted Nov 29, 2018 17:37 UTC (Thu) by iabervon (subscriber, #722) [Link] (1 responses)

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"

Posted Dec 3, 2018 15:09 UTC (Mon) by ncm (guest, #165) [Link]

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