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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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

Jason




[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]
  Powered by Linux