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: <CAMj1kXFCqLnWDw7hJVL9FShF9V=YZ_Ucf6jSSeq0E=BeuENdkQ@mail.gmail.com>
Date: Thu, 24 Apr 2025 09:22:37 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Ard Biesheuvel <ardb@...gle.com>
Cc: Tom Lendacky <thomas.lendacky@....com>, Ard Biesheuvel <ardb+git@...gle.com>, 
	linux-efi@...r.kernel.org, x86@...nel.org, linux-kernel@...r.kernel.org, 
	mingo@...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, 22 Apr 2025 at 18:40, Ard Biesheuvel <ardb@...gle.com> wrote:
>
> 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.
> >

Why is that, though? The EFI stub never replaces the #VC and #PF
handlers, and so cpuid instructions will be handled as before, right?
And the SVSM setup code will run again when the core kernel boots and
this time, it will need to update the cpuid tables to record the SVSM
presence.