From: Jann Horn <jannh@google.com>
To: Minchan Kim <minchan@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>, Linux-MM <linux-mm@kvack.org>,
kernel list <linux-kernel@vger.kernel.org>,
Daniel Colascione <dancol@google.com>,
Dave Hansen <dave.hansen@intel.com>,
"Joel Fernandes (Google)" <joel@joelfernandes.org>
Subject: interaction of MADV_PAGEOUT with CoW anonymous mappings?
Date: Tue, 10 Mar 2020 19:08:28 +0100 [thread overview]
Message-ID: <CAG48ez0G3JkMq61gUmyQAaCq=_TwHbi1XKzWRooxZkv08PQKuw@mail.gmail.com> (raw)
Hi!
From looking at the source code, it looks to me as if using
MADV_PAGEOUT on a CoW anonymous mapping will page out the page if
possible, even if other processes still have the same page mapped. Is
that correct?
If so, that's probably bad in environments where many processes (with
different privileges) are forked from a single zygote process (like
Android and Chrome), I think? If you accidentally call it on a CoW
anonymous mapping with shared pages, you'll degrade the performance of
other processes. And if an attacker does it intentionally, they could
use that to aid with exploiting race conditions or weird
microarchitectural stuff (e.g. the new https://lviattack.eu/lvi.pdf
talks about "the assumption that attackers can provoke page faults or
microcode assists for (arbitrary) load operations in the victim
domain").
Should madvise_cold_or_pageout_pte_range() maybe refuse to operate on
pages with mapcount>1, or something like that? Or does it already do
that, and I just missed the check?
next reply other threads:[~2020-03-10 18:08 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-10 18:08 Jann Horn [this message]
2020-03-10 18:48 ` interaction of MADV_PAGEOUT with CoW anonymous mappings? Michal Hocko
2020-03-10 19:11 ` Jann Horn
2020-03-10 21:09 ` Michal Hocko
2020-03-10 22:48 ` Dave Hansen
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 \
--in-reply-to='CAG48ez0G3JkMq61gUmyQAaCq=_TwHbi1XKzWRooxZkv08PQKuw@mail.gmail.com' \
--to=jannh@google.com \
--cc=dancol@google.com \
--cc=dave.hansen@intel.com \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=minchan@kernel.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).