[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aedde96f-c1fe-4d88-bef1-1d07aef72c44@lucifer.local>
Date: Wed, 26 Feb 2025 18:14:16 +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 05:43:22PM +0000, Lorenzo Stoakes wrote:
> 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).
Apologies, I meant to reword this to sound less harsh but somebody phoned
me and I hit send...
What I mean to say is I think you _do_ ack what I've said here, but you
think it's not useful to reply because there's not really a converastion to
be had.
Whereas I'm saying it'd be useful to ack :)
Sorry I did not mean for this to sound quite so 'full on'.
>
> 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/
I did in the end go and check this, so hopefully this is useful at least.
But again, I really think we should hold off on PPC stuff until we come to
it and focus on getting this series into mergeable state.
Am doing my best to try to get you there ASAP as there's been a lot of
delays here.
>
> >
> > Thanks
> > -Jeff
> >
> >
> > > Thanks,
> > > Liam
Cheers, Lorenzo
Powered by blists - more mailing lists