[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABi2SkUprOT=TEDQb62SByjyW+csarKnGypdmxVdktj=+C9_yg@mail.gmail.com>
Date: Wed, 26 Feb 2025 09:17:10 -0800
From: Jeff Xu <jeffxu@...omium.org>
To: "Liam R. Howlett" <Liam.Howlett@...cle.com>, Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
Jeff Xu <jeffxu@...omium.org>, 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 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 ?
Thanks
-Jeff
> Thanks,
> Liam
Powered by blists - more mailing lists