Re: RE: KVM Forum BoF on I/O + secure virtualization

[Alexey Kardashevskiy <aik@amd.com>]

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