Message ID | 20240114223532.290550-4-sameo@rivosinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-25551-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:693c:2614:b0:101:6a76:bbe3 with SMTP id mm20csp1394337dyc; Sun, 14 Jan 2024 14:38:16 -0800 (PST) X-Google-Smtp-Source: AGHT+IEtu4dFmqIB7wZR3stuP7FaweX5FBJpdZVoHdFKJad/NJ0QuNGNlGS3zoVI0upG6atsnZMB X-Received: by 2002:a17:90b:b17:b0:28e:1e7a:3884 with SMTP id bf23-20020a17090b0b1700b0028e1e7a3884mr876266pjb.47.1705271896318; Sun, 14 Jan 2024 14:38:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1705271896; cv=none; d=google.com; s=arc-20160816; b=0y/6Duv7FV1gS6f6gWlb83vBaPCU0rDpxDpkQ1OeXvJyGhlwv4zizcaXtfgXpQ3l4q L74QwW3enu1n0nXQJjyMS5H9b1uOSRP2r7VucKWH3EePB1D7ST6VjjRluJpxr+4ipcdV YnmeE+0gzjgheFnpewgrCOcO2RwsZDcJFtnz1vDbgiomUWtEJZrS1S8LdxRg9z1hXC0O Q1Mej8BStAZkmnSd4gxwLxYRcpXs7C6x7ix8Que1/I2z8BCO7WGa1+8JB6P3UWrokVfP //MkmYNzdskdu+7ErW7mApAeJXmYPp6h3vxcjYYPNZNHpAfhZ3eNGkRzbNPx9nEi7nNx hoMg== 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:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=AlF8fFJ5lqdqj/4fKpFf4I4E1M06YT+qzoTwfOt/slo=; fh=il1A4p8Y2RU7C8awMmLfy7MVoYnl7dsy03dVseJVaq4=; b=U5djmKdj63r4RrAXzjS+yeumUTbOIYxwpKFDMDlLxX3avFBtA0whNg8MM26adACgjv fZVQs4dCRdlAg0fgvulrlmBKU8B+u+I5ebDDRA4TzviXGbxlvr3fJMkMI8NzIYillGfw T0hE7fyio40P5rAfMKfxEPWEI7nAxrNtBID9cfxqTYP/dS00H8PHSjUYcY3NNxA8smqP icKkOWABaqyf74/cVX7xfjBDQWwhHNhOpSOkGamqNPsVdm5t8O1OTA/O1Y1nBmQcIzkG KpMbrDBrAFbbGRFbAg6wL/OG6r8Dcyk0TSvmws6VKjnogUhhyV4p9H291X0ryySxbuE8 peTA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=J8+lkapW; spf=pass (google.com: domain of linux-kernel+bounces-25551-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-25551-ouuuleilei=gmail.com@vger.kernel.org" Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id y13-20020a170902b48d00b001d43cfe9773si7472286plr.651.2024.01.14.14.38.16 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Jan 2024 14:38:16 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-25551-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=J8+lkapW; spf=pass (google.com: domain of linux-kernel+bounces-25551-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-25551-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 sv.mirrors.kernel.org (Postfix) with ESMTPS id 1CFB82817FE for <ouuuleilei@gmail.com>; Sun, 14 Jan 2024 22:38:16 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id DB9E12CCBA; Sun, 14 Jan 2024 22:37:14 +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="J8+lkapW" Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) (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 3197E2C682 for <linux-kernel@vger.kernel.org>; Sun, 14 Jan 2024 22:37:09 +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-f53.google.com with SMTP id ffacd0b85a97d-3367632ce7bso5695599f8f.2 for <linux-kernel@vger.kernel.org>; Sun, 14 Jan 2024 14:37:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1705271827; x=1705876627; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=AlF8fFJ5lqdqj/4fKpFf4I4E1M06YT+qzoTwfOt/slo=; b=J8+lkapWekTAcxtfCxtP6RM4Z8kiqfJTUngq37Lq6x65t/ST+LSTl8ej63ZKxqXG+w 66KbRZqEWy9VqRUWvOYGa8emEa7N4tXqGhiEI/6B3qeADBBD8XO3M7W/TjRNv1uLMLUC iyzvXq7NPxIDkQwPZzHlu87KT2yqWrmmDisW0j2PWytDe1qn/FANWeUGo3HXUTDb1pMv DUgIr9zSQv66zmO2n8pn1dqoj72ZSqePSPz40CjN908C5b204f3SYhgwvxWDjzU8/8ZN 0e9X7G8rCLgvR11omgtFHg6wL4OUC421jeeMjUQY5LMq03vCfVr5smYTVhZIHu/RZDqo +T/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705271827; x=1705876627; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=AlF8fFJ5lqdqj/4fKpFf4I4E1M06YT+qzoTwfOt/slo=; b=cGVUN5k7rW3hUA7169KYzc4t2Gzwjr9B1hqnR8OnV4f5coB7T96TdjgHogQS5KyXIR U/hFsnD3A1bwjIr0M6Iu2rlLCdkVw4YrPF9XEg8w3AUj78PmXH5Pgml+RBE4QE3MwUu7 72lYArlG64FWpdqm9i8kjpwlIamj63omGZH+7p+KjSPvhOgNIq6BRQPuiFeJhizfwoXT 9ARVh5A8d5PuwEujTemFPok4zwNw6vLRu7xGOaBLRRkUvQ13jSIFrkwgSDo31CBSB1MP 9bCLvKvDu6N75tCLExsw+DQirvc8kbzHKPYEw6Lpnxtv5hhdFZpDbcJ3Owyn0kI9+3SR 0gug== X-Gm-Message-State: AOJu0Yz09s5aj8vsAaHvnPlnWFw3Q9V+7qOC9jUbDYnKdGiCJZAsHW2p N+fA78rOnjemYYOHCDBb2o7X13oheEO34A== X-Received: by 2002:adf:a18b:0:b0:337:5588:801f with SMTP id u11-20020adfa18b000000b003375588801fmr2716111wru.57.1705271827555; Sun, 14 Jan 2024 14:37:07 -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.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Jan 2024 14:37:06 -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 3/4] tsm: Allow for mapping RTMRs to TCG TPM PCRs Date: Sun, 14 Jan 2024 23:35:29 +0100 Message-ID: <20240114223532.290550-4-sameo@rivosinc.com> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20240114223532.290550-1-sameo@rivosinc.com> References: <20240114223532.290550-1-sameo@rivosinc.com> 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: 1788107184190559987 X-GMAIL-MSGID: 1788107184190559987 |
Series |
tsm: Runtime measurement registers ABI
|
|
Commit Message
Samuel Ortiz
Jan. 14, 2024, 10:35 p.m. UTC
Many user space and internal kernel subsystems (e.g. the Linux IMA)
expect a Root of Trust for Storage (RTS) that allows for extending
and reading measurement registers that are compatible with the TCG TPM
PCRs layout, e.g. a TPM. In order to allow those components to
alternatively use a platform TSM as their RTS, a TVM could map the
available RTMRs to one or more TCG TPM PCRs. Once configured, those PCR
to RTMR mappings give the kernel TSM layer all the necessary information
to be a RTS for e.g. the Linux IMA or any other components that expects
a TCG compliant TPM PCRs layout.
TPM PCR mappings are configured through configfs:
// Create and configure 2 RTMRs
mkdir /sys/kernel/config/tsm/rtmrs/rtmr0
mkdir /sys/kernel/config/tsm/rtmrs/rtmr1
echo 0 > /sys/kernel/config/tsm/rtmrs/rtmr0/index
echo 1 > /sys/kernel/config/tsm/rtmrs/rtmr1/index
// Map RTMR 0 to PCRs 4, 5, 6, 7 and 8
echo 4-8 > /sys/kernel/config/tsm/rtmrs/rtmr0/tcg_map
// Map RTMR 1 to PCRs 16, 17 and 18
echo 16-18 > /sys/kernel/config/tsm/rtmrs/rtmr1/tcg_map
Signed-off-by: Samuel Ortiz <sameo@rivosinc.com>
---
drivers/virt/coco/tsm.c | 60 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 60 insertions(+)
Comments
On 1/14/24 2:35 PM, Samuel Ortiz wrote: > Many user space and internal kernel subsystems (e.g. the Linux IMA) > expect a Root of Trust for Storage (RTS) that allows for extending > and reading measurement registers that are compatible with the TCG TPM > PCRs layout, e.g. a TPM. In order to allow those components to > alternatively use a platform TSM as their RTS, a TVM could map the > available RTMRs to one or more TCG TPM PCRs. Once configured, those PCR > to RTMR mappings give the kernel TSM layer all the necessary information > to be a RTS for e.g. the Linux IMA or any other components that expects > a TCG compliant TPM PCRs layout. > > TPM PCR mappings are configured through configfs: > > // Create and configure 2 RTMRs > mkdir /sys/kernel/config/tsm/rtmrs/rtmr0 > mkdir /sys/kernel/config/tsm/rtmrs/rtmr1 > echo 0 > /sys/kernel/config/tsm/rtmrs/rtmr0/index > echo 1 > /sys/kernel/config/tsm/rtmrs/rtmr1/index > > // Map RTMR 0 to PCRs 4, 5, 6, 7 and 8 > echo 4-8 > /sys/kernel/config/tsm/rtmrs/rtmr0/tcg_map > > // Map RTMR 1 to PCRs 16, 17 and 18 > echo 16-18 > /sys/kernel/config/tsm/rtmrs/rtmr1/tcg_map Any information on how this mapping will be used by TPM or IMA ? RTMR to PCR mapping is fixed by design, right? If yes, why allow user to configure it. We can let vendor drivers to configure it, right? > > Signed-off-by: Samuel Ortiz <sameo@rivosinc.com> > --- > drivers/virt/coco/tsm.c | 60 +++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 60 insertions(+) > > diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c > index 15b67d99fd54..f35f91cb7bd3 100644 > --- a/drivers/virt/coco/tsm.c > +++ b/drivers/virt/coco/tsm.c > @@ -472,8 +472,68 @@ static ssize_t tsm_rtmr_index_show(struct config_item *cfg, > } > CONFIGFS_ATTR(tsm_rtmr_, index); > > +static ssize_t tsm_rtmr_tcg_map_store(struct config_item *cfg, > + const char *buf, size_t len) > +{ > + struct tsm_rtmr_state *rtmr_state = to_tsm_rtmr_state(cfg); > + int i, pcrs[TPM2_PLATFORM_PCR + 1]; > + > + get_options(buf, ARRAY_SIZE(pcrs), pcrs); > + > + if (pcrs[0] > TPM2_PLATFORM_PCR - 1) > + return -EINVAL; > + > + guard(rwsem_write)(&tsm_rwsem); > + /* Check that the PCR list is valid */ > + for (i = 0; i < pcrs[0]; i++) { > + /* It must be a valid TPM2 PCR number */ > + if (pcrs[i] > TPM2_PLATFORM_PCR - 1) > + return -EINVAL; > + > + /* If another RTMR maps to this PCR, the list is discarded */ > + if (tsm_rtmrs->tcg_map[pcrs[i + 1]] && > + tsm_rtmrs->tcg_map[pcrs[i + 1]] != rtmr_state) > + return -EBUSY; > + } > + > + for (i = 0; i < pcrs[0]; i++) > + tsm_rtmrs->tcg_map[pcrs[i + 1]] = rtmr_state; > + > + return len; > +} > + > +static ssize_t tsm_rtmr_tcg_map_show(struct config_item *cfg, > + char *buf) > +{ > + struct tsm_rtmr_state *rtmr_state = to_tsm_rtmr_state(cfg); > + unsigned int nr_pcrs = ARRAY_SIZE(tsm_rtmrs->tcg_map), i; > + unsigned long *pcr_mask; > + ssize_t len; > + > + /* Build a bitmap mask of all PCRs that this RTMR covers */ > + pcr_mask = bitmap_zalloc(nr_pcrs, GFP_KERNEL); > + if (!pcr_mask) > + return -ENOMEM; > + > + guard(rwsem_read)(&tsm_rwsem); > + for (i = 0; i < nr_pcrs; i++) { > + if (tsm_rtmrs->tcg_map[i] != rtmr_state) > + continue; > + > + __set_bit(i, pcr_mask); > + } > + > + len = bitmap_print_list_to_buf(buf, pcr_mask, nr_pcrs, 0, > + nr_pcrs * 3 /* 2 ASCII digits and one comma */); > + bitmap_free(pcr_mask); > + > + return len; > +} > +CONFIGFS_ATTR(tsm_rtmr_, tcg_map); > + > static struct configfs_attribute *tsm_rtmr_attrs[] = { > &tsm_rtmr_attr_index, > + &tsm_rtmr_attr_tcg_map, > NULL, > }; >
Kuppuswamy Sathyanarayanan wrote: > > On 1/14/24 2:35 PM, Samuel Ortiz wrote: > > Many user space and internal kernel subsystems (e.g. the Linux IMA) > > expect a Root of Trust for Storage (RTS) that allows for extending > > and reading measurement registers that are compatible with the TCG TPM > > PCRs layout, e.g. a TPM. In order to allow those components to > > alternatively use a platform TSM as their RTS, a TVM could map the > > available RTMRs to one or more TCG TPM PCRs. Once configured, those PCR > > to RTMR mappings give the kernel TSM layer all the necessary information > > to be a RTS for e.g. the Linux IMA or any other components that expects > > a TCG compliant TPM PCRs layout. > > > > TPM PCR mappings are configured through configfs: > > > > // Create and configure 2 RTMRs > > mkdir /sys/kernel/config/tsm/rtmrs/rtmr0 > > mkdir /sys/kernel/config/tsm/rtmrs/rtmr1 > > echo 0 > /sys/kernel/config/tsm/rtmrs/rtmr0/index > > echo 1 > /sys/kernel/config/tsm/rtmrs/rtmr1/index > > > > // Map RTMR 0 to PCRs 4, 5, 6, 7 and 8 > > echo 4-8 > /sys/kernel/config/tsm/rtmrs/rtmr0/tcg_map > > > > // Map RTMR 1 to PCRs 16, 17 and 18 > > echo 16-18 > /sys/kernel/config/tsm/rtmrs/rtmr1/tcg_map > > Any information on how this mapping will be used by TPM or IMA ? > > RTMR to PCR mapping is fixed by design, right? If yes, why allow > user to configure it. We can let vendor drivers to configure it, right? I assume the "vendor driver", that publishes the RTMR to the tsm-core, has no idea whether they will be used for PCR emulation, or not. The TPM proxy layer sitting on top of this would know the mapping of which RTMRs are recording a transcript of which PCR extend events. For IMA the situation is different because that can be a kernel internal configuration flow without need to involve userspace.
On 1/16/24 5:24 PM, Dan Williams wrote: > Kuppuswamy Sathyanarayanan wrote: >> On 1/14/24 2:35 PM, Samuel Ortiz wrote: >>> Many user space and internal kernel subsystems (e.g. the Linux IMA) >>> expect a Root of Trust for Storage (RTS) that allows for extending >>> and reading measurement registers that are compatible with the TCG TPM >>> PCRs layout, e.g. a TPM. In order to allow those components to >>> alternatively use a platform TSM as their RTS, a TVM could map the >>> available RTMRs to one or more TCG TPM PCRs. Once configured, those PCR >>> to RTMR mappings give the kernel TSM layer all the necessary information >>> to be a RTS for e.g. the Linux IMA or any other components that expects >>> a TCG compliant TPM PCRs layout. >>> >>> TPM PCR mappings are configured through configfs: >>> >>> // Create and configure 2 RTMRs >>> mkdir /sys/kernel/config/tsm/rtmrs/rtmr0 >>> mkdir /sys/kernel/config/tsm/rtmrs/rtmr1 >>> echo 0 > /sys/kernel/config/tsm/rtmrs/rtmr0/index >>> echo 1 > /sys/kernel/config/tsm/rtmrs/rtmr1/index >>> >>> // Map RTMR 0 to PCRs 4, 5, 6, 7 and 8 >>> echo 4-8 > /sys/kernel/config/tsm/rtmrs/rtmr0/tcg_map >>> >>> // Map RTMR 1 to PCRs 16, 17 and 18 >>> echo 16-18 > /sys/kernel/config/tsm/rtmrs/rtmr1/tcg_map >> Any information on how this mapping will be used by TPM or IMA ? >> >> RTMR to PCR mapping is fixed by design, right? If yes, why allow >> user to configure it. We can let vendor drivers to configure it, right? > I assume the "vendor driver", that publishes the RTMR to the tsm-core, > has no idea whether they will be used for PCR emulation, or not. The TPM > proxy layer sitting on top of this would know the mapping of which RTMRs > are recording a transcript of which PCR extend events. My thinking is, since this mapping is ARCH-specific information and fixed by design, it makes more sense to hide this detail in the vendor driver than letting userspace configure it. If we allow users to configure it, there is a chance for incorrect mapping. Regarding the TPM proxy, I am still not clear how it is going to use this mapping. If we want to provide TPM like feature, it needs a special kernel TPM driver, right? Even if we enable TPM support with RTMR, I assume it can only support pcr_extend(). Other TPM features should be disabled. If yes, since we already have this ABI for measurement extension, why again support it via TPM or did I misunderstand the use case. > > For IMA the situation is different because that can be a kernel internal > configuration flow without need to involve userspace. >
On Tue, Jan 16, 2024 at 07:35:30PM -0800, Kuppuswamy Sathyanarayanan wrote: > > On 1/16/24 5:24 PM, Dan Williams wrote: > > Kuppuswamy Sathyanarayanan wrote: > >> On 1/14/24 2:35 PM, Samuel Ortiz wrote: > >>> Many user space and internal kernel subsystems (e.g. the Linux IMA) > >>> expect a Root of Trust for Storage (RTS) that allows for extending > >>> and reading measurement registers that are compatible with the TCG TPM > >>> PCRs layout, e.g. a TPM. In order to allow those components to > >>> alternatively use a platform TSM as their RTS, a TVM could map the > >>> available RTMRs to one or more TCG TPM PCRs. Once configured, those PCR > >>> to RTMR mappings give the kernel TSM layer all the necessary information > >>> to be a RTS for e.g. the Linux IMA or any other components that expects > >>> a TCG compliant TPM PCRs layout. > >>> > >>> TPM PCR mappings are configured through configfs: > >>> > >>> // Create and configure 2 RTMRs > >>> mkdir /sys/kernel/config/tsm/rtmrs/rtmr0 > >>> mkdir /sys/kernel/config/tsm/rtmrs/rtmr1 > >>> echo 0 > /sys/kernel/config/tsm/rtmrs/rtmr0/index > >>> echo 1 > /sys/kernel/config/tsm/rtmrs/rtmr1/index > >>> > >>> // Map RTMR 0 to PCRs 4, 5, 6, 7 and 8 > >>> echo 4-8 > /sys/kernel/config/tsm/rtmrs/rtmr0/tcg_map > >>> > >>> // Map RTMR 1 to PCRs 16, 17 and 18 > >>> echo 16-18 > /sys/kernel/config/tsm/rtmrs/rtmr1/tcg_map > >> Any information on how this mapping will be used by TPM or IMA ? > >> > >> RTMR to PCR mapping is fixed by design, right? If yes, why allow > >> user to configure it. We can let vendor drivers to configure it, right? > > I assume the "vendor driver", that publishes the RTMR to the tsm-core, > > has no idea whether they will be used for PCR emulation, or not. The TPM > > proxy layer sitting on top of this would know the mapping of which RTMRs > > are recording a transcript of which PCR extend events. > > My thinking is, since this mapping is ARCH-specific information > and fixed by design, it makes more sense to hide this detail in the > vendor driver than letting userspace configure it. If we allow users to > configure it, there is a chance for incorrect mapping. I think I agree with the fact that letting users configure that mapping may be error prone. But I'm not sure this is an architecture specific mapping, but rather a platform specific one. I'd expect the guest firmware to provide it through e.g. the MapPcrToMrIndex EFI CC protocol. So I agree I should remove the user interface for setting that mapping, and pass it from the provider capabilities instead. It is then up to the provider to choose how it'd build that information (hard coded, from EFI, etc). > Regarding the TPM proxy, I am still not clear how it is going to use > this mapping. If we want to provide TPM like feature, it needs a > special kernel TPM driver, right? Even if we enable TPM support > with RTMR, I assume it can only support pcr_extend(). Extend and read, yes. > Other TPM > features should be disabled. If yes, since we already have this ABI > for measurement extension, why again support it via TPM or did > I misunderstand the use case. I am not sure the TPM compatibility is always needed, but for subsystems (like e.g. IMA) that look for a TPM as their root of trust for storage, providing the extend+read ABI and the PCR mapping should be sufficient. Cheers, Samuel.
> On Jan 21, 2024, at 8:31 AM, Samuel Ortiz <sameo@rivosinc.com> wrote: > > On Tue, Jan 16, 2024 at 07:35:30PM -0800, Kuppuswamy Sathyanarayanan wrote: >> >> On 1/16/24 5:24 PM, Dan Williams wrote: >>> Kuppuswamy Sathyanarayanan wrote: >>>> On 1/14/24 2:35 PM, Samuel Ortiz wrote: >>>>> Many user space and internal kernel subsystems (e.g. the Linux IMA) >>>>> expect a Root of Trust for Storage (RTS) that allows for extending >>>>> and reading measurement registers that are compatible with the TCG TPM >>>>> PCRs layout, e.g. a TPM. In order to allow those components to >>>>> alternatively use a platform TSM as their RTS, a TVM could map the >>>>> available RTMRs to one or more TCG TPM PCRs. Once configured, those PCR >>>>> to RTMR mappings give the kernel TSM layer all the necessary information >>>>> to be a RTS for e.g. the Linux IMA or any other components that expects >>>>> a TCG compliant TPM PCRs layout. >>>>> >>>>> TPM PCR mappings are configured through configfs: >>>>> >>>>> // Create and configure 2 RTMRs >>>>> mkdir /sys/kernel/config/tsm/rtmrs/rtmr0 >>>>> mkdir /sys/kernel/config/tsm/rtmrs/rtmr1 >>>>> echo 0 > /sys/kernel/config/tsm/rtmrs/rtmr0/index >>>>> echo 1 > /sys/kernel/config/tsm/rtmrs/rtmr1/index >>>>> >>>>> // Map RTMR 0 to PCRs 4, 5, 6, 7 and 8 >>>>> echo 4-8 > /sys/kernel/config/tsm/rtmrs/rtmr0/tcg_map >>>>> >>>>> // Map RTMR 1 to PCRs 16, 17 and 18 >>>>> echo 16-18 > /sys/kernel/config/tsm/rtmrs/rtmr1/tcg_map >>>> Any information on how this mapping will be used by TPM or IMA ? >>>> >>>> RTMR to PCR mapping is fixed by design, right? If yes, why allow >>>> user to configure it. We can let vendor drivers to configure it, right? >>> I assume the "vendor driver", that publishes the RTMR to the tsm-core, >>> has no idea whether they will be used for PCR emulation, or not. The TPM >>> proxy layer sitting on top of this would know the mapping of which RTMRs >>> are recording a transcript of which PCR extend events. >> >> My thinking is, since this mapping is ARCH-specific information >> and fixed by design, it makes more sense to hide this detail in the >> vendor driver than letting userspace configure it. If we allow users to >> configure it, there is a chance for incorrect mapping. > > I think I agree with the fact that letting users configure that mapping > may be error prone. But I'm not sure this is an architecture specific > mapping, but rather a platform specific one. I'd expect the guest firmware > to provide it through e.g. the MapPcrToMrIndex EFI CC protocol. > > So I agree I should remove the user interface for setting that mapping, > and pass it from the provider capabilities instead. It is then up to the > provider to choose how it'd build that information (hard coded, from > EFI, etc). The UEFI specification has defined the mapping relationship between the TDX RTMR and TPM PCRs (See https://uefi.org/specs/UEFI/2.10/38_Confidential_Computing.html#intel-trust-domain-extension). The current RTMR implementation in the boot loader is “hooked” in the implementation for the TPM. When the bootloader needs to extend the PCR value, it calls `map_pcr_to_mr_index` to retrieve the corresponding RTMR index and then extends the RTMR. Considering this behavior, I don’t think we should allow users to configure the mappings between the PCR and RTMR. (See https://github.com/rhboot/shim/pull/485/files). Add Jiewen (owner of the RTMR changes in the firmware) and Ken ( owner of the RTMR changes in the boot loader) for the visibility. > >> Regarding the TPM proxy, I am still not clear how it is going to use >> this mapping. If we want to provide TPM like feature, it needs a >> special kernel TPM driver, right? Even if we enable TPM support >> with RTMR, I assume it can only support pcr_extend(). > > Extend and read, yes. > >> Other TPM >> features should be disabled. If yes, since we already have this ABI >> for measurement extension, why again support it via TPM or did >> I misunderstand the use case. > > I am not sure the TPM compatibility is always needed, but for subsystems > (like e.g. IMA) that look for a TPM as their root of trust for storage, > providing the extend+read ABI and the PCR mapping should be sufficient. > > Cheers, > Samuel. > >
Comment below: > -----Original Message----- > From: Qinkun Bao <qinkun@google.com> > Sent: Monday, January 22, 2024 10:13 AM > To: Samuel Ortiz <sameo@rivosinc.com>; Yao, Jiewen <jiewen.yao@intel.com>; > Lu, Ken <ken.lu@intel.com> > Cc: Kuppuswamy Sathyanarayanan > <sathyanarayanan.kuppuswamy@linux.intel.com>; Williams, Dan J > <dan.j.williams@intel.com>; linux-coco@lists.linux.dev; linux- > kernel@vger.kernel.org > Subject: Re: [RFC PATCH v1 3/4] tsm: Allow for mapping RTMRs to TCG TPM PCRs > > > > > On Jan 21, 2024, at 8:31 AM, Samuel Ortiz <sameo@rivosinc.com> wrote: > > > > On Tue, Jan 16, 2024 at 07:35:30PM -0800, Kuppuswamy Sathyanarayanan > wrote: > >> > >> On 1/16/24 5:24 PM, Dan Williams wrote: > >>> Kuppuswamy Sathyanarayanan wrote: > >>>> On 1/14/24 2:35 PM, Samuel Ortiz wrote: > >>>>> Many user space and internal kernel subsystems (e.g. the Linux IMA) > >>>>> expect a Root of Trust for Storage (RTS) that allows for extending > >>>>> and reading measurement registers that are compatible with the TCG TPM > >>>>> PCRs layout, e.g. a TPM. In order to allow those components to > >>>>> alternatively use a platform TSM as their RTS, a TVM could map the > >>>>> available RTMRs to one or more TCG TPM PCRs. Once configured, those > PCR > >>>>> to RTMR mappings give the kernel TSM layer all the necessary information > >>>>> to be a RTS for e.g. the Linux IMA or any other components that expects > >>>>> a TCG compliant TPM PCRs layout. > >>>>> > >>>>> TPM PCR mappings are configured through configfs: > >>>>> > >>>>> // Create and configure 2 RTMRs > >>>>> mkdir /sys/kernel/config/tsm/rtmrs/rtmr0 > >>>>> mkdir /sys/kernel/config/tsm/rtmrs/rtmr1 > >>>>> echo 0 > /sys/kernel/config/tsm/rtmrs/rtmr0/index > >>>>> echo 1 > /sys/kernel/config/tsm/rtmrs/rtmr1/index > >>>>> > >>>>> // Map RTMR 0 to PCRs 4, 5, 6, 7 and 8 > >>>>> echo 4-8 > /sys/kernel/config/tsm/rtmrs/rtmr0/tcg_map > >>>>> > >>>>> // Map RTMR 1 to PCRs 16, 17 and 18 > >>>>> echo 16-18 > /sys/kernel/config/tsm/rtmrs/rtmr1/tcg_map > >>>> Any information on how this mapping will be used by TPM or IMA ? > >>>> > >>>> RTMR to PCR mapping is fixed by design, right? If yes, why allow > >>>> user to configure it. We can let vendor drivers to configure it, right? > >>> I assume the "vendor driver", that publishes the RTMR to the tsm-core, > >>> has no idea whether they will be used for PCR emulation, or not. The TPM > >>> proxy layer sitting on top of this would know the mapping of which RTMRs > >>> are recording a transcript of which PCR extend events. > >> > >> My thinking is, since this mapping is ARCH-specific information > >> and fixed by design, it makes more sense to hide this detail in the > >> vendor driver than letting userspace configure it. If we allow users to > >> configure it, there is a chance for incorrect mapping. > > > > I think I agree with the fact that letting users configure that mapping > > may be error prone. But I'm not sure this is an architecture specific > > mapping, but rather a platform specific one. I'd expect the guest firmware > > to provide it through e.g. the MapPcrToMrIndex EFI CC protocol. > > > > So I agree I should remove the user interface for setting that mapping, > > and pass it from the provider capabilities instead. It is then up to the > > provider to choose how it'd build that information (hard coded, from > > EFI, etc). > > The UEFI specification has defined the mapping relationship between the > TDX RTMR and TPM PCRs (See > https://uefi.org/specs/UEFI/2.10/38_Confidential_Computing.html#intel-trust- > domain-extension). The current RTMR implementation in the boot loader > is “hooked” in the implementation for the TPM. > > When the bootloader needs to extend the PCR value, it calls > `map_pcr_to_mr_index` to retrieve the corresponding RTMR index and > then extends the RTMR. Considering this behavior, I don’t think we should > allow users to configure the mappings between the PCR and RTMR. (See > https://github.com/rhboot/shim/pull/485/files). > > Add Jiewen (owner of the RTMR changes in the firmware) and Ken ( > owner of the RTMR changes in the boot loader) for the visibility. I think the mapping should be static and determined by the hardware architecture. Allowing user to configure the mapping just adds complexity and confusing. For example, the user must understand clearly on what is Intel-TDX/AMD-SEV/ARM-CCA/RISCV-CoVE, how many registers they have, what is the best way to map it. It also adds complexity to the verifier. For example, the verifier must understand how a user configure the mapping, then get the expected measurement register value. I believe that hiding detail is a better way to avoid those complexity, and make it easy to use. Do we have some real use cases that a user MUST configure the mapping? > > > > >> Regarding the TPM proxy, I am still not clear how it is going to use > >> this mapping. If we want to provide TPM like feature, it needs a > >> special kernel TPM driver, right? Even if we enable TPM support > >> with RTMR, I assume it can only support pcr_extend(). > > > > Extend and read, yes. > > > >> Other TPM > >> features should be disabled. If yes, since we already have this ABI > >> for measurement extension, why again support it via TPM or did > >> I misunderstand the use case. > > > > I am not sure the TPM compatibility is always needed, but for subsystems > > (like e.g. IMA) that look for a TPM as their root of trust for storage, > > providing the extend+read ABI and the PCR mapping should be sufficient. > > > > Cheers, > > Samuel. > > > >
On Sun, Jan 21, 2024 at 06:09:19PM -0800, Qinkun Bao wrote: > > > > On Jan 21, 2024, at 8:31 AM, Samuel Ortiz <sameo@rivosinc.com> wrote: > > > > On Tue, Jan 16, 2024 at 07:35:30PM -0800, Kuppuswamy Sathyanarayanan wrote: > >> > >> On 1/16/24 5:24 PM, Dan Williams wrote: > >>> Kuppuswamy Sathyanarayanan wrote: > >>>> On 1/14/24 2:35 PM, Samuel Ortiz wrote: > >>>>> Many user space and internal kernel subsystems (e.g. the Linux IMA) > >>>>> expect a Root of Trust for Storage (RTS) that allows for extending > >>>>> and reading measurement registers that are compatible with the TCG TPM > >>>>> PCRs layout, e.g. a TPM. In order to allow those components to > >>>>> alternatively use a platform TSM as their RTS, a TVM could map the > >>>>> available RTMRs to one or more TCG TPM PCRs. Once configured, those PCR > >>>>> to RTMR mappings give the kernel TSM layer all the necessary information > >>>>> to be a RTS for e.g. the Linux IMA or any other components that expects > >>>>> a TCG compliant TPM PCRs layout. > >>>>> > >>>>> TPM PCR mappings are configured through configfs: > >>>>> > >>>>> // Create and configure 2 RTMRs > >>>>> mkdir /sys/kernel/config/tsm/rtmrs/rtmr0 > >>>>> mkdir /sys/kernel/config/tsm/rtmrs/rtmr1 > >>>>> echo 0 > /sys/kernel/config/tsm/rtmrs/rtmr0/index > >>>>> echo 1 > /sys/kernel/config/tsm/rtmrs/rtmr1/index > >>>>> > >>>>> // Map RTMR 0 to PCRs 4, 5, 6, 7 and 8 > >>>>> echo 4-8 > /sys/kernel/config/tsm/rtmrs/rtmr0/tcg_map > >>>>> > >>>>> // Map RTMR 1 to PCRs 16, 17 and 18 > >>>>> echo 16-18 > /sys/kernel/config/tsm/rtmrs/rtmr1/tcg_map > >>>> Any information on how this mapping will be used by TPM or IMA ? > >>>> > >>>> RTMR to PCR mapping is fixed by design, right? If yes, why allow > >>>> user to configure it. We can let vendor drivers to configure it, right? > >>> I assume the "vendor driver", that publishes the RTMR to the tsm-core, > >>> has no idea whether they will be used for PCR emulation, or not. The TPM > >>> proxy layer sitting on top of this would know the mapping of which RTMRs > >>> are recording a transcript of which PCR extend events. > >> > >> My thinking is, since this mapping is ARCH-specific information > >> and fixed by design, it makes more sense to hide this detail in the > >> vendor driver than letting userspace configure it. If we allow users to > >> configure it, there is a chance for incorrect mapping. > > > > I think I agree with the fact that letting users configure that mapping > > may be error prone. But I'm not sure this is an architecture specific > > mapping, but rather a platform specific one. I'd expect the guest firmware > > to provide it through e.g. the MapPcrToMrIndex EFI CC protocol. > > > > So I agree I should remove the user interface for setting that mapping, > > and pass it from the provider capabilities instead. It is then up to the > > provider to choose how it'd build that information (hard coded, from > > EFI, etc). > > The UEFI specification has defined the mapping relationship between the > TDX RTMR and TPM PCRs (See https://uefi.org/specs/UEFI/2.10/38_Confidential_Computing.html#intel-trust-domain-extension). The current RTMR implementation in the boot loader > is “hooked” in the implementation for the TPM. > > When the bootloader needs to extend the PCR value, it calls > `map_pcr_to_mr_index` to retrieve the corresponding RTMR index and > then extends the RTMR. Considering this behavior, I don’t think we should > allow users to configure the mappings between the PCR and RTMR. (See https://github.com/rhboot/shim/pull/485/files <https://github.com/rhboot/shim/pull/485/files>). Just to be clear: I agree with that and I am going to send a v2 with that user interface removed. However I believe that we still need the TSM framework to know about these mappings and the question is where does the kernel get it from? You're suggesting that for TDX these mappings are architecturally defined, as described by the UEFI spec. For other architectures (CCA, CoVE) they are not (yet), so I'm suggesting to leave each TSM provider backend decide how the PCR to RTMR mapping should be built/fetched and provide it to the TSM framework through the tsm_capabilities structure that this patchset introduces. The TDX implementation could decide to hardcode it to the UEFI specification. Cheers, Samuel.
Hi Jiewen, On Mon, Jan 22, 2024 at 02:23:02AM +0000, Yao, Jiewen wrote: > Comment below: > > > -----Original Message----- > > From: Qinkun Bao <qinkun@google.com> > > Sent: Monday, January 22, 2024 10:13 AM > > To: Samuel Ortiz <sameo@rivosinc.com>; Yao, Jiewen <jiewen.yao@intel.com>; > > Lu, Ken <ken.lu@intel.com> > > Cc: Kuppuswamy Sathyanarayanan > > <sathyanarayanan.kuppuswamy@linux.intel.com>; Williams, Dan J > > <dan.j.williams@intel.com>; linux-coco@lists.linux.dev; linux- > > kernel@vger.kernel.org > > Subject: Re: [RFC PATCH v1 3/4] tsm: Allow for mapping RTMRs to TCG TPM PCRs > > > > > > > > > On Jan 21, 2024, at 8:31 AM, Samuel Ortiz <sameo@rivosinc.com> wrote: > > > > > > On Tue, Jan 16, 2024 at 07:35:30PM -0800, Kuppuswamy Sathyanarayanan > > wrote: > > >> > > >> On 1/16/24 5:24 PM, Dan Williams wrote: > > >>> Kuppuswamy Sathyanarayanan wrote: > > >>>> On 1/14/24 2:35 PM, Samuel Ortiz wrote: > > >>>>> Many user space and internal kernel subsystems (e.g. the Linux IMA) > > >>>>> expect a Root of Trust for Storage (RTS) that allows for extending > > >>>>> and reading measurement registers that are compatible with the TCG TPM > > >>>>> PCRs layout, e.g. a TPM. In order to allow those components to > > >>>>> alternatively use a platform TSM as their RTS, a TVM could map the > > >>>>> available RTMRs to one or more TCG TPM PCRs. Once configured, those > > PCR > > >>>>> to RTMR mappings give the kernel TSM layer all the necessary information > > >>>>> to be a RTS for e.g. the Linux IMA or any other components that expects > > >>>>> a TCG compliant TPM PCRs layout. > > >>>>> > > >>>>> TPM PCR mappings are configured through configfs: > > >>>>> > > >>>>> // Create and configure 2 RTMRs > > >>>>> mkdir /sys/kernel/config/tsm/rtmrs/rtmr0 > > >>>>> mkdir /sys/kernel/config/tsm/rtmrs/rtmr1 > > >>>>> echo 0 > /sys/kernel/config/tsm/rtmrs/rtmr0/index > > >>>>> echo 1 > /sys/kernel/config/tsm/rtmrs/rtmr1/index > > >>>>> > > >>>>> // Map RTMR 0 to PCRs 4, 5, 6, 7 and 8 > > >>>>> echo 4-8 > /sys/kernel/config/tsm/rtmrs/rtmr0/tcg_map > > >>>>> > > >>>>> // Map RTMR 1 to PCRs 16, 17 and 18 > > >>>>> echo 16-18 > /sys/kernel/config/tsm/rtmrs/rtmr1/tcg_map > > >>>> Any information on how this mapping will be used by TPM or IMA ? > > >>>> > > >>>> RTMR to PCR mapping is fixed by design, right? If yes, why allow > > >>>> user to configure it. We can let vendor drivers to configure it, right? > > >>> I assume the "vendor driver", that publishes the RTMR to the tsm-core, > > >>> has no idea whether they will be used for PCR emulation, or not. The TPM > > >>> proxy layer sitting on top of this would know the mapping of which RTMRs > > >>> are recording a transcript of which PCR extend events. > > >> > > >> My thinking is, since this mapping is ARCH-specific information > > >> and fixed by design, it makes more sense to hide this detail in the > > >> vendor driver than letting userspace configure it. If we allow users to > > >> configure it, there is a chance for incorrect mapping. > > > > > > I think I agree with the fact that letting users configure that mapping > > > may be error prone. But I'm not sure this is an architecture specific > > > mapping, but rather a platform specific one. I'd expect the guest firmware > > > to provide it through e.g. the MapPcrToMrIndex EFI CC protocol. > > > > > > So I agree I should remove the user interface for setting that mapping, > > > and pass it from the provider capabilities instead. It is then up to the > > > provider to choose how it'd build that information (hard coded, from > > > EFI, etc). > > > > The UEFI specification has defined the mapping relationship between the > > TDX RTMR and TPM PCRs (See > > https://uefi.org/specs/UEFI/2.10/38_Confidential_Computing.html#intel-trust- > > domain-extension). The current RTMR implementation in the boot loader > > is “hooked” in the implementation for the TPM. > > > > When the bootloader needs to extend the PCR value, it calls > > `map_pcr_to_mr_index` to retrieve the corresponding RTMR index and > > then extends the RTMR. Considering this behavior, I don’t think we should > > allow users to configure the mappings between the PCR and RTMR. (See > > https://github.com/rhboot/shim/pull/485/files). > > > > Add Jiewen (owner of the RTMR changes in the firmware) and Ken ( > > owner of the RTMR changes in the boot loader) for the visibility. > > I think the mapping should be static and determined by the hardware architecture. > > Allowing user to configure the mapping just adds complexity and confusing. For example, the user must understand clearly on what is Intel-TDX/AMD-SEV/ARM-CCA/RISCV-CoVE, how many registers they have, what is the best way to map it. > > It also adds complexity to the verifier. For example, the verifier must understand how a user configure the mapping, then get the expected measurement register value. > > I believe that hiding detail is a better way to avoid those complexity, and make it easy to use. I agree. > Do we have some real use cases that a user MUST configure the mapping? Not that I know of, and I will remove that userspace interface in v2 of this patchset. Cheers, Samuel.
On 1/21/24 11:46 PM, Samuel Ortiz wrote: > On Sun, Jan 21, 2024 at 06:09:19PM -0800, Qinkun Bao wrote: >> >>> On Jan 21, 2024, at 8:31 AM, Samuel Ortiz <sameo@rivosinc.com> wrote: >>> >>> On Tue, Jan 16, 2024 at 07:35:30PM -0800, Kuppuswamy Sathyanarayanan wrote: >>>> On 1/16/24 5:24 PM, Dan Williams wrote: >>>>> Kuppuswamy Sathyanarayanan wrote: >>>>>> On 1/14/24 2:35 PM, Samuel Ortiz wrote: >>>>>>> Many user space and internal kernel subsystems (e.g. the Linux IMA) >>>>>>> expect a Root of Trust for Storage (RTS) that allows for extending >>>>>>> and reading measurement registers that are compatible with the TCG TPM >>>>>>> PCRs layout, e.g. a TPM. In order to allow those components to >>>>>>> alternatively use a platform TSM as their RTS, a TVM could map the >>>>>>> available RTMRs to one or more TCG TPM PCRs. Once configured, those PCR >>>>>>> to RTMR mappings give the kernel TSM layer all the necessary information >>>>>>> to be a RTS for e.g. the Linux IMA or any other components that expects >>>>>>> a TCG compliant TPM PCRs layout. >>>>>>> >>>>>>> TPM PCR mappings are configured through configfs: >>>>>>> >>>>>>> // Create and configure 2 RTMRs >>>>>>> mkdir /sys/kernel/config/tsm/rtmrs/rtmr0 >>>>>>> mkdir /sys/kernel/config/tsm/rtmrs/rtmr1 >>>>>>> echo 0 > /sys/kernel/config/tsm/rtmrs/rtmr0/index >>>>>>> echo 1 > /sys/kernel/config/tsm/rtmrs/rtmr1/index >>>>>>> >>>>>>> // Map RTMR 0 to PCRs 4, 5, 6, 7 and 8 >>>>>>> echo 4-8 > /sys/kernel/config/tsm/rtmrs/rtmr0/tcg_map >>>>>>> >>>>>>> // Map RTMR 1 to PCRs 16, 17 and 18 >>>>>>> echo 16-18 > /sys/kernel/config/tsm/rtmrs/rtmr1/tcg_map >>>>>> Any information on how this mapping will be used by TPM or IMA ? >>>>>> >>>>>> RTMR to PCR mapping is fixed by design, right? If yes, why allow >>>>>> user to configure it. We can let vendor drivers to configure it, right? >>>>> I assume the "vendor driver", that publishes the RTMR to the tsm-core, >>>>> has no idea whether they will be used for PCR emulation, or not. The TPM >>>>> proxy layer sitting on top of this would know the mapping of which RTMRs >>>>> are recording a transcript of which PCR extend events. >>>> My thinking is, since this mapping is ARCH-specific information >>>> and fixed by design, it makes more sense to hide this detail in the >>>> vendor driver than letting userspace configure it. If we allow users to >>>> configure it, there is a chance for incorrect mapping. >>> I think I agree with the fact that letting users configure that mapping >>> may be error prone. But I'm not sure this is an architecture specific >>> mapping, but rather a platform specific one. I'd expect the guest firmware >>> to provide it through e.g. the MapPcrToMrIndex EFI CC protocol. >>> >>> So I agree I should remove the user interface for setting that mapping, >>> and pass it from the provider capabilities instead. It is then up to the >>> provider to choose how it'd build that information (hard coded, from >>> EFI, etc). >> The UEFI specification has defined the mapping relationship between the >> TDX RTMR and TPM PCRs (See https://uefi.org/specs/UEFI/2.10/38_Confidential_Computing.html#intel-trust-domain-extension). The current RTMR implementation in the boot loader >> is “hooked” in the implementation for the TPM. >> >> When the bootloader needs to extend the PCR value, it calls >> `map_pcr_to_mr_index` to retrieve the corresponding RTMR index and >> then extends the RTMR. Considering this behavior, I don’t think we should >> allow users to configure the mappings between the PCR and RTMR. (See https://github.com/rhboot/shim/pull/485/files <https://github.com/rhboot/shim/pull/485/files>). > Just to be clear: I agree with that and I am going to send a v2 with > that user interface removed. > However I believe that we still need the TSM framework to know about > these mappings and the question is where does the kernel get it from? > > You're suggesting that for TDX these mappings are architecturally > defined, as described by the UEFI spec. For other architectures (CCA, > CoVE) they are not (yet), so I'm suggesting to leave each TSM provider > backend decide how the PCR to RTMR mapping should be built/fetched and > provide it to the TSM framework through the tsm_capabilities structure > that this patchset introduces. The TDX implementation could decide to > hardcode it to the UEFI specification. Agree. Lets leave it to TSM vendor drivers to provide this mapping. > Cheers, > Samuel.
Yao, Jiewen wrote: > Comment below: > > > -----Original Message----- > > From: Qinkun Bao <qinkun@google.com> > > Sent: Monday, January 22, 2024 10:13 AM > > To: Samuel Ortiz <sameo@rivosinc.com>; Yao, Jiewen <jiewen.yao@intel.com>; > > Lu, Ken <ken.lu@intel.com> > > Cc: Kuppuswamy Sathyanarayanan > > <sathyanarayanan.kuppuswamy@linux.intel.com>; Williams, Dan J > > <dan.j.williams@intel.com>; linux-coco@lists.linux.dev; linux- > > kernel@vger.kernel.org > > Subject: Re: [RFC PATCH v1 3/4] tsm: Allow for mapping RTMRs to TCG TPM PCRs > > > > > > > > > On Jan 21, 2024, at 8:31 AM, Samuel Ortiz <sameo@rivosinc.com> wrote: > > > > > > On Tue, Jan 16, 2024 at 07:35:30PM -0800, Kuppuswamy Sathyanarayanan > > wrote: > > >> > > >> On 1/16/24 5:24 PM, Dan Williams wrote: > > >>> Kuppuswamy Sathyanarayanan wrote: > > >>>> On 1/14/24 2:35 PM, Samuel Ortiz wrote: > > >>>>> Many user space and internal kernel subsystems (e.g. the Linux IMA) > > >>>>> expect a Root of Trust for Storage (RTS) that allows for extending > > >>>>> and reading measurement registers that are compatible with the TCG TPM > > >>>>> PCRs layout, e.g. a TPM. In order to allow those components to > > >>>>> alternatively use a platform TSM as their RTS, a TVM could map the > > >>>>> available RTMRs to one or more TCG TPM PCRs. Once configured, those > > PCR > > >>>>> to RTMR mappings give the kernel TSM layer all the necessary information > > >>>>> to be a RTS for e.g. the Linux IMA or any other components that expects > > >>>>> a TCG compliant TPM PCRs layout. > > >>>>> > > >>>>> TPM PCR mappings are configured through configfs: > > >>>>> > > >>>>> // Create and configure 2 RTMRs > > >>>>> mkdir /sys/kernel/config/tsm/rtmrs/rtmr0 > > >>>>> mkdir /sys/kernel/config/tsm/rtmrs/rtmr1 > > >>>>> echo 0 > /sys/kernel/config/tsm/rtmrs/rtmr0/index > > >>>>> echo 1 > /sys/kernel/config/tsm/rtmrs/rtmr1/index > > >>>>> > > >>>>> // Map RTMR 0 to PCRs 4, 5, 6, 7 and 8 > > >>>>> echo 4-8 > /sys/kernel/config/tsm/rtmrs/rtmr0/tcg_map > > >>>>> > > >>>>> // Map RTMR 1 to PCRs 16, 17 and 18 > > >>>>> echo 16-18 > /sys/kernel/config/tsm/rtmrs/rtmr1/tcg_map > > >>>> Any information on how this mapping will be used by TPM or IMA ? > > >>>> > > >>>> RTMR to PCR mapping is fixed by design, right? If yes, why allow > > >>>> user to configure it. We can let vendor drivers to configure it, right? > > >>> I assume the "vendor driver", that publishes the RTMR to the tsm-core, > > >>> has no idea whether they will be used for PCR emulation, or not. The TPM > > >>> proxy layer sitting on top of this would know the mapping of which RTMRs > > >>> are recording a transcript of which PCR extend events. > > >> > > >> My thinking is, since this mapping is ARCH-specific information > > >> and fixed by design, it makes more sense to hide this detail in the > > >> vendor driver than letting userspace configure it. If we allow users to > > >> configure it, there is a chance for incorrect mapping. > > > > > > I think I agree with the fact that letting users configure that mapping > > > may be error prone. But I'm not sure this is an architecture specific > > > mapping, but rather a platform specific one. I'd expect the guest firmware > > > to provide it through e.g. the MapPcrToMrIndex EFI CC protocol. > > > > > > So I agree I should remove the user interface for setting that mapping, > > > and pass it from the provider capabilities instead. It is then up to the > > > provider to choose how it'd build that information (hard coded, from > > > EFI, etc). > > > > The UEFI specification has defined the mapping relationship between the > > TDX RTMR and TPM PCRs (See > > https://uefi.org/specs/UEFI/2.10/38_Confidential_Computing.html#intel-trust- > > domain-extension). The current RTMR implementation in the boot loader > > is “hooked” in the implementation for the TPM. > > > > When the bootloader needs to extend the PCR value, it calls > > `map_pcr_to_mr_index` to retrieve the corresponding RTMR index and > > then extends the RTMR. Considering this behavior, I don’t think we should > > allow users to configure the mappings between the PCR and RTMR. (See > > https://github.com/rhboot/shim/pull/485/files). > > > > Add Jiewen (owner of the RTMR changes in the firmware) and Ken ( > > owner of the RTMR changes in the boot loader) for the visibility. > > I think the mapping should be static and determined by the hardware architecture. > > Allowing user to configure the mapping just adds complexity and > confusing. For example, the user must understand clearly on what is > Intel-TDX/AMD-SEV/ARM-CCA/RISCV-CoVE, how many registers they have, > what is the best way to map it. > > It also adds complexity to the verifier. For example, the verifier > must understand how a user configure the mapping, then get the > expected measurement register value. I agree with this, what I have a problem with is that this: https://uefi.org/specs/UEFI/2.10/38_Confidential_Computing.html#intel-trust-domain-extension ..is vendor specific, especially when the kernel enabling is being targeted as cross-vendor. So, yes, the mapping should be allowed to specified by the low-level driver, but at the same time every vendor should not reinvent their own enumeration method when we have EFI for that. In other words Linux should enforce unification across vendors and consider waiting until the RTMR enumeration is promoted out of the vendor specific section to a cross vendor standard.
On 1/22/2024 12:10 PM, Dan Williams wrote: > Yao, Jiewen wrote: >> Comment below: >> >>> -----Original Message----- >>> From: Qinkun Bao <qinkun@google.com> >>> Sent: Monday, January 22, 2024 10:13 AM >>> To: Samuel Ortiz <sameo@rivosinc.com>; Yao, Jiewen <jiewen.yao@intel.com>; >>> Lu, Ken <ken.lu@intel.com> >>> Cc: Kuppuswamy Sathyanarayanan >>> <sathyanarayanan.kuppuswamy@linux.intel.com>; Williams, Dan J >>> <dan.j.williams@intel.com>; linux-coco@lists.linux.dev; linux- >>> kernel@vger.kernel.org >>> Subject: Re: [RFC PATCH v1 3/4] tsm: Allow for mapping RTMRs to TCG TPM PCRs >>> >>> >>> >>>> On Jan 21, 2024, at 8:31 AM, Samuel Ortiz <sameo@rivosinc.com> wrote: >>>> >>>> On Tue, Jan 16, 2024 at 07:35:30PM -0800, Kuppuswamy Sathyanarayanan >>> wrote: >>>>> >>>>> On 1/16/24 5:24 PM, Dan Williams wrote: >>>>>> Kuppuswamy Sathyanarayanan wrote: >>>>>>> On 1/14/24 2:35 PM, Samuel Ortiz wrote: >>>>>>>> Many user space and internal kernel subsystems (e.g. the Linux IMA) >>>>>>>> expect a Root of Trust for Storage (RTS) that allows for extending >>>>>>>> and reading measurement registers that are compatible with the TCG TPM >>>>>>>> PCRs layout, e.g. a TPM. In order to allow those components to >>>>>>>> alternatively use a platform TSM as their RTS, a TVM could map the >>>>>>>> available RTMRs to one or more TCG TPM PCRs. Once configured, those >>> PCR >>>>>>>> to RTMR mappings give the kernel TSM layer all the necessary information >>>>>>>> to be a RTS for e.g. the Linux IMA or any other components that expects >>>>>>>> a TCG compliant TPM PCRs layout. >>>>>>>> >>>>>>>> TPM PCR mappings are configured through configfs: >>>>>>>> >>>>>>>> // Create and configure 2 RTMRs >>>>>>>> mkdir /sys/kernel/config/tsm/rtmrs/rtmr0 >>>>>>>> mkdir /sys/kernel/config/tsm/rtmrs/rtmr1 >>>>>>>> echo 0 > /sys/kernel/config/tsm/rtmrs/rtmr0/index >>>>>>>> echo 1 > /sys/kernel/config/tsm/rtmrs/rtmr1/index >>>>>>>> >>>>>>>> // Map RTMR 0 to PCRs 4, 5, 6, 7 and 8 >>>>>>>> echo 4-8 > /sys/kernel/config/tsm/rtmrs/rtmr0/tcg_map >>>>>>>> >>>>>>>> // Map RTMR 1 to PCRs 16, 17 and 18 >>>>>>>> echo 16-18 > /sys/kernel/config/tsm/rtmrs/rtmr1/tcg_map >>>>>>> Any information on how this mapping will be used by TPM or IMA ? >>>>>>> >>>>>>> RTMR to PCR mapping is fixed by design, right? If yes, why allow >>>>>>> user to configure it. We can let vendor drivers to configure it, right? >>>>>> I assume the "vendor driver", that publishes the RTMR to the tsm-core, >>>>>> has no idea whether they will be used for PCR emulation, or not. The TPM >>>>>> proxy layer sitting on top of this would know the mapping of which RTMRs >>>>>> are recording a transcript of which PCR extend events. >>>>> >>>>> My thinking is, since this mapping is ARCH-specific information >>>>> and fixed by design, it makes more sense to hide this detail in the >>>>> vendor driver than letting userspace configure it. If we allow users to >>>>> configure it, there is a chance for incorrect mapping. >>>> >>>> I think I agree with the fact that letting users configure that mapping >>>> may be error prone. But I'm not sure this is an architecture specific >>>> mapping, but rather a platform specific one. I'd expect the guest firmware >>>> to provide it through e.g. the MapPcrToMrIndex EFI CC protocol. >>>> >>>> So I agree I should remove the user interface for setting that mapping, >>>> and pass it from the provider capabilities instead. It is then up to the >>>> provider to choose how it'd build that information (hard coded, from >>>> EFI, etc). >>> >>> The UEFI specification has defined the mapping relationship between the >>> TDX RTMR and TPM PCRs (See >>> https://uefi.org/specs/UEFI/2.10/38_Confidential_Computing.html#intel-trust- >>> domain-extension). The current RTMR implementation in the boot loader >>> is “hooked” in the implementation for the TPM. >>> >>> When the bootloader needs to extend the PCR value, it calls >>> `map_pcr_to_mr_index` to retrieve the corresponding RTMR index and >>> then extends the RTMR. Considering this behavior, I don’t think we should >>> allow users to configure the mappings between the PCR and RTMR. (See >>> https://github.com/rhboot/shim/pull/485/files). >>> >>> Add Jiewen (owner of the RTMR changes in the firmware) and Ken ( >>> owner of the RTMR changes in the boot loader) for the visibility. >> >> I think the mapping should be static and determined by the hardware architecture. >> >> Allowing user to configure the mapping just adds complexity and >> confusing. For example, the user must understand clearly on what is >> Intel-TDX/AMD-SEV/ARM-CCA/RISCV-CoVE, how many registers they have, >> what is the best way to map it. >> >> It also adds complexity to the verifier. For example, the verifier >> must understand how a user configure the mapping, then get the >> expected measurement register value. > > I agree with this, what I have a problem with is that this: > > https://uefi.org/specs/UEFI/2.10/38_Confidential_Computing.html#intel-trust-domain-extension > > ...is vendor specific, especially when the kernel enabling is being > targeted as cross-vendor. > I have the same concern. > So, yes, the mapping should be allowed to specified by the low-level > driver, but at the same time every vendor should not reinvent their own > enumeration method when we have EFI for that. > Given PCR->RTMR mapping is static, I just wonder why it needs to be kept in kernel. Given that PCRs can never be 1:1 mapped to RTMRs, and that TDX quotes are never TPM quotes, applications used to extend PCRs would have to be changed/recompiled. Then wouldn't it suffice to define the mappings as macros in an architecture specific header file?
On 1/21/24 8:31 AM, Samuel Ortiz wrote: > On Tue, Jan 16, 2024 at 07:35:30PM -0800, Kuppuswamy Sathyanarayanan wrote: >> On 1/16/24 5:24 PM, Dan Williams wrote: >>> Kuppuswamy Sathyanarayanan wrote: >>>> On 1/14/24 2:35 PM, Samuel Ortiz wrote: >>>>> Many user space and internal kernel subsystems (e.g. the Linux IMA) >>>>> expect a Root of Trust for Storage (RTS) that allows for extending >>>>> and reading measurement registers that are compatible with the TCG TPM >>>>> PCRs layout, e.g. a TPM. In order to allow those components to >>>>> alternatively use a platform TSM as their RTS, a TVM could map the >>>>> available RTMRs to one or more TCG TPM PCRs. Once configured, those PCR >>>>> to RTMR mappings give the kernel TSM layer all the necessary information >>>>> to be a RTS for e.g. the Linux IMA or any other components that expects >>>>> a TCG compliant TPM PCRs layout. >>>>> >>>>> TPM PCR mappings are configured through configfs: >>>>> >>>>> // Create and configure 2 RTMRs >>>>> mkdir /sys/kernel/config/tsm/rtmrs/rtmr0 >>>>> mkdir /sys/kernel/config/tsm/rtmrs/rtmr1 >>>>> echo 0 > /sys/kernel/config/tsm/rtmrs/rtmr0/index >>>>> echo 1 > /sys/kernel/config/tsm/rtmrs/rtmr1/index >>>>> >>>>> // Map RTMR 0 to PCRs 4, 5, 6, 7 and 8 >>>>> echo 4-8 > /sys/kernel/config/tsm/rtmrs/rtmr0/tcg_map >>>>> >>>>> // Map RTMR 1 to PCRs 16, 17 and 18 >>>>> echo 16-18 > /sys/kernel/config/tsm/rtmrs/rtmr1/tcg_map >>>> Any information on how this mapping will be used by TPM or IMA ? >>>> >>>> RTMR to PCR mapping is fixed by design, right? If yes, why allow >>>> user to configure it. We can let vendor drivers to configure it, right? >>> I assume the "vendor driver", that publishes the RTMR to the tsm-core, >>> has no idea whether they will be used for PCR emulation, or not. The TPM >>> proxy layer sitting on top of this would know the mapping of which RTMRs >>> are recording a transcript of which PCR extend events. >> My thinking is, since this mapping is ARCH-specific information >> and fixed by design, it makes more sense to hide this detail in the >> vendor driver than letting userspace configure it. If we allow users to >> configure it, there is a chance for incorrect mapping. > I think I agree with the fact that letting users configure that mapping > may be error prone. But I'm not sure this is an architecture specific > mapping, but rather a platform specific one. I'd expect the guest firmware > to provide it through e.g. the MapPcrToMrIndex EFI CC protocol. > > So I agree I should remove the user interface for setting that mapping, > and pass it from the provider capabilities instead. It is then up to the > provider to choose how it'd build that information (hard coded, from > EFI, etc). > >> Regarding the TPM proxy, I am still not clear how it is going to use >> this mapping. If we want to provide TPM like feature, it needs a >> special kernel TPM driver, right? Even if we enable TPM support >> with RTMR, I assume it can only support pcr_extend(). > Extend and read, yes. > >> Other TPM >> features should be disabled. If yes, since we already have this ABI >> for measurement extension, why again support it via TPM or did >> I misunderstand the use case. > I am not sure the TPM compatibility is always needed, but for subsystems > (like e.g. IMA) that look for a TPM as their root of trust for storage, > providing the extend+read ABI and the PCR mapping should be sufficient. My question is, do we even want to expose the PCR-RTMR mapping to the user? Even if we want to support IMA with RTMR, I think the mapping needs to be done in the kernel and the userspace does not need to worry about it. > Cheers, > Samuel. >
Xing, Cedric wrote: [..] > > So, yes, the mapping should be allowed to specified by the low-level > > driver, but at the same time every vendor should not reinvent their own > > enumeration method when we have EFI for that. > > Given PCR->RTMR mapping is static, I just wonder why it needs to be kept > in kernel. Given that PCRs can never be 1:1 mapped to RTMRs, and that > TDX quotes are never TPM quotes, applications used to extend PCRs would > have to be changed/recompiled. Then wouldn't it suffice to define the > mappings as macros in an architecture specific header file? I think something is wrong if applications are exposed to the PCR->RTMR mapping thrash. I would hope / expect that detail is hidden behind a TPM proxy layer sitting in front of this mapping on behalf of TPM-client applications.
> -----Original Message----- > From: Xing, Cedric <cedric.xing@intel.com> > Sent: Tuesday, January 23, 2024 5:59 AM > To: Williams, Dan J <dan.j.williams@intel.com>; Yao, Jiewen > <jiewen.yao@intel.com>; Qinkun Bao <qinkun@google.com>; Samuel Ortiz > <sameo@rivosinc.com>; Lu, Ken <ken.lu@intel.com> > Cc: Kuppuswamy Sathyanarayanan > <sathyanarayanan.kuppuswamy@linux.intel.com>; linux-coco@lists.linux.dev; > linux-kernel@vger.kernel.org > Subject: Re: [RFC PATCH v1 3/4] tsm: Allow for mapping RTMRs to TCG TPM PCRs > > > > On 1/22/2024 12:10 PM, Dan Williams wrote: > > Yao, Jiewen wrote: > >> Comment below: > >> > >>> -----Original Message----- > >>> From: Qinkun Bao <qinkun@google.com> > >>> Sent: Monday, January 22, 2024 10:13 AM > >>> To: Samuel Ortiz <sameo@rivosinc.com>; Yao, Jiewen > <jiewen.yao@intel.com>; > >>> Lu, Ken <ken.lu@intel.com> > >>> Cc: Kuppuswamy Sathyanarayanan > >>> <sathyanarayanan.kuppuswamy@linux.intel.com>; Williams, Dan J > >>> <dan.j.williams@intel.com>; linux-coco@lists.linux.dev; linux- > >>> kernel@vger.kernel.org > >>> Subject: Re: [RFC PATCH v1 3/4] tsm: Allow for mapping RTMRs to TCG TPM > PCRs > >>> > >>> > >>> > >>>> On Jan 21, 2024, at 8:31 AM, Samuel Ortiz <sameo@rivosinc.com> wrote: > >>>> > >>>> On Tue, Jan 16, 2024 at 07:35:30PM -0800, Kuppuswamy Sathyanarayanan > >>> wrote: > >>>>> > >>>>> On 1/16/24 5:24 PM, Dan Williams wrote: > >>>>>> Kuppuswamy Sathyanarayanan wrote: > >>>>>>> On 1/14/24 2:35 PM, Samuel Ortiz wrote: > >>>>>>>> Many user space and internal kernel subsystems (e.g. the Linux IMA) > >>>>>>>> expect a Root of Trust for Storage (RTS) that allows for extending > >>>>>>>> and reading measurement registers that are compatible with the TCG > TPM > >>>>>>>> PCRs layout, e.g. a TPM. In order to allow those components to > >>>>>>>> alternatively use a platform TSM as their RTS, a TVM could map the > >>>>>>>> available RTMRs to one or more TCG TPM PCRs. Once configured, > those > >>> PCR > >>>>>>>> to RTMR mappings give the kernel TSM layer all the necessary > information > >>>>>>>> to be a RTS for e.g. the Linux IMA or any other components that > expects > >>>>>>>> a TCG compliant TPM PCRs layout. > >>>>>>>> > >>>>>>>> TPM PCR mappings are configured through configfs: > >>>>>>>> > >>>>>>>> // Create and configure 2 RTMRs > >>>>>>>> mkdir /sys/kernel/config/tsm/rtmrs/rtmr0 > >>>>>>>> mkdir /sys/kernel/config/tsm/rtmrs/rtmr1 > >>>>>>>> echo 0 > /sys/kernel/config/tsm/rtmrs/rtmr0/index > >>>>>>>> echo 1 > /sys/kernel/config/tsm/rtmrs/rtmr1/index > >>>>>>>> > >>>>>>>> // Map RTMR 0 to PCRs 4, 5, 6, 7 and 8 > >>>>>>>> echo 4-8 > /sys/kernel/config/tsm/rtmrs/rtmr0/tcg_map > >>>>>>>> > >>>>>>>> // Map RTMR 1 to PCRs 16, 17 and 18 > >>>>>>>> echo 16-18 > /sys/kernel/config/tsm/rtmrs/rtmr1/tcg_map > >>>>>>> Any information on how this mapping will be used by TPM or IMA ? > >>>>>>> > >>>>>>> RTMR to PCR mapping is fixed by design, right? If yes, why allow > >>>>>>> user to configure it. We can let vendor drivers to configure it, right? > >>>>>> I assume the "vendor driver", that publishes the RTMR to the tsm-core, > >>>>>> has no idea whether they will be used for PCR emulation, or not. The TPM > >>>>>> proxy layer sitting on top of this would know the mapping of which RTMRs > >>>>>> are recording a transcript of which PCR extend events. > >>>>> > >>>>> My thinking is, since this mapping is ARCH-specific information > >>>>> and fixed by design, it makes more sense to hide this detail in the > >>>>> vendor driver than letting userspace configure it. If we allow users to > >>>>> configure it, there is a chance for incorrect mapping. > >>>> > >>>> I think I agree with the fact that letting users configure that mapping > >>>> may be error prone. But I'm not sure this is an architecture specific > >>>> mapping, but rather a platform specific one. I'd expect the guest firmware > >>>> to provide it through e.g. the MapPcrToMrIndex EFI CC protocol. > >>>> > >>>> So I agree I should remove the user interface for setting that mapping, > >>>> and pass it from the provider capabilities instead. It is then up to the > >>>> provider to choose how it'd build that information (hard coded, from > >>>> EFI, etc). > >>> > >>> The UEFI specification has defined the mapping relationship between the > >>> TDX RTMR and TPM PCRs (See > >>> https://uefi.org/specs/UEFI/2.10/38_Confidential_Computing.html#intel- > trust- > >>> domain-extension). The current RTMR implementation in the boot loader > >>> is “hooked” in the implementation for the TPM. > >>> > >>> When the bootloader needs to extend the PCR value, it calls > >>> `map_pcr_to_mr_index` to retrieve the corresponding RTMR index and > >>> then extends the RTMR. Considering this behavior, I don’t think we should > >>> allow users to configure the mappings between the PCR and RTMR. (See > >>> https://github.com/rhboot/shim/pull/485/files). > >>> > >>> Add Jiewen (owner of the RTMR changes in the firmware) and Ken ( > >>> owner of the RTMR changes in the boot loader) for the visibility. > >> > >> I think the mapping should be static and determined by the hardware > architecture. > >> > >> Allowing user to configure the mapping just adds complexity and > >> confusing. For example, the user must understand clearly on what is > >> Intel-TDX/AMD-SEV/ARM-CCA/RISCV-CoVE, how many registers they have, > >> what is the best way to map it. > >> > >> It also adds complexity to the verifier. For example, the verifier > >> must understand how a user configure the mapping, then get the > >> expected measurement register value. > > > > I agree with this, what I have a problem with is that this: > > > > https://uefi.org/specs/UEFI/2.10/38_Confidential_Computing.html#intel-trust- > domain-extension > > > > ...is vendor specific, especially when the kernel enabling is being > > targeted as cross-vendor. > > > > I have the same concern. May I know what the definition of "targeted as cross-vendor"? And what exactly the concern or problem is? Please enlighten me on that. > > > So, yes, the mapping should be allowed to specified by the low-level > > driver, but at the same time every vendor should not reinvent their own > > enumeration method when we have EFI for that. > > > > Given PCR->RTMR mapping is static, I just wonder why it needs to be kept > in kernel. Given that PCRs can never be 1:1 mapped to RTMRs, and that > TDX quotes are never TPM quotes, applications used to extend PCRs would > have to be changed/recompiled. Then wouldn't it suffice to define the > mappings as macros in an architecture specific header file? My comment is "Please don’t let user application (ring 3) indicate the mapping". It will cause big problem if different user applications use different mapping. I see no benefit but confusion. I have no comment on how kernel module (ring 0) indicates the mapping. It can be static in kernel or by a driver. I don’t have strong opinion here.
On 1/22/2024 2:32 PM, Dan Williams wrote: > Xing, Cedric wrote: > [..] >>> So, yes, the mapping should be allowed to specified by the low-level >>> driver, but at the same time every vendor should not reinvent their own >>> enumeration method when we have EFI for that. >> >> Given PCR->RTMR mapping is static, I just wonder why it needs to be kept >> in kernel. Given that PCRs can never be 1:1 mapped to RTMRs, and that >> TDX quotes are never TPM quotes, applications used to extend PCRs would >> have to be changed/recompiled. Then wouldn't it suffice to define the >> mappings as macros in an architecture specific header file? > > I think something is wrong if applications are exposed to the PCR->RTMR > mapping thrash. I would hope / expect that detail is hidden behind a TPM > proxy layer sitting in front of this mapping on behalf of TPM-client > applications. Hi Dan, My apology for the confusion! I think we are talking about 2 different scenarios - (1) this patch alone; and (2) this patch + vTPM. Scenario 1: This patch provides RTMR access only. My assumption is, there are existing application (and/or kernel modules) that extend to PCRs today and would like to work in TDs where only RTMRs are available. Changes are of course necessary in those applications as TPMs/PCRs are no longer available, but from security perspective they would like to keep the same activity log and just change to use RTMRs (in lieu of PCRs) as the secure storage. Hence a PCR->RTMR mapping is necessary and must be agreed upon by all those applications and relying parties. IIUC, this is the intention of having PCR->RTMR mapping config maintained by the kernel, as proposed by Sam O. originally. Scenario 2: A vTPM is implemented on top of this patch, in which case the existing applications don't have to change as they can continue extending to the same PCRs, which will then be emulated by the underlying vTPM implementation. PCR->RTMR mapping in this scenario is obviously internal to the vTPM and I agree with you completely that it should be hidden inside the vTPM. My comment in my previous email was regarding Scenario 1. I hope the clarification above helps. -Cedric
Xing, Cedric wrote: > On 1/22/2024 2:32 PM, Dan Williams wrote: > > Xing, Cedric wrote: > > [..] > >>> So, yes, the mapping should be allowed to specified by the low-level > >>> driver, but at the same time every vendor should not reinvent their own > >>> enumeration method when we have EFI for that. > >> > >> Given PCR->RTMR mapping is static, I just wonder why it needs to be kept > >> in kernel. Given that PCRs can never be 1:1 mapped to RTMRs, and that > >> TDX quotes are never TPM quotes, applications used to extend PCRs would > >> have to be changed/recompiled. Then wouldn't it suffice to define the > >> mappings as macros in an architecture specific header file? > > > > I think something is wrong if applications are exposed to the PCR->RTMR > > mapping thrash. I would hope / expect that detail is hidden behind a TPM > > proxy layer sitting in front of this mapping on behalf of TPM-client > > applications. > > Hi Dan, > > My apology for the confusion! I think we are talking about 2 different > scenarios - (1) this patch alone; and (2) this patch + vTPM. > > Scenario 1: This patch provides RTMR access only. My assumption is, > there are existing application (and/or kernel modules) that extend to > PCRs today and would like to work in TDs where only RTMRs are available. > Changes are of course necessary in those applications as TPMs/PCRs are > no longer available, but from security perspective they would like to > keep the same activity log and just change to use RTMRs (in lieu of > PCRs) as the secure storage. Hence a PCR->RTMR mapping is necessary and > must be agreed upon by all those applications and relying parties. IIUC, > this is the intention of having PCR->RTMR mapping config maintained by > the kernel, as proposed by Sam O. originally. > > Scenario 2: A vTPM is implemented on top of this patch, in which case > the existing applications don't have to change as they can continue > extending to the same PCRs, which will then be emulated by the > underlying vTPM implementation. PCR->RTMR mapping in this scenario is > obviously internal to the vTPM and I agree with you completely that it > should be hidden inside the vTPM. > > My comment in my previous email was regarding Scenario 1. I hope the > clarification above helps. Got it, yes, makes sense. I think the only use cases in scenario 1 are either kernel internal or the backend of the vTPM implementation. Even though RTMR is cross-platform it is not universal, so vTPM remains the universal solution for most applications.
On 1/23/24 10:48 AM, Xing, Cedric wrote: > On 1/22/2024 2:32 PM, Dan Williams wrote: >> Xing, Cedric wrote: >> [..] >>>> So, yes, the mapping should be allowed to specified by the low-level >>>> driver, but at the same time every vendor should not reinvent their own >>>> enumeration method when we have EFI for that. >>> >>> Given PCR->RTMR mapping is static, I just wonder why it needs to be kept >>> in kernel. Given that PCRs can never be 1:1 mapped to RTMRs, and that >>> TDX quotes are never TPM quotes, applications used to extend PCRs would >>> have to be changed/recompiled. Then wouldn't it suffice to define the >>> mappings as macros in an architecture specific header file? >> >> I think something is wrong if applications are exposed to the PCR->RTMR >> mapping thrash. I would hope / expect that detail is hidden behind a TPM >> proxy layer sitting in front of this mapping on behalf of TPM-client >> applications. > > Hi Dan, > > My apology for the confusion! I think we are talking about 2 different scenarios - (1) this patch alone; and (2) this patch + vTPM. > > Scenario 1: This patch provides RTMR access only. My assumption is, there are existing application (and/or kernel modules) that extend to PCRs today and would like to work in TDs where only RTMRs are available. Changes are of course necessary in those applications as TPMs/PCRs are no longer available, but from security perspective they would like to keep the same activity log and just change to use RTMRs (in lieu of PCRs) as the secure storage. Hence a PCR->RTMR mapping is necessary and must be agreed upon by all those applications and relying parties. IIUC, this is the intention of having PCR->RTMR mapping config maintained by the kernel, as proposed by Sam O. originally. > > Scenario 2: A vTPM is implemented on top of this patch, in which case the existing applications don't have to change as they can continue extending to the same PCRs, which will then be emulated by the underlying vTPM implementation. PCR->RTMR mapping in this scenario is obviously internal to the vTPM and I agree with you completely that it should be hidden inside the vTPM. > > My comment in my previous email was regarding Scenario 1. I hope the clarification above helps. IMO, we should adapt an approach with as minimal user changes as possible. So I think we should try to avoid scenario 1 if possible. > > -Cedric >
diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c index 15b67d99fd54..f35f91cb7bd3 100644 --- a/drivers/virt/coco/tsm.c +++ b/drivers/virt/coco/tsm.c @@ -472,8 +472,68 @@ static ssize_t tsm_rtmr_index_show(struct config_item *cfg, } CONFIGFS_ATTR(tsm_rtmr_, index); +static ssize_t tsm_rtmr_tcg_map_store(struct config_item *cfg, + const char *buf, size_t len) +{ + struct tsm_rtmr_state *rtmr_state = to_tsm_rtmr_state(cfg); + int i, pcrs[TPM2_PLATFORM_PCR + 1]; + + get_options(buf, ARRAY_SIZE(pcrs), pcrs); + + if (pcrs[0] > TPM2_PLATFORM_PCR - 1) + return -EINVAL; + + guard(rwsem_write)(&tsm_rwsem); + /* Check that the PCR list is valid */ + for (i = 0; i < pcrs[0]; i++) { + /* It must be a valid TPM2 PCR number */ + if (pcrs[i] > TPM2_PLATFORM_PCR - 1) + return -EINVAL; + + /* If another RTMR maps to this PCR, the list is discarded */ + if (tsm_rtmrs->tcg_map[pcrs[i + 1]] && + tsm_rtmrs->tcg_map[pcrs[i + 1]] != rtmr_state) + return -EBUSY; + } + + for (i = 0; i < pcrs[0]; i++) + tsm_rtmrs->tcg_map[pcrs[i + 1]] = rtmr_state; + + return len; +} + +static ssize_t tsm_rtmr_tcg_map_show(struct config_item *cfg, + char *buf) +{ + struct tsm_rtmr_state *rtmr_state = to_tsm_rtmr_state(cfg); + unsigned int nr_pcrs = ARRAY_SIZE(tsm_rtmrs->tcg_map), i; + unsigned long *pcr_mask; + ssize_t len; + + /* Build a bitmap mask of all PCRs that this RTMR covers */ + pcr_mask = bitmap_zalloc(nr_pcrs, GFP_KERNEL); + if (!pcr_mask) + return -ENOMEM; + + guard(rwsem_read)(&tsm_rwsem); + for (i = 0; i < nr_pcrs; i++) { + if (tsm_rtmrs->tcg_map[i] != rtmr_state) + continue; + + __set_bit(i, pcr_mask); + } + + len = bitmap_print_list_to_buf(buf, pcr_mask, nr_pcrs, 0, + nr_pcrs * 3 /* 2 ASCII digits and one comma */); + bitmap_free(pcr_mask); + + return len; +} +CONFIGFS_ATTR(tsm_rtmr_, tcg_map); + static struct configfs_attribute *tsm_rtmr_attrs[] = { &tsm_rtmr_attr_index, + &tsm_rtmr_attr_tcg_map, NULL, };