On 7/16/24 08:42, Jason Gunthorpe wrote: > On Tue, Jul 16, 2024 at 08:26:55AM +0900, Damien Le Moal wrote: >> 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. > > Oh, I see, that is something quite different then. > > In that case you probably want to approve the storage device before > allowing read/write on the block device which is a quite a different > gate than the confidential VM people are talking about. > > It is the equivalent we are talking about here about approving the PCI > device before allowing an OS driver to use it. > >> 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). > > Yeah, probably. > > Without a way to bind the NVMe SPDM support to the TDISP it doesn't > seem useful to me for CC cases. Yes, that likely would not work at all anyway as the driver needs to start probing the device before authentication can happen, meaning that DMA needs to be working before we can authenticate. So unless device probing is changed to use untrusted memory for probing, that would not work anyway. > > Something like command based SPDM seems more useful to load an OPAL > media encryption secret or something like that - though you can't use > it to exclude an interposer attack so I wonder if it really matters.. > >>> 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. > > To be clear there are definately different sorts of trusted/untrusted > here > > For CC VMs and TDISP trusted/untrusted means the device is allowed to > DMA to secure memory. > > For storage trusted/untrusted may mean the drive is allowed to get a > media encryption secret, or have it's media accessed. > > I think they are very different targets Initially, we can certainly treat them like that. But eventually, we may need something more as CC VMs access to storage has to be trusted too and so will require both HBA and the device to be trusted. For the TDISP handling, I am however not sure how that should looks like (is it the HBA or the storage device secrets that are used, both ?). As I said, I have not spent any time yet thinking about that use case. -- Damien Le Moal Western Digital Research
