linux-kernel - Re: [PATCH] x86/sev: Fix host kdump support for SNP

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <3f887fb7-e30e-41f4-8ac1-bd245e707ccc@amd.com>
Date: Thu, 29 Aug 2024 09:30:54 -0500
From: "Kalra, Ashish" <ashish.kalra@....com>
To: Borislav Petkov <bp@...en8.de>, seanjc@...gle.com, pbonzini@...hat.com,
 dave.hansen@...ux.intel.com, tglx@...utronix.de, mingo@...hat.com,
 x86@...nel.org
Cc: hpa@...or.com, peterz@...radead.org, linux-kernel@...r.kernel.org,
 kvm@...r.kernel.org, thomas.lendacky@....com, michael.roth@....com,
 kexec@...ts.infradead.org, linux-coco@...ts.linux.dev
Subject: Re: [PATCH] x86/sev: Fix host kdump support for SNP

Hello Boris,

On 8/29/2024 3:34 AM, Borislav Petkov wrote:
> On August 27, 2024 10:38:04 PM GMT+02:00, Ashish Kalra <Ashish.Kalra@....com> wrote:
>> From: Ashish Kalra <ashish.kalra@....com>
>>
>> With active SNP VMs, SNP_SHUTDOWN_EX invoked during panic notifiers causes
>> crashkernel boot failure with the following signature:
> Why would SNP_SHUTDOWN be allowed *at all* if there are active SNP guests and there's potential to lose guest data in the process?!

If SNP_SHUTDOWN is not done, then crashkernel panics during boot as the crashdump attached to the fix/patch here shows, so essentially if SNP_DECOMMISSION followed by SNP_SHUTDOWN is not done then we can't boot crashkernel in case of any active SNP guests (which i will believe is an important requirement for cloud providers).

Additionally, in case of SNP_DECOMMISSION, the firmware marks the ASID of the guest as not runnable and then transitions the SNP guest context page into a Firmware page (so that is one RMP table change) and for SNP_SHUTDOWN_EX, the firmware transitions all pages associated with the IOMMU to the Reclaim state (which then the HV marks as hypervisor pages), these IOMMU pages are the event log, PPR log, and completion wait buffers of the IOMMU.

Aside from the IOMMU pages mentioned above, the firmware will not automatically reclaim or modify any other pages in the RMP table and also does not reset the RMP table.

So essentially all host memory (and guest data) will still be available and saved by crashkernel.

Thanks, Ashish