Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Michael Roth <michael.roth@amd.com>
To: <linux-crypto@vger.kernel.org>
Cc: <herbert@gondor.apana.org.au>, <davem@davemloft.net>,
	<ackerleytng@google.com>, <thomas.lendacky@amd.com>,
	<ashish.kalra@amd.com>, <aik@amd.com>, <seanjc@google.com>
Subject: [PATCH v2 0/9] crypto: ccp - Make sev_cmd_mutex more granular
Date: Thu, 15 Oct 2026 23:09:28 -0500	[thread overview]
Message-ID: <20261016041109.1778673-1-michael.roth@amd.com> (raw)

This patchset is also available at:

  https://github.com/amdese/linux/commits/ccp-mutex-rework-v2

and is based on cryptodev-2.6 master (a29888556578).

v1: https://lore.kernel.org/linux-crypto/20261014132145.1726322-1-michael.roth@amd.com/
v2:
 - rework to address cleanup.h guidelines about not mixing goto
   with guard()'s (Sashiko)
 - invert boolean logic for better readability (Tom)
 - simplify by avoiding uncessary helper for sev_do_snp_platform_status() (Tom)


OVERVIEW
--------

The current code makes very coarse usage of the sev_cmd_mutex; for SEV
firmware ioctls, it is essentially taken upon entry, and ends up wrapping
a lot of potentially time-consuming prep/cleanup work that may need to be
done before/after issuing the actual firmware call, which is the main
thing the mutex is meant to protect.

Additionally, some of that prep work involves
copy_from_user()/copy_to_user() calls which can generate page faults and
unecessarily lead to potential deadlock scenarios. No known case exists
in current upstream, but with the upcoming KVM/guest_memfd support for
in-place conversion of the same PFN between shared/private state (which
is currently targeted for kernel 7.4), a special fault handler is added
that could theoretically deadlock if a malicious user tries to use
guest_memfd pages as the source/target of target of said
copy_from_user()/copy_to_user() scenarios[1].

So this series is a prereq to enabling the above-mentioned KVM/guest_memfd
in-place conversion support on SNP-enabled hosts, as well as a cleanup
for SEV ioctls in general.

Patches #7 and #9 are where the mutexes are actually made more granular,
the other patches are just prep for them.

Thank you to Sean for suggesting this approach and Ackerley for wrangling
the changes into a presentable patchset.


REFERENCES
----------

[1] https://lore.kernel.org/kvm/asz8GKNO9aQANr5E@google.com/


Thanks!

-Mike


----------------------------------------------------------------
Ackerley Tng (3):
      crypto: ccp - Shut down SEV firmware before copying to user
      crypto: ccp - Check SNP initialization state after copying user inputs
      crypto: ccp - Make usage of sev_cmd_mutex more granular

Michael Roth (6):
      crypto: ccp - Use __free() handlers for sev_ioctl_do_pek_csr() allocations
      crypto: ccp - Use __free() handlers for sev_ioctl_do_pek_import() allocations
      crypto: ccp - Use __free() handlers for sev_ioctl_do_pdh_export() allocations
      crypto: ccp: - Rework sev_ioctl_do_pdh_export() to avoid goto usage
      crypto: ccp - Use __free() handlers for __sev_do_snp_platform_status() allocations
      crypto: ccp - Allocate status page outside sev_cmd_mutex in SNP_PLATFORM_STATUS

 drivers/crypto/ccp/sev-dev.c | 277 ++++++++++++++++++++-----------------------
 1 file changed, 130 insertions(+), 147 deletions(-)


             reply	other threads:[~2026-10-16  4:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-16  4:09 Michael Roth [this message]
2026-10-16  4:09 ` [PATCH v2 1/9] crypto: ccp - Shut down SEV firmware before copying to user Michael Roth
2026-10-16  4:09 ` [PATCH v2 2/9] crypto: ccp - Check SNP initialization state after copying user inputs Michael Roth
2026-10-16  4:09 ` [PATCH v2 3/9] crypto: ccp - Use __free() handlers for sev_ioctl_do_pek_csr() allocations Michael Roth
2026-10-16  4:09 ` [PATCH v2 4/9] crypto: ccp - Use __free() handlers for sev_ioctl_do_pek_import() allocations Michael Roth
2026-10-16  4:09 ` [PATCH v2 5/9] crypto: ccp - Use __free() handlers for sev_ioctl_do_pdh_export() allocations Michael Roth
2026-10-16  4:09 ` [PATCH v2 6/9] crypto: ccp: - Rework sev_ioctl_do_pdh_export() to avoid goto usage Michael Roth
2026-10-16  4:09 ` [PATCH v2 7/9] crypto: ccp - Make usage of sev_cmd_mutex more granular Michael Roth
2026-10-16  4:09 ` [PATCH v2 8/9] crypto: ccp - Use __free() handlers for __sev_do_snp_platform_status() allocations Michael Roth
2026-10-16  4:09 ` [PATCH v2 9/9] crypto: ccp - Allocate status page outside sev_cmd_mutex in SNP_PLATFORM_STATUS Michael Roth

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=20261016041109.1778673-1-michael.roth@amd.com \
    --to=michael.roth@amd.com \
    --cc=ackerleytng@google.com \
    --cc=aik@amd.com \
    --cc=ashish.kalra@amd.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=seanjc@google.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox