On Tue, Jan 08, 2019 at 09:57:49AM -0800, Linus Torvalds wrote: > On Mon, Jan 7, 2019 at 8:43 PM Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > > > So, I read the paper and before I was half way through it I figured > > there are a bunch of other similar page cache invalidation attacks > > we can perform without needing mincore. i.e. Focussing on mmap() and > > mincore() misses the wider issues we have with global shared caches. > > Oh, agreed, and that was discussed in the original report too. > > The thing is, you can also depend on our pre-faulting of pages in the > page fault handler, and use that to get the cached status of nearby > pages. So do something like "fault one page, then do mincore() to see > how many pages near it were mapped". See our "do_fault_around()" > logic. Observing fault-around could help you detect what code an application is running, but it's not necessary (and can be turned off). Also, such an it observation is not dependent on using mincore. neither fault-around nor mincore are required functionality to exploit the information leaks. And, FWIW, fault-around actually destroys the information in the exfiltration channel described in the paper because it perturbs the carefully constructed page cache residency pattern that encodes the message. > But mincore is certainly the easiest interface, and the one that > doesn't require much effort or setup. Off the top of my head, here's a few vectors for reading the page cache residency state without perturbing the page cache residency pattern: - mincore - preadv2(RWF_NOWAIT) - fadvise(POSIX_FADV_RANDOM); timed read(2) syscalls - madvise(MADV_RANDOM); timed read of first byte in each page i.e. mincore is a messenger, but it's not the only trivial observation technique available. The only difference between mincore and the others will be the observation latency and hence channel bandwidth. IOWs, the question we need to focus on now is not "does breaking mincore affect anyone", it is "how the hell do we mitigate and isolate an information leak exposed by fundamental OS functionality that *everything* depends on for performance"? > It's also the one where our old > behavior was actually arguably simply stupid and actively wrong (ie > "in caches" isn't even strictly speaking a valid question, since the > caches in question may be invalid). This is irrelevant to the problem reported. Sure, mincore may be an awful interface, but it's semantics are not the cause of the information leak. You're just shooting the messenger... > I do think that the RWF_NOWAIT case might also be interesting to look at. As are all the other mechanisms you can use to observer page cache residency without perturbing it's state. Keep in mind that the researchers documented a remote observation technique that leaked the information across the network to a remote host, so this leak has much, much wider scope than changing mincore can address... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
