All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: x86@kernel.org, Joan Bruguera <joanbrugueram@gmail.com>
Cc: linux-kernel@vger.kernel.org, peterz@infradead.org,
	"Juergen Gross" <jgross@suse.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	xen-devel <xen-devel@lists.xenproject.org>,
	"Jan Beulich" <jbeulich@suse.com>,
	"Roger Pau Monne" <roger.pau@citrix.com>,
	"Kees Cook" <keescook@chromium.org>,
	mark.rutland@arm.com, "Andrew Cooper" <Andrew.Cooper3@citrix.com>,
	"Jörg Rödel" <joro@8bytes.org>, "H. Peter Anvin" <hpa@zytor.com>,
	jroedel@suse.de
Subject: [PATCH v2 1/7] x86/boot: Remove verify_cpu() from secondary_startup_64()
Date: Mon, 16 Jan 2023 15:25:34 +0100	[thread overview]
Message-ID: <20230116143645.589522290@infradead.org> (raw)
In-Reply-To: 20230116142533.905102512@infradead.org

The boot trampolines from trampoline_64.S have code flow like:

  16bit BIOS			SEV-ES				64bit EFI

  trampoline_start()		sev_es_trampoline_start()	trampoline_start_64()
    verify_cpu()			  |				|
  switch_to_protected:    <---------------'				v
       |							pa_trampoline_compat()
       v								|
  startup_32()		<-----------------------------------------------'
       |
       v
  startup_64()
       |
       v
  tr_start() := head_64.S:secondary_startup_64()

Since AP bringup always goes through the 16bit BIOS path (EFI doesn't
touch the APs), there is already a verify_cpu() invocation.

Removing the verify_cpu() invocation from secondary_startup_64()
renders the whole secondary_startup_64_no_verify() thing moot, so
remove that too.

Cc: jroedel@suse.de
Cc: hpa@zytor.com
Fixes: e81dc127ef69 ("x86/callthunks: Add call patching for call depth tracking")
Reported-by: Joan Bruguera <joanbrugueram@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
 arch/x86/include/asm/realmode.h |    1 -
 arch/x86/kernel/head_64.S       |   16 ----------------
 arch/x86/realmode/init.c        |    6 ------
 3 files changed, 23 deletions(-)

--- a/arch/x86/include/asm/realmode.h
+++ b/arch/x86/include/asm/realmode.h
@@ -73,7 +73,6 @@ extern unsigned char startup_32_smp[];
 extern unsigned char boot_gdt[];
 #else
 extern unsigned char secondary_startup_64[];
-extern unsigned char secondary_startup_64_no_verify[];
 #endif
 
 static inline size_t real_mode_size_needed(void)
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -143,22 +143,6 @@ SYM_CODE_START(secondary_startup_64)
 	 * after the boot processor executes this code.
 	 */
 
-	/* Sanitize CPU configuration */
-	call verify_cpu
-
-	/*
-	 * The secondary_startup_64_no_verify entry point is only used by
-	 * SEV-ES guests. In those guests the call to verify_cpu() would cause
-	 * #VC exceptions which can not be handled at this stage of secondary
-	 * CPU bringup.
-	 *
-	 * All non SEV-ES systems, especially Intel systems, need to execute
-	 * verify_cpu() above to make sure NX is enabled.
-	 */
-SYM_INNER_LABEL(secondary_startup_64_no_verify, SYM_L_GLOBAL)
-	UNWIND_HINT_EMPTY
-	ANNOTATE_NOENDBR
-
 	/*
 	 * Retrieve the modifier (SME encryption mask if SME is active) to be
 	 * added to the initial pgdir entry that will be programmed into CR3.
--- a/arch/x86/realmode/init.c
+++ b/arch/x86/realmode/init.c
@@ -74,12 +74,6 @@ static void __init sme_sev_setup_real_mo
 		th->flags |= TH_FLAGS_SME_ACTIVE;
 
 	if (cc_platform_has(CC_ATTR_GUEST_STATE_ENCRYPT)) {
-		/*
-		 * Skip the call to verify_cpu() in secondary_startup_64 as it
-		 * will cause #VC exceptions when the AP can't handle them yet.
-		 */
-		th->start = (u64) secondary_startup_64_no_verify;
-
 		if (sev_es_setup_ap_jump_table(real_mode_header))
 			panic("Failed to get/update SEV-ES AP Jump Table");
 	}



  reply	other threads:[~2023-01-16 14:53 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-16 14:25 [PATCH v2 0/7] x86: retbleed=stuff fixes Peter Zijlstra
2023-01-16 14:25 ` Peter Zijlstra [this message]
2023-01-17  9:25   ` [PATCH v2 1/7] x86/boot: Remove verify_cpu() from secondary_startup_64() Ingo Molnar
2023-01-18  9:45   ` Peter Zijlstra
2023-01-18 11:46     ` kirill.shutemov
2023-01-19 19:35     ` H. Peter Anvin
2023-01-26 14:15       ` Peter Zijlstra
2023-01-16 14:25 ` [PATCH v2 2/7] x86/boot: Delay sev_verify_cbit() a bit Peter Zijlstra
2023-01-19 13:18   ` Borislav Petkov
2023-01-20 12:43     ` Jörg Rödel
2023-01-16 14:25 ` [PATCH v2 3/7] x86/power: De-paravirt restore_processor_state() Peter Zijlstra
2023-01-20 20:26   ` Borislav Petkov
2023-01-16 14:25 ` [PATCH v2 4/7] x86/power: Inline write_cr[04]() Peter Zijlstra
2023-01-20 20:29   ` Borislav Petkov
2023-01-16 14:25 ` [PATCH v2 5/7] x86/callthunk: No callthunk for restore_processor_state() Peter Zijlstra
2023-01-16 14:25 ` [PATCH v2 6/7] x86/power: Sprinkle some noinstr Peter Zijlstra
2023-01-17  9:31   ` Ingo Molnar
2023-01-17 11:29     ` Peter Zijlstra
2023-01-17 11:54       ` Ingo Molnar
2023-01-16 14:25 ` [PATCH v2 7/7] PM / hibernate: Add minimal noinstr annotations Peter Zijlstra
2023-01-18  1:54 ` [PATCH v2 0/7] x86: retbleed=stuff fixes Joan Bruguera
2023-05-16 13:59 ` Josh Poimboeuf

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=20230116143645.589522290@infradead.org \
    --to=peterz@infradead.org \
    --cc=Andrew.Cooper3@citrix.com \
    --cc=hpa@zytor.com \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=joanbrugueram@gmail.com \
    --cc=joro@8bytes.org \
    --cc=jroedel@suse.de \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=rafael@kernel.org \
    --cc=roger.pau@citrix.com \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xenproject.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.