linux-hardening - Re: [PATCH v4 1/1] exec: seal system mappings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJgzZoovOhEFAcG93iQ2_iTLyqKf-TLzLJAX2vZnOWUC0Waq=A@mail.gmail.com>
Date: Thu, 6 Feb 2025 09:19:12 -0500
From: enh <enh@...gle.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: Vlastimil Babka <vbabka@...e.cz>, "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>, 
	Christopher Ferris <cferris@...gle.com>
Subject: Re: [PATCH v4 1/1] exec: seal system mappings

On Thu, Jan 23, 2025 at 5:38 PM Matthew Wilcox <willy@...radead.org> wrote:

[heh, long time no see! haven't been on an email thread with you in a
while :-) ]

> 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.

yeah, fwiw i can't think i've seen a case where a duplicate would
matter --- half the code i've seen ["tell me more about the VMA
containing this address"] would just stop at the first match anyway
(though that's exactly the case where i'd rather have "direct access"
than have to search), and the other half ["give me a snapshot of all
the VMAs for offline debugging purposes"] doesn't really bother with
interpretation and leaves that up to humans.