[Patch v2 0/7] Implement SNP live firmware update support
From: Pratik R. Sampat
Date: Fri Sep 18 2026 - 12:50:28 EST
Introducing support for live update on AMD SEV-SNP platforms via
DOWNLOAD_FIRMWARE_EX.
This patchset is an extension of the RFC patchset from Tycho
Andersen.
This series also fronts firmware_loader patches from Dan Williams[1]
which majorly cleans up refcount issues so that registering the upload
interface no longer pins the module. Without which having live firmware
update will cause failure to reload the ccp module as well as break
kexec.
Patches based on cryptodev-2.6
v2:
* In snp_get_platform_data() use snp_[alloc|free]_firmware_page() to
transition pages to and from firmware-owned state, instead of
open-coding rmp_mark_pages_firmware()/snp_reclaim_pages() around the
SNP_FEATURE_INFO command - Tom, Sashiko
* Claim sev->fwl atomically with xchg() in unregister_sev_fw_uploader()
so a concurrent module removal and sysfs unbind cannot both reach
firmware_upload_unregister() - Sashiko
Responding to other Sashiko comments:
* __sev_release_firmware_buffers() called with panic=true can cause
deadlock as another stopped CPU might currently hold zone->lock or
other page allocator locks.
- I think having a panic param within __snp_free_firmware_pages
which checks and returns before __free_pages() should resolve
this issue. Since this is a pre-existing issue not relevant
to this patchset, plan to send this as a seperate patch
* The sev_download_firmware_ex() function is called with the lock held
and performs a GFP_KERNEL allocation. Since GFP_KERNEL can trigger
direct memory reclaim, could this invoke SEV page reclaim operations
that attempt to acquire the already-held sev_cmd_mutex, resulting in
a deadlocked state?
- GFP_KERNEL may perform direct MM reclaim, but SNP page
reclamation is not registered as an MM shrinker or normal
page-reclaim callback. snp_reclaim_pages() acquires
sev_cmd_mutex only when explicitly called with locked=false
* "If snp_reclaim_cmd_buf() fails and returns early, the code skips
resetting sev->cmd_buf_active and sev->cmd_buf_backup_active.
Will this permanently leak the bounce buffer slots and result in
future -EBUSY failures?"
- Since the command buffer may still be firmware owned, I think
declaring psp_dead = true is the way to ensure we do not make
it available for reuse after a failed reclaim. Pre-existing
issue, plan to send this as a seperate patch
v1: https://lore.kernel.org/linux-crypto/cover.1789059391.git.prsampat@xxxxxxx/
* firmware-loader patches are rebased as-is and only incorporates
fixes for minor build issues
* Dropped crypto/ccp: Hoist kernel part of SNP_PLATFORM_STATUS as that
patch has been merged since
* Dropped crypto/ccp: Reclaim command buffer when the PSP dies and
subsequent handling since firmware quirk is now resolved and need not be
handled in the OS
* Use guard(mutex) for the locked region, which the split makes
possible since sev_get_api_version() acquires sev_cmd_mutex - Maxwell
* Added a patch factoring out the TMR and INIT_EX teardown, so the update
path and __sev_firmware_shutdown() share it - Shantanu
* Skip the re-init when the PSP is dead, not just when a rollback is
outstanding - Shantanu
* Re-initialize the platform before refreshing the cached status -
Shantanu
* Split the monolithic .write into a locked update helper, an error
translation helper, and a thin .write that refreshes the cached status
once the lock is dropped and clean up various allocations
* Convert rollback required and reinit required globals to reside in
sev_dev struct to avoid carrying over states if manually reloaded
RFC: https://lore.kernel.org/all/20260430160716.1120553-1-tycho@xxxxxxxxxx/
[1]: https://lore.kernel.org/lkml/20260331214726.903274-2-dan.j.williams@xxxxxxxxx/
Dan Williams (3):
firmware_loader: Stop pinning modules on registration
firmware_loader: Stop pinning parent device per workqueue invocation
treewide: firmware_loader: Drop the unused @module argument
Pratik R. Sampat (4):
crypto: ccp - Factor out the release of the SEV firmware buffers
crypto: ccp - Allow SNP platform data to be queried after SNP INIT
crypto/ccp: Register with fw_uploader and always fail
crypto/ccp: Implement SNP Download Firmware EX
.../driver-api/firmware/fw_upload.rst | 2 +-
drivers/base/firmware_loader/sysfs_upload.c | 50 +--
drivers/base/firmware_loader/sysfs_upload.h | 1 -
drivers/crypto/ccp/sev-dev.c | 423 ++++++++++++++++--
drivers/crypto/ccp/sev-dev.h | 4 +
drivers/cxl/core/memdev.c | 4 +-
drivers/firmware/microchip/mpfs-auto-update.c | 2 +-
drivers/fpga/intel-m10-bmc-sec-update.c | 4 +-
drivers/greybus/gb-beagleplay.c | 2 +-
drivers/media/i2c/thp7312.c | 2 +-
drivers/net/pse-pd/pd692x0.c | 4 +-
drivers/virt/coco/tdx-host/tdx-host.c | 4 +-
include/linux/firmware.h | 15 +-
include/linux/psp-sev.h | 19 +
lib/test_firmware.c | 3 +-
15 files changed, 446 insertions(+), 93 deletions(-)
--
2.43.0