Re: [PATCH v5 04/10] PCI/TSM: Authenticate devices via platform TSM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Alexey Kardashevskiy wrote:
> 
> 
> On 3/9/25 01:08, Aneesh Kumar K.V wrote:
> > Dan Williams <dan.j.williams@xxxxxxxxx> writes:
> > 
> >> The PCIe 7.0 specification, section 11, defines the Trusted Execution
> >> Environment (TEE) Device Interface Security Protocol (TDISP).  This
> >> protocol definition builds upon Component Measurement and Authentication
> >> (CMA), and link Integrity and Data Encryption (IDE). It adds support for
> >> assigning devices (PCI physical or virtual function) to a confidential VM
> >> such that the assigned device is enabled to access guest private memory
> >> protected by technologies like Intel TDX, AMD SEV-SNP, RISCV COVE, or ARM
> >> CCA.
> >>
> >> The "TSM" (TEE Security Manager) is a concept in the TDISP specification
> >> of an agent that mediates between a "DSM" (Device Security Manager) and
> >> system software in both a VMM and a confidential VM. A VMM uses TSM ABIs
> >> to setup link security and assign devices. A confidential VM uses TSM
> >> ABIs to transition an assigned device into the TDISP "RUN" state and
> >> validate its configuration. From a Linux perspective the TSM abstracts
> >> many of the details of TDISP, IDE, and CMA. Some of those details leak
> >> through at times, but for the most part TDISP is an internal
> >> implementation detail of the TSM.
> >>
> >> CONFIG_PCI_TSM adds an "authenticated" attribute and "tsm/" subdirectory
> >> to pci-sysfs. Consider that the TSM driver may itself be a PCI driver.
> >> Userspace can watch for the arrival of a "TSM" device,
> >> /sys/class/tsm/tsm0/uevent KOBJ_CHANGE, to know when the PCI core has
> >> initialized TSM services.
> >>
> >> The operations that can be executed against a PCI device are split into
> >> two mutually exclusive operation sets, "Link" and "Security" (struct
> >> pci_tsm_{link,security}_ops). The "Link" operations manage physical link
> >> security properties and communication with the device's Device Security
> >> Manager firmware. These are the host side operations in TDISP. The
> >> "Security" operations coordinate the security state of the assigned
> >> virtual device (TDI). These are the guest side operations in TDISP. Only
> >> link management operations are defined at this stage and placeholders
> >> provided for the security operations.
> >>
> >> The locking allows for multiple devices to be executing commands
> >> simultaneously, one outstanding command per-device and an rwsem
> >> synchronizes the implementation relative to TSM
> >> registration/unregistration events.
> >>
> >> Thanks to Wu Hao for his work on an early draft of this support.
> >>
> >> Cc: Lukas Wunner <lukas@xxxxxxxxx>
> >> Cc: Samuel Ortiz <sameo@xxxxxxxxxxxx>
> >> Cc: Alexey Kardashevskiy <aik@xxxxxxx>
> >> Acked-by: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
> >> Co-developed-by: Xu Yilun <yilun.xu@xxxxxxxxxxxxxxx>
> >> Signed-off-by: Xu Yilun <yilun.xu@xxxxxxxxxxxxxxx>
> >> Signed-off-by: Dan Williams <dan.j.williams@xxxxxxxxx>
> > 
> > you dropped pci_tsm_doe_transfer from an earlier version of this patch
> > in this series. Any reason for that?
> 
> yeah, me, it was rather useless wrapper.

...but then you did say ok to bring back later.

> https://lore.kernel.org/r/68ae4a0c45650_75db10016@dwillia2-mobl4.notmuch

The type safety of to_pci_tsm_pf0() probably has some value. Yilun has a
user. You are free to ignore in the SEV-TIO case, it's just a library
helper.




[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux