[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cf95db88-968d-fee5-1c15-10d024c09d8a@intel.com>
Date: Tue, 10 Mar 2020 15:48:31 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Michal Hocko <mhocko@...nel.org>, Jann Horn <jannh@...gle.com>
Cc: Minchan Kim <minchan@...nel.org>, Linux-MM <linux-mm@...ck.org>,
kernel list <linux-kernel@...r.kernel.org>,
Daniel Colascione <dancol@...gle.com>,
"Joel Fernandes (Google)" <joel@...lfernandes.org>
Subject: Re: interaction of MADV_PAGEOUT with CoW anonymous mappings?
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.
Powered by blists - more mailing lists