From: Tycho Andersen <tycho@kernel.org>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Ashish Kalra <ashish.kalra@amd.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
John Allen <john.allen@amd.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S . Miller" <davem@davemloft.net>,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
Alexey Kardashevskiy <aik@amd.com>
Subject: Re: [PATCH 1/2] crypto: ccp - Fix a case where SNP_SHUTDOWN is missed
Date: Wed, 4 Mar 2026 07:59:27 -0700 [thread overview]
Message-ID: <aahIz8bTPNpnaSZM@tycho.pizza> (raw)
In-Reply-To: <0182578a-424d-454f-8a38-57b885eb966b@roeck-us.net>
Hi Guenter,
On Tue, Mar 03, 2026 at 02:35:10PM -0800, Guenter Roeck wrote:
> Hi,
>
> On Mon, Jan 05, 2026 at 10:22:17AM -0700, Tycho Andersen wrote:
> > From: Tom Lendacky <thomas.lendacky@amd.com>
> >
> > If page reclaim fails in sev_ioctl_do_snp_platform_status() and SNP was
> > moved from UNINIT to INIT for the function, SNP is not moved back to
> > UNINIT state. Additionally, SNP is not required to be initialized in order
> > to execute the SNP_PLATFORM_STATUS command, so don't attempt to move to
> > INIT state and let SNP_PLATFORM_STATUS report the status as is.
> >
> > Fixes: ceac7fb89e8d ("crypto: ccp - Ensure implicit SEV/SNP init and shutdown in ioctls")
> > Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> > Reviewed-by: Tycho Andersen (AMD) <tycho@kernel.org>
> > Reviewed-by: Alexey Kardashevskiy <aik@amd.com>
> > Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org>
> > ---
> > drivers/crypto/ccp/sev-dev.c | 46 ++++++++++++++++++------------------
> > 1 file changed, 23 insertions(+), 23 deletions(-)
> >
> > - if (snp_reclaim_pages(__pa(data), 1, true))
> > - return -EFAULT;
> > + if (sev->snp_initialized) {
> > + /*
> > + * The status page will be in Reclaim state on success, or left
> > + * in Firmware state on failure. Use snp_reclaim_pages() to
> > + * transition either case back to Hypervisor-owned state.
> > + */
> > + if (snp_reclaim_pages(__pa(data), 1, true)) {
> > + snp_leak_pages(__page_to_pfn(status_page), 1);
>
> This change got flagged by an experimental AI agent:
>
> If `snp_reclaim_pages()` fails, it already internally calls
> `snp_leak_pages()`. Does calling `snp_leak_pages()` a second time
> on the exact same page corrupt the `snp_leaked_pages_list` because
> `list_add_tail(&page->buddy_list, &snp_leaked_pages_list)` is
> executed again?
>
> I don't claim to understand the code, but it does look like snp_leak_pages()
> is indeed called twice on the same page, which does suggest that it is added
> twice to the leaked pages list if it is not a compound page.
>
> Does this make sense, or is the AI missing something ?
Thanks for flagging this, I agree. I think we can drop that call:
diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
index 096f993974d1..bd31ebfc85d5 100644
--- a/drivers/crypto/ccp/sev-dev.c
+++ b/drivers/crypto/ccp/sev-dev.c
@@ -2410,10 +2410,8 @@ static int sev_ioctl_do_snp_platform_status(struct sev_issue_cmd *argp)
* in Firmware state on failure. Use snp_reclaim_pages() to
* transition either case back to Hypervisor-owned state.
*/
- if (snp_reclaim_pages(__pa(data), 1, true)) {
- snp_leak_pages(__page_to_pfn(status_page), 1);
+ if (snp_reclaim_pages(__pa(data), 1, true))
return -EFAULT;
- }
}
if (ret)
Double checking other uses of snp_reclaim_pages(), I don't think
anyone else makes this mistake.
Do you want to send a patch? Otherwise, how do I credit via
Reported-by:, to just you?
Thanks,
Tycho
next prev parent reply other threads:[~2026-03-04 14:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-05 17:22 [PATCH 1/2] crypto: ccp - Fix a case where SNP_SHUTDOWN is missed Tycho Andersen
2026-01-05 17:22 ` [PATCH 2/2] crypto/ccp: narrow scope of snp_range_list Tycho Andersen
2026-01-05 17:43 ` Tom Lendacky
2026-01-23 6:01 ` [PATCH 1/2] crypto: ccp - Fix a case where SNP_SHUTDOWN is missed Herbert Xu
2026-03-03 22:35 ` Guenter Roeck
2026-03-04 14:59 ` Tycho Andersen [this message]
2026-03-04 19:54 ` Guenter Roeck
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=aahIz8bTPNpnaSZM@tycho.pizza \
--to=tycho@kernel.org \
--cc=aik@amd.com \
--cc=ashish.kalra@amd.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=john.allen@amd.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=thomas.lendacky@amd.com \
/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.