Re: [PATCH 6.8.y] x86/sev: Skip ROM range scans and validation for SEV-SNP guests

[Greg KH <greg@kroah.com>]

On Mon, Apr 01, 2024 at 02:12:02PM +0000, Kevin Loughlin wrote:
> SEV-SNP requires encrypted memory to be validated before access.
> Because the ROM memory range is not part of the e820 table, it is not
> pre-validated by the BIOS. Therefore, if a SEV-SNP guest kernel wishes
> to access this range, the guest must first validate the range.
> 
> The current SEV-SNP code does indeed scan the ROM range during early
> boot and thus attempts to validate the ROM range in probe_roms().
> However, this behavior is neither sufficient nor necessary for the
> following reasons:
> 
> * With regards to sufficiency, if EFI_CONFIG_TABLES are not enabled and
>   CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK is set, the kernel will
>   attempt to access the memory at SMBIOS_ENTRY_POINT_SCAN_START (which
>   falls in the ROM range) prior to validation.
> 
>   For example, Project Oak Stage 0 provides a minimal guest firmware
>   that currently meets these configuration conditions, meaning guests
>   booting atop Oak Stage 0 firmware encounter a problematic call chain
>   during dmi_setup() -> dmi_scan_machine() that results in a crash
>   during boot if SEV-SNP is enabled.
> 
> * With regards to necessity, SEV-SNP guests generally read garbage
>   (which changes across boots) from the ROM range, meaning these scans
>   are unnecessary. The guest reads garbage because the legacy ROM range
>   is unencrypted data but is accessed via an encrypted PMD during early
>   boot (where the PMD is marked as encrypted due to potentially mapping
>   actually-encrypted data in other PMD-contained ranges).
> 
> In one exceptional case, EISA probing treats the ROM range as
> unencrypted data, which is inconsistent with other probing.
> 
> Continuing to allow SEV-SNP guests to use garbage and to inconsistently
> classify ROM range encryption status can trigger undesirable behavior.
> For instance, if garbage bytes appear to be a valid signature, memory
> may be unnecessarily reserved for the ROM range. Future code or other
> use cases may result in more problematic (arbitrary) behavior that
> should be avoided.
> 
> While one solution would be to overhaul the early PMD mapping to always
> treat the ROM region of the PMD as unencrypted, SEV-SNP guests do not
> currently rely on data from the ROM region during early boot (and even
> if they did, they would be mostly relying on garbage data anyways).
> 
> As a simpler solution, skip the ROM range scans (and the otherwise-
> necessary range validation) during SEV-SNP guest early boot. The
> potential SEV-SNP guest crash due to lack of ROM range validation is
> thus avoided by simply not accessing the ROM range.
> 
> In most cases, skip the scans by overriding problematic x86_init
> functions during sme_early_init() to SNP-safe variants, which can be
> likened to x86_init overrides done for other platforms (ex: Xen); such
> overrides also avoid the spread of cc_platform_has() checks throughout
> the tree.
> 
> In the exceptional EISA case, still use cc_platform_has() for the
> simplest change, given (1) checks for guest type (ex: Xen domain status)
> are already performed here, and (2) these checks occur in a subsys
> initcall instead of an x86_init function.
> 
>   [ bp: Massage commit message, remove "we"s. ]
> 
> Fixes: 9704c07bf9f7 ("x86/kernel: Validate ROM memory before accessing when SEV-SNP is active")
> Signed-off-by: Kevin Loughlin <kevinloughlin@google.com>
> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
> Cc: <stable@kernel.org>
> Link: https://lore.kernel.org/r/20240313121546.2964854-1-kevinloughlin@google.com
> (cherry picked from commit 0f4a1e80989aca185d955fcd791d7750082044a2)
> Signed-off-by: Kevin Loughlin <kevinloughlin@google.com>

Now queued up, thanks for the backport!

greg k-h