From: Vlastimil Babka <vbabka@suse.cz>
To: enh <enh@google.com>, "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>
Subject: Re: [PATCH v4 1/1] exec: seal system mappings
Date: Thu, 23 Jan 2025 09:40:48 +0100 [thread overview]
Message-ID: <881c3558-1101-496e-9ef4-5bef13f3f233@suse.cz> (raw)
In-Reply-To: <CAJgzZopiyhq9Wpu+gxUssoNhQT7tNjiey0JGsKPJAXjraEBRiw@mail.gmail.com>
On 1/22/25 23:29, enh wrote:
> On Wed, Jan 22, 2025 at 12:24 PM Liam R. Howlett
> <Liam.Howlett@oracle.com> wrote:
>>
>>
>> We are making changes in this area. Can you elaborate on the 'awkward'
>> part? The locking or the tearing of data?
>>
>> The way you state the page, it makes me think it's the tearing that is
>> the issue? I think the ioctl would be worse for the possible tearing of
>> data.
>
> there are two main styles of use of the /proc/<pid>/maps data i've
> seen in userspace:
>
> 1. i need to know about _all_ the vmas, so i'm reading the whole file
> and stitching it together.
> 2. i need to know about the vma containing a specific address, so i'm
> reading line-by-line looking for a match.
>
> the former is typically just for humans anyway (to be added to a crash
> report) -- so the ability to sendfile() or whatever would be something
> we could use there (though i've no idea whether that actually solves
> the tearing issue) -- so those use cases mostly tend to ignore (or not
> notice) the problem.
>
> for the latter, tearing is a bigger problem because what does "not
> found" mean? do we try again? how many times do we try? so i think the
> ioctl() would solve those problems. plus it would be a lot cheaper,
> and in particular not require [or at least "strongly benefit from"]
> dynamic memory allocation like parsing a text file does.
IIUC tearing can only happen in place of parallel changes (mmap/munmap etc)
by another thread, but if it does not affect the VMA in question it
shouldn't lead to skipping it. If it does affect it, the query would be
inherently racy anyway.
One corner case I can however think of is a modification of a previous vma
leads to merging with the vma we are querying but even then IIRC the races
could mean the previous vma could be reported still as separate, but then
followed by the merged result, so the virtual address range corresponding of
the previous vma would appear twice in the report, not that a range would be
skipped.
But if you have examples of a different experience, i.e. where a vma would
indeed be missing, we would be eager to hear that!
I think the ioctl interface lets you "seek" to the address of interest
quickly, but I believe it also can't eliminate these racing issues completely.
>> Thanks,
>> Liam
>>
>>
next prev parent reply other threads:[~2025-01-23 8:40 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 [this message]
2025-01-23 21:50 ` enh
2025-01-23 22:38 ` Matthew Wilcox
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=881c3558-1101-496e-9ef4-5bef13f3f233@suse.cz \
--to=vbabka@suse.cz \
--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=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 \
/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