Re: [RFC PATCH 1/5] PCI/CMA: Prepare to interoperate with TSM authentication

From: Bjorn Helgaas <helgaas@kernel.org>
To: Dan Williams <dan.j.williams@intel.com>
Cc: linux-coco@lists.linux.dev, Wu Hao <hao.wu@intel.com>,
	Yilun Xu <yilun.xu@intel.com>, Lukas Wunner <lukas@wunner.de>,
	Samuel Ortiz <sameo@rivosinc.com>,
	Alexey Kardashevskiy <aik@amd.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	linux-pci@vger.kernel.org, gregkh@linuxfoundation.org
Subject: Re: [RFC PATCH 1/5] PCI/CMA: Prepare to interoperate with TSM authentication
Date: Thu, 8 Feb 2024 16:09:09 -0600	[thread overview]
Message-ID: <20240208220909.GA975234@bhelgaas> (raw)
In-Reply-To: <170660663177.224441.2104783746551322918.stgit@dwillia2-xfh.jf.intel.com>

On Tue, Jan 30, 2024 at 01:23:51AM -0800, Dan Williams wrote:
> A TSM (TEE Security Manager) is a platform agent that facilitates TEE
> I/O (device assignment for confidential VMs). It uses PCI CMA, IDE, and
> TDISP to authenticate, encrypt/integrity-protect the link, and bind
> device-virtual-functions capable of accessing private memory to
> confidential VMs (TVMs).
> 
> Unlike native PCI CMA many of the details of establishing a connection
> between a device (DSM) and the TSM are abstracted through platform APIs.
> I.e. in the native case Linux picks the keys and validates the
> certificates, in the TSM case Linux just sees a "success" from invoking
> a "connect" API with the TSM.
> 
> SPDM only allows for one session-owner per transport (DOE), so the
> expectation is that authentication will only ever be in the "native"
> established case, or the "tsm" established case.

Holy cow, this is tasty nested acronym soup.  TEE, CMA, IDE, TDISP,
TVM, DSM, SPDM, DOE?  I know these will all become common knowledge in
a few years, but this is a big mouthful right now.  Is there any
overview or glossary in Documentation/ or similar?

Bjorn