From: Matthew Wilcox <willy@infradead.org>
To: enh <enh@google.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Jeff Xu <jeffxu@chromium.org>,
Pedro Falcato <pedro.falcato@gmail.com>,
Benjamin Berg <benjamin@sipsolutions.net>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Kees Cook <kees@kernel.org>,
akpm@linux-foundation.org, jannh@google.com,
torvalds@linux-foundation.org, adhemerval.zanella@linaro.org,
oleg@redhat.com, linux-kernel@vger.kernel.org,
linux-hardening@vger.kernel.org, linux-mm@kvack.org,
jorgelo@chromium.org, sroettger@google.com, ojeda@kernel.org,
adobriyan@gmail.com, anna-maria@linutronix.de,
mark.rutland@arm.com, linus.walleij@linaro.org, Jason@zx2c4.com,
deller@gmx.de, rdunlap@infradead.org, davem@davemloft.net,
hch@lst.de, peterx@redhat.com, hca@linux.ibm.com,
f.fainelli@gmail.com, gerg@kernel.org,
dave.hansen@linux.intel.com, mingo@kernel.org, ardb@kernel.org,
mhocko@suse.com, 42.hyeyoo@gmail.com, peterz@infradead.org,
ardb@google.com, rientjes@google.com, groeck@chromium.org,
mpe@ellerman.id.au, Andrei Vagin <avagin@gmail.com>,
Dmitry Safonov <0x7f454c46@gmail.com>,
Mike Rapoport <mike.rapoport@gmail.com>,
Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>,
Christopher Ferris <cferris@google.com>
Subject: Re: [PATCH v4 1/1] exec: seal system mappings
Date: Thu, 23 Jan 2025 22:38:32 +0000 [thread overview]
Message-ID: <Z5LE6BkIQjgyVfvb@casper.infradead.org> (raw)
In-Reply-To: <CAJgzZoq29GzVsqAMrGiKoUpXFPVjPRQRO87SiagaQCVXfH90Lw@mail.gmail.com>
On Thu, Jan 23, 2025 at 04:50:46PM -0500, enh wrote:
> yeah, at this point i should (a) drag in +cferris who may have actual
> experience of this and (b) admit that iirc i've never personally seen
> _evidence_ of this, just claims. most famously in the chrome source...
> if you `grep -r /proc/.*/maps` you'll find lots of examples, but
> something like https://chromium.googlesource.com/chromium/src/+/main/base/debug/proc_maps_linux.h#61
> is quite representative of the "folklore" in this area.
That folklore is 100% based on a true story! I'm not sure that all of
the details are precisely correct, but it's true enough that I wouldn't
quibble with it.
In fact, we want to make it worse. Because the mmap_lock is such a
huge point of contention, we want to read /proc/PID/maps protected
only by RCU. That will relax the guarantees to:
a. If a VMA existed and was not modified during the duration of the
read, it will definitely be returned.
b. If a VMA was added during the call, it might be returned.
c. If a VMA was removed during the call, it might be returned.
d. If an address was covered by a VMA before the call and that
VMA was modified during the call, you might get the prior or
posterior state of the VMA. And you might get both!
What might be confusing:
e. If VMA A is added, then VMA B is added, your call might show you VMA
B and not VMA A.
f. Similarly for deleted.
g. If you have, say, a VMA from (4000-9000) and you mprotect the region
(5000-6000), you might see:
4000-9000 oldA
or
4000-5000 newA
4000-9000 oldA
or
4000-5000 newA
5000-6000 newB
4000-9000 oldA
or
4000-5000 newA
5000-6000 newB
6000-9000 newC
(it's possible other combinations might be visible; i'm not working on
the details of this right now)
We shouldn't be able to _skip_ a VMA. That seems far worse than
returning duplicates; if your maps parser sees duplicates it can either
try to figure it out itself, or retry the whole read.
next prev parent reply other threads:[~2025-01-23 22:38 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-25 20:20 [PATCH v4 0/1] Seal " jeffxu
2024-11-25 20:20 ` [PATCH v4 1/1] exec: seal " jeffxu
2024-11-25 20:40 ` Matthew Wilcox
2024-12-02 17:22 ` Jeff Xu
2024-12-02 17:57 ` Lorenzo Stoakes
2024-12-02 20:05 ` Jeff Xu
2024-12-02 19:57 ` Jeff Xu
2024-12-02 18:29 ` Lorenzo Stoakes
2024-12-02 20:38 ` Jeff Xu
2024-12-03 7:35 ` Lorenzo Stoakes
2024-12-03 18:19 ` Jeff Xu
2024-12-03 20:16 ` Lorenzo Stoakes
2024-12-04 14:04 ` Benjamin Berg
2024-12-04 17:43 ` Jeff Xu
2024-12-04 18:24 ` Benjamin Berg
2024-12-10 4:12 ` Andrei Vagin
2024-12-11 22:46 ` Jeff Xu
2024-12-13 6:33 ` Andrei Vagin
2024-12-16 18:35 ` Jeff Xu
2024-12-16 18:56 ` Liam R. Howlett
2024-12-16 20:20 ` Jeff Xu
2024-12-17 22:18 ` Kees Cook
2025-01-02 19:15 ` Andrei Vagin
2025-01-03 20:48 ` Liam R. Howlett
2025-01-07 1:17 ` Kees Cook
2025-02-04 18:17 ` Johannes Berg
2025-01-03 21:38 ` Lorenzo Stoakes
2025-01-07 1:12 ` Kees Cook
2025-01-13 21:26 ` Jeff Xu
2025-01-14 4:19 ` Matthew Wilcox
2025-01-15 19:02 ` Jeff Xu
2025-01-15 19:46 ` Lorenzo Stoakes
2025-01-15 20:20 ` Jeff Xu
2025-01-16 15:48 ` Lorenzo Stoakes
2025-01-16 17:01 ` Benjamin Berg
2025-01-16 17:16 ` Lorenzo Stoakes
2025-01-16 17:18 ` Pedro Falcato
2025-01-17 18:20 ` Jeff Xu
2025-01-17 19:35 ` enh
2025-01-17 20:15 ` Jeff Xu
2025-01-17 22:08 ` Liam R. Howlett
2025-01-21 15:38 ` enh
2025-01-22 17:23 ` Liam R. Howlett
2025-01-22 22:29 ` enh
2025-01-23 8:40 ` Vlastimil Babka
2025-01-23 21:50 ` enh
2025-01-23 22:38 ` Matthew Wilcox [this message]
2025-02-06 14:19 ` enh
2025-02-06 13:20 ` Thomas Weißschuh
2025-02-06 14:38 ` enh
2025-02-06 15:28 ` Thomas Weißschuh
2025-02-06 15:51 ` enh
2025-02-06 16:37 ` Thomas Weißschuh
2025-01-17 18:08 ` Jeff Xu
2025-01-15 23:52 ` Kees Cook
2025-01-16 5:26 ` Christoph Hellwig
2025-01-16 19:40 ` Kees Cook
2025-01-17 10:14 ` Heiko Carstens
2025-01-16 15:34 ` Lorenzo Stoakes
2025-01-16 19:44 ` Kees Cook
2024-11-26 16:39 ` [PATCH v4 0/1] Seal " Lorenzo Stoakes
2024-12-02 17:28 ` Jeff Xu
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=Z5LE6BkIQjgyVfvb@casper.infradead.org \
--to=willy@infradead.org \
--cc=0x7f454c46@gmail.com \
--cc=42.hyeyoo@gmail.com \
--cc=Jason@zx2c4.com \
--cc=Liam.Howlett@oracle.com \
--cc=adhemerval.zanella@linaro.org \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=aleksandr.mikhalitsyn@canonical.com \
--cc=anna-maria@linutronix.de \
--cc=ardb@google.com \
--cc=ardb@kernel.org \
--cc=avagin@gmail.com \
--cc=benjamin@sipsolutions.net \
--cc=cferris@google.com \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=deller@gmx.de \
--cc=enh@google.com \
--cc=f.fainelli@gmail.com \
--cc=gerg@kernel.org \
--cc=groeck@chromium.org \
--cc=hca@linux.ibm.com \
--cc=hch@lst.de \
--cc=jannh@google.com \
--cc=jeffxu@chromium.org \
--cc=jorgelo@chromium.org \
--cc=kees@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mark.rutland@arm.com \
--cc=mhocko@suse.com \
--cc=mike.rapoport@gmail.com \
--cc=mingo@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=ojeda@kernel.org \
--cc=oleg@redhat.com \
--cc=pedro.falcato@gmail.com \
--cc=peterx@redhat.com \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=rientjes@google.com \
--cc=sroettger@google.com \
--cc=torvalds@linux-foundation.org \
--cc=vbabka@suse.cz \
/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