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: <2294bbdf-7860-f6c8-0162-992ee79f4817@amd.com>
Date: Thu, 24 Apr 2025 09:18:42 -0500
From: Tom Lendacky <thomas.lendacky@....com>
To: Ard Biesheuvel <ardb@...nel.org>, Ard Biesheuvel <ardb@...gle.com>
Cc: 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 4/24/25 02:22, Ard Biesheuvel wrote:
> 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.

It's more of a statement about the CPUID table modifications made by
svsm_setup_ca() that need to be skipped if setup_cpuid_table() isn't
called, not the use of CPUID itself.

But taking a closer look, snp_cpuid_get_table() is actually returning
the address of cpuid_table_copy, which is a static in the file. So maybe
it isn't an issue because the loop at the end of svsm_setup_ca() will
not crash, which was the main concern.

I think we can use CPUID 0x8000001f_EAX[28] to detect an SVSM and read
MSR 0xc001f000 to get the CAA. OVMF has that support, just would need to
figure out where to check for it, then we can probably skip the
svsm_setup_ca() and do everything in the snp_accept_memory() path.

Let me take a look...

Thanks,
Tom