summaryrefslogtreecommitdiff
path: root/drivers/virt/coco/Kconfig
AgeCommit message (Collapse)Author
2025-12-04virt: Fix Kconfig warning when selecting TSM without VIRT_DRIVERSNathan Chancellor
After commit 3225f52cde56 ("PCI/TSM: Establish Secure Sessions and Link Encryption"), there is a Kconfig warning when selecting CONFIG_TSM without CONFIG_VIRT_DRIVERS: WARNING: unmet direct dependencies detected for TSM Depends on [n]: VIRT_DRIVERS [=n] Selected by [y]: - PCI_TSM [=y] && PCI [=y] CONFIG_TSM is defined in drivers/virt/coco/Kconfig but this Kconfig is only sourced when CONFIG_VIRT_DRIVERS is enabled. Since this symbol is hidden with no dependencies, it should be available without a symbol that just enables a menu. Move the sourcing of drivers/virt/coco/Kconfig outside of CONFIG_VIRT_DRIVERS and wrap the other source statements in drivers/virt/coco/Kconfig with CONFIG_VIRT_DRIVERS to ensure users do not get any additional prompts while ensuring CONFIG_TSM is always available to select. This complements commit 110c155e8a68 ("drivers/virt: Drop VIRT_DRIVERS build dependency"), which addressed the build issue that this Kconfig warning was pointing out. Fixes: 3225f52cde56 ("PCI/TSM: Establish Secure Sessions and Link Encryption") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202511140712.NubhamPy-lkp@intel.com/ Signed-off-by: Nathan Chancellor <nathan@kernel.org> Link: https://patch.msgid.link/20251203-fix-pci-tsm-select-tsm-warning-v1-1-c3959c1cb110@kernel.org Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2025-11-03coco/tsm: Introduce a core device for TEE Security ManagersDan Williams
A "TSM" is a platform component that provides an API for securely provisioning resources for a confidential guest (TVM) to consume. The name originates from the PCI specification for platform agent that carries out operations for PCIe TDISP (TEE Device Interface Security Protocol). Instances of this core device are parented by a device representing the platform security function like CONFIG_CRYPTO_DEV_CCP or CONFIG_INTEL_TDX_HOST. This device interface is a frontend to the aspects of a TSM and TEE I/O that are cross-architecture common. This includes mechanisms like enumerating available platform TEE I/O capabilities and provisioning connections between the platform TSM and device DSMs (Device Security Manager (TDISP)). For now this is just the scaffolding for registering a TSM device sysfs interface. Cc: Xu Yilun <yilun.xu@linux.intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Co-developed-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alexey Kardashevskiy <aik@amd.com> Link: https://patch.msgid.link/20251031212902.2256310-2-dan.j.williams@intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2025-05-02coco/guest: Move shared guest CC infrastructure to drivers/virt/coco/guest/Dan Williams
In preparation for creating a new drivers/virt/coco/host/ directory to house shared host driver infrastructure for confidential computing, move configfs-tsm to a guest/ sub-directory. The tsm.ko module is renamed to tsm_reports.ko. The old tsm.ko module was only ever demand loaded by kernel internal dependencies, so it should not affect existing userspace module install scripts. The new drivers/virt/coco/guest/ is also a preparatory landing spot for new / optional TSM Report mechanics like a TCB stability enumeration / watchdog mechanism. To be added later. Cc: Wu Hao <hao.wu@intel.com> Cc: Yilun Xu <yilun.xu@intel.com> Cc: Samuel Ortiz <sameo@rivosinc.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Alexey Kardashevskiy <aik@amd.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Link: https://patch.msgid.link/174107246641.1288555.208426916259466774.stgit@dwillia2-xfh.jf.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2024-10-23virt: arm-cca-guest: TSM_REPORT support for realmsSami Mujawar
Introduce an arm-cca-guest driver that registers with the configfs-tsm module to provide user interfaces for retrieving an attestation token. When a new report is requested the arm-cca-guest driver invokes the appropriate RSI interfaces to query an attestation token. The steps to retrieve an attestation token are as follows: 1. Mount the configfs filesystem if not already mounted mount -t configfs none /sys/kernel/config 2. Generate an attestation token report=/sys/kernel/config/tsm/report/report0 mkdir $report dd if=/dev/urandom bs=64 count=1 > $report/inblob hexdump -C $report/outblob rmdir $report Signed-off-by: Sami Mujawar <sami.mujawar@arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Link: https://lore.kernel.org/r/20241017131434.40935-11-steven.price@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-08-30drivers/virt: pkvm: Add initial support for running as a protected guestWill Deacon
Implement a pKVM protected guest driver to probe the presence of pKVM and determine the memory protection granule using the HYP_MEMINFO hypercall. Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20240830130150.8568-3-will@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2023-10-19configfs-tsm: Introduce a shared ABI for attestation reportsDan Williams
One of the common operations of a TSM (Trusted Security Module) is to provide a way for a TVM (confidential computing guest execution environment) to take a measurement of its launch state, sign it and submit it to a verifying party. Upon successful attestation that verifies the integrity of the TVM additional secrets may be deployed. The concept is common across TSMs, but the implementations are unfortunately vendor specific. While the industry grapples with a common definition of this attestation format [1], Linux need not make this problem worse by defining a new ABI per TSM that wants to perform a similar operation. The current momentum has been to invent new ioctl-ABI per TSM per function which at best is an abdication of the kernel's responsibility to make common infrastructure concepts share common ABI. The proposal, targeted to conceptually work with TDX, SEV-SNP, COVE if not more, is to define a configfs interface to retrieve the TSM-specific blob. report=/sys/kernel/config/tsm/report/report0 mkdir $report dd if=binary_userdata_plus_nonce > $report/inblob hexdump $report/outblob This approach later allows for the standardization of the attestation blob format without needing to invent a new ABI. Once standardization happens the standard format can be emitted by $report/outblob and indicated by $report/provider, or a new attribute like "$report/tcg_coco_report" can emit the standard format alongside the vendor format. Review of previous iterations of this interface identified that there is a need to scale report generation for multiple container environments [2]. Configfs enables a model where each container can bind mount one or more report generation item instances. Still, within a container only a single thread can be manipulating a given configuration instance at a time. A 'generation' count is provided to detect conflicts between multiple threads racing to configure a report instance. The SEV-SNP concepts of "extended reports" and "privilege levels" are optionally enabled by selecting 'tsm_report_ext_type' at register_tsm() time. The expectation is that those concepts are generic enough that they may be adopted by other TSM implementations. In other words, configfs-tsm aims to address a superset of TSM specific functionality with a common ABI where attributes may appear, or not appear, based on the set of concepts the implementation supports. Link: http://lore.kernel.org/r/64961c3baf8ce_142af829436@dwillia2-xfh.jf.intel.com.notmuch [1] Link: http://lore.kernel.org/r/57f3a05e-8fcd-4656-beea-56bb8365ae64@linux.microsoft.com [2] Cc: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Cc: Dionna Amalie Glaze <dionnaglaze@google.com> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Peter Gonda <pgonda@google.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Samuel Ortiz <sameo@rivosinc.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Tested-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-10-19virt: coco: Add a coco/Makefile and coco/KconfigDan Williams
In preparation for adding another coco build target, relieve drivers/virt/Makefile of the responsibility to track new compilation unit additions to drivers/virt/coco/, and do the same for drivers/virt/Kconfig. Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Tested-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>