linux.git/drivers/virt/coco, branch v7.2-rc1

Merge tag 'x86_tdx_for_7.2-rc1' of gitolite.kernel.org:pub/scm/linux/kernel/git/tip/tip

2026-06-16T00:56:12+00:00

Pull x86 TDX updates from Dave Hansen:
 "There are a few cleanups, and some changes that should allow TDX and
  kexec to coexist nicely.

  The biggest change, however, is support for updating the TDX module
  after boot, just like CPU microcode. TDX users really want this
  because it lets them do security updates without tearing things down
  and rebooting.

   - Add TDX module update support

   - Make kexec and TDX finally place nice together

   - Put TDX error codes into a single header"

* tag 'x86_tdx_for_7.2-rc1' of gitolite.kernel.org:pub/scm/linux/kernel/git/tip/tip: (30 commits)
  x86/virt/tdx: Document TDX module update
  x86/virt/tdx: Enable TDX module runtime updates
  x86/virt/tdx: Refresh TDX module version after update
  coco/tdx-host: Lock out module updates when reading version
  x86/virt/seamldr: Add module update locking
  x86/virt/tdx: Restore TDX module state
  x86/virt/seamldr: Initialize the newly-installed TDX module
  x86/virt/seamldr: Install a new TDX module
  x86/virt/tdx: Reset software states during TDX module shutdown
  x86/virt/seamldr: Shut down the current TDX module
  x86/virt/seamldr: Abort updates after a failed step
  x86/virt/seamldr: Introduce skeleton for TDX module updates
  x86/virt/seamldr: Allocate and populate a module update request
  coco/tdx-host: Implement firmware upload sysfs ABI for TDX module updates
  coco/tdx-host: Don't expose P-SEAMLDR information on CPUs with erratum
  coco/tdx-host: Expose P-SEAMLDR information via sysfs
  x86/virt/seamldr: Add a helper to retrieve P-SEAMLDR information
  x86/virt/seamldr: Introduce a wrapper for P-SEAMLDR SEAMCALLs
  coco/tdx-host: Expose TDX module version
  coco/tdx-host: Introduce a "tdx_host" device
  ...

coco/tdx-host: Lock out module updates when reading version

2026-06-03T15:59:44+00:00

The TDX module version is currently stashed in some global variables
and dumped out to sysfs without locking. This works fine when the
version is static and never changes.

But with runtime module updates, the TDX module version can change.
Some kind of locking is needed. Barring this, userspace could
theoretically see a strange torn module version that is some
Frankenstein version from from two different updates.

Use the new module update lock/unlock to prevent updates while
trying to read the version.

Don't be fussy about it. There's no need to snapshot the version or do
READ_ONCE(), or minimize lock holding times. sysfs_emit() does not
sleep. Also note that the lock/unlock are backed by
preempt_dis/enable() which are really cheap CPU-local operations.
This is not a heavyweight lock.

Signed-off-by: Dave Hansen

coco/tdx-host: Implement firmware upload sysfs ABI for TDX module updates

2026-06-03T15:14:51+00:00

tl;dr: Select fw_upload for doing TDX module updates. The process of
selecting among available update images is complicated and nuanced. Punt
the selection process out to userspace. One existing userspace
implementation today is the script in the Intel TDX Module Binaries
repository[1].

Long Version:

The kernel supports two primary firmware update mechanisms:
 1. request_firmware() - used by microcode, SEV firmware, hundreds of
			 other drivers
 2. 'struct fw_upload' - used by CXL, FPGA updates, dozens of others

The key difference between is that request_firmware() loads a named file
from the filesystem where the filename is kernel-controlled, while
fw_upload accepts firmware data directly from userspace.

TDX module firmware update selection policy is too complex for the kernel.
Leave it to userspace and use fw_upload.

Add a skeleton fw_upload implementation to be fleshed out in subsequent
patches.

Refactor the sysfs visiblity attribute function so it can be used as a
more generic flag for the presence of viable runtime update support.

Why fw_upload instead of request_firmware()?
============================================

Selecting a TDX module update image is not a simple "load the latest"
decision. Userspace needs to choose an image that is compatible with both
the platform and the currently running module.

Some constraints are hard requirements:

a. Module version series are platform-specific. For example, the 1.5.x
   series runs on Sapphire Rapids but not Granite Rapids, which needs
   2.0.x.

b. Updates are also constrained by version distance. A 1.5.6 module
   might permit updates to 1.5.7 but not to 1.5.50.

There may also be userspace policy choices:

c. Decide the update direction: upgrade or downgrade

d. Choose whether to optimize for fewer updates or smaller version
   steps, for example, 1.2.3=>1.2.5 versus 1.2.3=>1.2.4=>1.2.5.

Given that complexity, leave module selection to userspace and use
fw_upload.

1. https://github.com/intel/confidential-computing.tdx.tdx-module.binaries/blob/main/version_select_and_load.py

[ dhansen: add version script link, add more explanation of code moves,
 	   fix some minor whitespace issues ]

Signed-off-by: Chao Gao 
Signed-off-by: Dave Hansen 
Reviewed-by: Tony Lindgren 
Reviewed-by: Kai Huang 
Reviewed-by: Kiryl Shutsemau (Meta) 
Link: https://lore.kernel.org/kvm/01fc8946-eb84-46fa-9458-f345dd3f6033@intel.com/
Link: https://patch.msgid.link/20260520133909.409394-13-chao.gao@intel.com

coco/tdx-host: Don't expose P-SEAMLDR information on CPUs with erratum

2026-06-03T15:14:51+00:00

TDX-capable CPUs clobber the current VMCS on P-SEAMLDR calls. Clearing
the current VMCS behind KVM's back breaks KVM.

Future CPUs will fix this by preserving the current VMCS across
P-SEAMLDR calls. A future specification update will describe the
VMCS-clearing behavior as an erratum and to state that it does not
occur when IA32_VMX_BASIC[60] is set.

Add a CPU bug bit and refuse to expose P-SEAMLDR information on
affected CPUs.

Use a CPU bug bit to stay consistent with X86_BUG_TDX_PW_MCE. As a
bonus, the bug bit is visible to userspace, which allows userspace to
determine why these sysfs files are not exposed, and it can also be
checked by other kernel components in the future if needed.

== Alternatives ==
Two workarounds were considered but both were rejected:

1. Save/restore the current VMCS around P-SEAMLDR calls. This produces ugly
   assembly code [1] and doesn't play well with #MCE or #NMI if they
   need to use the current VMCS.

2. Move KVM's VMCS tracking logic to the TDX core code, which would break
   the boundary between KVM and the TDX core code [2].

[ dhansen: comment and changelog munging. Add seamldr_call() bug check. ]

Signed-off-by: Chao Gao 
Signed-off-by: Dave Hansen 
Reviewed-by: Kai Huang 
Reviewed-by: Kiryl Shutsemau (Meta) 
Reviewed-by: Rick Edgecombe 
Reviewed-by: Dave Hansen 
Link: https://lore.kernel.org/kvm/fedb3192-e68c-423c-93b2-a4dc2f964148@intel.com/ # [1]
Link: https://lore.kernel.org/kvm/aYIXFmT-676oN6j0@google.com/ # [2]
Link: https://patch.msgid.link/20260520133909.409394-12-chao.gao@intel.com

coco/tdx-host: Expose P-SEAMLDR information via sysfs

2026-06-03T15:14:51+00:00

TDX module updates require userspace to select the appropriate module
to load. Expose necessary information to facilitate this decision. Two
values are needed:

- P-SEAMLDR version: for compatibility checks between TDX module and
		     P-SEAMLDR
- num_remaining_updates: indicates how many updates can be performed

Expose them as tdx-host device attributes visible only when updates
are supported.

Note that the underlying P-SEAMLDR attributes are available regardless
of update support; this only restricts their visibility to userspace.

Signed-off-by: Chao Gao 
Signed-off-by: Dave Hansen 
Reviewed-by: Kiryl Shutsemau (Meta) 
Reviewed-by: Dave Hansen 
Link: https://patch.msgid.link/20260520133909.409394-11-chao.gao@intel.com

coco/tdx-host: Expose TDX module version

2026-06-03T15:14:51+00:00

For TDX module updates, userspace needs to select compatible update
versions based on the current module version.

For example, the 1.5.x series runs on Sapphire Rapids but not Granite
Rapids, which needs 2.0.x. Updates are also constrained by version
distance, so a 1.5.6 module might permit updates to 1.5.7 but not to
1.5.20.

Start the process of punting the version selection logic to userspace.
Expose the TDX module version in the new faux device.

Define TDX_VERSION_FMT macro for the TDX version format since it will be
used multiple times. Also convert an existing print statement to use it.

== Background ==

For posterity, here's what other firmware mechanisms do:

1. AMD SEV leverages an existing PCI device for the PSP to expose
   metadata. TDX uses a faux device as it doesn't have PCI device
   in its architecture.

2. Microcode uses per-CPU virtual devices to report microcode revisions
   because CPUs can have different revisions. But, there is only a
   single TDX module, so exposing the TDX module version through a global
   TDX faux device is appropriate

3. ARM's CCA implementation isn't in-tree yet, but will likely follow a
   similar faux device approach, though it's unclear whether they need
   to expose firmware version information

[ dhansen: trim changelog ]

Signed-off-by: Chao Gao 
Signed-off-by: Dave Hansen 
Reviewed-by: Binbin Wu 
Reviewed-by: Tony Lindgren 
Reviewed-by: Xu Yilun 
Reviewed-by: Kai Huang 
Reviewed-by: Kiryl Shutsemau (Meta) 
Reviewed-by: Xiaoyao Li 
Reviewed-by: Dave Hansen 
Link: https://lore.kernel.org/all/2025073035-bulginess-rematch-b92e@gregkh/ # [1]
Link: https://patch.msgid.link/20260520133909.409394-8-chao.gao@intel.com

coco/tdx-host: Introduce a "tdx_host" device

2026-06-03T15:14:51+00:00

TDX depends on a platform firmware module that runs on the CPU.
Unlike other CoCo architectures, TDX has no hardware "device"
running the show, just a blob on the CPU.

Create a virtual device to anchor interactions with this platform
firmware. This lets later code:

 - expose metadata: TDX module version, seamldr version, to userspace
   as device attributes

 - implement firmware uploader APIs (which are tied to a device) to
   support TDX module runtime updates

Use a faux device because the TDX module is singular within the system
and has no platform resources. Using a faux device eliminates the need
to create a stub bus.

The call to tdx_get_sysinfo() ensures that the TDX module is ready to
provide services.

Note that AMD has a PCI device for the PSP for SEV and ARM CCA will
likely have a faux device [1].

Thanks to Dan and Yilun for all the help on this one.

[ dhansen: trim changelog ]

Signed-off-by: Chao Gao 
Signed-off-by: Dave Hansen 
Reviewed-by: Jonathan Cameron 
Reviewed-by: Tony Lindgren 
Reviewed-by: Xu Yilun 
Reviewed-by: Kai Huang 
Reviewed-by: Kiryl Shutsemau (Meta) 
Reviewed-by: Xiaoyao Li 
Link: https://lore.kernel.org/all/2025073035-bulginess-rematch-b92e@gregkh/ # [1]
Link: https://patch.msgid.link/20260520133909.409394-7-chao.gao@intel.com

virt: sev-guest: Explicitly leak pages in unknown state

2026-05-21T01:03:17+00:00

When set_memory_{encrypted,decrypted}() fail, the user cannot know at which
point the function failed, meaning that the pages are left in an unknown state
from the point of view of the caller.

Since the pages may be left in an unencrypted state, they are not suitable for
general use, and cannot be returned safely to the buddy allocator. Avoid the
issue by never freeing the pages, and then do the proper accounting by calling
snp_leak_pages().

Fixes: 3e385c0d6ce8 ("virt: sev-guest: Move SNP Guest Request data pages handling under snp_cmd_mutex")
Signed-off-by: Carlos López 
Signed-off-by: Borislav Petkov (AMD) 
Cc: stable@kernel.org

virt: sev-guest: Do not use host-controlled page order in cleanup path

2026-05-17T18:45:07+00:00

When issuing an extended guest request (SVM_VMGEXIT_EXT_GUEST_REQUEST),
get_ext_report() allocates a buffer to retrieve a certificate blob from the
host, keeping track of its size in report_req->certs_len.

However, the host may return SNP_GUEST_VMM_ERR_INVALID_LEN, indicating
an invalid buffer size, as well as the expected length of such buffer.
get_ext_report() subsequently updates report_req->certs_len with the
host-controlled value, and cleans up the buffer by computing a page order
from such value. This is incorrect, as the host-provided length may not
match the page order of the original allocation, potentially resulting
in corruption in the page allocator.

Fix this by using alloc_pages_exact() instead, and reusing @npages to
compute the size passed to free_pages_exact(). For consistency, also
use @npages to compute the size when allocating the pages, even though
this last change has no functional effect.

Fixes: 3e385c0d6ce8 ("virt: sev-guest: Move SNP Guest Request data pages handling under snp_cmd_mutex")
Signed-off-by: Carlos López 
Signed-off-by: Borislav Petkov (AMD) 
Tested-by: Michael Roth 
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds

Merge tag 'tsm-for-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/devsec/tsm

2026-04-26T16:51:29+00:00

Pull PCIe TSP update from Dan Williams:
 "A small update for the TSM core. It is arguably a fix and coming in
  late as I have been offline the past few weeks:

   - Drop class_create() for the 'tsm' class"

* tag 'tsm-for-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/devsec/tsm:
  virt: coco: change tsm_class to a const struct