[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aAqBl3Odf4oX2SCL@gmail.com>
Date: Thu, 24 Apr 2025 20:23:19 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Ard Biesheuvel <ardb+git@...gle.com>, linux-kernel@...r.kernel.org,
x86@...nel.org
Subject: Re: [RFC PATCH PoC 01/11] x86/linkage: Add SYM_PI_ALIAS() macro
helper to emit symbol aliases
* Ard Biesheuvel <ardb@...nel.org> wrote:
> On Thu, 24 Apr 2025 at 20:05, Ingo Molnar <mingo@...nel.org> wrote:
> >
> >
> > * Ard Biesheuvel <ardb+git@...gle.com> wrote:
> >
> > > From: Ard Biesheuvel <ardb@...nel.org>
> > >
> > > Startup code that may execute from the early 1:1 mapping of memory will
> > > be confined into its own address space, and only be permitted to access
> > > ordinary kernel symbols if this is known to be safe.
> > >
> > > Introduce a macro helper PI_ALIAS() that emits a __pi_ prefixed alias
> > > for a symbol, which allows startup code to access it.
> >
> > s/PI_ALIAS
> > /SYM_PI_ALIAS
> >
> > What does 'PI' stand for? 'Physical memory Identity' map?
> >
>
> 'position independent'
/facepalm
Clearly it's getting late here :)
> - it's what we ended up with on arm64, but I'm
> not attached to it so happy to switch to something better.
Could we make it something like SYM_PIC_ALIAS() at least? Because 'PIC'
is something most people will recognize in this context. PI goes for
3.1415. ;-)
Thanks,
Ingo
Powered by blists - more mailing lists