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 stable@vger.kernel.org.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 541ac97186d9ea88491961a46284de3603c914fd Mon Sep 17 00:00:00 2001
From: Borislav Petkov bp@suse.de 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 bp@suse.de Tested-by: Tom Lendacky thomas.lendacky@amd.com Tested-by: Brijesh Singh brijesh.singh@amd.com Link: https://lkml.kernel.org/r/YVt1IMjIs7pIZTRR@zn.tnic
diff --git a/arch/x86/include/asm/cpu_entry_area.h b/arch/x86/include/asm/cpu_entry_area.h index 3d52b094850a..dd5ea1bdf04c 100644 --- a/arch/x86/include/asm/cpu_entry_area.h +++ b/arch/x86/include/asm/cpu_entry_area.h @@ -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. */ diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c index 53a6837d354b..4d0d1c2b65e1 100644 --- a/arch/x86/kernel/sev.c +++ b/arch/x86/kernel/sev.c @@ -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(); diff --git a/arch/x86/mm/cpu_entry_area.c b/arch/x86/mm/cpu_entry_area.c index f5e1e60c9095..6c2f1b76a0b6 100644 --- a/arch/x86/mm/cpu_entry_area.c +++ b/arch/x86/mm/cpu_entry_area.c @@ -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)
On Tue, Nov 16, 2021 at 11:54:46AM +0100, gregkh@linuxfoundation.org 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 stable@vger.kernel.org.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 541ac97186d9ea88491961a46284de3603c914fd Mon Sep 17 00:00:00 2001 From: Borislav Petkov bp@suse.de 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")
$ git tag --contains 7fae4c24a2b8 | grep -E "^v" v5.16-rc1
Scripts kaputtski?
:-)
On Tue, Nov 16, 2021 at 12:10:48PM +0100, Borislav Petkov wrote:
On Tue, Nov 16, 2021 at 11:54:46AM +0100, gregkh@linuxfoundation.org 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 stable@vger.kernel.org.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 541ac97186d9ea88491961a46284de3603c914fd Mon Sep 17 00:00:00 2001 From: Borislav Petkov bp@suse.de 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")
$ 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
On Tue, Nov 16, 2021 at 12:24:01PM +0100, Greg KH wrote:
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.
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%2BY@zn.tnic
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...
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.
On Tue, Nov 16, 2021 at 12:52:44PM +0100, Borislav Petkov wrote:
On Tue, Nov 16, 2021 at 12:24:01PM +0100, Greg KH wrote:
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.
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%2BY@zn.tnic
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...
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
On Tue, Nov 16, 2021 at 01:50:13PM +0100, Greg KH wrote:
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. :-)
linux-stable-mirror@lists.linaro.org