aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/bin
diff options
context:
space:
mode:
authorBorislav Petkov (AMD) <[email protected]>2023-07-16 20:22:20 +0200
committerBorislav Petkov (AMD) <[email protected]>2023-08-07 18:05:13 +0200
commitbee6cf1a80b54548a039e224c651bb15b644a480 (patch)
tree55b480185b9be65014cf2f726e4674db364d7dee /tools/perf/scripts/python/bin
parent52a93d39b17dc7eb98b6aa3edb93943248e03b2f (diff)
x86/sev: Do not try to parse for the CC blob on non-AMD hardware
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 <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Acked-by: Tom Lendacky <[email protected]> Tested-by: Tao Liu <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Diffstat (limited to 'tools/perf/scripts/python/bin')
0 files changed, 0 insertions, 0 deletions