Message ID | 20240114223532.290550-1-sameo@rivosinc.com |
---|---|
Headers |
Return-Path: <linux-kernel+bounces-25548-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:693c:2614:b0:101:6a76:bbe3 with SMTP id mm20csp1394196dyc; Sun, 14 Jan 2024 14:37:46 -0800 (PST) X-Google-Smtp-Source: AGHT+IFsjj4mqNJj+eQthy1uZrnK55G8uGlm3owXkdbCSI4xKiRtO06no0/O2JteHmL/o78+IYDw X-Received: by 2002:a17:902:e747:b0:1d4:e234:2a20 with SMTP id p7-20020a170902e74700b001d4e2342a20mr6795529plf.67.1705271865949; Sun, 14 Jan 2024 14:37:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1705271865; cv=none; d=google.com; s=arc-20160816; b=AydV/ouOFfxwc+Xxv4c5g3QV+y/VbiyiGhLYFOA+yVdDMvKLB4j9dfzv8bqUGf0R1Q O1+WWhfQqt6iZAKAumQxw8tD6PrxumFzX9nmryEV6JZ+SuZkqUm0mocEWVk5gtC/Gz+h f2CcKOUk/GGTAlcRrBhKlcrPKZxgBGMoInoqAR00ZDeOPe/vow24uFbRiTdv70QDSDh7 xKCe2D+9mvGJUeq3DrHnESL5IdTuDnRCVC4GrY59YeJ+SXlMYMwvIblYdpt68nblr/rh ZWo1G/dDfht5YAU9mWtoavgrZdg/2bzbLu7X19r602nBeeJNsU24QP5vLk4B307NEayC av1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=6s2rXWc/tMH4uago23e498UJr39tRJPeqGDGZSoMKEY=; fh=il1A4p8Y2RU7C8awMmLfy7MVoYnl7dsy03dVseJVaq4=; b=eMPqhZFaJVd9F9kxICfCxNX+bPV/jF0+8IVN0GHrzwUUuYCW5MoLGN/yg4r2IjGQA6 zgqneuDOm7/us8iONyTWjqFz36wqA+IO38U5sNVNi/n0qt4J4iaagi62NTfGjxR2jYxu ndvPOKkZjVIIrKGoIhYE2qlfGT/wpcT9skOlRR5ogwNn3aWsNvije+DtmUMrwxj3FEEI U7ZiX+7i0DlEbN+M1NHq6n8t1usxUn6azH32RR6NKvqtUjHtvxG4qvVb/UylOAsF64Q/ n2vtivATdbQRl/5HC85uIIeEPL48uC+cIv3ItSQxGfQ888goxStYHANSjqxtnSIX8OwA lN/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=ZsXSJ60S; spf=pass (google.com: domain of linux-kernel+bounces-25548-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-25548-ouuuleilei=gmail.com@vger.kernel.org" Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id bi4-20020a170902bf0400b001cfdbd5fe0bsi7573843plb.551.2024.01.14.14.37.45 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Jan 2024 14:37:45 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-25548-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=pass header.i=@rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=ZsXSJ60S; spf=pass (google.com: domain of linux-kernel+bounces-25548-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-25548-ouuuleilei=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 883ABB20EF3 for <ouuuleilei@gmail.com>; Sun, 14 Jan 2024 22:37:38 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 231492C6AE; Sun, 14 Jan 2024 22:37:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b="ZsXSJ60S" Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2EEEC1F17B for <linux-kernel@vger.kernel.org>; Sun, 14 Jan 2024 22:37:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-3376ead25e1so6240570f8f.3 for <linux-kernel@vger.kernel.org>; Sun, 14 Jan 2024 14:37:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1705271824; x=1705876624; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=6s2rXWc/tMH4uago23e498UJr39tRJPeqGDGZSoMKEY=; b=ZsXSJ60ScqbTnUW7xSp7xhB+KU4YxDESsQ90vQNlOKNvuUy3BmymTqVnl/vJAibJII QmkKR/b53Fl+cYxwZpAsnPROqFUnw6KAKJR3bSKiIBX1k+JNyORRq2FqNe/9W8y1MX// wjc4sxn+HcMEiuApYx32TK0TlyD9NN+9cdiA1GnO3AL/iqY5e89wJno8o28CvEjElutJ qMPVGgpGjBXDLx85uDvZUpco1N0xqFAqyuikSZPFGMK1WkI3YhJyVm4nMor7JmEIkRAm xAZxC4yFtFsTJnEcTm6kSaUTD/7Nuwl+pEvUdadQxM5uh4MvoUMah/DP/LNAm+7vVxeR KQxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705271824; x=1705876624; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6s2rXWc/tMH4uago23e498UJr39tRJPeqGDGZSoMKEY=; b=xIzLDHC7cU+LuY4gKHBa5VHJKE9HzhhJmRjk3kuwblqd9I034vDRAEo1RX+Z9/i6GY bW3Q0KSOKOKDP7ABBM2o4/DJYDXfgqF58mPYIoxxSw1eMHMHUseYX/CG3G2NxKAwePwR oEipG4/QFQ/Qt8tzXYzhdCLbAA8QFdtQRUFjqDaf+vL3uKy9WqO/HzmuoTS8c5nVMdpV tWE8Xh/qXUVEX36aZnXcQ6SXxHEEzmF9kahf18Aajkg+V5fUIb9kKzVFzZQKNy+NYiqt nCE/exwXsA+NBuHeA9HUUHL7SGVOERKbsnUSoxZQDoDpvOjiLRQ18v9k7Aqrp07GWc9z TBKg== X-Gm-Message-State: AOJu0Yze6Z2iKjBuVgKxSgGvGNraAiyrIlSdQGX6UPiokfstFknOQ9o+ Op0PGxi72gT9BYdsR3LqaxRyhg0xDJf2yA== X-Received: by 2002:a05:6000:11cc:b0:337:6e32:1812 with SMTP id i12-20020a05600011cc00b003376e321812mr2196492wrx.35.1705271824318; Sun, 14 Jan 2024 14:37:04 -0800 (PST) Received: from vermeer.ba.rivosinc.com (lfbn-mon-1-1176-165.w90-113.abo.wanadoo.fr. [90.113.119.165]) by smtp.gmail.com with ESMTPSA id v10-20020a5d610a000000b0033719111458sm10158693wrt.36.2024.01.14.14.37.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Jan 2024 14:37:03 -0800 (PST) From: Samuel Ortiz <sameo@rivosinc.com> To: Dan Williams <dan.j.williams@intel.com> Cc: linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [RFC PATCH v1 0/4] tsm: Runtime measurement registers ABI Date: Sun, 14 Jan 2024 23:35:26 +0100 Message-ID: <20240114223532.290550-1-sameo@rivosinc.com> X-Mailer: git-send-email 2.42.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1788107152475304354 X-GMAIL-MSGID: 1788107152475304354 |
Series | tsm: Runtime measurement registers ABI | |
Message
Samuel Ortiz
Jan. 14, 2024, 10:35 p.m. UTC
Some confidential computing architectures (Intel TDX, ARM CCA, RISC-V CoVE) provide their guests with a set of measurements registers that can be extended at runtime, i.e. after the initial, host-initiated measurements of the TVM are finalized. Those runtime measurement registers (RTMR) are isolated from the host accessible ones but TSMs include them in their signed attestation reports. All architectures supporting RTMRs expose a similar interface to their TVMs: An extension command/call that takes a measurement value and an RTMR index to extend it with, and a readback command for reading an RTMR value back (taking an RTMR index as an argument as well). This patch series builds an architecture agnostic, configfs-based ABI for userspace to extend and read RTMR values back. It extends the current TSM ops structure and each confidential computing architecture can implement this extension to provide RTMR support. --- Samuel Ortiz (4): tsm: Runtime measurement register support tsm: Add RTMRs to the configfs-tsm hierarchy tsm: Allow for mapping RTMRs to TCG TPM PCRs tsm: Allow for extending and reading configured RTMRs drivers/virt/coco/Kconfig | 1 + drivers/virt/coco/tsm.c | 362 ++++++++++++++++++++++++++++++++++++++ include/linux/tsm.h | 28 ++- 3 files changed, 390 insertions(+), 1 deletion(-)
Comments
Samuel Ortiz wrote: > Some confidential computing architectures (Intel TDX, ARM CCA, RISC-V > CoVE) provide their guests with a set of measurements registers that can > be extended at runtime, i.e. after the initial, host-initiated > measurements of the TVM are finalized. Those runtime measurement > registers (RTMR) are isolated from the host accessible ones but TSMs > include them in their signed attestation reports. > > All architectures supporting RTMRs expose a similar interface to their > TVMs: An extension command/call that takes a measurement value and an > RTMR index to extend it with, and a readback command for reading an RTMR > value back (taking an RTMR index as an argument as well). This patch series > builds an architecture agnostic, configfs-based ABI for userspace to extend > and read RTMR values back. It extends the current TSM ops structure and > each confidential computing architecture can implement this extension to > provide RTMR support. Hi Samuel, this looks like the right direction to me. One of my goals at Plumbers was to explore the tension of the perception of RTMR being a one-off (Intel-only) solution, and that the ecosystem is otherwise best served by preserving TPM ABI momentum. This submission clears that first concern, several vendors have an RTMR concept. The second concern, after talking with others, is that a soft-TPM (e.g. vtpm_proxy) backed by RTMR can support the TPM ecosystem. Such a layer on top of this achieves TPM support for several architectures at once which seems the right thing to do from an upstream maintenance perspective. I will likely have some questions about the details, but that basic "should we do this" threshold in my view has been overcome.
Samuel Ortiz wrote: > Some confidential computing architectures (Intel TDX, ARM CCA, RISC-V > CoVE) provide their guests with a set of measurements registers that can > be extended at runtime, i.e. after the initial, host-initiated > measurements of the TVM are finalized. Those runtime measurement > registers (RTMR) are isolated from the host accessible ones but TSMs > include them in their signed attestation reports. > > All architectures supporting RTMRs expose a similar interface to their > TVMs: An extension command/call that takes a measurement value and an > RTMR index to extend it with, and a readback command for reading an RTMR > value back (taking an RTMR index as an argument as well). This patch series > builds an architecture agnostic, configfs-based ABI for userspace to extend > and read RTMR values back. It extends the current TSM ops structure and > each confidential computing architecture can implement this extension to > provide RTMR support. Hi, Samuel The ABI does not include eventlog, but eventlog is usually used with RTMR. What do you think about how to implement eventlog?
On Wed, Jan 17, 2024 at 7:36 PM <biao.lu@intel.com> wrote: > > Samuel Ortiz wrote: > > Some confidential computing architectures (Intel TDX, ARM CCA, RISC-V > > CoVE) provide their guests with a set of measurements registers that can > > be extended at runtime, i.e. after the initial, host-initiated > > measurements of the TVM are finalized. Those runtime measurement > > registers (RTMR) are isolated from the host accessible ones but TSMs > > include them in their signed attestation reports. > > > > All architectures supporting RTMRs expose a similar interface to their > > TVMs: An extension command/call that takes a measurement value and an > > RTMR index to extend it with, and a readback command for reading an RTMR > > value back (taking an RTMR index as an argument as well). This patch series > > builds an architecture agnostic, configfs-based ABI for userspace to extend > > and read RTMR values back. It extends the current TSM ops structure and > > each confidential computing architecture can implement this extension to > > provide RTMR support. > > Hi, Samuel > The ABI does not include eventlog, but eventlog is usually used with RTMR. > What do you think about how to implement eventlog? > > I had the same question and deleted my reply. The event log in TPM is made available in sysfs only up to the point that control transitions to user space. After that, all extensions to PCRs have to be logged by user space with whatever chosen workload event log representation. I imagine the same is true for RTMRs. What this patch series doesn't take into account is how RTMRs might not be represented in the hardware attestation, but rather would be in a supervisor service whose integrity is chained from hardware attestation. In the configfs-tsm model, tsm/report with its single provider requirement will not be able to interface with the SVSM attestation protocol /and/ the AMD hardware protocol. That may as well be okay, but that's a choice folks need to be aware of. There's still the issue of attesting a single service vs attesting all services in the SVSM. I imagine single service attestation will have to be abandoned. In SVSM, a vTPM is a service that an updated linux driver will be able to get a quote from, and the same AMD SEV-SNP attestation report TSM provider would still be present, but if we want a simpler RTMR service, then we're in a little pickle with this design.
Dionna Amalie Glaze wrote: > On Wed, Jan 17, 2024 at 7:36 PM <biao.lu@intel.com> wrote: > > > > Samuel Ortiz wrote: > > > Some confidential computing architectures (Intel TDX, ARM CCA, RISC-V > > > CoVE) provide their guests with a set of measurements registers that can > > > be extended at runtime, i.e. after the initial, host-initiated > > > measurements of the TVM are finalized. Those runtime measurement > > > registers (RTMR) are isolated from the host accessible ones but TSMs > > > include them in their signed attestation reports. > > > > > > All architectures supporting RTMRs expose a similar interface to their > > > TVMs: An extension command/call that takes a measurement value and an > > > RTMR index to extend it with, and a readback command for reading an RTMR > > > value back (taking an RTMR index as an argument as well). This patch series > > > builds an architecture agnostic, configfs-based ABI for userspace to extend > > > and read RTMR values back. It extends the current TSM ops structure and > > > each confidential computing architecture can implement this extension to > > > provide RTMR support. > > > > Hi, Samuel > > The ABI does not include eventlog, but eventlog is usually used with RTMR. > > What do you think about how to implement eventlog? > > > > > > I had the same question and deleted my reply. The event log in TPM is > made available in sysfs only up to the point that control transitions > to user space. After that, all extensions to PCRs have to be logged by > user space with whatever chosen workload event log representation. I > imagine the same is true for RTMRs. > > What this patch series doesn't take into account is how RTMRs might > not be represented in the hardware attestation, but rather would be in > a supervisor service whose integrity is chained from hardware > attestation. In the configfs-tsm model, tsm/report with its single > provider requirement will not be able to interface with the SVSM > attestation protocol /and/ the AMD hardware protocol. That may as well > be okay, but that's a choice folks need to be aware of. There's still > the issue of attesting a single service vs attesting all services in > the SVSM. I imagine single service attestation will have to be > abandoned. > > In SVSM, a vTPM is a service that an updated linux driver will be able > to get a quote from, and the same AMD SEV-SNP attestation report TSM > provider would still be present, but if we want a simpler RTMR > service, then we're in a little pickle with this design. There is a good chance I am misunderstanding the concern, but I would say yes, the vTPM that would be layered on top of RTMRs is independent of the SVSM vTPM effort. For an architecture without RTMRs, vTPM via SVSM is likely the only choice, and for architectures with RTMRs an SVSM indepdendent vTPM is possible. For the kernel it already has a vtpm_proxy driver that could be put to use here, and that would be independent of the eventual SVSM vTPM driver. I am using "SVSM" above with the model of a layer providing services to an unenlightened TVM in mind. In contrast, this RTMR model requires some TVM enlightenment to setup vtpm_proxy on top of this cross-architecture building block.
On Thu, Jan 18, 2024 at 11:35:15AM +0800, biao.lu@intel.com wrote: > Samuel Ortiz wrote: > > Some confidential computing architectures (Intel TDX, ARM CCA, RISC-V > > CoVE) provide their guests with a set of measurements registers that can > > be extended at runtime, i.e. after the initial, host-initiated > > measurements of the TVM are finalized. Those runtime measurement > > registers (RTMR) are isolated from the host accessible ones but TSMs > > include them in their signed attestation reports. > > > > All architectures supporting RTMRs expose a similar interface to their > > TVMs: An extension command/call that takes a measurement value and an > > RTMR index to extend it with, and a readback command for reading an RTMR > > value back (taking an RTMR index as an argument as well). This patch series > > builds an architecture agnostic, configfs-based ABI for userspace to extend > > and read RTMR values back. It extends the current TSM ops structure and > > each confidential computing architecture can implement this extension to > > provide RTMR support. > > Hi, Samuel > The ABI does not include eventlog, but eventlog is usually used with RTMR. > What do you think about how to implement eventlog? Since the event log is typically maintained in the firmware and not in the TSM itself, I don't think we should expose e.g. an event log extension ABI through the config-tsm one. We could decide to check for an EFI CC protocol availability and extend the event log when any RTMR gets extended, and that would be an internal, not userspace visible operation. I'm not sure that this would scale well with e.g. IMA (a lot more events than pre-OS boot afaik). Cheers, Samuel.
Samuel Ortiz wrote: > On Thu, Jan 18, 2024 at 11:35:15AM +0800, biao.lu@intel.com wrote: > > Samuel Ortiz wrote: > > > Some confidential computing architectures (Intel TDX, ARM CCA, RISC-V > > > CoVE) provide their guests with a set of measurements registers that can > > > be extended at runtime, i.e. after the initial, host-initiated > > > measurements of the TVM are finalized. Those runtime measurement > > > registers (RTMR) are isolated from the host accessible ones but TSMs > > > include them in their signed attestation reports. > > > > > > All architectures supporting RTMRs expose a similar interface to their > > > TVMs: An extension command/call that takes a measurement value and an > > > RTMR index to extend it with, and a readback command for reading an RTMR > > > value back (taking an RTMR index as an argument as well). This patch series > > > builds an architecture agnostic, configfs-based ABI for userspace to extend > > > and read RTMR values back. It extends the current TSM ops structure and > > > each confidential computing architecture can implement this extension to > > > provide RTMR support. > > > > Hi, Samuel > > The ABI does not include eventlog, but eventlog is usually used with RTMR. > > What do you think about how to implement eventlog? > > Since the event log is typically maintained in the firmware and not in > the TSM itself, I don't think we should expose e.g. an event log > extension ABI through the config-tsm one. > We could decide to check for an EFI CC protocol availability and extend > the event log when any RTMR gets extended, and that would be an > internal, not userspace visible operation. I'm not sure that this > would scale well with e.g. IMA (a lot more events than pre-OS boot > afaik). Another observation after chatting with my colleague Cedric is that the TPM layer that builds on RTMR can maintain an event log that forks from the RTMR log. I.e. instead of the TPM event log containig pre-OS events starting from 0, it would start from a golden point in the RTMR measurements.
On 1/21/2024 11:15 AM, Dan Williams wrote: > Samuel Ortiz wrote: >> On Thu, Jan 18, 2024 at 11:35:15AM +0800, biao.lu@intel.com wrote: >>> Samuel Ortiz wrote: >>>> Some confidential computing architectures (Intel TDX, ARM CCA, RISC-V >>>> CoVE) provide their guests with a set of measurements registers that can >>>> be extended at runtime, i.e. after the initial, host-initiated >>>> measurements of the TVM are finalized. Those runtime measurement >>>> registers (RTMR) are isolated from the host accessible ones but TSMs >>>> include them in their signed attestation reports. >>>> >>>> All architectures supporting RTMRs expose a similar interface to their >>>> TVMs: An extension command/call that takes a measurement value and an >>>> RTMR index to extend it with, and a readback command for reading an RTMR >>>> value back (taking an RTMR index as an argument as well). This patch series >>>> builds an architecture agnostic, configfs-based ABI for userspace to extend >>>> and read RTMR values back. It extends the current TSM ops structure and >>>> each confidential computing architecture can implement this extension to >>>> provide RTMR support. >>> >>> Hi, Samuel >>> The ABI does not include eventlog, but eventlog is usually used with RTMR. >>> What do you think about how to implement eventlog? >> >> Since the event log is typically maintained in the firmware and not in >> the TSM itself, I don't think we should expose e.g. an event log >> extension ABI through the config-tsm one. >> We could decide to check for an EFI CC protocol availability and extend >> the event log when any RTMR gets extended, and that would be an >> internal, not userspace visible operation. I'm not sure that this >> would scale well with e.g. IMA (a lot more events than pre-OS boot >> afaik). > > Another observation after chatting with my colleague Cedric is that the > TPM layer that builds on RTMR can maintain an event log that forks from > the RTMR log. I.e. instead of the TPM event log containig pre-OS events > starting from 0, it would start from a golden point in the RTMR > measurements. > That's right. What's needed in verification is the full history of how a measurement register's value was transitioned from A->B, which could be segmented as A->X then X->B and stored in separate event logs. Those event logs don't have to be maintained by the same entity or in the same format.