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: <ba04b513-0eb5-425d-b24c-82c9f9b6c7ee@lucifer.local>
Date: Wed, 26 Feb 2025 17:43:22 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Jeff Xu <jeffxu@...omium.org>
Cc: "Liam R. Howlett" <Liam.Howlett@...cle.com>, akpm@...ux-foundation.org,
        keescook@...omium.org, jannh@...gle.com, torvalds@...ux-foundation.org,
        vbabka@...e.cz, adhemerval.zanella@...aro.org, oleg@...hat.com,
        avagin@...il.com, benjamin@...solutions.net,
        linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org,
        linux-mm@...ck.org, jorgelo@...omium.org, sroettger@...gle.com,
        hch@....de, ojeda@...nel.org, thomas.weissschuh@...utronix.de,
        adobriyan@...il.com, johannes@...solutions.net,
        pedro.falcato@...il.com, hca@...ux.ibm.com, willy@...radead.org,
        anna-maria@...utronix.de, mark.rutland@....com,
        linus.walleij@...aro.org, Jason@...c4.com, deller@....de,
        rdunlap@...radead.org, davem@...emloft.net, peterx@...hat.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,
        enh@...gle.com, rientjes@...gle.com, groeck@...omium.org,
        mpe@...erman.id.au, aleksandr.mikhalitsyn@...onical.com,
        mike.rapoport@...il.com
Subject: Re: [PATCH v7 4/7] mseal, system mappings: enable arm64

On Wed, Feb 26, 2025 at 09:17:10AM -0800, Jeff Xu wrote:
> On Wed, Feb 26, 2025 at 9:12 AM Liam R. Howlett <Liam.Howlett@...cle.com> wrote:
> >
> > * Lorenzo Stoakes <lorenzo.stoakes@...cle.com> [250226 00:26]:
> > > On Tue, Feb 25, 2025 at 02:26:50PM -0800, Jeff Xu wrote:
> > > > On Mon, Feb 24, 2025 at 10:20 PM Lorenzo Stoakes
> > > > <lorenzo.stoakes@...cle.com> wrote:
> > > > >
> > > > > On Mon, Feb 24, 2025 at 10:52:43PM +0000, jeffxu@...omium.org wrote:
> > > > > > From: Jeff Xu <jeffxu@...omium.org>
> > > > > >
> > > > > > Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on arm64, covering
> > > > > > the vdso, vvar, and compat-mode vectors and sigpage mappings.
> > > > > >
> > > > > > Production release testing passes on Android and Chrome OS.
> > > > >
> > > > > This is pretty limited (yes yes I know android is massive etc. but we must
> > > > > account for all the weird and wonderful arm64 devices out there in context of
> > > > > upstream :)
> > > > >
> > > > > Have you looking through all arm64-code relating to vdso, vvar, compat-mode
> > > > > vectors, sigpage mapping and ensured nothing kernel-side relies upon relocation?
> > > > > Some arches actually seem to want to do this. Pretty sure PPC does... so a bit
> > > > > nervous of that.
> > > > >
> > > > Can you please point out where PPC munmap/mremap the vdso ?
> > > >
> > > > Previously, when you mentioned that, I thought you meant user space in
> > > > PPC, I didn't realize that you meant that kernel code in PPC.  I
> > > > tried, but didn't find anything, hence asking.
> > >
> > > Jeff, please stick to replying to review. 'Have you looking through all
> > > arm64-code'.
> > >
> > > I ended up doing this myself yesterday and found no issues, as with x86-64.
> > >
> > > I said I'm _pretty sure_ PPC does this. Liam mentioned something about
> > > it. We can discuss it, and I can find specifics if + when you try to add
> > > this to PPC.
> > >
> >
> > PPC allows the vma to be munmapped then detects and falls back to the
> > slower method, iirc.
> >
> Is this code in the kernel or userspace?
>
> If PPC doesn't want to create vdso for all its userspace apps, we
> could instead "don't create" vdso during the execve call.
>
>
> > They were against the removal of the fallback; other archs also have
> > this infrastructure.  Really, if we fixed the fallback to work for
> > all platforms then it would probably also remove the possibility of a
> > remap over the VDSO being a problem (if it is today, which still isn't
> > clear?).
> >
> Any past thread/communication about this that I can read ?

Jeff, I'm sure you don't intend to, but I find it quite disrespectful that you
ignored my feedback here (and elsewhere, regarding you ignoring 4 sets of
feedback).

This?

https://elixir.bootlin.com/linux/v6.13.4/source/arch/powerpc/kernel/vdso.c#L236

Was [0] a relevant discussion?

[0]: https://lore.kernel.org/all/lhe2mky6ahlk2jzvvfjyongqiseelyx2uy7sbyuso6jcy3b2dq@7ju6cea62jgk/

>
> Thanks
> -Jeff
>
>
> > Thanks,
> > Liam

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ