On Wed, 9 Jan 2019, Dave Chinner wrote: > FWIW, I just realised that the easiest, most reliable way to invalidate > the page cache over a file range is simply to do a O_DIRECT read on it. Neat, good catch indeed. Still, it's only the invalidation part, but the residency check is the crucial one. > > Rationale has been provided by Daniel Gruss in this thread -- if the > > attacker is left with cache timing as the only available vector, he's > > going to be much more successful with mounting hardware cache timing > > attack anyway. > > No, he said: > > "Restricting mincore() is sufficient to fix the hardware-agnostic > part." > > That's not correct - preadv2(RWF_NOWAIT) is also hardware agnostic and > provides exactly the same information about the page cache as mincore. Yeah, preadv2(RWF_NOWAIT) is in the same teritory as mincore(), it has "just" been overlooked. I can't speak for Daniel, but I believe he might be ok with rephrasing the above as "Restricting mincore() and RWF_NOWAIT is sufficient ...". > Timed read/mmap access loops for cache observation are also hardware > agnostic, and on fast SSD based storage will only be marginally slower > bandwidth than preadv2(RWF_NOWAIT). > > Attackers will pick whatever leak vector we don't fix, so we either fix > them all (which I think is probably impossible without removing caching > altogether) We can't really fix the fact that it's possible to do the timing on the HW caches though. > or we start thinking about how we need to isolate the page cache so that > information isn't shared across important security boundaries (e.g. page > cache contents are per-mount namespace). Umm, sorry for being dense, but how would that help that particular attack scenario on a system that doesn't really employ any namespacing? (which I still believe is a majority of the systems out there, but I might have just missed the containers train long time ago :) ). -- Jiri Kosina SUSE Labs
