All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kalra, Ashish" <ashish.kalra@amd.com>
To: sashiko-reviews@lists.linux.dev
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v11 2/6] x86/sev: Disable CPU hotplug while SNP is active
Date: Mon, 27 Jul 2026 15:44:00 -0500	[thread overview]
Message-ID: <8aaf5794-e052-4a19-ad28-b3c75752dfa1@amd.com> (raw)
In-Reply-To: <20260727193729.7D8E21F000E9@smtp.kernel.org>


On 7/27/2026 2:37 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [High] System suspend/resume bypasses `cpu_hotplug_disable()`, causing secondary CPUs to come online without the `SnpEn` bit set.
> --
> 
> --- Patch [2]: [PATCH v11 2/6] x86/sev: Disable CPU hotplug while SNP is active ---
> commit 2ca360619d15fed203ba00f43d20453130503df3
> Author: Ashish Kalra <ashish.kalra@amd.com>
> 
> x86/sev: Disable CPU hotplug while SNP is active
> 
> This commit replaces cpus_read_lock() with cpu_hotplug_disable() in
> snp_prepare() to prevent CPU hotplug while SEV-SNP is being enabled. It
> additionally keeps hotplug disabled as long as SNP is active to ensure OS CPU
> hotplug does not diverge from firmware expectations.
> 
>> diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
>> index cff285d8ad8e3..e2f69fba09389 100644
>> --- a/arch/x86/virt/svm/sev.c
>> +++ b/arch/x86/virt/svm/sev.c
> 
> [ ... ]
> 
>> @@ -526,14 +525,21 @@ int snp_prepare(void)
>>  
>>  	clear_rmp();
>>  
>> -	cpus_read_lock();
>> +	/*
>> +	 * Disable CPU hotplug before enabling SNP: no CPU may come online
>> +	 * without SnpEn while SNP is active, and none may go offline during
>> +	 * enable.  This keeps cpu_online_mask stable for the check and the
>> +	 * on_each_cpu() calls below, so cpus_read_lock() is not needed.  It is
>> +	 * re-enabled in snp_shutdown() once the firmware disables SNP.
>> +	 */
>> +	cpu_hotplug_disable();
> 
> [Severity: High]
> This is a pre-existing issue, but does cpu_hotplug_disable() reliably
> prevent secondary CPUs from coming online without the SnpEn bit set?
> 
> System suspend and resume transitions bypass the sysfs hotplug locks. During a
> suspend and resume cycle, freeze_secondary_cpus() and thaw_secondary_cpus()
> directly invoke internal routines that offline and online CPUs, respectively.
> 
> Because snp_enable() is not registered in a CPU hotplug callback, if a
> secondary CPU is thawed, it appears it would wake up and come online without
> the MSR_AMD64_SYSCFG_SNP_EN bit set. Would this leave the system vulnerable
> by allowing arbitrary host access to SEV-SNP guest memory, since no RMP
> checks would be performed by those CPUs?
> 

Pre-existing base SNP-host behaviour, not introduced here (as tagged). An SNP host doesn't support suspend/resume: 
SnpEn is set on all CPUs once at boot, immediately followed by SNP_INIT, and that state can't be rebuilt on resume without a full re-init.
So a CPU coming back online without SnpEn can't occur in a working config.

Thanks,
Ashish

  reply	other threads:[~2026-07-27 20:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-27 19:00 [PATCH v11 0/6] Add RMPOPT support Ashish Kalra
2026-07-27 19:01 ` [PATCH v11 1/6] x86/cpufeatures: Add X86_FEATURE_RMPOPT feature flag Ashish Kalra
2026-07-27 19:01   ` Ashish Kalra
2026-07-27 19:03     ` Ashish Kalra
2026-07-27 19:04 ` [PATCH v11 2/6] x86/sev: Disable CPU hotplug while SNP is active Ashish Kalra
2026-07-27 19:37   ` sashiko-bot
2026-07-27 20:44     ` Kalra, Ashish [this message]
2026-07-27 19:04 ` [PATCH v11 3/6] x86/sev: Initialize RMPOPT configuration MSRs Ashish Kalra
2026-07-27 19:22   ` sashiko-bot
2026-07-27 21:02     ` Kalra, Ashish
2026-07-27 19:05 ` [PATCH v11 4/6] x86/sev: Add support to perform RMP optimizations asynchronously Ashish Kalra
2026-07-27 19:22   ` sashiko-bot
2026-07-27 20:49     ` Kalra, Ashish
2026-07-27 19:05 ` [PATCH v11 5/6] x86/sev: Add interface to re-enable RMP optimizations Ashish Kalra
2026-07-27 19:06 ` [PATCH v11 6/6] KVM: SEV: Perform RMP optimizations on SNP guest shutdown Ashish Kalra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8aaf5794-e052-4a19-ad28-b3c75752dfa1@amd.com \
    --to=ashish.kalra@amd.com \
    --cc=kvm@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.