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: <26da9c1f-3cb6-45a5-b4df-1e4838057ea4@amd.com>
Date: Fri, 30 Aug 2024 16:08:35 -0500
From: "Kalra, Ashish" <ashish.kalra@....com>
To: Sean Christopherson <seanjc@...gle.com>, Borislav Petkov <bp@...en8.de>
Cc: pbonzini@...hat.com, dave.hansen@...ux.intel.com, tglx@...utronix.de,
 mingo@...hat.com, x86@...nel.org, 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 10:16 AM, Kalra, Ashish wrote:
> On 8/29/2024 9:50 AM, Sean Christopherson wrote:
>
>> On Thu, Aug 29, 2024, 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?!
>> Because if the host is panicking, guests are hosed regardless.  Unless I'm
>> misreading things, the goal here is to ensure the crashkernel can actually capture
>> a kdump.
> Yes, that is the main goal here to ensure that crashkernel can boot and capture a kdump on a SNP enabled host regardless of SNP VMs running.

Are you convinced with Sean's feedback here that this is a required feature to fix ?

And it is important to reiterate this again:

SNP_DECOMMISSION mainly unbinds the ASID from SNP context and marks the ASID as unusable and then transitions the SNP guest context page to a FW page and SNP_SHUTDOWN_EX transitions all pages associated with the IOMMU to reclaim state which the HV then transitions to hypervisor state, all these page state changes are in the RMP table, so there is no loss of guest data as such and the complete host memory is captured with the crashkernel boot. There are no processes which are being killed and host/guest memory is not being altered or modified in any way.

Additionally, i believe that the support staff will absolutely need this kind of support which enables crashkernel/kdump for SNP hosts.

Thanks, Ashish


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ