From: Ard Biesheuvel <ardb@kernel.org>
To: Ard Biesheuvel <ardb+git@google.com>
Cc: linux-kernel@vger.kernel.org,
Kevin Loughlin <kevinloughlin@google.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Dionna Glaze <dionnaglaze@google.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Justin Stitt <justinstitt@google.com>,
Kees Cook <keescook@chromium.org>,
Brian Gerst <brgerst@gmail.com>,
linux-arch@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [PATCH v5 10/16] x86/startup_64: Simplify virtual switch on primary boot
Date: Fri, 23 Feb 2024 14:11:11 +0100 [thread overview]
Message-ID: <CAMj1kXGFP0oz=7_4sW=Cd-n2k5=M6Nzzrst-dAdkYtmdeTqYrg@mail.gmail.com> (raw)
In-Reply-To: <20240221113506.2565718-28-ardb+git@google.com>
On Wed, 21 Feb 2024 at 12:36, Ard Biesheuvel <ardb+git@google.com> wrote:
>
> From: Ard Biesheuvel <ardb@kernel.org>
>
> The secondary startup code is used on the primary boot path as well, but
> in this case, the initial part runs from a 1:1 mapping, until an
> explicit cross-jump is made to the kernel virtual mapping of the same
> code.
>
> On the secondary boot path, this jump is pointless as the code already
> executes from the mapping targeted by the jump. So combine this
> cross-jump with the jump from startup_64() into the common boot path.
> This simplifies the execution flow, and clearly separates code that runs
> from a 1:1 mapping from code that runs from the kernel virtual mapping.
>
> Note that this requires a page table switch, so hoist the CR3 assignment
> into startup_64() as well. And since absolute symbol references will no
> longer be permitted in .head.text once we enable the associated build
> time checks, a RIP-relative memory operand is used in the JMP
> instruction, referring to an absolute constant in the .init.rodata
> section.
>
> Given that the secondary startup code does not require a special
> placement inside the executable, move it to the .noinstr.text section.
This should be the .text section, or we get
vmlinux.o: warning: objtool: early_setup_idt+0x4: call to
startup_64_load_idt() leaves .noinstr.text section
It would be better to have the secondary startup code in
.noinstr.text, but it is only a very minor improvement. I'll be
looking into teaching objtool to be strict about .head.text code and
reject references that use absolute addressing, so I might be able to
tweak it to permit this use case as well but at this point we should
probably just move it into ordinary .text
> This requires the use of a subsection so that the payload is placed
> after the page aligned Xen hypercall page, as otherwise, objtool will
> complain about the resulting JMP instruction emitted by the assembler
> being unreachable.
>
^^^ this bit can be dropped, and the following hunk applied (apologies
if my gmail mangles this - i can resend the patch or the series)
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 4bee33d8e1dc..e16df01791be 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -515,7 +515,7 @@
}
/* This is used when running on kernel addresses */
-void noinstr early_setup_idt(void)
+void early_setup_idt(void)
{
void *handler = NULL;
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 32fefb23f4df..c9ee92550508 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -139,8 +139,7 @@
__INITRODATA
0: .quad common_startup_64
- .section .noinstr.text, "ax"
- .subsection 1
+ .text
SYM_CODE_START(secondary_startup_64)
UNWIND_HINT_END_OF_STACK
ANNOTATE_NOENDBR
next prev parent reply other threads:[~2024-02-23 13:11 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-21 11:35 [PATCH v5 00/16] x86: Confine early 1:1 mapped startup code Ard Biesheuvel
2024-02-21 11:35 ` [PATCH v5 01/16] x86/startup_64: Simplify global variable accesses in GDT/IDT programming Ard Biesheuvel
2024-02-21 11:35 ` [PATCH v5 02/16] x86/startup_64: Use RIP_REL_REF() to assign phys_base Ard Biesheuvel
2024-02-21 11:35 ` [PATCH v5 03/16] x86/startup_64: Use RIP_REL_REF() to access early_dynamic_pgts[] Ard Biesheuvel
2024-02-21 11:35 ` [PATCH v5 04/16] x86/startup_64: Use RIP_REL_REF() to access __supported_pte_mask Ard Biesheuvel
2024-02-21 11:35 ` [PATCH v5 05/16] x86/startup_64: Use RIP_REL_REF() to access early page tables Ard Biesheuvel
2024-02-21 11:35 ` [PATCH v5 06/16] x86/startup_64: Use RIP_REL_REF() to access early_top_pgt[] Ard Biesheuvel
2024-02-21 11:35 ` [PATCH v5 07/16] x86/startup_64: Simplify CR4 handling in startup code Ard Biesheuvel
2024-02-21 14:52 ` Brian Gerst
2024-02-21 11:35 ` [PATCH v5 08/16] x86/startup_64: Defer assignment of 5-level paging global variables Ard Biesheuvel
2024-02-21 11:35 ` [PATCH v5 09/16] x86/startup_64: Simplify calculation of initial page table address Ard Biesheuvel
2024-02-21 11:35 ` [PATCH v5 10/16] x86/startup_64: Simplify virtual switch on primary boot Ard Biesheuvel
2024-02-23 13:11 ` Ard Biesheuvel [this message]
2024-02-21 11:35 ` [PATCH v5 11/16] x86/sme: Avoid SME/SVE related checks on non-SME/SVE platforms Ard Biesheuvel
2024-02-21 11:35 ` [PATCH v5 12/16] efi/libstub: Add generic support for parsing mem_encrypt= Ard Biesheuvel
2024-02-21 11:35 ` [PATCH v5 13/16] x86/boot: Move mem_encrypt= parsing to the decompressor Ard Biesheuvel
2024-02-21 11:35 ` [PATCH v5 14/16] x86/sme: Move early SME kernel encryption handling into .head.text Ard Biesheuvel
2024-02-21 11:35 ` [PATCH v5 15/16] x86/sev: Move early startup code into .head.text section Ard Biesheuvel
2024-02-21 11:35 ` [PATCH v5 16/16] x86/startup_64: Drop global variables keeping track of LA57 state 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='CAMj1kXGFP0oz=7_4sW=Cd-n2k5=M6Nzzrst-dAdkYtmdeTqYrg@mail.gmail.com' \
--to=ardb@kernel.org \
--cc=ardb+git@google.com \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=dave.hansen@linux.intel.com \
--cc=dionnaglaze@google.com \
--cc=justinstitt@google.com \
--cc=keescook@chromium.org \
--cc=kevinloughlin@google.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).