Maybe instead of just punting on MADV_PAGEOUT for map_count>1 we should only let it affect the *local* process. We could still put the page in the swap cache, we just wouldn't go do the rmap walk. On 3/10/20 2:09 PM, Michal Hocko wrote: > I still have to think about how this could be used for any reasonable > attack. While this sounds theoretically vulnerable, I'm having a hard time convincing myself that it's in any way practical. Code that's a victim to LVI has to hit a fault or an "assist". The most likely assist in this case is if the victim needs to set the PTE Accessed or Dirty bits. There would first need to be some secret that an attacker wants to steal, then some *other* data that directly or indirectly protects the secret. The load of the "other" data would be what needs to encounter the fault or the assist, and would also need to be able to speculatively reach a "disclosure gadget". The attacker would sit there and do MADV_PAGEOUT constantly, inducing lots of faults and assists and then _separately_ poison the microarchitectural buffers that lead to the "other" data getting an injected speculative value. If an app is vulnerable to this, it's probably going to need to be using the "other" data a *lot*. It's going to have a really hard time doing that because it's going to be handling page faults all the time. It also can't ever write to the data being shared, or it will break the COW.
