From: Dave Hansen <firstname.lastname@example.org> To: Michal Hocko <email@example.com>, Jann Horn <firstname.lastname@example.org> Cc: Minchan Kim <email@example.com>, Linux-MM <firstname.lastname@example.org>, kernel list <email@example.com>, Daniel Colascione <firstname.lastname@example.org>, "Joel Fernandes (Google)" <email@example.com> Subject: Re: interaction of MADV_PAGEOUT with CoW anonymous mappings? Date: Tue, 10 Mar 2020 15:48:31 -0700 Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <20200310210906.GD8447@dhcp22.suse.cz> 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.
next prev parent reply index Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-10 18:08 Jann Horn 2020-03-10 18:48 ` Michal Hocko 2020-03-10 19:11 ` Jann Horn 2020-03-10 21:09 ` Michal Hocko 2020-03-10 22:48 ` Dave Hansen [this message] 2020-03-11 8:45 ` Michal Hocko 2020-03-11 22:02 ` Minchan Kim 2020-03-11 23:53 ` Shakeel Butt 2020-03-12 0:18 ` Minchan Kim 2020-03-12 2:03 ` Daniel Colascione 2020-03-12 15:15 ` Shakeel Butt 2020-03-10 20:19 ` Daniel Colascione 2020-03-10 21:40 ` Jann Horn 2020-03-10 21:52 ` Daniel Colascione 2020-03-10 22:14 ` Minchan Kim 2020-03-12 8:22 ` Michal Hocko 2020-03-12 15:40 ` Vlastimil Babka 2020-03-12 20:16 ` Minchan Kim 2020-03-12 20:26 ` Dave Hansen 2020-03-12 20:41 ` Michal Hocko 2020-03-13 2:08 ` Minchan Kim 2020-03-13 8:05 ` Michal Hocko 2020-03-13 20:59 ` Minchan Kim 2020-03-16 9:20 ` Michal Hocko 2020-03-17 1:43 ` Minchan Kim 2020-03-17 7:12 ` Michal Hocko 2020-03-17 15:00 ` Minchan Kim 2020-03-17 15:58 ` Michal Hocko 2020-03-17 17:20 ` Minchan Kim 2020-03-12 21:41 ` Dave Hansen 2020-03-13 2:00 ` Minchan Kim 2020-03-13 16:59 ` Dave Hansen 2020-03-13 21:13 ` Minchan Kim 2020-03-12 23:29 ` Jann Horn
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-mm Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-mm/0 linux-mm/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-mm linux-mm/ https://lore.kernel.org/linux-mm \ firstname.lastname@example.org public-inbox-index linux-mm Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kvack.linux-mm AGPL code for this site: git clone https://public-inbox.org/public-inbox.git