Re: [PATCH v2 08/18] PCI/CMA: Authenticate devices on enumeration

[Damien Le Moal <dlemoal@kernel.org>]

On 7/16/24 08:03, Jason Gunthorpe wrote:
> On Tue, Jul 16, 2024 at 07:17:55AM +0900, Damien Le Moal wrote:
> 
>> Of note though is that in the case of SCSI/ATA storage, the device
>> (the HDD or SSD) is not the one doing DMA directly to the host/guest
>> memory. That is the adapter (the HBA). So we could ask ourselves if
>> it makes sense to authenticate storage devices without the HBA being
>> authenticated first.
> 
> For sure, you have to have all parts of the equation
> authenticated before you can turn on access to trusted memory.
> 
> Is there some way these non DOE messages channel bind the attestation
> they return to the PCI TDISP encryption keys?

For the scsi/ata case, at least initially, I think the use case will be only
device authentication to ensure that the storage device is genuine (not
counterfeit), has a good FW, and has not been tempered with and not the
confidential VM case.

> What is the sequence you are after?

The above as a first use case. For the confidential VM case, I think the HBA
needs to be involved as that is the one doing the DMA. But to be frank, I have
not spent time thinking about that use case at all.

>> And for PCI nvme devices that can support SPDM either through either
>> PCI DOE or SPDM-over-storage (SECURITY SEND/RECV commands), then I
>> guess we need some special handling/config to allow (or not)
>> SPDM-over-storage authentication as that will require the device
>> driver to be loaded and to execute some commands before
>> authentication can happen.
> 
> I'm not sure those commands make sense in a PCI context? They make
> more sense to me in a NVMe over Network scenario where you could have
> the attestation bind a TLS secret..

100% agree, but I can foresee PCI NVMe device vendors adding SPDM support
"cheaply" using these commands since that can be implemented as a FW change
while adding DOE would be a controller HW change... So at least initially, it
may be safer to simply not support the NVMe SPDM-over-storage case, or at least
not support it for trusted platform/confidential VMs and only allow it for
storage authentication (in addition to the usual encryption, OPAL locking etc).

> Still, my remarks from before stand, it looks like it is going to be
> complex to flip a device from non-trusted to trusted.

Indeed, and we may need to have different ways of doing that given the different
transport and use cases.

-- 
Damien Le Moal
Western Digital Research