Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37;
Message-ID: <0340908d-8d23-4553-be46-50bab7fe053a@kernel.org>
Date:   Thu, 12 Oct 2023 13:37:36 +0900
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 07/12] spdm: Introduce library to authenticate devices
Content-Language: en-US
To:     Alistair Francis <Alistair.Francis@wdc.com>,
        "Jonathan.Cameron@Huawei.com" <Jonathan.Cameron@Huawei.com>,
        "lukas@wunner.de" <lukas@wunner.de>
Cc:     "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
        Wilfred Mallawa <wilfred.mallawa@wdc.com>,
        "graf@amazon.com" <graf@amazon.com>,
        "linux-cxl@vger.kernel.org" <linux-cxl@vger.kernel.org>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "ming4.li@intel.com" <ming4.li@intel.com>,
        "herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
        "helgaas@kernel.org" <helgaas@kernel.org>,
        "alex.williamson@redhat.com" <alex.williamson@redhat.com>,
        "seanjc@google.com" <seanjc@google.com>,
        "zhi.a.wang@intel.com" <zhi.a.wang@intel.com>,
        "dwmw2@infradead.org" <dwmw2@infradead.org>,
        "dave.jiang@intel.com" <dave.jiang@intel.com>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        "thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
        "keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
        "aik@amd.com" <aik@amd.com>,
        "david.e.box@intel.com" <david.e.box@intel.com>,
        "linuxarm@huawei.com" <linuxarm@huawei.com>,
        "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
        "dhowells@redhat.com" <dhowells@redhat.com>,
        "dan.j.williams@intel.com" <dan.j.williams@intel.com>
References: <cover.1695921656.git.lukas@wunner.de>
 <89a83f42ae3c411f46efd968007e9b2afd839e74.1695921657.git.lukas@wunner.de>
 <20231003153937.000034ca@Huawei.com>
 <caf11c28d21382cc1a81d84a23cbca9e70805a87.camel@wdc.com>
From:   Damien Le Moal <dlemoal@kernel.org>
Organization: Western Digital Research
In-Reply-To: <caf11c28d21382cc1a81d84a23cbca9e70805a87.camel@wdc.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 10/12/23 12:26, Alistair Francis wrote:
> On Tue, 2023-10-03 at 15:39 +0100, Jonathan Cameron wrote:
>> On Thu, 28 Sep 2023 19:32:37 +0200
>> Lukas Wunner <lukas@wunner.de> wrote:
>>
>>> From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>>>
>>> The Security Protocol and Data Model (SPDM) allows for
>>> authentication,
>>> measurement, key exchange and encrypted sessions with devices.
>>>
>>> A commonly used term for authentication and measurement is
>>> attestation.
>>>
>>> SPDM was conceived by the Distributed Management Task Force (DMTF).
>>> Its specification defines a request/response protocol spoken
>>> between
>>> host and attached devices over a variety of transports:
>>>
>>>   https://www.dmtf.org/dsp/DSP0274
>>>
>>> This implementation supports SPDM 1.0 through 1.3 (the latest
>>> version).
>>
>> I've no strong objection in allowing 1.0, but I think we do need
>> to control min version accepted somehow as I'm not that keen to get
>> security folk analyzing old version...
> 
> Agreed. I'm not sure we even need to support 1.0
> 
>>
>>> It is designed to be transport-agnostic as the kernel already
>>> supports
>>> two different SPDM-capable transports:
>>>
>>> * PCIe Data Object Exchange (PCIe r6.1 sec 6.30, drivers/pci/doe.c)
>>> * Management Component Transport Protocol (MCTP,
>>>   Documentation/networking/mctp.rst)
>>
>> The MCTP side of things is going to be interesting because mostly you
>> need to jump through a bunch of hoops (address assignment, routing
>> setup
>> etc) before you can actually talk to a device.   That all involves
>> a userspace agent.  So I'm not 100% sure how this will all turn out.
>> However still makes sense to have a transport agnostic implementation
>> as if nothing else it makes it easier to review as keeps us within
>> one specification.
> 
> This list will probably expand in the future though
> 
>>>
>>> Use cases for SPDM include, but are not limited to:
>>>
>>> * PCIe Component Measurement and Authentication (PCIe r6.1 sec
>>> 6.31)
>>> * Compute Express Link (CXL r3.0 sec 14.11.6)
>>> * Open Compute Project (Attestation of System Components r1.0)
>>>  
>>> https://www.opencompute.org/documents/attestation-v1-0-20201104-pdf
>>
>> Alastair, would it make sense to also call out some of the storage
>> use cases you are interested in?
> 
> I don't really have anything to add at the moment. I think PCIe CMA
> covers the current DOE work

Specifications for SPDM encapsulation in SCSI and ATA commands (SECURITY
PROTOCOL IN/OUT and TRUSTED SNED/RECEIVE) is being worked on now but that is
still in early phases of definition. So that support can come later. I suspect
the API may need some modification to accommodate that use case, but we need
more complete specification first to clearly see what is needed (if anything at
all).


-- 
Damien Le Moal
Western Digital Research