Re: [PATCH 00/12] PCI device authentication

[Lukas Wunner <lukas@wunner.de>]

On Tue, Oct 10, 2023 at 03:07:41PM +1100, Alexey Kardashevskiy wrote:
> But the way SPDM is done now is that if the user (as myself) wants to let
> the firmware run SPDM - the only choice is disabling CONFIG_CMA completely
> as CMA is not a (un)loadable module or built-in (with some "blacklist"
> parameters), and does not provide a sysfs knob to control its tentacles.
> Kinda harsh.

On AMD SEV-TIO, does the PSP perform SPDM exchanges with a device
*before* it is passed through to a guest?  If so, why does it do that?

Dan and I discussed this off-list and Dan is arguing for lazy attestation,
i.e. the TSM should only have the need to perform SPDM exchanges with
the device when it is passed through.

So the host enumerates the DOE protocols and authenticates the device.
When the device is passed through, patch 12/12 ensures that the host
keeps its hands off of the device, thus affording the TSM exclusive
SPDM control.

I agree that the commit message of 12/12 is utterly misleading in that
it says "the guest" is granted exclusive control.  It should say "the TSM"
instead.  (There might be implementations where the guest itself has
the role of the TSM and authenticates the device on its own behalf,
but PCIe r6.1 sec 11 uses the term "TSM" so that's what the commit
message needs to use.)

However apart from the necessary rewrite of the commit message and
perhaps a rename of the PCI_CMA_OWNED_BY_GUEST flag, I think patch 12/12
should already be doing exactly what you need -- provided that the
PSP doesn't perform SPDM exchanges before passthrough.  If it already
performs them, say, on boot, I'd like to understand the reason.

Thanks,

Lukas