x86/sev: Do not try to parse for the CC blob on non-AMD hardware
authorBorislav Petkov (AMD) <bp@alien8.de>
Sun, 16 Jul 2023 18:22:20 +0000 (20:22 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 16 Aug 2023 16:27:25 +0000 (18:27 +0200)
commit179430c2aa46a927ce4c01f635a172f851fd15ac
treee3c3f9ebd4cd99f6140d0d5fae14140cf48bd83d
parent9ad49178c00a5f20cd97a81cfa87dba8dfa9ff0f
x86/sev: Do not try to parse for the CC blob on non-AMD hardware

commit bee6cf1a80b54548a039e224c651bb15b644a480 upstream.

Tao Liu reported a boot hang on an Intel Atom machine due to an unmapped
EFI config table. The reason being that the CC blob which contains the
CPUID page for AMD SNP guests is parsed for before even checking
whether the machine runs on AMD hardware.

Usually that's not a problem on !AMD hw - it simply won't find the CC
blob's GUID and return. However, if any parts of the config table
pointers array is not mapped, the kernel will #PF very early in the
decompressor stage without any opportunity to recover.

Therefore, do a superficial CPUID check before poking for the CC blob.
This will fix the current issue on real hardware. It would also work as
a guest on a non-lying hypervisor.

For the lying hypervisor, the check is done again, *after* parsing the
CC blob as the real CPUID page will be present then.

Clear the #VC handler in case SEV-{ES,SNP} hasn't been detected, as
a precaution.

Fixes: c01fce9cef84 ("x86/compressed: Add SEV-SNP feature detection/setup")
Reported-by: Tao Liu <ltao@redhat.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Tested-by: Tao Liu <ltao@redhat.com>
Cc: <stable@kernel.org>
Link: https://lore.kernel.org/r/20230601072043.24439-1-ltao@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
arch/x86/boot/compressed/idt_64.c
arch/x86/boot/compressed/sev.c