All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Ard Biesheuvel <ardb+git@google.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [RFC PATCH PoC 00/11] x86: strict separation of startup code
Date: Thu, 24 Apr 2025 20:09:13 +0200	[thread overview]
Message-ID: <aAp-SThmX5PcsrWU@gmail.com> (raw)
In-Reply-To: <20250423110948.1103030-13-ardb+git@google.com>


* 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

  parent reply	other threads:[~2025-04-24 18:09 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-23 11:09 [RFC PATCH PoC 00/11] x86: strict separation of startup code Ard Biesheuvel
2025-04-23 11:09 ` [RFC PATCH PoC 01/11] x86/linkage: Add SYM_PI_ALIAS() macro helper to emit symbol aliases Ard Biesheuvel
2025-04-24 18:05   ` Ingo Molnar
2025-04-24 18:17     ` Ard Biesheuvel
2025-04-24 18:23       ` Ingo Molnar
2025-04-23 11:09 ` [RFC PATCH PoC 02/11] x86/boot: Move early_setup_gdt() back into head64.c Ard Biesheuvel
2025-04-23 11:09 ` [RFC PATCH PoC 03/11] x86/boot: Disregard __supported_pte_mask in __startup_64() Ard Biesheuvel
2025-04-23 11:09 ` [RFC PATCH PoC 04/11] x86/boot: Add a bunch of PI aliases Ard Biesheuvel
2025-04-23 11:09 ` [RFC PATCH PoC 05/11] HACK: provide __pti_set_user_pgtbl() to startup code Ard Biesheuvel
2025-04-23 11:09 ` [RFC PATCH PoC 06/11] x86/boot: Created a confined code area for " Ard Biesheuvel
2025-04-23 11:09 ` [RFC PATCH PoC 07/11] HACK: work around sev-startup.c being omitted for now Ard Biesheuvel
2025-04-23 11:09 ` [RFC PATCH PoC 08/11] x86/boot: Move startup code out of __head section Ard Biesheuvel
2025-04-24 15:12   ` kernel test robot
2025-04-23 11:09 ` [RFC PATCH PoC 09/11] x86/boot: Disallow absolute symbol references in startup code Ard Biesheuvel
2025-04-23 11:09 ` [RFC PATCH PoC 10/11] x86/boot: Revert "Reject absolute references in .head.text" Ard Biesheuvel
2025-04-23 11:10 ` [RFC PATCH PoC 11/11] x86/boot: Get rid of the .head.text section Ard Biesheuvel
2025-04-24 18:09 ` Ingo Molnar [this message]
2025-04-24 18:16   ` [RFC PATCH PoC 00/11] x86: strict separation of startup code Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aAp-SThmX5PcsrWU@gmail.com \
    --to=mingo@kernel.org \
    --cc=ardb+git@google.com \
    --cc=ardb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.