Received: by 2002:a05:7412:da14:b0:e2:908c:2ebd with SMTP id fe20csp256557rdb; Fri, 6 Oct 2023 02:31:30 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFPzSmkH3HeR0B3vdD5uJ0umOQXmUYHotW8A6MJH3vLZbMus79DzQKc78iOL1EnJE6i7XVg X-Received: by 2002:a05:6a20:f388:b0:16b:7519:55b9 with SMTP id qr8-20020a056a20f38800b0016b751955b9mr1516022pzb.34.1696584690020; Fri, 06 Oct 2023 02:31:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696584690; cv=none; d=google.com; s=arc-20160816; b=RflN8WCbvf1Br82N7cYTv2On790WToPJaKsOSiJy/OBhnrBB/m/X6rNYQgo5m3gjrb /mFaXVr5LMKPM5Gehl/96C8LUkDMhPFbMssY9Ny6imAmcm8G6sYQz5bCv91HMc2u9I2Y tzLqls3rQQ2P+yLcz1lMKMlt0hI8Rp8RzkaEWPoCmhhejO5E543S3ISpbJvTPUIsfgon 2urwIegivzCOSjTF9XrsgM0ACcDa89W5O0K7ljCXTG7eeVSX8lhXZZT+Tlvj6k+Lt9e7 rivp7TISzTWZ2Rpeiq//sDvP7h3RoxiQ+0/2qy4aPrkqRr3+06AuSFpu5mRuM7Satf/q tmsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=MGRD8QpA54WD1etjf1CEKTYh8p7x18ItjsxtBS47V7c=; fh=VytaWnrtIe6rQzSTidyaXKVP21CYVB05Erb1vcNmZ/4=; b=Ku8T55yogDOatvfGBGHTRlukMzTvToq3lD9KCk6ufE99ll1RzcRHgBgNOPYr13kM2G wvs4ks83YkhsaMn2+Cw9/pUc8E2ZgH06HAYpudOlGDhWk7tBTLM+eUGNa9Cc6zH5V9qc X+25R6YytCRaDlsUdIgRo81xaJyD1qN5QfCGl4a05Gs2Wb2zLQWVAZqO+98DF+5v8VsC mFnTiURY1uk3SuJYnGxnOhH48s2McwojJQSG7lTKky+fV9t0PR09obhgk0S6GYCUmiiz udjzfngjb5Up2XrTmNkpez52hWQlkpPzFJbNKHQ/If2ajU9ZiIfnZcVbR2nAVmEyRle4 udHQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id q2-20020a170902788200b001c604fdbb14si3169948pll.81.2023.10.06.02.31.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Oct 2023 02:31:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 290F88089857; Fri, 6 Oct 2023 02:30:32 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231443AbjJFJa3 (ORCPT + 99 others); Fri, 6 Oct 2023 05:30:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54214 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231373AbjJFJa1 (ORCPT ); Fri, 6 Oct 2023 05:30:27 -0400 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 614CDC6; Fri, 6 Oct 2023 02:30:25 -0700 (PDT) Received: from lhrpeml500005.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4S23462Dsgz6HJbf; Fri, 6 Oct 2023 17:27:34 +0800 (CST) Received: from localhost (10.202.227.76) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Fri, 6 Oct 2023 10:30:22 +0100 Date: Fri, 6 Oct 2023 10:30:20 +0100 From: Jonathan Cameron To: Lukas Wunner CC: Bjorn Helgaas , David Howells , David Woodhouse , Herbert Xu , "David S. Miller" , Alex Williamson , , , , , , , , 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: <20231006103020.0000174f@Huawei.com> In-Reply-To: <20231003193058.GA16417@wunner.de> References: <467bff0c4bab93067b1e353e5b8a92f1de353a3f.1695921657.git.lukas@wunner.de> <20231003164048.0000148c@Huawei.com> <20231003193058.GA16417@wunner.de> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.202.227.76] X-ClientProxiedBy: lhrpeml500001.china.huawei.com (7.191.163.213) To lhrpeml500005.china.huawei.com (7.191.163.240) X-CFilter-Loop: Reflected 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 agentk.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 (agentk.vger.email [0.0.0.0]); Fri, 06 Oct 2023 02:30:32 -0700 (PDT) On Tue, 3 Oct 2023 21:30:58 +0200 Lukas Wunner wrote: > 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. It's a little messy and a bit of American vs British English I think. If it said "The instance of DOE used for a specific CMA-SPDM must support..." then it would clearly allow multiple instances. However, conversely, I don't read that sentence as blocking multiple instances (even though I suspect you are right and the author was thinking of there being one). > > 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? Not clear enough to me as it stands. That "as long" definitely feels like there is more to follow it as Ilpo noted. Maybe reword as something like Prevent this by letting the guest claim exclusive ownership of the device during passthrough ensuring problematic CMA reauthentication by the host is blocked. Also combine this with previous paragraph to make the 'this' more obvious refer to the problem described in that paragraph. Jonathan > > Thanks, > > Lukas >