Re: [PATCH 00/12] PCI device authentication

[Alexey Kardashevskiy <aik@amd.com>]

On 12/10/23 03:57, Jonathan Cameron wrote:
> On Tue, 10 Oct 2023 23:53:16 +1100
> Alexey Kardashevskiy <aik@amd.com> wrote:
> 
>> On 10/10/23 19:19, Lukas Wunner wrote:
>>> On Tue, Oct 10, 2023 at 03:07:41PM +1100, Alexey Kardashevskiy wrote:
>>>> On 10/10/23 00:49, Lukas Wunner wrote:
>>>>> PCI Firmware Spec would seem to be appropriate.  However this can't
>>>>> be solved by the kernel community.
>>>>
>>>> How so? It is up to the user to decide whether it is SPDM/CMA in the kernel
>>>> or   the firmware + coco, both are quite possible (it is IDE which is not
>>>> possible without the firmware on AMD but we are not there yet).
>>>
>>> The user can control ownership of CMA-SPDM e.g. through a BIOS knob.
>>> And that BIOS knob then influences the outcome of the _OSC negotiation
>>> between platform and OS.
>>>
>>>    
>>>> 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.
>>>
>>> The problem is every single vendor thinks they can come up with
>>> their own idea of who owns the SPDM session:
>>>
>>> I've looked at the Nvidia driver and they've hacked libspdm into it,
>>> so their idea is that the device driver owns the SPDM session.
>>   >
>>> AMD wants the host to proxy DOE but not own the SPDM session.
>>   >
>>> We have *standards* for a reason.  So that products are interoperable.
>>
>> There is no "standard PCI ethernet device", somehow we survive ;)
>>
>>> If the kernel tries to accommodate to every vendor's idea of SPDM ownership
>>> we'll end up with an unmaintainable mess of quirks, plus sysfs knobs
>>> which were once intended as a stopgap but can never be removed because
>>> they're userspace ABI.
>>
>> The host kernel needs to accommodate the idea that it is not trusted,
>> and neither is the BIOS.
>>
>>> This needs to be solved in the *specification*.
>>   >
>>> And the existing solution for who owns a particular PCI feature is _OSC.
>>> Hence this needs to be taken up with the Firmware Working Group at the
>>> PCISIG.
>>
>> I do like the general idea of specifying things, etc but this place does
>> not sound right. The firmware you are talking about has full access to
>> PCI, the PSP firmware does not have any (besides the IDE keys
>> programming), is there any example of such firmware in the PCI Firmware
>> spec? From the BIOS standpoint, the host OS owns DOE and whatever is
>> sent over it (on AMD SEV TIO). The host OS chooses not to compose these
>> SPDM packets itself (while it could) in order to be able to run guests
>> without having them to trust the host OS.
> 
> As a minimum I'd like to see something saying - "keep away from discovery
> protocol on this DOE instance".  An ACPI _OSC or _DSM or similar could do that.
> It won't be needed for every approach, but it might for some.

I am relying on the existing DOE code to do the discovery. No APCI in 
the SEV TIO picture.

> Then either firmwware knows what to do, or a specific driver does.
> 
> If your proxy comes up late enough that we've already done (and cached) discovery
> protocols results then this might not be a problem for this particular
> approach as we have no reason to rerun discovery (other than hotplug in which
> case there is lots of other stuff to do anyway).
> 
> For your case we need some hooks for the PSP to be able to drive the SPDM session
> but that should be easy to allow. 

This is just a couple of calls:
doe_md = pci_find_doe_mailbox(pdev, PCI_VENDOR_ID_PCI_SIG, 
PCI_DOE_PROTOCOL_SECURED_CMA_SPDM);
and
pci_doe(doe_mb, PCI_VENDOR_ID_PCI_SIG, 
PCI_DOE_PROTOCOL_SECURED_CMA_SPDM, ...)


> I don't think precludes the hypervisor also
> verifying the hardware is trusted by it along the way (though not used for IDE).
> So if you are relying on a host OS proxy I don't thing you need to disable CONFIG_CMA
> (maybe something around resets?)

If I do the above 2 calls, then pdev->spdm_state will be out of sync.

> Potentially the host OS tries first (maybe succeeds - that doesn't matter though
> nothing wrong with defense in depth) and then the PSP via a proxy does it all over
> again which is fine.  All we need to do is guarantee ordering and I think we are
> fine for that.

Only trusted bits go all over again, untrusted stuff such as discovery 
is still done by the host OS and PSP is not rerunning it.


> Far too many possible models here but such is life I guess.

True. When I joined the x86 world (quite recently), I was surprised how 
different AMD and Intel are in everything besides the userspace :)


>>>> Note, this PSP firmware is not BIOS (which runs on the same core and has
>>>> same access to PCI as the host OS), it is a separate platform processor
>>>> which only programs IDE keys to the PCI RC (via some some internal bus
>>>> mechanism) but does not do anything on the bus itself and relies on the host
>>>> OS proxying DOE, and there is no APCI between the core and the psp.
>>>
>>> Somewhat tangentially, would it be possible in your architecture
>>> that the host or guest asks PSP to program IDE keys into the Root Port?
>>
>> Sure it is possible to implement. But this does not help our primary use
>> case which is confidential VMs where the host OS is not trusted with the
>> keys.
>>
>>> Or alternatively, access the key registers directly without PSP involvement?
>>
>> No afaik, for the reason above.


-- 
Alexey