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(-)
--
2.42.0
Some confidential computing architecture (Intel TDX, ARM-CCA, RISC-V
CoVE) provide the TVM (confidential computing guest) with a set of
runtime measurement registers (RTMR). TVMs can extend those registers
with their measurements at runtime, i.e. after the TVM initial
measurements are finalized and the TVM actually runs.
RTMRs are separated from the initial measurement registers set, and TSMs
typically includes RTMR values into a distinct section of their signed
attestion reports.
We add support for extending and reading a TSM runtime measurement
registers by extending the TSM ops structure with resp. an rtmr_extend()
and an rtmr_read() function pointers. TSM providers/backends will
implement those ops if they are capable of exposing RTMRs to their
TVMs. This capability is now described by a tsm_capabilites structure,
passed by the TSM provider to the TSM framework at registration time.
TVMs can configure, extend and read RTMRs from the configfs-tsm interface.
Signed-off-by: Samuel Ortiz <[email protected]>
---
drivers/virt/coco/tsm.c | 80 +++++++++++++++++++++++++++++++++++++++++
include/linux/tsm.h | 28 ++++++++++++++-
2 files changed, 107 insertions(+), 1 deletion(-)
diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
index d1c2db83a8ca..6b71650271fe 100644
--- a/drivers/virt/coco/tsm.c
+++ b/drivers/virt/coco/tsm.c
@@ -11,6 +11,7 @@
#include <linux/module.h>
#include <linux/cleanup.h>
#include <linux/configfs.h>
+#include <linux/tpm.h>
static struct tsm_provider {
const struct tsm_ops *ops;
@@ -50,6 +51,85 @@ enum tsm_data_select {
TSM_CERTS,
};
+/**
+ * DOC: Trusted Security Module (TSM) Runtime Measurement Register (RTMR) Interface
+ *
+ * The TSM RTMR interface is a common ABI for allowing TVMs to extend
+ * and read measurement registers at runtime, i.e. after the TVM initial
+ * measurement is finalized. TSMs that support such capability will typically
+ * include all runtime measurement registers values into their signed
+ * attestation report, providing the TVM post-boot measurements to e.g. remote
+ * attestation services.
+ *
+ * A TVM uses the TSM RTMR configfs ABI to create all runtime measurement
+ * registers (RTMR) that it needs. Each created RTMR must be configured first
+ * before being readable and extensible. TVM configures an RTMR by setting its
+ * index and optionally by mapping it to one or more TCG PCR indexes.
+ *
+ * A TSM backend statically declares the number of RTMRs it supports and which
+ * hash algorithm must be used when extending them. This declaration is done
+ * through the tsm_capabilities structure, at TSM registration time (see
+ * tsm_register()).
+ */
+
+/**
+ * struct tsm_rtmr_state - tracks the state of a TSM RTMR.
+ * @index: The RTMR hardware index.
+ * @alg: The hash algorithm used for this RTMR.
+ * @digest: The RTMR cached digest value.
+ * @cached_digest: Is the RTMR cached digest valid or not.
+ * @cfg: The configfs item for this RTMR.
+ */
+struct tsm_rtmr_state {
+ u32 index;
+ enum hash_algo alg;
+ u8 digest[TSM_DIGEST_MAX];
+ bool cached_digest;
+ struct config_item cfg;
+};
+
+static bool is_rtmr_configured(struct tsm_rtmr_state *rtmr_state)
+{
+ return rtmr_state->index != U32_MAX;
+}
+
+/**
+ * struct tsm_rtmrs_state - tracks the state of all RTMRs for a TSM.
+ * @rtmrs: The array of all created RTMRs.
+ * @tcg_map: A mapping between TCG PCR and RTMRs, indexed by PCR indexes.
+ * Entry `i` on this map points to an RTMR that covers TCG PCR[i] for the TSM
+ * hash algorithm.
+ * @group: The configfs group for a TSM RTMRs.
+ */
+static struct tsm_rtmrs_state {
+ struct tsm_rtmr_state **rtmrs;
+ struct tsm_rtmr_state *tcg_map[TPM2_PLATFORM_PCR];
+ struct config_group *group;
+} *tsm_rtmrs;
+
+static int tsm_rtmr_read(struct tsm_provider *tsm, u32 idx,
+ u8 *digest, size_t digest_size)
+{
+ if (tsm->ops && tsm->ops->rtmr_read)
+ return tsm->ops->rtmr_read(idx, digest, digest_size);
+
+ return -ENXIO;
+}
+
+static int tsm_rtmr_extend(struct tsm_provider *tsm, u32 idx,
+ const u8 *digest, size_t digest_size)
+{
+ if (tsm->ops && tsm->ops->rtmr_extend)
+ return tsm->ops->rtmr_extend(idx, digest, digest_size);
+
+ return -ENXIO;
+}
+
+static struct tsm_rtmr_state *to_tsm_rtmr_state(struct config_item *cfg)
+{
+ return container_of(cfg, struct tsm_rtmr_state, cfg);
+}
+
static struct tsm_report *to_tsm_report(struct config_item *cfg)
{
struct tsm_report_state *state =
diff --git a/include/linux/tsm.h b/include/linux/tsm.h
index de8324a2223c..e912cd665684 100644
--- a/include/linux/tsm.h
+++ b/include/linux/tsm.h
@@ -2,11 +2,13 @@
#ifndef __TSM_H
#define __TSM_H
+#include <crypto/hash_info.h>
#include <linux/sizes.h>
#include <linux/types.h>
#define TSM_INBLOB_MAX 64
#define TSM_OUTBLOB_MAX SZ_32K
+#define TSM_DIGEST_MAX SHA512_DIGEST_SIZE
/*
* Privilege level is a nested permission concept to allow confidential
@@ -42,12 +44,33 @@ struct tsm_report {
u8 *auxblob;
};
+#define TSM_MAX_RTMR 32
+
+/**
+ * struct tsm_capabilities - Describes a TSM capabilities.
+ * @num_rtmrs: The number of Runtime Measurement Registers (RTMR) available from
+ * a TSM.
+ * @rtmr_hash_alg: The hash algorithm used to extend a runtime measurement
+ * register.
+ */
+struct tsm_capabilities {
+ size_t num_rtmrs;
+ enum hash_algo rtmr_hash_alg;
+};
+
/**
* struct tsm_ops - attributes and operations for tsm instances
* @name: tsm id reflected in /sys/kernel/config/tsm/report/$report/provider
* @privlevel_floor: convey base privlevel for nested scenarios
+ * @capabilities: Describe the TSM capabilities, e.g. the number of available
+ * runtime measurement registers (see `struct tsm_capabilities`).
* @report_new: Populate @report with the report blob and auxblob
- * (optional), return 0 on successful population, or -errno otherwise
+ * (optional), return 0 on successful population, or -errno
+ * otherwise
+ * @rtmr_extend: Extend an RTMR with the provided digest.
+ * Return 0 on successful extension, or -errno otherwise.
+ * @rtmr_read: Reads the value of an RTMR.
+ * Return the number of bytes read or -errno for errors.
*
* Implementation specific ops, only one is expected to be registered at
* a time i.e. only one of "sev-guest", "tdx-guest", etc.
@@ -55,7 +78,10 @@ struct tsm_report {
struct tsm_ops {
const char *name;
const unsigned int privlevel_floor;
+ const struct tsm_capabilities capabilities;
int (*report_new)(struct tsm_report *report, void *data);
+ int (*rtmr_extend)(u32 idx, const u8 *digest, size_t digest_size);
+ ssize_t (*rtmr_read)(u32 idx, u8 *digest, size_t digest_size);
};
extern const struct config_item_type tsm_report_default_type;
--
2.42.0
RTMRs are defined and managed by their corresponding TSM provider. As
such, they can be configured through the TSM configfs root.
An additional `rtmrs` directory is added by default under the `tsm` one,
where each supported RTMR can be configured:
mkdir /sys/kernel/config/tsm/rtmrs/rtmr0
echo 0 > /sys/kernel/config/tsm/rtmrs/rtmr0/index
An RTMR can not be extended nor read before its configured by assigning
it an index. It is the TSM backend responsibility and choice to map that
index to a hardware RTMR.
Signed-off-by: Samuel Ortiz <[email protected]>
---
drivers/virt/coco/tsm.c | 164 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 164 insertions(+)
diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
index 6b71650271fe..15b67d99fd54 100644
--- a/drivers/virt/coco/tsm.c
+++ b/drivers/virt/coco/tsm.c
@@ -419,6 +419,108 @@ static const struct config_item_type tsm_reports_type = {
.ct_group_ops = &tsm_report_group_ops,
};
+static ssize_t tsm_rtmr_index_store(struct config_item *cfg,
+ const char *buf, size_t len)
+{
+ struct tsm_rtmr_state *rtmr_state = to_tsm_rtmr_state(cfg);
+ const struct tsm_ops *ops;
+ unsigned int val;
+ int rc;
+
+ rc = kstrtouint(buf, 0, &val);
+ if (rc)
+ return rc;
+
+ guard(rwsem_write)(&tsm_rwsem);
+
+ /* Index can only be configured once */
+ if (is_rtmr_configured(rtmr_state))
+ return -EBUSY;
+
+ /* Check that index stays within the TSM provided capabilities */
+ ops = provider.ops;
+ if (!ops)
+ return -ENOTTY;
+
+ if (val > ops->capabilities.num_rtmrs - 1)
+ return -EINVAL;
+
+ /* Check that this index is available */
+ if (tsm_rtmrs->rtmrs[val])
+ return -EINVAL;
+
+ rtmr_state->index = val;
+ rtmr_state->alg = ops->capabilities.rtmr_hash_alg;
+
+ tsm_rtmrs->rtmrs[val] = rtmr_state;
+
+ return len;
+}
+
+static ssize_t tsm_rtmr_index_show(struct config_item *cfg,
+ char *buf)
+{
+ struct tsm_rtmr_state *rtmr_state = to_tsm_rtmr_state(cfg);
+
+ guard(rwsem_read)(&tsm_rwsem);
+
+ /* An RTMR is not available if it has not been configured */
+ if (!is_rtmr_configured(rtmr_state))
+ return -ENXIO;
+
+ return sysfs_emit(buf, "%u\n", rtmr_state->index);
+}
+CONFIGFS_ATTR(tsm_rtmr_, index);
+
+static struct configfs_attribute *tsm_rtmr_attrs[] = {
+ &tsm_rtmr_attr_index,
+ NULL,
+};
+
+static void tsm_rtmr_item_release(struct config_item *cfg)
+{
+ struct tsm_rtmr_state *state = to_tsm_rtmr_state(cfg);
+
+ kfree(state);
+}
+
+static struct configfs_item_operations tsm_rtmr_item_ops = {
+ .release = tsm_rtmr_item_release,
+};
+
+const struct config_item_type tsm_rtmr_type = {
+ .ct_owner = THIS_MODULE,
+ .ct_attrs = tsm_rtmr_attrs,
+ .ct_item_ops = &tsm_rtmr_item_ops,
+};
+
+static struct config_item *tsm_rtmrs_make_item(struct config_group *group,
+ const char *name)
+{
+ struct tsm_rtmr_state *state;
+
+ guard(rwsem_read)(&tsm_rwsem);
+ if (!(provider.ops && (provider.ops->capabilities.num_rtmrs > 0)))
+ return ERR_PTR(-ENXIO);
+
+ state = kzalloc(sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return ERR_PTR(-ENOMEM);
+ state->index = U32_MAX;
+
+ config_item_init_type_name(&state->cfg, name, &tsm_rtmr_type);
+ return &state->cfg;
+}
+
+static struct configfs_group_operations tsm_rtmrs_group_ops = {
+ .make_item = tsm_rtmrs_make_item,
+};
+
+static const struct config_item_type tsm_rtmrs_type = {
+ .ct_owner = THIS_MODULE,
+ .ct_group_ops = &tsm_rtmrs_group_ops,
+};
+
static const struct config_item_type tsm_root_group_type = {
.ct_owner = THIS_MODULE,
};
@@ -433,10 +535,48 @@ static struct configfs_subsystem tsm_configfs = {
.su_mutex = __MUTEX_INITIALIZER(tsm_configfs.su_mutex),
};
+static int tsm_rtmr_register(const struct tsm_ops *ops)
+{
+ struct config_group *rtmrs_group;
+
+ lockdep_assert_held_write(&tsm_rwsem);
+
+ if (!ops || !ops->capabilities.num_rtmrs)
+ return 0;
+
+ if (ops->capabilities.num_rtmrs > TSM_MAX_RTMR)
+ return -EINVAL;
+
+ tsm_rtmrs = kzalloc(sizeof(struct tsm_rtmrs_state), GFP_KERNEL);
+ if (!tsm_rtmrs)
+ return -ENOMEM;
+
+ tsm_rtmrs->rtmrs = kcalloc(ops->capabilities.num_rtmrs,
+ sizeof(struct tsm_rtmr_state *),
+ GFP_KERNEL);
+ if (!tsm_rtmrs->rtmrs) {
+ kfree(tsm_rtmrs);
+ return -ENOMEM;
+ }
+
+ rtmrs_group = configfs_register_default_group(&tsm_configfs.su_group, "rtmrs",
+ &tsm_rtmrs_type);
+ if (IS_ERR(rtmrs_group)) {
+ kfree(tsm_rtmrs->rtmrs);
+ kfree(tsm_rtmrs);
+ return PTR_ERR(rtmrs_group);
+ }
+
+ tsm_rtmrs->group = rtmrs_group;
+
+ return 0;
+}
+
int tsm_register(const struct tsm_ops *ops, void *priv,
const struct config_item_type *type)
{
const struct tsm_ops *conflict;
+ int rc;
if (!type)
type = &tsm_report_default_type;
@@ -450,6 +590,10 @@ int tsm_register(const struct tsm_ops *ops, void *priv,
return -EBUSY;
}
+ rc = tsm_rtmr_register(ops);
+ if (rc < 0)
+ return rc;
+
provider.ops = ops;
provider.data = priv;
provider.type = type;
@@ -457,11 +601,31 @@ int tsm_register(const struct tsm_ops *ops, void *priv,
}
EXPORT_SYMBOL_GPL(tsm_register);
+static int tsm_rtmr_unregister(const struct tsm_ops *ops)
+{
+ lockdep_assert_held_write(&tsm_rwsem);
+
+ if ((ops) && (ops->capabilities.num_rtmrs > 0)) {
+ configfs_unregister_default_group(tsm_rtmrs->group);
+ kfree(tsm_rtmrs->rtmrs);
+ kfree(tsm_rtmrs);
+ }
+
+ return 0;
+}
+
int tsm_unregister(const struct tsm_ops *ops)
{
+ int rc;
+
guard(rwsem_write)(&tsm_rwsem);
if (ops != provider.ops)
return -EBUSY;
+
+ rc = tsm_rtmr_unregister(ops);
+ if (rc < 0)
+ return rc;
+
provider.ops = NULL;
provider.data = NULL;
provider.type = NULL;
--
2.42.0
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 <[email protected]>
---
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,
};
--
2.42.0
The whole purpose of TSM supported RTMRs is for userspace to extend them
with runtime measurements and to read them back.
This can be done through a binary configfs attribute for each RTMR:
rtmr0=/sys/kernel/config/tsm/rtmrs/rtmr0
mkdir $rtmr0
echo 0 > $rtmr0/index
dd if=software_layer_digest > $rtmr0/digest
hexdump $rtmr0/digest
An RTMR digest can not be extended or read before the RTMR is configured
by assigning it an index.
Signed-off-by: Samuel Ortiz <[email protected]>
---
drivers/virt/coco/Kconfig | 1 +
drivers/virt/coco/tsm.c | 58 +++++++++++++++++++++++++++++++++++++++
2 files changed, 59 insertions(+)
diff --git a/drivers/virt/coco/Kconfig b/drivers/virt/coco/Kconfig
index 87d142c1f932..5d924bae1ed8 100644
--- a/drivers/virt/coco/Kconfig
+++ b/drivers/virt/coco/Kconfig
@@ -5,6 +5,7 @@
config TSM_REPORTS
select CONFIGFS_FS
+ select CRYPTO_HASH_INFO
tristate
source "drivers/virt/coco/efi_secret/Kconfig"
diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
index f35f91cb7bd3..16fceed4bdb9 100644
--- a/drivers/virt/coco/tsm.c
+++ b/drivers/virt/coco/tsm.c
@@ -537,6 +537,63 @@ static struct configfs_attribute *tsm_rtmr_attrs[] = {
NULL,
};
+static ssize_t tsm_rtmr_digest_read(struct config_item *cfg, void *buf,
+ size_t count)
+{
+ struct tsm_rtmr_state *rtmr_state = to_tsm_rtmr_state(cfg);
+ int rc, digest_size = hash_digest_size[rtmr_state->alg];
+
+ /* configfs is asking for the digest size */
+ if (!buf)
+ return digest_size;
+
+ if (!is_rtmr_configured(rtmr_state))
+ return -ENXIO;
+
+ if (count > TSM_DIGEST_MAX || count < digest_size)
+ return -EINVAL;
+
+ /* Read from the cached digest */
+ if (rtmr_state->cached_digest) {
+ memcpy(buf, rtmr_state->digest, count);
+ return digest_size;
+ }
+
+ /* Slow path, this RTMR got extended */
+ guard(rwsem_write)(&tsm_rwsem);
+ rc = tsm_rtmr_read(&provider, rtmr_state->index, buf, count);
+ if (rc < 0)
+ return rc;
+
+ /* Update the cached digest */
+ memcpy(rtmr_state->digest, buf, count);
+ rtmr_state->cached_digest = true;
+
+ return rc;
+}
+
+static ssize_t tsm_rtmr_digest_write(struct config_item *cfg,
+ const void *buf, size_t count)
+{
+ struct tsm_rtmr_state *rtmr_state = to_tsm_rtmr_state(cfg);
+
+ if (!is_rtmr_configured(rtmr_state))
+ return -ENXIO;
+
+ if (count > TSM_DIGEST_MAX || count < hash_digest_size[rtmr_state->alg])
+ return -EINVAL;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ rtmr_state->cached_digest = false;
+ return tsm_rtmr_extend(&provider, rtmr_state->index, buf, count);
+}
+CONFIGFS_BIN_ATTR(tsm_rtmr_, digest, NULL, TSM_DIGEST_MAX);
+
+static struct configfs_bin_attribute *tsm_rtmr_bin_attrs[] = {
+ &tsm_rtmr_attr_digest,
+ NULL,
+};
+
static void tsm_rtmr_item_release(struct config_item *cfg)
{
struct tsm_rtmr_state *state = to_tsm_rtmr_state(cfg);
@@ -550,6 +607,7 @@ static struct configfs_item_operations tsm_rtmr_item_ops = {
const struct config_item_type tsm_rtmr_type = {
.ct_owner = THIS_MODULE,
+ .ct_bin_attrs = tsm_rtmr_bin_attrs,
.ct_attrs = tsm_rtmr_attrs,
.ct_item_ops = &tsm_rtmr_item_ops,
};
--
2.42.0
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.
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/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 <[email protected]>
> ---
> 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,
> };
>
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
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.
>
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
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 <[email protected]> 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 Glaze, PhD (she/her)
Dionna Amalie Glaze wrote:
> On Wed, Jan 17, 2024 at 7:36 PM <[email protected]> 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 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 Thu, Jan 18, 2024 at 11:35:15AM +0800, [email protected] 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, [email protected] 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 Jan 21, 2024, at 8:31 AM, Samuel Ortiz <[email protected]> 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 <[email protected]>
> Sent: Monday, January 22, 2024 10:13 AM
> To: Samuel Ortiz <[email protected]>; Yao, Jiewen <[email protected]>;
> Lu, Ken <[email protected]>
> Cc: Kuppuswamy Sathyanarayanan
> <[email protected]>; Williams, Dan J
> <[email protected]>; [email protected]; linux-
> [email protected]
> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
> > Sent: Monday, January 22, 2024 10:13 AM
> > To: Samuel Ortiz <[email protected]>; Yao, Jiewen <[email protected]>;
> > Lu, Ken <[email protected]>
> > Cc: Kuppuswamy Sathyanarayanan
> > <[email protected]>; Williams, Dan J
> > <[email protected]>; [email protected]; linux-
> > [email protected]
> > 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 <[email protected]> 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 <[email protected]> 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.
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
Yao, Jiewen wrote:
> Comment below:
>
> > -----Original Message-----
> > From: Qinkun Bao <[email protected]>
> > Sent: Monday, January 22, 2024 10:13 AM
> > To: Samuel Ortiz <[email protected]>; Yao, Jiewen <[email protected]>;
> > Lu, Ken <[email protected]>
> > Cc: Kuppuswamy Sathyanarayanan
> > <[email protected]>; Williams, Dan J
> > <[email protected]>; [email protected]; linux-
> > [email protected]
> > 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 <[email protected]> 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 <[email protected]>
>>> Sent: Monday, January 22, 2024 10:13 AM
>>> To: Samuel Ortiz <[email protected]>; Yao, Jiewen <[email protected]>;
>>> Lu, Ken <[email protected]>
>>> Cc: Kuppuswamy Sathyanarayanan
>>> <[email protected]>; Williams, Dan J
>>> <[email protected]>; [email protected]; linux-
>>> [email protected]
>>> 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 <[email protected]> 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/2024 11:15 AM, Dan Williams wrote:
> Samuel Ortiz wrote:
>> On Thu, Jan 18, 2024 at 11:35:15AM +0800, [email protected] 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.
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.
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.
>
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
> -----Original Message-----
> From: Xing, Cedric <[email protected]>
> Sent: Tuesday, January 23, 2024 5:59 AM
> To: Williams, Dan J <[email protected]>; Yao, Jiewen
> <[email protected]>; Qinkun Bao <[email protected]>; Samuel Ortiz
> <[email protected]>; Lu, Ken <[email protected]>
> Cc: Kuppuswamy Sathyanarayanan
> <[email protected]>; [email protected];
> [email protected]
> 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 <[email protected]>
> >>> Sent: Monday, January 22, 2024 10:13 AM
> >>> To: Samuel Ortiz <[email protected]>; Yao, Jiewen
> <[email protected]>;
> >>> Lu, Ken <[email protected]>
> >>> Cc: Kuppuswamy Sathyanarayanan
> >>> <[email protected]>; Williams, Dan J
> >>> <[email protected]>; [email protected]; linux-
> >>> [email protected]
> >>> 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 <[email protected]> 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
>
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer