Sorry for the delay on getting this out, it's been a crazy couple of weeks
since KVM Forum. Here's my summary of the discussion had at the KVM Forum
Trusted I/O BoF.
Some initial discussion of why Trusted I/O is really needed:
- Secure end-to-end path between the CVM and the device
- Performance advantage to avoid bounce buffering through shared memory
- Attestation of device
The discussion turned to the device model and was more guest focused:
- Where should the support to transition the TDI live?
- PCI subsystem?
- Device driver?
- Other (such as in an SVSM)?
- TDI readiness
- Use an SVSM to take TDI to run state and hand to the OS
- Firmware or kernel takes device to run state
- Hot-plug like
- Leave unlocked until guest requests to make device secure
- Attestation
- Generic or device specific?
- Is it a device specific policy?
- How to account for firmware revisions
- Should we just care about the measurement?
- Don't do any attestation
- Use SYSFS to present an interface to "activate" secure device
- Until activation, OS enforces DMA to shared memory
- Remote attestation can be performed to decide activation
- DMA security
- Can MMIO be locked but still not make DMA secure to allow the device
to be used similar to today
- Allow DMA, but only allow to shared memory (software enforced)
- Start in "OS non-secure" and move to "OS secure"
- vIOMMU prevents access to the whole address space
- Device driver work to transition DMA buffers
- Can this state be detected?
- What if OVMF has transitioned the device to secure
- Firmware, e.g. OVMF, would need to do the same
- The device should always be available for use
- Device does not need to be attested to be used
- Attestation could be done later to then move the device to
"OS secure"
It was hard to hear at times during the discussion. Thanks to Christophe
de Dinechin for recording the session and getting a copy of it to me.
Hopefully I didn't miss too much.
Thanks,
Tom
