Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/1.2/patches/2234745/?format=api
{ "id": 2234745, "url": "http://patchwork.ozlabs.org/api/1.2/patches/2234745/?format=api", "web_url": "http://patchwork.ozlabs.org/project/linux-pci/patch/20260508031710.514574-11-alistair.francis@wdc.com/", "project": { "id": 28, "url": "http://patchwork.ozlabs.org/api/1.2/projects/28/?format=api", "name": "Linux PCI development", "link_name": "linux-pci", "list_id": "linux-pci.vger.kernel.org", "list_email": "linux-pci@vger.kernel.org", "web_url": null, "scm_url": null, "webscm_url": null, "list_archive_url": "", "list_archive_url_format": "", "commit_url_format": "" }, "msgid": "<20260508031710.514574-11-alistair.francis@wdc.com>", "list_archive_url": null, "date": "2026-05-08T03:17:02", "name": "[10/18] PCI/CMA: Validate Subject Alternative Name in certificates", "commit_ref": null, "pull_url": null, "state": "new", "archived": false, "hash": "7b53c7cd337c1815be9d7db303706000f5c0c1b8", "submitter": { "id": 64571, "url": "http://patchwork.ozlabs.org/api/1.2/people/64571/?format=api", "name": "Alistair Francis", "email": "alistair23@gmail.com" }, "delegate": null, "mbox": "http://patchwork.ozlabs.org/project/linux-pci/patch/20260508031710.514574-11-alistair.francis@wdc.com/mbox/", "series": [ { "id": 503312, "url": "http://patchwork.ozlabs.org/api/1.2/series/503312/?format=api", "web_url": "http://patchwork.ozlabs.org/project/linux-pci/list/?series=503312", "date": "2026-05-08T03:16:52", "name": "lib: Rust implementation of SPDM", "version": 1, "mbox": "http://patchwork.ozlabs.org/series/503312/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/patches/2234745/comments/", "check": "pending", "checks": "http://patchwork.ozlabs.org/api/patches/2234745/checks/", "tags": {}, "related": [], "headers": { "Return-Path": "\n <linux-pci+bounces-54165-incoming=patchwork.ozlabs.org@vger.kernel.org>", "X-Original-To": [ "incoming@patchwork.ozlabs.org", "linux-pci@vger.kernel.org" ], "Delivered-To": "patchwork-incoming@legolas.ozlabs.org", "Authentication-Results": [ "legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=OWFzOtHH;\n\tdkim-atps=neutral", "legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c04:e001:36c::12fc:5321; helo=tor.lore.kernel.org;\n envelope-from=linux-pci+bounces-54165-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)", "smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com\n header.b=\"OWFzOtHH\"", "smtp.subspace.kernel.org;\n arc=none smtp.client-ip=209.85.216.52", "smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com", "smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=gmail.com" ], "Received": [ "from tor.lore.kernel.org (tor.lore.kernel.org\n [IPv6:2600:3c04:e001:36c::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4gBZCt6496z1yK7\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 08 May 2026 13:21:46 +1000 (AEST)", "from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id 6E5C43067B20\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 8 May 2026 03:19:08 +0000 (UTC)", "from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 144102FD696;\n\tFri, 8 May 2026 03:18:47 +0000 (UTC)", "from mail-pj1-f52.google.com (mail-pj1-f52.google.com\n [209.85.216.52])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id C28083081BE\n\tfor <linux-pci@vger.kernel.org>; Fri, 8 May 2026 03:18:41 +0000 (UTC)", "by mail-pj1-f52.google.com with SMTP id\n 98e67ed59e1d1-3664df32e91so104670a91.3\n for <linux-pci@vger.kernel.org>; Thu, 07 May 2026 20:18:41 -0700 (PDT)", "from toolbx.alistair23.me ([2403:581e:fdf9:0:6209:4521:6813:45b7])\n by smtp.gmail.com with ESMTPSA id\n d9443c01a7336-2baf1eafa62sm3220685ad.74.2026.05.07.20.18.32\n (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n Thu, 07 May 2026 20:18:39 -0700 (PDT)" ], "ARC-Seal": "i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1778210326; cv=none;\n b=W8wQfzYR8VXgsWfJyyR6K6C7fgXQfPO39zVeh6wY1AvaXLzl161hCPRFRhUaIP4Mf0elLX3CyE17BxnbjlJrVN2XIwscwZYafn4oSjUMzxrIr9spj3sdRAWRUgO8B2Tk1V0pr/xJg5BIlqyYtJpRnnMekLPldTyZbIei0ab/SF0=", "ARC-Message-Signature": "i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1778210326; c=relaxed/simple;\n\tbh=dxOLfnidXHIPF44qYjA6iMj3D0ywoc3U+N9lkLLSMyY=;\n\th=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:\n\t MIME-Version;\n b=VMQ1cmJ8erNqf+wCg8RJD6kOxhNer/qMOUl9FG8LTMTetyBd16MDrLcmjHbT9D3XPoYDtNYCK03EGPzD96C3C3xH/nLFjxADXuJMvkz7gaTve2+WpemIWLFaSkfCCskTdzER6nDeyAYUjhk3V1TlHwp6sgiPlgr3rYR1QgQw9dw=", "ARC-Authentication-Results": "i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com;\n spf=pass smtp.mailfrom=gmail.com;\n dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com\n header.b=OWFzOtHH; arc=none smtp.client-ip=209.85.216.52", "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1778210320; x=1778815120;\n darn=vger.kernel.org;\n h=content-transfer-encoding:mime-version:references:in-reply-to\n :message-id:date:subject:cc:to:from:from:to:cc:subject:date\n :message-id:reply-to;\n bh=5fOXX2qAUnj9LLpneLJIQV+9d5i1z0dWTv1dvOWS9wE=;\n b=OWFzOtHHsq+B8bgFW1EtQfnerOpTFEtZfUIFFgyusJa3w66MF3RuxQQQyHK23Y2Oui\n Oz83v07gyHSnjG5w3dNUSKoRdPLol9FiXwLTmRvmrLmlFYF93lUDDhtKkNxsN6ywG371\n WyVVHrIST0STErN4Lrmgtz/fg7JnCJ8C82XncgwEkMeYkjqe7Hw2v9irqFpJKttG1lNl\n i3BJyd4WUZn3FqDcwfMbMDzsCPDWXlAYu2h55A+Lw0xsSkRul5XNki4UNzR0O/a1gTOV\n hvIUialmYlrDUS3eRAO8YKsET0CA+fjSlEdi0Rn/zbHvxFLZ+z9s/lI8ytDxyHc4sND9\n dJmw==", "X-Google-DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1778210320; x=1778815120;\n h=content-transfer-encoding:mime-version:references:in-reply-to\n :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=5fOXX2qAUnj9LLpneLJIQV+9d5i1z0dWTv1dvOWS9wE=;\n b=AsPm552aQAQjCZaBU6k2QwGy7b4ZhcHiMpB9cyjOpyYDcuRa6+4Wvfg2E7vOHlA8z1\n chYUqRuXg1m0e/85ze+y805Q/JFm/E6qyE60JyELZY5OYdPYZl5AcdUcR04MZro8cGPN\n rkNf+J1h704iPtLARFaBGIAorZDnLYuJjHWUMCzm7ZOiRWiPFJ/cLp/qIgNHZoIi1BOA\n E+fMTXnLqYRp7wMUMoJyfthKokqAEUhQFHC+TsbHfxoqByudQp4yE2PwHyOwCMb17B3Q\n LEMCtuhUcfZd+D+a1yb1OakgOajjTDxZKcdRxKG9sDv2fjWdCCs4L/Vnp0l2mQVw073j\n gg7A==", "X-Forwarded-Encrypted": "i=1;\n AFNElJ/ZrX/QJoOuyVycHDnny3mxmnFr3OvalDD56S4adHxtYvbMRsu/McbKL0fDXhujgIVGZ7NfR8VHqxc=@vger.kernel.org", "X-Gm-Message-State": "AOJu0YxtyqEHEA1BwYlI8o8W+1Q/G+0D3HCCDnAicHXKtKdL4AEJ6oJn\n\telqmxokIB9CptDCpT4KBTuzE4H/LG2T/u9TaADkp729wAFjQ1kShHlMm", "X-Gm-Gg": "Acq92OFM5CiixdQ4jpABzJe+MkwDdj5nYDaD12SxSOm+xkHjT+OiDYOniKOWtLgQ3aH\n\tZQKUVwdAPvA49sBjViH27RRkTzcN4LLpizXaRhD4JYJ7sZqRwB50vSNDPQNpV1A/3KX4LUpWxPY\n\tfgIvdMffq5He+XXhtQtate9GV9jCsbTZYpY2bngPUJ7D7OgRbPtimclWfyv6lNtE+DV3RJ+hTCY\n\t3cXGy1aqUcwC4Q7V0LOGoDLpq7re81zYmzJELXTWT4XVmnkAg8LAhxbkTC1N2BJdbM16/eLoH1A\n\t8S/ZDYa+QVA/1YPKmhKiDZCHNdALPzbTdEgw6jZ4qPJJ3lAeU+lX+p7w7mxgQgu4VNK2AS1Qs4t\n\tS8CM8ZN6DHANozoLKZ8ga9374Vzrxiy2F9oPLxYuOwYOrNHInY2e6oytD7KUM8qHzcbBSX8Yrrk\n\tyniUhoDuvzwuG0a18jTOyGsN/wOugsoupiEJyYjcaQ", "X-Received": "by 2002:a17:90b:2d0d:b0:35f:bd29:75b9 with SMTP id\n 98e67ed59e1d1-365ac670f60mr11374479a91.22.1778210319770;\n Thu, 07 May 2026 20:18:39 -0700 (PDT)", "From": "alistair23@gmail.com", "X-Google-Original-From": "alistair.francis@wdc.com", "To": "alistair@alistair23.me,\n\tlinux-kernel@vger.kernel.org,\n\tlukas@wunner.de,\n\tJonathan.Cameron@huawei.com,\n\tbhelgaas@google.com,\n\trust-for-linux@vger.kernel.org,\n\takpm@linux-foundation.org,\n\tlinux-cxl@vger.kernel.org,\n\tdjbw@kernel.org,\n\tlinux-pci@vger.kernel.org", "Cc": "alex.gaynor@gmail.com,\n\twilfred.mallawa@wdc.com,\n\tgary@garyguo.net,\n\tbjorn3_gh@protonmail.com,\n\tbenno.lossin@proton.me,\n\taliceryhl@google.com,\n\tboqun.feng@gmail.com,\n\ta.hindborg@kernel.org,\n\ttmgross@umich.edu,\n\tojeda@kernel.org,\n\talistair23@gmail.com", "Subject": "[PATCH 10/18] PCI/CMA: Validate Subject Alternative Name in\n certificates", "Date": "Fri, 8 May 2026 13:17:02 +1000", "Message-ID": "<20260508031710.514574-11-alistair.francis@wdc.com>", "X-Mailer": "git-send-email 2.52.0", "In-Reply-To": "<20260508031710.514574-1-alistair.francis@wdc.com>", "References": "<20260508031710.514574-1-alistair.francis@wdc.com>", "Precedence": "bulk", "X-Mailing-List": "linux-pci@vger.kernel.org", "List-Id": "<linux-pci.vger.kernel.org>", "List-Subscribe": "<mailto:linux-pci+subscribe@vger.kernel.org>", "List-Unsubscribe": "<mailto:linux-pci+unsubscribe@vger.kernel.org>", "MIME-Version": "1.0", "Content-Transfer-Encoding": "8bit" }, "content": "From: Lukas Wunner <lukas@wunner.de>\n\nPCIe r6.1 sec 6.31.3 stipulates requirements for Leaf Certificates\npresented by devices, in particular the presence of a Subject Alternative\nName which encodes the Vendor ID, Device ID, Device Serial Number, etc.\n\nThis prevents a mismatch between the device identity in Config Space and\nthe certificate. A device cannot misappropriate a certificate from a\ndifferent device without also spoofing Config Space. As a corollary,\nit cannot dupe an arbitrary driver into binding to it. Only drivers\nwhich bind to the device identity in the Subject Alternative Name work\n(PCIe r6.1 sec 6.31 \"Implementation Note: Overview of Threat Model\").\n\nThe Subject Alternative Name is signed, hence constitutes a signed copy\nof a Config Space portion. It's the same concept as web certificates\nwhich contain a set of domain names in the Subject Alternative Name for\nidentity verification.\n\nParse the Subject Alternative Name using a small ASN.1 module and\nvalidate its contents. The theory of operation is explained in a\ncomment at the top of the newly inserted code.\n\nThis functionality is introduced in a separate commit on top of basic\nCMA-SPDM support to split the code into digestible, reviewable chunks.\n\nThe CMA OID added here is taken from the official OID Repository\n(it's not documented in the PCIe Base Spec):\nhttps://oid-rep.orange-labs.fr/get/2.23.147\n\nSide notes:\n\n* PCIe r6.2 removes the spec language on the Subject Alternative Name.\n It still \"requires the leaf certificate to include the information\n typically used by system software for device driver binding\", but no\n longer specifies how that information is encoded into the certificate.\n\n According to the editor of the PCIe Base Spec and the author of the\n CMA 1.1 ECN (which caused this change), FPGA cards which mutate their\n device identity at runtime (due to a firmware update) were thought as\n unable to satisfy the previous spec language. The Protocol Working\n Group could not agree on a better solution and therefore dropped the\n spec language entirely. They acknowledge that the requirement is now\n under-spec'd. Because products already exist which adhere to the\n Subject Alternative Name requirement per PCIe r6.1 sec 6.31.3, they\n recommended to \"push through\" and use it as the de facto standard.\n\n The FPGA concerns are easily overcome by reauthenticating the device\n after a firmware update, either via sysfs or pci_cma_reauthenticate()\n (added by a subsequent commit).\n\n* PCIe r6.1 sec 6.31.3 strongly recommends to verify that \"the\n information provided in the Subject Alternative Name entry is signed\n by the vendor indicated by the Vendor ID.\" In other words, the root\n certificate on pci_cma_keyring which signs the device's certificate\n chain must have been created for a particular Vendor ID.\n\n Unfortunately the spec neglects to define how the Vendor ID shall be\n encoded into the root certificate. So the recommendation cannot be\n implemented at this point and it is thus possible that a vendor signs\n device certificates of a different vendor.\n\n* Instead of a Subject Alternative Name, Leaf Certificates may include\n \"a Reference Integrity Manifest, e.g., see Trusted Computing Group\" or\n \"a pointer to a location where such a Reference Integrity Manifest can\n be obtained\" (PCIe r6.1 sec 6.31.3).\n\n A Reference Integrity Manifest contains \"golden\" measurements which\n can be compared to actual measurements retrieved from a device.\n It serves a different purpose than the Subject Alternative Name,\n hence it is unclear why the spec says only either of them is necessary.\n It is also unclear how a Reference Integrity Manifest shall be encoded\n into a certificate.\n\n Hence ignore the Reference Integrity Manifest requirement.\n\nSigned-off-by: Lukas Wunner <lukas@wunner.de>\nReviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # except ASN.1\n---\n drivers/pci/Makefile | 4 +-\n drivers/pci/cma.asn1 | 41 ++++++++++++\n drivers/pci/cma.c | 123 ++++++++++++++++++++++++++++++++++-\n include/linux/oid_registry.h | 3 +\n 4 files changed, 169 insertions(+), 2 deletions(-)\n create mode 100644 drivers/pci/cma.asn1", "diff": "diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile\nindex 16abfd0e17e1..15512512fce7 100644\n--- a/drivers/pci/Makefile\n+++ b/drivers/pci/Makefile\n@@ -41,7 +41,9 @@ obj-$(CONFIG_PCI_NPEM)\t\t+= npem.o\n obj-$(CONFIG_PCIE_TPH)\t\t+= tph.o\n obj-$(CONFIG_CARDBUS)\t\t+= setup-cardbus.o\n \n-obj-$(CONFIG_PCI_CMA)\t\t+= cma.o\n+obj-$(CONFIG_PCI_CMA)\t\t+= cma.o cma.asn1.o\n+$(obj)/cma.o:\t\t\t$(obj)/cma.asn1.h\n+$(obj)/cma.asn1.o:\t\t$(obj)/cma.asn1.c $(obj)/cma.asn1.h\n \n # Endpoint library must be initialized before its users\n obj-$(CONFIG_PCI_ENDPOINT)\t+= endpoint/\ndiff --git a/drivers/pci/cma.asn1 b/drivers/pci/cma.asn1\nnew file mode 100644\nindex 000000000000..da41421d4085\n--- /dev/null\n+++ b/drivers/pci/cma.asn1\n@@ -0,0 +1,41 @@\n+-- SPDX-License-Identifier: BSD-3-Clause\n+--\n+-- Component Measurement and Authentication (CMA-SPDM, PCIe r6.1 sec 6.31.3)\n+-- X.509 Subject Alternative Name (RFC 5280 sec 4.2.1.6)\n+--\n+-- Copyright (C) 2008 IETF Trust and the persons identified as authors\n+-- of the code\n+--\n+-- https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.6\n+--\n+-- The ASN.1 module in RFC 5280 appendix A.1 uses EXPLICIT TAGS whereas the one\n+-- in appendix A.2 uses IMPLICIT TAGS. The kernel's simplified asn1_compiler.c\n+-- always uses EXPLICIT TAGS, hence this ASN.1 module differs from RFC 5280 in\n+-- that it adds IMPLICIT to definitions from appendix A.2 (such as GeneralName)\n+-- and omits EXPLICIT in those definitions.\n+\n+SubjectAltName ::= GeneralNames\n+\n+GeneralNames ::= SEQUENCE OF GeneralName\n+\n+GeneralName ::= CHOICE {\n+\totherName\t\t\t[0] IMPLICIT OtherName,\n+\trfc822Name\t\t\t[1] IMPLICIT IA5String,\n+\tdNSName\t\t\t\t[2] IMPLICIT IA5String,\n+\tx400Address\t\t\t[3] ANY,\n+\tdirectoryName\t\t\t[4] ANY,\n+\tediPartyName\t\t\t[5] IMPLICIT EDIPartyName,\n+\tuniformResourceIdentifier\t[6] IMPLICIT IA5String,\n+\tiPAddress\t\t\t[7] IMPLICIT OCTET STRING,\n+\tregisteredID\t\t\t[8] IMPLICIT OBJECT IDENTIFIER\n+\t}\n+\n+OtherName ::= SEQUENCE {\n+\ttype-id\t\t\tOBJECT IDENTIFIER ({ pci_cma_note_oid }),\n+\tvalue\t\t\t[0] ANY ({ pci_cma_note_san })\n+\t}\n+\n+EDIPartyName ::= SEQUENCE {\n+\tnameAssigner\t\t[0] ANY OPTIONAL,\n+\tpartyName\t\t[1] ANY\n+\t}\ndiff --git a/drivers/pci/cma.c b/drivers/pci/cma.c\nindex 998fde6366fb..ee186f361940 100644\n--- a/drivers/pci/cma.c\n+++ b/drivers/pci/cma.c\n@@ -11,6 +11,9 @@\n \n #define dev_fmt(fmt) \"CMA: \" fmt\n \n+#include <keys/x509-parser.h>\n+#include <linux/asn1_decoder.h>\n+#include <linux/oid_registry.h>\n #include <linux/pci.h>\n #include <linux/pci-doe.h>\n #include <linux/pci-tsm.h>\n@@ -18,8 +21,126 @@\n #include <linux/spdm.h>\n #include <linux/tsm.h>\n \n+#include \"cma.asn1.h\"\n #include \"pci.h\"\n \n+/*\n+ * The spdm_requester.c library calls pci_cma_validate() to check requirements\n+ * for Leaf Certificates per PCIe r6.1 sec 6.31.3.\n+ *\n+ * pci_cma_validate() parses the Subject Alternative Name using the ASN.1\n+ * module cma.asn1, which calls pci_cma_note_oid() and pci_cma_note_san()\n+ * to compare an OtherName against the expected name.\n+ *\n+ * The expected name is constructed beforehand by pci_cma_construct_san().\n+ *\n+ * PCIe r6.2 drops the Subject Alternative Name spec language, even though\n+ * it continues to require \"the leaf certificate to include the information\n+ * typically used by system software for device driver binding\". Use the\n+ * Subject Alternative Name per PCIe r6.1 for lack of a replacement and\n+ * because it is the de facto standard among existing products.\n+ */\n+#define CMA_NAME_MAX sizeof(\"Vendor=1234:Device=1234:CC=123456:\"\t \\\n+\t\t\t \"REV=12:SSVID=1234:SSID=1234:1234567890123456\")\n+\n+struct pci_cma_x509_context {\n+\tstruct pci_dev *pdev;\n+\tu8 slot;\n+\tenum OID last_oid;\n+\tchar expected_name[CMA_NAME_MAX];\n+\tunsigned int expected_len;\n+\tunsigned int found:1;\n+};\n+\n+int pci_cma_note_oid(void *context, size_t hdrlen, unsigned char tag,\n+\t\t const void *value, size_t vlen)\n+{\n+\tstruct pci_cma_x509_context *ctx = context;\n+\n+\tctx->last_oid = look_up_OID(value, vlen);\n+\n+\treturn 0;\n+}\n+\n+int pci_cma_note_san(void *context, size_t hdrlen, unsigned char tag,\n+\t\t const void *value, size_t vlen)\n+{\n+\tstruct pci_cma_x509_context *ctx = context;\n+\n+\t/* These aren't the drOIDs we're looking for. */\n+\tif (ctx->last_oid != OID_CMA)\n+\t\treturn 0;\n+\n+\tif (tag != ASN1_UTF8STR ||\n+\t vlen != ctx->expected_len ||\n+\t memcmp(value, ctx->expected_name, vlen) != 0) {\n+\t\tpci_err(ctx->pdev, \"Leaf certificate of slot %u \"\n+\t\t\t\"has invalid Subject Alternative Name\\n\", ctx->slot);\n+\t\treturn -EINVAL;\n+\t}\n+\n+\tctx->found = true;\n+\n+\treturn 0;\n+}\n+\n+static unsigned int pci_cma_construct_san(struct pci_dev *pdev, char *name)\n+{\n+\tunsigned int len;\n+\tu64 serial;\n+\n+\tlen = snprintf(name, CMA_NAME_MAX,\n+\t\t \"Vendor=%04hx:Device=%04hx:CC=%06x:REV=%02hhx\",\n+\t\t pdev->vendor, pdev->device, pdev->class, pdev->revision);\n+\n+\tif (pdev->hdr_type == PCI_HEADER_TYPE_NORMAL)\n+\t\tlen += snprintf(name + len, CMA_NAME_MAX - len,\n+\t\t\t\t\":SSVID=%04hx:SSID=%04hx\",\n+\t\t\t\tpdev->subsystem_vendor, pdev->subsystem_device);\n+\n+\tserial = pci_get_dsn(pdev);\n+\tif (serial)\n+\t\tlen += snprintf(name + len, CMA_NAME_MAX - len,\n+\t\t\t\t\":%016llx\", serial);\n+\n+\treturn len;\n+}\n+\n+static int pci_cma_validate(struct device *dev, u8 slot,\n+\t\t\t struct x509_certificate *leaf_cert)\n+{\n+\tstruct pci_dev *pdev = to_pci_dev(dev);\n+\tstruct pci_cma_x509_context ctx;\n+\tint ret;\n+\n+\tif (!leaf_cert->raw_san) {\n+\t\tpci_err(pdev, \"Leaf certificate of slot %u \"\n+\t\t\t\"has no Subject Alternative Name\\n\", slot);\n+\t\treturn -EINVAL;\n+\t}\n+\n+\tctx.pdev = pdev;\n+\tctx.slot = slot;\n+\tctx.found = false;\n+\tctx.expected_len = pci_cma_construct_san(pdev, ctx.expected_name);\n+\n+\tret = asn1_ber_decoder(&cma_decoder, &ctx, leaf_cert->raw_san,\n+\t\t\t leaf_cert->raw_san_size);\n+\tif (ret == -EBADMSG || ret == -EMSGSIZE)\n+\t\tpci_err(pdev, \"Leaf certificate of slot %u \"\n+\t\t\t\"has malformed Subject Alternative Name\\n\", slot);\n+\tif (ret < 0)\n+\t\treturn ret;\n+\n+\tif (!ctx.found) {\n+\t\tpci_err(pdev, \"Leaf certificate of slot %u \"\n+\t\t\t\"has no OtherName with CMA OID\\n\", slot);\n+\t\treturn -EINVAL;\n+\t}\n+\n+\treturn 0;\n+}\n+\n static ssize_t pci_doe_transport(void *priv, struct device *dev,\n \t\t\t\t const void *request, size_t request_sz,\n \t\t\t\t void *response, size_t response_sz)\n@@ -80,7 +201,7 @@ static struct pci_tsm *pci_cma_tsm_probe(struct tsm_dev *tsm_dev,\n \tcma->pf0.base_tsm.tsm_dev = tsm_dev;\n \n \tcma->spdm = spdm_create(&pdev->dev, pci_doe_transport, doe,\n-\t\t\t\tPCI_DOE_MAX_PAYLOAD, NULL);\n+\t\t\t\tPCI_DOE_MAX_PAYLOAD, pci_cma_validate);\n \tif (!cma->spdm) {\n \t\tmutex_destroy(&cma->pf0.lock);\n \t\tkfree(cma);\ndiff --git a/include/linux/oid_registry.h b/include/linux/oid_registry.h\nindex ebce402854de..113f4e802ec4 100644\n--- a/include/linux/oid_registry.h\n+++ b/include/linux/oid_registry.h\n@@ -150,6 +150,9 @@ enum OID {\n \tOID_id_ml_dsa_65,\t\t\t/* 2.16.840.1.101.3.4.3.18 */\n \tOID_id_ml_dsa_87,\t\t\t/* 2.16.840.1.101.3.4.3.19 */\n \n+\t/* PCI */\n+\tOID_CMA,\t\t\t/* 2.23.147 */\n+\n \tOID__NR\n };\n \n", "prefixes": [ "10/18" ] }