linux-kernel - Re: [PATCH v3 0/5] efi: Don't initalize SEV-SNP from the EFI stub

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAGnOC3b2XBFw+xdMhTtpfDYG480BG-KwfkPMWOiOP+13XeHFfg@mail.gmail.com>
Date: Tue, 22 Apr 2025 18:40:20 +0200
From: Ard Biesheuvel <ardb@...gle.com>
To: Tom Lendacky <thomas.lendacky@....com>
Cc: Ard Biesheuvel <ardb+git@...gle.com>, linux-efi@...r.kernel.org, x86@...nel.org, 
	linux-kernel@...r.kernel.org, mingo@...nel.org, 
	Ard Biesheuvel <ardb@...nel.org>, Borislav Petkov <bp@...en8.de>, 
	Dionna Amalie Glaze <dionnaglaze@...gle.com>, Kevin Loughlin <kevinloughlin@...gle.com>
Subject: Re: [PATCH v3 0/5] efi: Don't initalize SEV-SNP from the EFI stub

On Tue, Apr 22, 2025 at 5:51 PM Tom Lendacky <thomas.lendacky@....com> wrote:
>
> On 4/22/25 05:07, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel <ardb@...nel.org>
> >
>
> Hi Ard,
>
> I'll try to get to reviewing and testing this series very soon.

Thanks.

> But one
> thing I can see is that we never set the snp_vmpl level anymore in the
> EFI stub and so PVALIDATE will fail when running under an SVSM.
>
> But I don't think this series is completely at fault. This goes back to
> fixing memory acceptance before sev_enable() was called and I missed the
> SVSM situation. So I don't think we can completely remove all SNP
> initialization and might have to do svsm_setup_ca() which has a pre-req
> on setup_cpuid_table()...  sigh.
>

OK, so memory acceptance from the EFI stub is still broken even when
using the MSR protocol, right?

But SVSM is relatively recent, and so we probably have more leeway to
fix it properly. And I assume the firmware itself can be expected to
have its own working configuration to communicate with the VMM and/or
the hypervisor?

This hybrid mode of executing in the firmware execution context but
taking control of everything under the hood is really a maintenance
nightmare, and so I'd rather do less of that than more of that. If
that implies that we need to re-engineer the early memory acceptance
and the population of the unaccepted memory table, I still think we
need to consider it. Ultimately, the memory acceptance in the stub is
not fundamentally needed, it is only there because there is a mismatch
between the table's granularity and the EFI memory map granularity. In
fact, given that this appears to be a rare occurrence anyway, and
ultimately under the control of the firmware (which we can also fix),
we might simply decide to use an unaccepted memory table with 4k
granularity unless all existing regions unaccepted memory regions are
aligned to 2M.