On Fri, Jan 11, 2019 at 08:26:14AM -0800, Linus Torvalds wrote: > On Thu, Jan 10, 2019 at 11:36 PM Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > > > > It's only that single page that *matters*. That's the page that the > > > probe reveals the status of - but it's also the page that the probe > > > then *changes* the status of. > > > > It changes the state of it /after/ we've already got the information > > we need from it. It's not up to date, it has to come from disk, we > > return EAGAIN, which means it was not in the cache. > > Oh, I see the confusion. > > Yes, you get the information about whether something was in the cache > or not, so the side channel does exist to some degree. > > But it's actually hugely reduced for a rather important reason: the > _primary_ reason for needing to know whether some page is in the cache > or not is not actually to see if it was ever accessed - it's to see > that the cache has been scrubbed (and to _guide_ the scrubbing), and > *when* it was accessed. Oh, you're assuming that you need to probe the page cache to determine if brute force invalidation has progressed far enough to invalidate the page in question. I'm assuming that you can invalidate the page cache reliably by a means that does not repeated require probing to detect invalidation has occurred. I've mentioned one method in this discussion already... IOWs, just because the specific brute force attack documented in the paper required repeated probing it doesn't mean all future invalidation attacks will require repeated probing. Hence a robust defense mechanism should not rely on the attacker requiring multiple observations of the page cache to extract the information they are seeking... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
