[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7d436f5d-083d-4d7f-ac98-39d7ec0ae73b@lucifer.local>
Date: Fri, 28 Feb 2025 10:31:42 +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 Thu, Feb 27, 2025 at 04:48:23PM -0800, Jeff Xu wrote:
> On Wed, Feb 26, 2025 at 9:43 AM Lorenzo Stoakes
> <lorenzo.stoakes@...cle.com> 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 checked the kernel code and couldn't find any instances of kernel
> unmap/remap system mapping in any architecture. But I could be wrong,
> so I've also included developers from different architectures since
> V1, and hoping to get some insight.
Thanks, yeah me also. Perhaps you said somewhere but I missed, apologies if
so. Might be worth adding explicitly to commit messages, though I think you
allude to it actually.
>
> > > > > I ended up doing this myself yesterday and found no issues, as with x86-64.
> > > > >
> Thank you for double checking.
No problem, in the went was fairly quick.
>
> > > > > 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).
> >
> I'm just interested in the details :), If we know why PPC needs to
> unmap/remap vdso, then there are additional data points to consider,
> when we develop pre-process level control for this feature. But sure,
> we can postpone this.
>
> > This?
> >
> > https://elixir.bootlin.com/linux/v6.13.4/source/arch/powerpc/kernel/vdso.c#L236
> >
> OK, you meant the failed case ? i.e. when install_special_mappings
> failed ? That is a case that I haven't considered. It looks like error
> handling, and I was expecting the install_special_mappings to never
> fail, maybe I'm wrong here for PPC.
>
> > Was [0] a relevant discussion?
> >
> Sorry, I'm kind of lost. This link doesn't give a reason why PPC
> needs to be unmap. If it is due to CRIU or other user space apps,
> that is not an architecture dependency, maybe a distribution
> dependency.
Yeah I actually think the web might be somewhat tangled here, I don't know
but...
>
> Anyway, we can postpone this discussion for PPC, I don't mean to make
> you spend more time responding to me. Please feel free to ignore this
> one.
...agreed, let's postpone this to there, at least hopefully these links provide
some basis for further research! :)
>
> Thanks.
> -Jeff
>
>
> > [0]: https://lore.kernel.org/all/lhe2mky6ahlk2jzvvfjyongqiseelyx2uy7sbyuso6jcy3b2dq@7ju6cea62jgk/
> >
> > >
> > > Thanks
> > > -Jeff
> > >
> > >
> > > > Thanks,
> > > > Liam
Cheers, Lorenzo
Powered by blists - more mailing lists