Received: by 2002:a05:7412:d8a:b0:e2:908c:2ebd with SMTP id b10csp127151rdg; Thu, 12 Oct 2023 00:16:49 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGCpdQK7MljaKVrQnucbefXqcNfh6KxoeLBz4rxy/HehfVLCio3iszN4BtVzc7OYGQRXdiR X-Received: by 2002:a05:6a00:13a9:b0:68c:3f2:5ff7 with SMTP id t41-20020a056a0013a900b0068c03f25ff7mr27901104pfg.1.1697095008849; Thu, 12 Oct 2023 00:16:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697095008; cv=none; d=google.com; s=arc-20160816; b=WIH8dJS7Dwx3HwdxyRkctxGtIRn4FH87VUAefGIGd16bZcKOeClT8RMW607N7YtvfN vWl2c3sjIV9ofJ58TXQ7Fr4HbMLYk9jq6vhAWTDWMTpWaYzBmqkSn2FjXaNjspuBDToH XZIaavJjnZMWDPJIOdf63wLwKsxA4SVhWxvGRTZFgsdrQnHdeGm5CMlxCEI2qIDSJfeI thL1uvtOnc3gz1hRkemQxHGTA1G1hly87dxFt3+XJWJI+UTXeuYsqW9iLElEj/VTfX4G bKQvXYqeZ99KRxeRtFdmVpIeshzQNORyPD4frHKSJd6913jDBi8mIiYuYpmNx3ucjTKK iE3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=eg06ZpAWIvfzamuVvW5/Ok0mfHMTS+8u8GdOpSFpEDI=; fh=d2r/6acjQ7tIjSiO/AcUqcqIO9HhiWGkI6ywxQdYis4=; b=ohFmmX3a0EqCo4ZjyMWOBWd/LF4cUvPVwO3HtuA4CFGUYnkukjAlHqTE47OH14rO7t r6PhmNQozBuvQ+KobHGh8vSsUa5KdfiDNKiHzHMmKPYI7EcwaHMhnTVpuDfWje6n+OaE rC2EyQPP5OejSFd17N0+X9bVRcW0LLMq4W/rYPDid7hRBojOV+EwSCqqz7OaNdcAAT8U 0tokwdPOGDX7oWoZR/fbPtKb+lvfoxWmFjSp+oZZ6J/v6Afd8NPC/DlkU4YdIHtnYlzF ZlIbCiIenQeNPTVA4ZgEn6DM/5Yus32O+RmHQw85TOfXKzW1+VAsoS6a+RIVGG+J6tSL Xwjw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from morse.vger.email (morse.vger.email. [2620:137:e000::3:1]) by mx.google.com with ESMTPS id p27-20020a63951b000000b0059d48c43152si1610501pgd.40.2023.10.12.00.16.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Oct 2023 00:16:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by morse.vger.email (Postfix) with ESMTP id E7648803EE0F; Thu, 12 Oct 2023 00:16:45 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at morse.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347085AbjJLHQg (ORCPT + 99 others); Thu, 12 Oct 2023 03:16:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49366 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343607AbjJLHQe (ORCPT ); Thu, 12 Oct 2023 03:16:34 -0400 Received: from bmailout2.hostsharing.net (bmailout2.hostsharing.net [83.223.78.240]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7FEC29D; Thu, 12 Oct 2023 00:16:31 -0700 (PDT) Received: from h08.hostsharing.net (h08.hostsharing.net [IPv6:2a01:37:1000::53df:5f1c:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.hostsharing.net", Issuer "RapidSSL Global TLS RSA4096 SHA256 2022 CA1" (verified OK)) by bmailout2.hostsharing.net (Postfix) with ESMTPS id 904BD2800B1AF; Thu, 12 Oct 2023 09:16:29 +0200 (CEST) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 821D9224D1; Thu, 12 Oct 2023 09:16:29 +0200 (CEST) Date: Thu, 12 Oct 2023 09:16:29 +0200 From: Lukas Wunner To: Alistair Francis Cc: "Jonathan.Cameron@Huawei.com" , "kvm@vger.kernel.org" , "linux-coco@lists.linux.dev" , Wilfred Mallawa , "graf@amazon.com" , "linux-cxl@vger.kernel.org" , "davem@davemloft.net" , "ming4.li@intel.com" , "herbert@gondor.apana.org.au" , "helgaas@kernel.org" , "alex.williamson@redhat.com" , "seanjc@google.com" , "zhi.a.wang@intel.com" , "dwmw2@infradead.org" , "dave.jiang@intel.com" , "linux-crypto@vger.kernel.org" , "thomas.lendacky@amd.com" , "keyrings@vger.kernel.org" , "aik@amd.com" , "david.e.box@intel.com" , "linuxarm@huawei.com" , "linux-pci@vger.kernel.org" , "dhowells@redhat.com" , "dan.j.williams@intel.com" Subject: Re: [PATCH 07/12] spdm: Introduce library to authenticate devices Message-ID: <20231012071629.GA6305@wunner.de> References: <89a83f42ae3c411f46efd968007e9b2afd839e74.1695921657.git.lukas@wunner.de> <20231003153937.000034ca@Huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Thu, 12 Oct 2023 00:16:46 -0700 (PDT) On Thu, Oct 12, 2023 at 03:26:44AM +0000, 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 wrote: > > > 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 According to PCIe r6.1 page 115 ("Reference Documents"): "CMA requires SPDM Version 1.0 or above. IDE requires SPDM Version 1.1 or above. TDISP requires version 1.2 or above." This could be interpreted as SPDM 1.0 support being mandatory to be spec-compliant. Even if we drop support for 1.0 from the initial bringup patches, someone could later come along and propose a patch to re-add it on the grounds of the above-quoted spec section. So I think we can't avoid it. Thanks, Lukas