linux-kernel - Re: [PATCH 0/4] mm: permit guard regions for file-backed/shmem 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: <7eacc1ca-f890-4ae4-9965-ee1a5832a59c@lucifer.local>
Date: Thu, 20 Feb 2025 09:53:04 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: Kalesh Singh <kaleshsingh@...gle.com>,
        David Hildenbrand <david@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Suren Baghdasaryan <surenb@...gle.com>,
        "Liam R . Howlett" <Liam.Howlett@...cle.com>,
        Matthew Wilcox <willy@...radead.org>,
        "Paul E . McKenney" <paulmck@...nel.org>, Jann Horn <jannh@...gle.com>,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Shuah Khan <shuah@...nel.org>, linux-kselftest@...r.kernel.org,
        linux-api@...r.kernel.org, John Hubbard <jhubbard@...dia.com>,
        Juan Yescas <jyescas@...gle.com>
Subject: Re: [PATCH 0/4] mm: permit guard regions for file-backed/shmem
 mappings

On Thu, Feb 20, 2025 at 10:22:29AM +0100, Vlastimil Babka wrote:
> On 2/20/25 09:51, Lorenzo Stoakes wrote:
> > On Wed, Feb 19, 2025 at 12:56:31PM -0800, Kalesh Singh wrote:
> >
> > As I said to you earlier, the _best_ we could do in smaps would be to add a
> > flag like 'Grd' or something to indicate some part of the VMA is
>
> In smaps we could say how many kB is covered by guard ptes and it would be
> in line with the current output, and the fact it's already scanning page
> tables, so virtually no new overhead. But it wouldn't tell you the address
> ranges, of course.

Yes right. Sorry, I didn't think to suggest this, the fundamental point
being that there is essentially a 'flag' or 'entry' saying 'there are
guard regions here'. And indeed that could include ranges.

But it doesn't tell you the actual address ranges which is what Kalesh
appears to require.

You could equally well find these, and the sizes (albeit less conveniently)
with a combination of /proc/$pid/maps and adding a guard bit to
/proc/$pid/pagemap.

>
> > guarded. But I won't do that unless somebody has an -actual use case- for
> > it.
>
> Right, we need to hear that first. Also I'm a bit confused about what's the
> issue with the existing Android apps and the proposals. Do the existing apps
> expect to see particular PROT_NONE regions, which would be gone (become part
> of the surrounding vma's) when using guards instead? Then clearly there's no
> way to use guards for them without breaking their assumptions.
>
> But assuming future versions of these apps for future android versions would
> have to adapt to guards instead of PROT_NONE, why do we have to promise them
> to represent the guards, if the point is just so they adapt to the new state
> of smaps in their dubious security checking code, and not break anymore?
>
> (but geez, if android apps are to use the android apis, which is java based
> (IIRC?) why were there ever allowed to read /proc in the first place? such a
> mistake, sigh)
>
> > David's /proc/$pid/pagemaps suggestion is excellent, avoids all the
> > pitfalls, exposes guard regions to anybody who really really wants to know
> > and doesn't interfere with anything else, so this is what we'll go with.
> >
> > Regards, Lorenzo
>