On 6/6/23 12:43, Dan Williams wrote:
[ add Lukas ]
Giani, Dhaval wrote:
[AMD Official Use Only - General]
Hi all,
We have proposed a trusted I/O BoF session at KVM forum this year. I wanted
to kick off the discussion to maximize the 25 mins we have.
By trusted I/O, I mean using TDISP to have “trusted” communications with a
device using something like AMD SEV-TIO [1] or Intel’s TDX connect [2].
Some topics we would like to discuss are
o What is the device model like?
o Do we enlighten the PCI subsystem?
o Do we enlighten device drivers?
One observation in relation to these first questions is something that
has been brewing since SPDM and IDE were discussed at Plumbers 2022.
https://lpc.events/event/16/contributions/1304/
Namely, that there is value in the base specs on the way to the full
vendor TSM implementations. I.e. that if the Linux kernel can aspire to
the role of a TSM it becomes easier to incrementally add proxying to a
platform TSM later. In the meantime, platforms and endpoints that
support CMA / SPDM and PCIe/CXL IDE but not full "trusted I/O" still
gain incremental benefit.
TSM on the AMD hardware is a PSP firmware and it is going to implement
all of SPDM/IDE and the only proxying the host kernel will do is PCI DOE.
The first proof point for that idea is teaching the PCI core to perform
CMA / SPDM session establishment and provide that result to drivers.
That is what Lukas has been working on after picking up Jonathan's
initial SPDM RFC. I expect the discussion on those forthcoming patches
starts to answer device-model questions around attestation.
Those SPDM patches should work on the AMD hw (as they do not need any
additional host PCI support) but that's about it - IDE won't be possible
that way as there is no way to program the IDE keys to PCI RC without
the PSP.
If we want reuse any of that code to provide
certificates/measurements/reports for the host kernel, then that will
need to allow skipping the bits that the firmware implements (SPDM, IDE)
+ calling the firmware instead. And TDISP is worse as it is based on the
idea of not trusting the VMM (is there any use for TDISP for the
host-only config at all?) so such SPDM-enabled linux has to not run KVM.
o What does the guest need to know from the device?
o How does the attestation workflow work?
o Generic vs vendor specific TSMs
Some of these topics may be better suited for LPC,
Maybe, but there's so much to discuss that the more opportunities to
collaborate on the details the better.
however we want to get the discussion going from the KVM perspective
and continue wider discussions at LPC.
While I worry that my points above are more suited to something like a
PCI Micro-conference than a KVM BoF, I think the nature of "trusted I/O"
requires those tribes to talk more to each other.
--
Alexey
