Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
Date:   Fri, 6 Oct 2023 09:06:13 -0700
From:   Dan Williams <dan.j.williams@intel.com>
To:     Lukas Wunner <lukas@wunner.de>, Bjorn Helgaas <helgaas@kernel.org>,
        "David Howells" <dhowells@redhat.com>,
        David Woodhouse <dwmw2@infradead.org>,
        "Herbert Xu" <herbert@gondor.apana.org.au>,
        "David S. Miller" <davem@davemloft.net>,
        Alex Williamson <alex.williamson@redhat.com>,
        <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>
CC:     Jonathan Cameron <Jonathan.Cameron@huawei.com>,
        <linuxarm@huawei.com>, David Box <david.e.box@intel.com>,
        Dan Williams <dan.j.williams@intel.com>,
        Dave Jiang <dave.jiang@intel.com>,
        "Li, Ming" <ming4.li@intel.com>, Zhi Wang <zhi.a.wang@intel.com>,
        Alistair Francis <alistair.francis@wdc.com>,
        "Wilfred Mallawa" <wilfred.mallawa@wdc.com>,
        Alexey Kardashevskiy <aik@amd.com>,
        "Tom Lendacky" <thomas.lendacky@amd.com>,
        Sean Christopherson <seanjc@google.com>,
        Alexander Graf <graf@amazon.com>
Subject: RE: [PATCH 00/12] PCI device authentication
Message-ID: <652030759e42d_ae7e72946@dwillia2-xfh.jf.intel.com.notmuch>
References: <cover.1695921656.git.lukas@wunner.de>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <cover.1695921656.git.lukas@wunner.de>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?uH4Yto7NDt9Qr9wFIHmUQJm4JNpXDgtRVOo9izLE0bGYHihXP+40ij1VQQ7v?=
 =?us-ascii?Q?AV9sJdqtmf4HQ3Mee0ZKS/e1aCFwVq0fdSksX/KJnflcxLRgjgyLfZ8KV6/p?=
 =?us-ascii?Q?/GVdEO0WgzToYlEQ/VjTMWZwXiDpQ036jtWw6EkXqLlxiIL3KbuBvPM8q5kg?=
 =?us-ascii?Q?Q51ir8zT2rmPjBvQTu3n77M0kDDPg5Nhn2lsIMbTzmpeDagSjah1nYcidh+r?=
 =?us-ascii?Q?L3/1X84eJS6S4RvG2gZ30xMoZdvn3oYRYLFY9X44GBixwcPpZZz5F6UlY9La?=
 =?us-ascii?Q?K1zMOYtubk68ikRu2damnS+hOw50D6fl9X4XxfvGgyrsGC7bBclnmsgj8pVx?=
 =?us-ascii?Q?11BjnK0mmfsNSXmUuvz14U1skBt+M2iiR71PvBrNc7/RSoAEa05es1zN1OfE?=
 =?us-ascii?Q?PcfS3Gkku/ziItP7QKMpQ1vHgvFml+rQKgctbCwA6G2SiKf7T/Ws4hwi4cns?=
 =?us-ascii?Q?D+AJjYfoeQUujO91/NW5lAIwgVoIYdfsmOJkvavqkQm+nXsCtTTdUwGRFyvg?=
 =?us-ascii?Q?0/dOSZAvP2epTdyBICQ95mIvHFzZbmDVx+GTBSkN7xT1yTzC+YGmW8u1nFY0?=
 =?us-ascii?Q?r+xDZJN786JfuER0gdDygt3xKECvmYSrHiZ32WA86TN8NYtc/r6cugBztjMn?=
 =?us-ascii?Q?bBXpiGgbBwtG4NP14E7PllCVBQhd49HnOjr1cjXPfruvFzbLJppWntjkGFgI?=
 =?us-ascii?Q?S8cSIPKgcqCDY5W79AONW+URLzmF5me+d9LyF2RcN0++z2AZnOZvkQcN5Zvf?=
 =?us-ascii?Q?mFMpO368qM55Q/qx/y3LmpiAF2HBKrN8EVHEsypMJcCy7gNsVqwhJnBKsBI6?=
 =?us-ascii?Q?5qMBkUZZIwcFm2+ZdcKzd3dhyaq+43hicFkmXmKBo09a6IJ4zFATKZMf0Q3A?=
 =?us-ascii?Q?Zmy913hDffb2pom4gDJNMQiH3T54mEGM9c0FroS7Jbep9f8JinccHEPlDWTN?=
 =?us-ascii?Q?KGimkJ/vK2+z9LjKJ4A20RNtZ8oB5hq9P853NeGlfG+wS2Ya1IRKnQXr2WXL?=
 =?us-ascii?Q?ydyH7WheqUTxqcTvT2UHOIXBxXG+/5clcX/MyPW8DKvcQ7N/xA1G9jnuwIUL?=
 =?us-ascii?Q?3OY6+gxp1nGOiubc1fhVvGiMj3cgTkzVMLYNFuMu1nHxH1Ps5s6YXt+0aAQ8?=
 =?us-ascii?Q?fUEuqm+o8Xv5yBYkkoHEcVjgdmYyYrEuEdmxwdsXU4K+CtmL4Bj5yXqb4gP4?=
 =?us-ascii?Q?Unx7Pcl7MCyKXchblPQU8l+lckjL/dHIXU3Hhn8c/in2lBvWdY7/9lkF436q?=
 =?us-ascii?Q?blCxiFbjY+ewzazRhZ5ibZS2MBKKPvBufSUANW9EqTfw9N536RWoF+D6RThx?=
 =?us-ascii?Q?MOeLlAYEiJblA54RsnfYMc2RlARl/rFtlTCtM0ySfs19DflOArfs+CZHXj40?=
 =?us-ascii?Q?dc2MgCkfX1g8AZxXBGqFsNVxczGac6XUQEzrtgYwoxMMMLTUkz/A4FPWiRg6?=
 =?us-ascii?Q?YE2jeU0dgX1pqrJEsyyAPOpDxn4PUXbbolmsUJIwq2jt/BbeZRa3eShE6B2P?=
 =?us-ascii?Q?CE4rENqvlckff9hP7v7jewn4/ykUbAbhXdWXQZiXmfgW/OhMQDCpgKDYl3M7?=
 =?us-ascii?Q?pJVZezH1FKFJRwSit1lBLzJV2MJDAL0Bh0fZmD6BOQ6CPYdK7IT0ELCI+tLU?=
 =?us-ascii?Q?9g=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: dbc741d7-84d4-497e-5c25-08dbc6862c19
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2023 16:06:17.7557
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Etm5y+aLlnAC/GrJQTGrP4xZ3+EzT6qkhuse7Rq4Zo4UcIJTYcxgUoQ/81CwrY6RUHUu2CN4sXMhXrYRgIkXzDGu2pGNzkatmvmJIsuO4sE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB7541
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=2.7 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS autolearn=no
	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: <linux-crypto.vger.kernel.org>
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 09:08:10 -0700 (PDT)
X-Spam-Level: **

This looks great Lukas, some forward looking review comments below.

Lukas Wunner wrote:
> Authenticate PCI devices with CMA-SPDM (PCIe r6.1 sec 6.31) and
> expose the result in sysfs.  This enables user-defined policies
> such as forbidding driver binding to devices which failed
> authentication.
> 
> CMA-SPDM forms the basis for PCI encryption (PCIe r6.1 sec 6.33),
> which will be submitted later.
> 
> The meat of the series is in patches [07/12] and [08/12], which contain
> the SPDM library and the CMA glue code (the PCI-adaption of SPDM).
> 
> The reason why SPDM is done in-kernel is provided in patch [10/12]:
> Briefly, when devices are reauthenticated on resume from system sleep,
> user space is not yet available.  Same when reauthenticating after
> recovery from reset.
> 
> One use case for CMA-SPDM and PCI encryption is confidential access
> to passed-through devices:  Neither the host nor other guests are
> able to eavesdrop on device accesses, in particular if guest memory
> is encrypted as well.

Note, only for traffic over the SPDM session. In order for private MMIO and
T=1 traffic to private memory, coordination with the platform TSM is
mandated by all the known TSM (CPU/Platform security modules). This has
implications for policy decisions later in this series.

> Further use cases for the SPDM library are appearing on the horizon:
> Alistair Francis and Wilfred Mallawa from WDC are interested in using
> it for SCSI/SATA.  David Box from Intel has implemented measurement
> retrieval over SPDM.
> 
> 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.

> If you wish to play with PCI device authentication but lack capable
> hardware, Wilfred has written a guide how to test with qemu:
> https://github.com/twilfredo/spdm-emulation-guide-b
>