> That being said, this issue is mitigated in all common OSes and latest microcode.

Emphasis on this issue, eh?

> I'll be curious as to what there is to learn from this...

I'm also very interested to see what you and the community can discover using this trick!

I'll eat my hat for this, but effectively the mitigation to this is clearing all caches and internal buffers in the CPU on each context switch.

I'm sure we'll see more types of leaks, but unless they're actively fetching invalid data [1], there isn't much sensitive data to leak anymore.

I don't think there is much during speculation that can load _new_ data during that window.

[1]: So far almost every CPU bug has leaked something in an internal cache.

A machine clear clears the pipeline. Does it clear these internal caches? There is, of course, no machine clear instruction. Could you construct a machine clearing sequence, insert it into the context switch code and test your hypothesis?

The `verrw` legacy instruction has been added to with microcode to flush internal caches (load buffers, store buffers, etc). Any serializing instruction should (hopefully) cause a pipeline flush. This is the mitigation solution Intel made available to OS developers and should be what is being used.

> I'll eat my hat for this, but effectively the mitigation to this is clearing all caches and internal buffers in the CPU on each context switch.

Are you talking about software context switches or hardware (hyperthreading) ones?

If HW threading constantly clears caches wouldn't it cause a huge performance loss? Isn't that something that can occur 1-100 million times per second?

Sadly, software context switch cache clearing is pretty much given these days.

In this case a privilege transition requires flushing caches. The scheduler has to be aware to not schedule two different permission levels/domains on the same core. It's a huge amount of osdev work to make hyperthreading "safe". I'll be curious if Intel doubles down on HT again.