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
