From: Ard Biesheuvel <ardb@kernel.org>

This is a proof-of-concept series that implements a strict separation
between startup code and ordinary code, where startup code is built in a
way that tolerates being invoked from the initial 1:1 mapping of memory.

The current approach of emitting this code into .head.text and checking
for absolute relocations in that section is not 100% safe, and produces
diagnostics that are sometimes difficult to interpret.

Instead, rely on symbol prefixes, similar to how this is implemented for
the EFI stub and for the startup code in the arm64 port. This ensures
that startup code can only call other startup code, unless a special
symbol alias is emitted that exposes a non-startup routine to the
startup code.

This is somewhat intrusive, as there are many data objects that are
referenced both by startup code and by ordinary code, and an alias needs
to be emitted for each of those.

This ultimately allows the .head.text section to be dropped entirely, as
it no longer has a special significance. Instead, code that only
executes at boot is emitted into .init.text as it should.

This series is presented for discussion only - defconfig should build
and run correctly, but allmodconfig will likely need the last patch
omitted. 

Ard Biesheuvel (11):
  x86/linkage: Add SYM_PI_ALIAS() macro helper to emit symbol aliases
  x86/boot: Move early_setup_gdt() back into head64.c
  x86/boot: Disregard __supported_pte_mask in __startup_64()
  x86/boot: Add a bunch of PI aliases
  HACK: provide __pti_set_user_pgtbl() to startup code
  x86/boot: Created a confined code area for startup code
  HACK: work around sev-startup.c being omitted for now
  x86/boot: Move startup code out of __head section
  x86/boot: Disallow absolute symbol references in startup code
  x86/boot: Revert "Reject absolute references in .head.text"
  x86/boot: Get rid of the .head.text section

 arch/x86/boot/startup/Makefile      | 26 ++++++++++++++--
 arch/x86/boot/startup/gdt_idt.c     | 17 ++---------
 arch/x86/boot/startup/map_kernel.c  |  6 ++--
 arch/x86/boot/startup/sev-startup.c |  3 ++
 arch/x86/boot/startup/sme.c         | 31 ++++++++++++--------
 arch/x86/coco/core.c                |  2 ++
 arch/x86/include/asm/linkage.h      |  6 ++++
 arch/x86/include/asm/setup.h        |  2 ++
 arch/x86/include/asm/sev.h          |  2 +-
 arch/x86/kernel/cpu/common.c        |  1 +
 arch/x86/kernel/head64.c            | 19 ++++++++++++
 arch/x86/kernel/head_32.S           |  2 +-
 arch/x86/kernel/head_64.S           | 16 +++++++---
 arch/x86/kernel/setup.c             |  1 +
 arch/x86/kernel/vmlinux.lds.S       |  9 +++---
 arch/x86/lib/retpoline.S            |  1 +
 arch/x86/mm/mem_encrypt_amd.c       |  2 ++
 arch/x86/mm/mem_encrypt_boot.S      |  6 ++--
 arch/x86/mm/pgtable.c               |  1 +
 arch/x86/platform/pvh/head.S        |  2 +-
 arch/x86/tools/relocs.c             |  8 +----
 21 files changed, 107 insertions(+), 56 deletions(-)


base-commit: 121c335b36e02d6aefb72501186e060474fdf33c
-- 
2.49.0.805.g082f7c87e0-goog

* Ard Biesheuvel <ardb+git@google.com> wrote:

> From: Ard Biesheuvel <ardb@kernel.org>
> 
> This is a proof-of-concept series that implements a strict separation
> between startup code and ordinary code, where startup code is built in a
> way that tolerates being invoked from the initial 1:1 mapping of memory.
> 
> The current approach of emitting this code into .head.text and checking
> for absolute relocations in that section is not 100% safe, and produces
> diagnostics that are sometimes difficult to interpret.
> 
> Instead, rely on symbol prefixes, similar to how this is implemented for
> the EFI stub and for the startup code in the arm64 port. This ensures
> that startup code can only call other startup code, unless a special
> symbol alias is emitted that exposes a non-startup routine to the
> startup code.

So when startup code accidentally references non-startup symbols 
outside the __pi namespace, we get a build/link error, right?

> This is somewhat intrusive, as there are many data objects that are 
> referenced both by startup code and by ordinary code, and an alias 
> needs to be emitted for each of those.

Yeah, but this should make it ultimately safe(r): every object is 
either local to the startup code, or has been 'exported' intentionally 
to the startup code.

> This ultimately allows the .head.text section to be dropped entirely, 
> as it no longer has a special significance. Instead, code that only 
> executes at boot is emitted into .init.text as it should.
> 
> This series is presented for discussion only - defconfig should build
> and run correctly, but allmodconfig will likely need the last patch
> omitted. 

No fundamental objections from me.

Thanks,

	Ingo

On Thu, 24 Apr 2025 at 20:09, Ingo Molnar <mingo@kernel.org> wrote:
>
>
> * Ard Biesheuvel <ardb+git@google.com> wrote:
>
> > From: Ard Biesheuvel <ardb@kernel.org>
> >
> > This is a proof-of-concept series that implements a strict separation
> > between startup code and ordinary code, where startup code is built in a
> > way that tolerates being invoked from the initial 1:1 mapping of memory.
> >
> > The current approach of emitting this code into .head.text and checking
> > for absolute relocations in that section is not 100% safe, and produces
> > diagnostics that are sometimes difficult to interpret.
> >
> > Instead, rely on symbol prefixes, similar to how this is implemented for
> > the EFI stub and for the startup code in the arm64 port. This ensures
> > that startup code can only call other startup code, unless a special
> > symbol alias is emitted that exposes a non-startup routine to the
> > startup code.
>
> So when startup code accidentally references non-startup symbols
> outside the __pi namespace, we get a build/link error, right?
>

Yes.

> > This is somewhat intrusive, as there are many data objects that are
> > referenced both by startup code and by ordinary code, and an alias
> > needs to be emitted for each of those.
>
> Yeah, but this should make it ultimately safe(r): every object is
> either local to the startup code, or has been 'exported' intentionally
> to the startup code.
>

Indeed.

> > This ultimately allows the .head.text section to be dropped entirely,
> > as it no longer has a special significance. Instead, code that only
> > executes at boot is emitted into .init.text as it should.
> >
> > This series is presented for discussion only - defconfig should build
> > and run correctly, but allmodconfig will likely need the last patch
> > omitted.
>
> No fundamental objections from me.
>

Good to know - thanks.