On Thu, Jan 26, 2023 at 04:07:29PM +0000, Jonathan Cameron wrote: > On Thu, 26 Jan 2023 14:15:05 +0100 > Samuel Ortiz <sameo@xxxxxxxxxxxx> wrote: > > > On Thu, Jan 26, 2023 at 10:58:47AM +0000, Jonathan Cameron wrote: > > > On Thu, 26 Jan 2023 10:24:32 +0100 > > > Samuel Ortiz <sameo@xxxxxxxxxxxx> wrote: > > > > > > > Hi Lukas, > > > > > > > > On Wed, Jan 25, 2023 at 11:03 PM Lukas Wunner <lukas@xxxxxxxxx> wrote: > > > > > > > > > [cc += Jonathan Cameron, linux-pci] > > > > > > > > > > On Wed, Jan 25, 2023 at 02:57:40PM +0000, Dr. David Alan Gilbert wrote: > > > > > > Greg Kroah-Hartman (gregkh@xxxxxxxxxxxxxxxxxxx) wrote: > > > > > > > Great, so why not have hardware attestation also for your devices you > > > > > > > wish to talk to? Why not use that as well? Then you don't have to > > > > > > > worry about anything in the guest. > > > > > > > > > > > > There were some talks at Plumbers where PCIe is working on adding that; > > > > > > it's not there yet though. I think that's PCIe 'Integrity and Data > > > > > > Encryption' (IDE - sigh), and PCIe 'Security Prtocol and Data Model' - > > > > > > SPDM. I don't know much of the detail of those, just that they're far > > > > > > enough off that people aren't depending on them yet. > > > > > > > > > > CMA/SPDM (PCIe r6.0 sec 6.31) is in active development on this branch: > > > > > > > > > > https://github.com/l1k/linux/commits/doe > > > > > > > > Nice, thanks a lot for that. > > > > > > > > > > > > > > > > > The device authentication service afforded here is generic. > > > > > It is up to users and vendors to decide how to employ it, > > > > > be it for "confidential computing" or something else. > > > > > > > > > > Trusted root certificates to validate device certificates can be > > > > > installed into a kernel keyring using the familiar keyctl(1) utility, > > > > > but platform-specific roots of trust (such as a HSM) could be > > > > > supported as well. > > > > > > > > > > > > > This may have been discussed at LPC, but are there any plans to also > > > > support confidential computing flows where the host kernel is not part > > > > of the TCB and would not be trusted for validating the device cert chain > > > > nor for running the SPDM challenge? > > > > > > There are lots of possible models for this. One simple option if the assigned > > > VF supports it is a CMA instance per VF. That will let the guest > > > do full attestation including measurement of whether the device is > > > appropriately locked down so the hypervisor can't mess with > > > configuration that affects the guest (without a reset anyway and that > > > is guest visible). > > > > So the VF would be directly assigned to the guest, and the guest kernel > > would create a CMA instance for the VF, and do the SPDM authentication > > (based on a guest provided trusted root certificate). I think one > > security concern with that approach is assigning the VF to the > > (potentially confidential) guest address space without the guest being > > able to attest of the device trustworthiness first. That's what TDISP is > > aiming at fixing (establish a secure SPDM between the confidential guest > > and the device, lock the device from the guest, attest and then enable > > DMA). > > Agreed, TDISP is more comprehensive, but also much more complex with > more moving parts that we don't really have yet. > > Depending on your IOMMU design (+ related stuff) and interaction with > the secure guest, you might be able to block any rogue DMA until > after attestation / lock down checks even if the Hypervisor was letting > it through. Provided that the guest or, in the TDX and AP-TEE cases, the TSM have protected access to the IOMMU, yes. But then the implementation becomes platform specific. Cheers, Samuel.
