One of the most exciting merges this weekend to the [1]Linux 6.19 kernel is establishing the infrastructure for supporting PCI Express link encryption and device authentication. Multiple vendors are working on PCIe link encryption for their hardware while this initial pull begins laying the foundation of AMD SEV-TIO Trusted I/O support for the mainline kernel.

Dan Williams of Intel sent out the pull request for laying out the new PCI infrastructure for PCIe link encryption and device authentication. The first implementation of that new code is the AMD SEV-TIO for Trusted I/O support. Dan explained in the [2]pull request :

"This work is the result of multiple vendors coming to consensus on some core infrastructure (thanks Alexey, Yilun, and Aneesh!), and three vendor implementations, although only one is included in this pull. The PCI core changes have an ack from Bjorn, the crypto/ccp/ changes have an ack from Tom, and the iommu/amd/ changes have an ack from Joerg. It has all appeared in linux-next with a small conflict reported by Stephen (I agree with his resolution), and some late build fixes for odd configs reported by the 0day robot. A recent small fix from Dan Carpenter, expect Tom to pick up for post-rc1.

PCIe link encryption is made possible by the soup of acronyms mentionedin the shortlog below. Link Integrity and Data Encryption (IDE) is a protocol for installing keys in the transmitter and receiver at each end of a link. That protocol is transported over Data Object Exchange (DOE) mailboxes using PCI configuration requests.

The aspect that makes this a "platform firmware service" is that the key provisioning and protocol is coordinated through a Trusted Execution Envrionment (TEE) Security Manager (TSM). That is either firmware running in a coprocessor (AMD SEV-TIO), or quasi-hypervisor software (Intel TDX Connect / ARM CCA) running in a protected CPU mode.

Now, the only reason to ask a TSM to run this protocol and install the keys rather than have a Linux driver do the same is so that later, a confidential VM can ask the TSM directly "can you certify this device?". That precludes host Linux from provisioning its own keys, because host Linux is outside the trust domain for the VM. It also turns out that all architectures, save for one, do not publish a mechanism for an OS to establish keys in the root port. So "TSM-established link encryption" is the only cross-architecture path for this capability for the foreseeable future.

Acceptance of this pull request unblocks the other arch implementations to follow in v6.20/v7.0, once they clear some other dependencies, and it unblocks the next phase of work to implement the end-to-end flow of confidential device assignment. The PCIe specification calls this end-to-end flow Trusted Execution Environment (TEE) Device Interface Security Protocol (TDISP).

In the meantime, Linux gets a link encryption facility which has practical benefits along the same lines as memory encryption. It authenticates devices via certificates and may protect against interposer attacks trying to capture clear-text PCIe traffic."

This is just the start and the first phase of AMD SEV-TIO being upstreamed but more code is expected for the Linux 6.20~7.0 cycle.

See [3]the merge if wanting to browse through the initial 4K lines of code and see the new sysfs interface documentation around the TEE Security Manager, etc.

AMD SEV-TIO for PCIe device protection with NICs, accelerators, storage, etc as part of the TEE Device Interface Security Protocol is supported with current AMD EPYC 9005 "Turin" platforms.



[1] https://www.phoronix.com/search/Linux+6.19

[2] https://lore.kernel.org/lkml/69339e215b09f_1e0210057@dwillia2-mobl4.notmuch/

[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=249872f53d64441690927853e9d3af36394802d5