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

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

On 7/12/24 02:50, Dan Williams wrote:
> Lukas Wunner wrote:
>> On Tue, Jul 09, 2024 at 04:31:30PM -0700, Dan Williams wrote:
>>> Non-authenticated operation is the status quo. CMA is a building block
>>> to other security features.
>>
>> That's not quite correct:  Products exist which support CMA but neither
>> IDE nor TDISP.  CMA is not just a building block for IDE or TDISP,
>> but is useful on its own merits.
> 
> Agree it is useful. The use case of signed device inventory at a CSP,
> that I understand storage vendors are interested, does not demand
> aggressive forced authentication of all PCI devices in early init. As far
> as I understand the non PCI-CMA consumers of lib/spdm/ are going to be
> drivers possibly built as modules.

Yes, and they already are: SCSI/ATA and NVMe command transport for SPDM is being
defined (SPDM-over-storage using the SECURITY IN/OUT for SCSI and SECURITY
SEND/RECV commands for NVMe). Authentication of such storage device will require
the device driver to be loaded first and the device to be scanned and probed to
discover this feature. So SPDM authentication in this case would not even happen
early in the device initialization process as we will need the device to already
be functional to issue the security commands.

For PCIe/DOE devices (which could be PCIe NVMe devices not using
SPDM-over-storage), I do not see why we cannot also do the authentication from
the device driver context. As you suggested, pci_enable_device() context could
be the right place to do that, if the device driver opts-in (and that can be
driven by distro config).

This would result in all calls to lib/spdm authentication for all devices to
happen at the same timing, i.e. device driver initialization, whenever that
happens (at boot with kernel built-in or modules loaded later).

This approach would also likely facilitate handling re-authentication on resume
since that also involves the device driver, at least for the SPDM-over-storage
case (e.g. OPAL device locking/unlocking for SCSI already has code to be
suspend/resume aware).

-- 
Damien Le Moal
Western Digital Research