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@xxxxxxxxxx>
> Signed-off-by: Borislav Petkov (AMD) <bp@xxxxxxxxx>
> Cc: <stable@xxxxxxxxxx>
> Link: https://lore.kernel.org/r/20240313121546.2964854-1-kevinloughlin@xxxxxxxxxx
> (cherry picked from commit 0f4a1e80989aca185d955fcd791d7750082044a2)
> Signed-off-by: Kevin Loughlin <kevinloughlin@xxxxxxxxxx>
Now queued up, thanks for the backport!
greg k-h
