Received: by 2002:a05:7412:3784:b0:e2:908c:2ebd with SMTP id jk4csp2178243rdb; Tue, 3 Oct 2023 12:41:24 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHtwto9b4efF99ilpQNZsovXFCw256/BfbRQmpxv1ut5F7Xi6AEoRR1ZmtzKysY/Iggn/Lo X-Received: by 2002:a05:6a20:3d1b:b0:152:4615:cb9e with SMTP id y27-20020a056a203d1b00b001524615cb9emr307864pzi.13.1696362083866; Tue, 03 Oct 2023 12:41:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696362083; cv=none; d=google.com; s=arc-20160816; b=hv/W7B7/S2F/jcdaqW8LL2ceQHIw2rRPxbXYTjPW5xlCMMR3GgkCj781KXFa10tEAK VXORWKfmwWerqa4pBboLDFHrXr8eCpygRwKHcL44Ji+s1gFYLL96p96xWGVy1K22zEVh KQUeSHWmLRn4tUZZVRD3HueA72UAXitayiWzBSnDixj8dXK1sc3EOtqAJl9IIA22ta7n Z5fPMPqxKb3bgA8ywcR068oHzX2K3pJ3Ya4pv/c6Qd/WwipykD+GB0UWCAbUlWzTmR4p PG4Ci2Eo3zJ3zeNbiYnE0gVR+XlI0ueEqwDor2cBUEUycmmlKV+fyhWo4y+QNfj+n5dX OVtQ== 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=XfeWwXD3I2/wtv3nChO4MfZpcFQ2PKi6dTp2o+vlEhY=; fh=3E1ryY0Z73P1xmNxFM2as7GbRYY5Pw0oMgz0KIC0kQE=; b=ZiXLYwDFelwudT3222Cw+AlCGi9rXukPfkD3u0ArcL4cnh+1JXYPPmj6Uka2rdNsCw tisdNxDaHT0yMaKu1aaeT61DH60Ef/WKVLUZ/n3WUSYB20ueSyPsZ2OKMRIw6T0G2cMw D2+OVZ8VvxSLIlZGNMFtEmlXMoSfhNMlRxpjXEjctoPl4Zce9hw/xnsCizdXf8gIisZi HNVaWmBWwaowWhLeETqoaKG7rsoOWPiaLgFpcXfu25Tt6P/iCgm3uTR9nC25cudbuAo9 btFEzrsc/t5UuMrNTzt2qnrgKtNBtwEm10Oa9aWBvE1p93N4g5GXUfBRlr56FQe8ZWXv d/Vw== 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:3 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id fi11-20020a056a00398b00b00690bc21d900si2298362pfb.136.2023.10.03.12.41.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Oct 2023 12:41:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::3:3 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 lipwig.vger.email (Postfix) with ESMTP id D8E8981A5ADF; Tue, 3 Oct 2023 12:41:17 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240933AbjJCTlR (ORCPT + 99 others); Tue, 3 Oct 2023 15:41:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36422 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232069AbjJCTlR (ORCPT ); Tue, 3 Oct 2023 15:41:17 -0400 X-Greylist: delayed 613 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Tue, 03 Oct 2023 12:41:13 PDT Received: from bmailout3.hostsharing.net (bmailout3.hostsharing.net [IPv6:2a01:4f8:150:2161:1:b009:f23e:0]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DD25293; Tue, 3 Oct 2023 12:41:13 -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 bmailout3.hostsharing.net (Postfix) with ESMTPS id 820FB100D9414; Tue, 3 Oct 2023 21:30:58 +0200 (CEST) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 2DF8042A4F9; Tue, 3 Oct 2023 21:30:58 +0200 (CEST) Date: Tue, 3 Oct 2023 21:30:58 +0200 From: Lukas Wunner To: Jonathan Cameron Cc: Bjorn Helgaas , David Howells , David Woodhouse , Herbert Xu , "David S. Miller" , Alex Williamson , linux-pci@vger.kernel.org, linux-cxl@vger.kernel.org, linux-coco@lists.linux.dev, keyrings@vger.kernel.org, linux-crypto@vger.kernel.org, kvm@vger.kernel.org, linuxarm@huawei.com, David Box , Dan Williams , Dave Jiang , "Li, Ming" , Zhi Wang , Alistair Francis , Wilfred Mallawa , Alexey Kardashevskiy , Tom Lendacky , Sean Christopherson , Alexander Graf Subject: Re: [PATCH 12/12] PCI/CMA: Grant guests exclusive control of authentication Message-ID: <20231003193058.GA16417@wunner.de> References: <467bff0c4bab93067b1e353e5b8a92f1de353a3f.1695921657.git.lukas@wunner.de> <20231003164048.0000148c@Huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231003164048.0000148c@Huawei.com> 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 lipwig.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 (lipwig.vger.email [0.0.0.0]); Tue, 03 Oct 2023 12:41:18 -0700 (PDT) On Tue, Oct 03, 2023 at 04:40:48PM +0100, Jonathan Cameron wrote: > On Thu, 28 Sep 2023 19:32:42 +0200 Lukas Wunner wrote: > > At any given time, only a single entity in a physical system may have > > an SPDM connection to a device. That's because the GET_VERSION request > > (which begins an authentication sequence) resets "the connection and all > > context associated with that connection" (SPDM 1.3.0 margin no 158). > > > > Thus, when a device is passed through to a guest and the guest has > > authenticated it, a subsequent authentication by the host would reset > > the device's CMA-SPDM session behind the guest's back. > > > > Prevent by letting the guest claim exclusive CMA ownership of the device > > during passthrough. Refuse CMA reauthentication on the host as long. > > After passthrough has concluded, reauthenticate the device on the host. > > Is there anything stopping a PF presenting multiple CMA capable DOE > instances? I'd expect them to have their own contexts if they do.. The spec does not seem to *explicitly* forbid a PF having multiple CMA-capable DOE instances, but PCIe r6.1 sec 6.31.3 says: "The instance of DOE used for CMA-SPDM must support ..." Note the singular ("The instance"). It seems to suggest that the spec authors assumed there's only a single DOE instance for CMA-SPDM. Could you (as an English native speaker) comment on the clarity of the two sentences "Prevent ... as long." above, as Ilpo objected to them? The antecedent of "Prevent" is the undesirable behaviour in the preceding sentence (host resets guest's SPDM connection). The antecedent of "as long" is "during passthrough" in the preceding sentence. Is that clear and understandable for an English native speaker or should I rephrase? Thanks, Lukas