> My understanding is that the standard “breadcrumb” is that a cache line is > fetched into L1D, and that the cacheline in question will go into L1D even if > it was previously not cached at all. So flushing L1D will cause the timing > from a probe to be different, but the breadcrumb is still there, and the > attack will still work.
Flush not write back. The L1D is empty (or full of other stuff the way the prototype I tested did it as x86 lacked a true L1 flushing primitive) > > At best you have a microscopic window to attack it on the SMT pair. > > So only the extra clever attackers will pull it off. This isn’t all that > reassuring. It's going to be very hard for them to do that. You don't really have the timing control in userspace to do that sort of thing easily. At the end of the day it's an additional hardenening not a fix. It's designed to provide extra protection for the cases we don't know about until we find them and lfence them. All of this (and all sidechannel of any kind) is merely about reducing the bandwidth an attacker can achieve. The idea is that it's cheap enough that it's worth doing. > Or I would get a fancy new CPU and use UMONITOR and, unless UMONITOR is much > cleverer than I suspect it is, the gig is up. The time window for the attack > could be as small as you want, and UMONITOR will catch it. That would be an interesting line of attack. You would still have to navigate a fair bit of noise. Alan
