Message-ID: <881c3558-1101-496e-9ef4-5bef13f3f233@suse.cz>
Date: Thu, 23 Jan 2025 09:40:48 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: enh <enh@...gle.com>, "Liam R. Howlett" <Liam.Howlett@...cle.com>,
 Jeff Xu <jeffxu@...omium.org>, Pedro Falcato <pedro.falcato@...il.com>,
 Benjamin Berg <benjamin@...solutions.net>,
 Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, Kees Cook <kees@...nel.org>,
 akpm@...ux-foundation.org, jannh@...gle.com, torvalds@...ux-foundation.org,
 adhemerval.zanella@...aro.org, oleg@...hat.com,
 linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org,
 linux-mm@...ck.org, jorgelo@...omium.org, sroettger@...gle.com,
 ojeda@...nel.org, adobriyan@...il.com, anna-maria@...utronix.de,
 mark.rutland@....com, linus.walleij@...aro.org, Jason@...c4.com,
 deller@....de, rdunlap@...radead.org, davem@...emloft.net, hch@....de,
 peterx@...hat.com, hca@...ux.ibm.com, f.fainelli@...il.com, gerg@...nel.org,
 dave.hansen@...ux.intel.com, mingo@...nel.org, ardb@...nel.org,
 mhocko@...e.com, 42.hyeyoo@...il.com, peterz@...radead.org, ardb@...gle.com,
 rientjes@...gle.com, groeck@...omium.org, mpe@...erman.id.au,
 Andrei Vagin <avagin@...il.com>, Dmitry Safonov <0x7f454c46@...il.com>,
 Mike Rapoport <mike.rapoport@...il.com>,
 Alexander Mikhalitsyn <aleksandr.mikhalitsyn@...onical.com>
Subject: Re: [PATCH v4 1/1] exec: seal system mappings

On 1/22/25 23:29, enh wrote:
> On Wed, Jan 22, 2025 at 12:24 PM Liam R. Howlett
> <Liam.Howlett@...cle.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
>>
>>

Powered by blists - more mailing lists