It might also depend on how AMD clears this temporal register across contexts, and the method it's updated.
The first I could think of (in the 5 minutes I've read this) is that it could be potentially ASLR breaking. As Agner says, it's highly useful for stack operations, but that also can help an adversary derive where the stack is.
Second, I could see an attack where the CPU predicts a sequence will use this register (since the address in the register could be speculative) and prefetch (since it kind of looks like it's prefetching) but it ends up being wrong and not killing/clearing the register, or not preventing its usage speculatively.
But it all depends heavily on lots of things. I feel like it's pretty similar to spec v4 in that exploitation would depend on the memory disambiguator, but we'll see.
Agner Fog mentions that the CPU assumes different registers have different values and the calculation has to be rerun if it turns out a write with one register invalidated a cached read with another register.
That means you can measure this penalty and infer that the registers had the same or overlapping addresses.
This is no different than the existing memory aliasing predictor that has existed for a long time already though, so it doesn't add any new speculation opportunity as far as I can tell.
A thread in the same process could observe the timing change and infer certain things about the memory address. This is mitigated by the fact that intra-thread and host-guest communication is already a side channel nightmare and everyone now only considers process boundaries to be defensible. It's sort of like worrying about someone being able to cut keys from a picture you posted on Facebook when all your house locks can be raked open with a $5 tool from Amazon.
