On Thu, Dec 26, 2024 at 9:26 PM Kevin Loughlin <kevinloughlin@xxxxxxxxxx> wrote:
>
> On Thu, Dec 19, 2024 at 6:44 AM Ajay Kaher <ajay.kaher@xxxxxxxxxxxx> wrote:
> >
> > For VMware hypervisor, SEV-SNP enabled VM's could boot without UEFI.
> > In this case, mpparse_find_mptable() has to be called to parse MP
> > tables which contains boot information.
> >
> > Fixes: 0f4a1e80989a ("x86/sev: Skip ROM range scans and validation for SEV-SNP guests")
> > Signed-off-by: Ajay Kaher <ajay.kaher@xxxxxxxxxxxx>
> > Signed-off-by: Ye Li <ye.li@xxxxxxxxxxxx>
> > Tested-by: Ye Li <ye.li@xxxxxxxxxxxx>
> > ---
> > arch/x86/kernel/cpu/vmware.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
> > index 00189cd..3e2594d 100644
> > --- a/arch/x86/kernel/cpu/vmware.c
> > +++ b/arch/x86/kernel/cpu/vmware.c
> > @@ -26,6 +26,7 @@
> > #include <linux/export.h>
> > #include <linux/clocksource.h>
> > #include <linux/cpu.h>
> > +#include <linux/efi.h>
> > #include <linux/reboot.h>
> > #include <linux/static_call.h>
> > #include <asm/div64.h>
> > @@ -35,6 +36,8 @@
> > #include <asm/apic.h>
> > #include <asm/vmware.h>
> > #include <asm/svm.h>
> > +#include <asm/mem_encrypt.h>
> > +#include <asm/efi.h>
> >
> > #undef pr_fmt
> > #define pr_fmt(fmt) "vmware: " fmt
> > @@ -429,6 +432,10 @@ static void __init vmware_platform_setup(void)
> > pr_warn("Failed to get TSC freq from the hypervisor\n");
> > }
> >
> > + if (sev_status & MSR_AMD64_SEV_SNP_ENABLED &&
> > + !efi_enabled(EFI_BOOT))
> > + x86_init.mpparse.find_mptable = mpparse_find_mptable;
>
> As far I know, Linux itself currently doesn't PVALIDATE the address
> ranges scanned in mpparse_find_mptable(), and Linux accesses these
> addresses as encrypted during early boot. Given this, am I correct
> that the guest firmware that you're using is doing the PVALIDATE of
> these ranges before starting Linux (else there would be a crash upon
> scan)? And then presumably the firmware is also making sure that this
> memory is encrypted so that Linux isn't reading unencrypted data as
> encrypted (i.e., garbage)?
Yes, Linux (as a guest) receives valid data.
> If so, does that mean all the ROM region scans removed in [0] are
> permissible for SEV-SNP guests booting on whichever guest firmware
> this is? But you only want/need the mptable info here?
Yes, VMware firmware validates MPTABLE info when 'non-EFI guest boots
on VMware Hypervisor'. The other ROM regions removed in [0] were not
encrypted and validated. This is a specific use case for the VMware platform.
Linux today assumes SNP VMs will be booted with UEFI.
> [0] 0f4a1e80989a ("x86/sev: Skip ROM range scans and validation for
> SEV-SNP guests")
>
> More broadly, ideally the guest firmware would communicate to Linux
> that these ranges are safe to access (perhaps via the e820 table),
> rather than Linux making the assumption that the ranges are safe for
> non-EFI SEV-SNP guest boots in this scenario. However, since you're
> only changing vmware_platform_setup() for such boots, I don't think we
> need to hold up this patch on that generality.
This is a VMware specific scenario. VMware Hypervisor makes the MPTABLE
memory available in e820 when 'non-EFI guest boots on VMware Hypervisor'.
So it makes sense to do the changes only for vmware_platform_setup().
- Ajay
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
