linux-coco.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
* KVM Forum: Trusted I/O BoF summary
@ 2023-07-06 14:53 Tom Lendacky
  0 siblings, 0 replies; only message in thread
From: Tom Lendacky @ 2023-07-06 14:53 UTC (permalink / raw)
  To: linux-coco, kvm list
  Cc: Kaplan, David, Jeremy Powell, Giani, Dhaval,
	Alexey Kardashevskiy, Ashish Kalra

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

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2023-07-06 14:53 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-07-06 14:53 KVM Forum: Trusted I/O BoF summary Tom Lendacky

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).