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: <6vhuf2uuaibrmtb47tqf6qm6ckpsvmxgrh776wyrpd4ezccrnr@vdbv7msydynk>
Date: Thu, 11 Jul 2024 11:59:25 -0400
From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
To: LEROY Christophe <christophe.leroy2@...soprasteria.com>
Cc: "linux-mm@...ck.org" <linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Suren Baghdasaryan <surenb@...gle.com>,
        Vlastimil Babka <vbabka@...e.cz>, Lorenzo Stoakes <lstoakes@...il.com>,
        Matthew Wilcox <willy@...radead.org>,
        "sidhartha.kumar@...cle.com" <sidhartha.kumar@...cle.com>,
        "Paul E . McKenney" <paulmck@...nel.org>,
        Bert Karwatzki <spasswolf@....de>, Jiri Olsa <olsajiri@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Kees Cook <kees@...nel.org>, Dave Hansen <dave.hansen@...el.com>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        Dmitry Safonov <dima@...sta.com>,
        Michael Ellerman <mpe@...erman.id.au>
Subject: Re: [PATCH v4 17/21] mm/mmap: Drop arch_unmap() call from all archs

* LEROY Christophe <christophe.leroy2@...soprasteria.com> [240711 04:28]:
> 
> 
> Le 11/07/2024 à 01:26, Liam R. Howlett a écrit :
> > * LEROY Christophe <christophe.leroy2@...soprasteria.com> [240710 17:02]:
> >>
> >>
> >> Le 10/07/2024 à 21:22, Liam R. Howlett a écrit :
> >>> From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
> >>>
> >>> The arch_unmap call was previously moved above the rbtree modifications
> >>> in commit 5a28fc94c914 ("x86/mpx, mm/core: Fix recursive munmap()
> >>> corruption").  The move was motivated by an issue with calling
> >>> arch_unmap() after the rbtree was modified.
> >>>
> >>> Since the above commit, mpx was dropped from the kernel in 45fc24e89b7c
> >>> ("x86/mpx: remove MPX from arch/x86"), so the motivation for calling
> >>> arch_unmap() prior to modifying the vma tree no longer exists
> >>> (regardless of rbtree or maple tree implementations).
> >>>
> >>> Furthermore, the powerpc implementation is also no longer needed as per
> >>> [1] and [2].  So the arch_unmap() function can be completely removed.
> >>
> >> I'm not sure to understand. Is it replaced by something else ?
> >> We wanted to get rid of arch_unmap() but it was supposed to be replaced
> >> by some core function because the functionnality itself is still
> >> required and indeed all the discussion around [2] demonstrated that not
> >> only powerpc but at least arm and probably others needed to properly
> >> clean-up reference to VDSO mappings on unmapping.
> >>
> >> So as mentioned by Michael you can't just drop that without replacing it
> >> by something else. We need the VDSO signal handling to properly fallback
> >> on stack-based trampoline when the VDSO trampoline gets mapped out.
> >
> > I'll address this after the part I missed..
> 
> After ? What do you mean ? It needs to be addressed _before_ removing
> arch_unmap()

After the later comments in this email, sorry that wasn't clear.

> 
> >
> >>
> >> Or did I miss something ?
> >>
> >
> > I think I missed something in regards to what you need in ppc.
> 
> It is not only powerpc. Powerpc is the only one doing it at the moment
> but investigation has demonstrated that other architectures are affected.
> 
> >
> >  From what I understand, other platforms still map and use the vdso
> > (context.vdso is set), but unmap_arch() does nothing.  It is only the
> > powerpc version that clears the vdso pointer if it is unmapped.
> 
> Yes on powerpc it works. On other platforms like arm it segfaults so it
> should be fixed
> (https://lore.kernel.org/lkml/87imd5h5kb.fsf@mpe.ellerman.id.au/)
> 
> Could be fixed by properly implementing arch_unmap() on every arch, or
> carry-on with Dmitry's series.

Okay, I understand what you are saying now.  I'm not going to tackle
that change within this series, so I'll just relocate the arch_munmap()
back to where it was, after the removal of the vmas in v5.

> I think you fully understand that it doesn't work as it is except on
> powerpc. Again the goal should be to make it work on all architectures.

Got it, thanks for clarifying.

Regards,
Liam

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ