From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B9AF3E95A61 for ; Sat, 7 Oct 2023 10:04:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234176AbjJGKEi (ORCPT ); Sat, 7 Oct 2023 06:04:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60872 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234148AbjJGKEh (ORCPT ); Sat, 7 Oct 2023 06:04:37 -0400 Received: from bmailout3.hostsharing.net (bmailout3.hostsharing.net [176.9.242.62]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 22002BF for ; Sat, 7 Oct 2023 03:04:36 -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 593B6100D587B; Sat, 7 Oct 2023 12:04:33 +0200 (CEST) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 22C151C0227; Sat, 7 Oct 2023 12:04:33 +0200 (CEST) Date: Sat, 7 Oct 2023 12:04:33 +0200 From: Lukas Wunner To: Dan Williams 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, Jonathan Cameron , linuxarm@huawei.com, David Box , Dave Jiang , "Li, Ming" , Zhi Wang , Alistair Francis , Wilfred Mallawa , Alexey Kardashevskiy , Tom Lendacky , Sean Christopherson , Alexander Graf Subject: Re: [PATCH 00/12] PCI device authentication Message-ID: <20231007100433.GA7596@wunner.de> References: <652030759e42d_ae7e72946@dwillia2-xfh.jf.intel.com.notmuch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <652030759e42d_ae7e72946@dwillia2-xfh.jf.intel.com.notmuch> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Fri, Oct 06, 2023 at 09:06:13AM -0700, Dan Williams wrote: > Lukas Wunner wrote: > > The root of trust is initially an in-kernel key ring of certificates. > > We can discuss linking the system key ring into it, thereby allowing > > EFI to pass trusted certificates to the kernel for CMA. Alternatively, > > a bundle of trusted certificates could be loaded from the initrd. > > I envision that we'll add TPMs or remote attestation services such as > > https://keylime.dev/ to create an ecosystem of various trust sources. > > Linux also has an interest in accommodating opt-in to using platform > managed keys, so the design requires that key management and session > ownership is a system owner policy choice. You're pointing out a gap in the specification: There's an existing mechanism to negotiate which PCI features are handled natively by the OS and which by platform firmware and that's the _OSC Control Field (PCI Firmware Spec r3.3 table 4-5 and 4-6). There are currently 10 features whose ownership is negotiated with _OSC, examples are Hotplug control and DPC configuration control. I propose adding an 11th bit to negotiate ownership of the CMA-SPDM session. Once that's added to the PCI Firmware Spec, amending the implementation to honor it is trivial: Just check for platform ownership at the top of pci_cma_init() and return. Thanks, Lukas