linux-kernel - Re: [PATCH] docs/mm: expand vma doc to highlight pte freeing, non-vma traversal

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] [day] [month] [year] [list]

Message-ID: <685b78df-2dde-4e83-aa2a-3b105aa1c0ad@lucifer.local>
Date: Tue, 3 Jun 2025 19:52:27 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Jann Horn <jannh@...gle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
        Suren Baghdasaryan <surenb@...gle.com>,
        "Liam R . Howlett" <Liam.Howlett@...cle.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Shakeel Butt <shakeel.butt@...ux.dev>,
        Jonathan Corbet <corbet@....net>,
        Qi Zheng <zhengqi.arch@...edance.com>, linux-mm@...ck.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] docs/mm: expand vma doc to highlight pte freeing,
 non-vma traversal

On Tue, Jun 03, 2025 at 08:36:13PM +0200, Jann Horn wrote:
> On Tue, Jun 3, 2025 at 12:45 PM Lorenzo Stoakes
> <lorenzo.stoakes@...cle.com> wrote:
> > On Tue, Jun 03, 2025 at 12:25:36AM +0200, Jann Horn wrote:
> > > The one way in which I think this is currently kinda yolo/broken is
> > > that vmap_try_huge_pud() can end up freeing page tables via
> > > pud_free_pmd_page(), while holding no MM locks AFAICS, so that could
> > > race with the ptdump debug logic such that ptdump walks into freed
> > > page tables?
> >
> > But those mappings would be kernel mappings? How could ptdump walk into
> > those?
>
> /sys/kernel/debug/page_tables/kernel dumps kernel page tables. And I
> think /sys/kernel/debug/page_tables/current_kernel dumps page tables
> for the entire address space including both userspace and kernel.

Ugh god, so it's checking kernel stuff while passing an mm_struct for the
process?? Or does it pass init_mm in that case? I mean that breaks my proposed
patch right away if so...

And... yes it does. Brilliant.

ptdump_walk_pgd_level_core(NULL, &init_mm, pgd, true, false);

God almighty.

>
> > > (I think we should take all the vma locks in that ptdump code and get
> > > rid of this weird exception instead of documenting it.)
> >
> > We really need to be sure that there aren't some weird architectures doing
> > weird things or circumstances where this is meaningful.
> >
> > I mean people went to great lengths to make this possible, I find it hard
> > to believe there aren't some _weird_ real world use cases.
>
> FWIW, looking through the git logs for the x86 version of it, it seems
> to mainly be used by developers of arch-specific code trying to
> debug/validate kernel behavior.

So yeah they just want something that can traverse both I guess? But the
comments in the code seem to strongly suggest that we must lock carefully...

Maybe this whole thing was literally to make life easier to have the same
function check both kernel and non-kernel mappings. I mean...

OK let me reply to my own series to say 'nope'.