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
