FAILED: patch "[PATCH] x86/sev: Make the #VC exception stacks part of the default" failed to apply to 5.15-stable tree

PATCH [email protected] 2 participants 6 messages Nov 16, 2021

Subsystems (3)

Stable branch x86 x86 MM

lore

Share & tools

lore

[email protected]

author maintainer

2021-11-16 10:54 UTC #0 lore raw

The patch below does not apply to the 5.15-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From 541ac97186d9ea88491961a46284de3603c914fd Mon Sep 17 00:00:00 2001
From: Borislav Petkov <[email protected]>
Date: Fri, 1 Oct 2021 21:41:20 +0200
Subject: [PATCH] x86/sev: Make the #VC exception stacks part of the default
stacks storage

The size of the exception stacks was increased by the commit in Fixes, resulting in stack sizes greater than a page in size. The #VC exception handling was only mapping the first (bottom) page, resulting in an SEV-ES guest failing to boot.

Make the #VC exception stacks part of the default exception stacks storage and allocate them with a CONFIG_AMD_MEM_ENCRYPT=y .config. Map them only when a SEV-ES guest has been detected.

Rip out the custom VC stacks mapping and storage code.

[ bp: Steal and adapt Tom's commit message. ]

Fixes 7fae4c24a2b8 ("x86: Increase exception stack sizes")

Signed-off-by Borislav Petkov <[email protected]>

Tested-by Tom Lendacky <[email protected]>

Tested-by Brijesh Singh <[email protected]>

Link https://lkml.kernel.org/r/[email protected] open here

arch/x86/include/asm/cpu_entry_area.h +7 -1

index 3d52b094850a..dd5ea1bdf04c 100644
@@ -10,6 +10,12 @@
 
 #ifdef CONFIG_X86_64
 
+#ifdef CONFIG_AMD_MEM_ENCRYPT
+#define VC_EXCEPTION_STKSZ	EXCEPTION_STKSZ
+#else
+#define VC_EXCEPTION_STKSZ	0
+#endif
+
 /* Macro to enforce the same ordering and stack sizes */
 #define ESTACKS_MEMBERS(guardsize, optional_stack_size)		\
 	char	DF_stack_guard[guardsize];			\

@@ -28,7 +34,7 @@
 
 /* The exception stacks' physical storage. No guard pages required */
 struct exception_stacks {
-	ESTACKS_MEMBERS(0, 0)
+	ESTACKS_MEMBERS(0, VC_EXCEPTION_STKSZ)
 };
 
 /* The effective cpu entry area mapping with guard pages. */

arch/x86/kernel/sev.c +0 ~~-32~~

index 53a6837d354b..4d0d1c2b65e1 100644
@@ -46,16 +46,6 @@ static struct ghcb __initdata *boot_ghcb;
 struct sev_es_runtime_data {
 	struct ghcb ghcb_page;
 
-	/* Physical storage for the per-CPU IST stack of the #VC handler */
-	char ist_stack[EXCEPTION_STKSZ] __aligned(PAGE_SIZE);
-
-	/*
-	 * Physical storage for the per-CPU fall-back stack of the #VC handler.
-	 * The fall-back stack is used when it is not safe to switch back to the
-	 * interrupted stack in the #VC entry code.
-	 */
-	char fallback_stack[EXCEPTION_STKSZ] __aligned(PAGE_SIZE);
-
 	/*
 	 * Reserve one page per CPU as backup storage for the unencrypted GHCB.
 	 * It is needed when an NMI happens while the #VC handler uses the real

@@ -99,27 +89,6 @@ DEFINE_STATIC_KEY_FALSE(sev_es_enable_key);
 /* Needed in vc_early_forward_exception */
 void do_early_exception(struct pt_regs *regs, int trapnr);
 
-static void __init setup_vc_stacks(int cpu)
-{
-	struct sev_es_runtime_data *data;
-	struct cpu_entry_area *cea;
-	unsigned long vaddr;
-	phys_addr_t pa;
-
-	data = per_cpu(runtime_data, cpu);
-	cea  = get_cpu_entry_area(cpu);
-
-	/* Map #VC IST stack */
-	vaddr = CEA_ESTACK_BOT(&cea->estacks, VC);
-	pa    = __pa(data->ist_stack);
-	cea_set_pte((void *)vaddr, pa, PAGE_KERNEL);
-
-	/* Map VC fall-back stack */
-	vaddr = CEA_ESTACK_BOT(&cea->estacks, VC2);
-	pa    = __pa(data->fallback_stack);
-	cea_set_pte((void *)vaddr, pa, PAGE_KERNEL);
-}
-
 static __always_inline bool on_vc_stack(struct pt_regs *regs)
 {
 	unsigned long sp = regs->sp;

@@ -787,7 +756,6 @@ void __init sev_es_init_vc_handling(void)
 	for_each_possible_cpu(cpu) {
 		alloc_runtime_data(cpu);
 		init_ghcb(cpu);
-		setup_vc_stacks(cpu);
 	}
 
 	sev_es_setup_play_dead();

arch/x86/mm/cpu_entry_area.c +7 -0

index f5e1e60c9095..6c2f1b76a0b6 100644
@@ -110,6 +110,13 @@ static void __init percpu_setup_exception_stacks(unsigned int cpu)
 	cea_map_stack(NMI);
 	cea_map_stack(DB);
 	cea_map_stack(MCE);
+
+	if (IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT)) {
+		if (cc_platform_has(CC_ATTR_GUEST_STATE_ENCRYPT)) {
+			cea_map_stack(VC);
+			cea_map_stack(VC2);
+		}
+	}
 }
 #else
 static inline void percpu_setup_exception_stacks(unsigned int cpu)

Borislav Petkov

2021-11-16 11:10 UTC #1 lore raw

Quoted 27 lines · On Tue, Nov 16, 2021 at 11:54:46AM +0100, [email protected] wrote:

The patch below does not apply to the 5.15-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 541ac97186d9ea88491961a46284de3603c914fd Mon Sep 17 00:00:00 2001
From: Borislav Petkov <[email protected]>
Date: Fri, 1 Oct 2021 21:41:20 +0200
Subject: [PATCH] x86/sev: Make the #VC exception stacks part of the default
stacks storage
The size of the exception stacks was increased by the commit in Fixes, resulting in stack sizes greater than a page in size. The #VC exception handling was only mapping the first (bottom) page, resulting in an SEV-ES guest failing to boot.
Make the #VC exception stacks part of the default exception stacks storage and allocate them with a CONFIG_AMD_MEM_ENCRYPT=y .config. Map them only when a SEV-ES guest has been detected.

Quoted 5 lines

Rip out the custom VC stacks mapping and storage code.
[ bp: Steal and adapt Tom's commit message. ]
Fixes 7fae4c24a2b8 ("x86: Increase exception stack sizes")

$ git tag --contains 7fae4c24a2b8 | grep -E "^v"
v5.16-rc1

Scripts kaputtski?

:-)

Signature · 4 lines

Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Ivo Totev, HRB 36809, AG Nürnberg

Greg KH

author maintainer

2021-11-16 11:25 UTC #2 lore raw

Quoted 30 lines · Borislav Petkov

Quoted 29 lines · On Tue, Nov 16, 2021 at 11:54:46AM +0100, [email protected] wrote:
The patch below does not apply to the 5.15-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 541ac97186d9ea88491961a46284de3603c914fd Mon Sep 17 00:00:00 2001
From: Borislav Petkov <[email protected]>
Date: Fri, 1 Oct 2021 21:41:20 +0200
Subject: [PATCH] x86/sev: Make the #VC exception stacks part of the default
stacks storage
The size of the exception stacks was increased by the commit in Fixes, resulting in stack sizes greater than a page in size. The #VC exception handling was only mapping the first (bottom) page, resulting in an SEV-ES guest failing to boot.
Make the #VC exception stacks part of the default exception stacks storage and allocate them with a CONFIG_AMD_MEM_ENCRYPT=y .config. Map them only when a SEV-ES guest has been detected.
Rip out the custom VC stacks mapping and storage code.

Quoted 8 lines

Quoted 3 lines
[ bp: Steal and adapt Tom's commit message. ]
Fixes 7fae4c24a2b8 ("x86: Increase exception stack sizes")
$ git tag --contains 7fae4c24a2b8 | grep -E "^v"
v5.16-rc1
Scripts kaputtski?

Nope, planning ahead:

	$ ~/linux/stable/commit_tree/id_found_in 7fae4c24a2b8
	5.16-rc1 queue-4.4 queue-4.9 queue-4.14 queue-4.19 queue-5.4 queue-5.10 queue-5.14 queue-5.15

That commit is in the current -rc releases right now.

The problem with this commit is that the cc_platform_has() function is not present. I thought about backporting it as well, but that seemed odd as I do not think that feature is in the 5.15 and older kernels, right?

Or is it ok to take the cc_platform_has() function?

thanks,

greg k-h

Borislav Petkov

2021-11-16 11:53 UTC #3 lore raw

Quoted 5 lines · Greg KH

Nope, planning ahead:
	$ ~/linux/stable/commit_tree/id_found_in 7fae4c24a2b8
	5.16-rc1 queue-4.4 queue-4.9 queue-4.14 queue-4.19 queue-5.4 queue-5.10 queue-5.14 queue-5.15
That commit is in the current -rc releases right now.

Bah, there's stuff in-flight.

Quoted 4 lines

The problem with this commit is that the cc_platform_has() function is not present. I thought about backporting it as well, but that seemed odd as I do not think that feature is in the 5.15 and older kernels, right?

The cc_platform_has() was a small set:

https://lore.kernel.org/r/YX%2B5ekjTbK3rhX%[email protected]

which wants to keep all those checks confidential guests are going to do around the code, sane. So you don't really need it but...

Quoted 1 line

Or is it ok to take the cc_platform_has() function?

... it will simplify all those backports which use it in the future. And we will use cc_platform_has() from now on in common code.

In any case, we're going to backport it into SLE just for that reason - so that it can ease backports and there's no kABI nightmares.

HTH.

Signature · 4 lines

Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Ivo Totev, HRB 36809, AG Nürnberg

Greg KH

author maintainer

2021-11-16 12:50 UTC #4 lore raw

Quoted 21 lines · Borislav Petkov

Quoted 5 lines · Greg KH
Nope, planning ahead:
	$ ~/linux/stable/commit_tree/id_found_in 7fae4c24a2b8
	5.16-rc1 queue-4.4 queue-4.9 queue-4.14 queue-4.19 queue-5.4 queue-5.10 queue-5.14 queue-5.15
That commit is in the current -rc releases right now.
Bah, there's stuff in-flight.
Quoted 4 lines
The problem with this commit is that the cc_platform_has() function is not present. I thought about backporting it as well, but that seemed odd as I do not think that feature is in the 5.15 and older kernels, right?
The cc_platform_has() was a small set:
https://lore.kernel.org/r/YX%2B5ekjTbK3rhX%[email protected]
which wants to keep all those checks confidential guests are going to do around the code, sane. So you don't really need it but...

Quoted 7 lines

Quoted 1 line
Or is it ok to take the cc_platform_has() function?
... it will simplify all those backports which use it in the future. And we will use cc_platform_has() from now on in common code.
In any case, we're going to backport it into SLE just for that reason - so that it can ease backports and there's no kABI nightmares.

Ok, sounds good, I'll go queue them up now and see how the builds go to save you the trouble of backporting into SLE...

greg k-h

Borislav Petkov

2021-11-16 12:59 UTC #5 lore raw

Quoted 2 lines · Greg KH

Ok, sounds good, I'll go queue them up now and see how the builds go to save you the trouble of backporting into SLE...

Thanks but Joerg has already backported them. :-)

Signature · 4 lines

Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Ivo Totev, HRB 36809, AG Nürnberg