From: Tom Lendacky <thomas.lendacky@amd.com>
To: "linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
kvm list <kvm@vger.kernel.org>
Cc: "Kaplan, David" <david.kaplan@amd.com>,
Jeremy Powell <jeremy.powell@amd.com>,
"Giani, Dhaval" <Dhaval.Giani@amd.com>,
Alexey Kardashevskiy <aik@amd.com>,
Ashish Kalra <ashkalra@amd.com>
Subject: KVM Forum: Trusted I/O BoF summary
Date: Thu, 6 Jul 2023 09:53:52 -0500 [thread overview]
Message-ID: <8e8eea5a-c5bb-c460-0e80-0f769ec9e6d8@amd.com> (raw)
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
reply other threads:[~2023-07-06 14:53 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8e8eea5a-c5bb-c460-0e80-0f769ec9e6d8@amd.com \
--to=thomas.lendacky@amd.com \
--cc=Dhaval.Giani@amd.com \
--cc=aik@amd.com \
--cc=ashkalra@amd.com \
--cc=david.kaplan@amd.com \
--cc=jeremy.powell@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 read-only IMAP folder(s) and NNTP newsgroup(s).