On Fri, Oct 12, 2018 at 5:03 PM Alan Cox <gno...@lxorguk.ukuu.org.uk> wrote: > > > 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)
What about the TLB? Once KPTI is unnecessary, are you going to need an extra TLB flush here to prevent PRIME+PROBE on the TLB? Also: Are you assuming that the attacker would only be able to do PRIME+PROBE, not FLUSH+RELOAD or other attacks that rely on shared memory (like FLUSH+FLUSH, or the MESI-based stuff that detects when a line stops being in modified state on another core)? > > > 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
