drivers/virt/coco/Kconfig | 4 +- drivers/virt/coco/tsm.c | 598 +++++++++++++++++++++++++++++++++++++- include/linux/tsm.h | 62 ++++ samples/Kconfig | 4 + samples/Makefile | 1 + samples/tsm/Makefile | 2 + samples/tsm/measurement-example.c | 116 ++++++++ 7 files changed, 777 insertions(+), 10 deletions(-)
NOTE: This patch series introduces the Measurement Register (MR) ABI, and is
largely a continuation of Samuel Ortiz’s previous work on the RTMR ABI [1].
This patch series adds a unified interface to TSM core for confidential
computing (CC) guest drivers to provide access to measurement registers (MRs),
which are essential for relying parties (RPs) to verify the integrity of the
computing environment. The interface is structured around
`struct tsm_measurement_provider`, which holds an array of
`struct tsm_measurement_register` and includes operations for reading and
updating MRs.
The MRs come in two varieties: static and runtime. Static MRs are determined at
the TEE VM (TVM) build time and capture the initial memory image or the
configuration/policy specified by the TVM's owner. In contrast, Runtime MRs
(RTMRs) start with known values, such as all zeros, at TVM build time and are
extended with measurements of loaded code, data, configuration, or executed
actions by the TVM guest during runtime.
Each `struct tsm_measurement_register` features a `mr_flags` member that
indicates the MR's properties. Static MRs are typically marked as read-only
with only the `TSM_MR_F_R` flag set, while RTMRs are marked as extensible with
the `TSM_MR_F_X` flag. For examples of defining and implementing MRs, refer to
Patch 3.
MRs are made accessible to applications through a directory tree, where static
MRs are represented as files and RTMRs as directories containing elements like
`digest` and `hash_algo`. Although the current root of this directory tree is
`/sys/kernel/tsm/`, other potential locations include configfs
(`/sys/kernel/config/tsm/`) and securityfs (`/sys/kernel/security/tsm/`). This
RFC (Request for Comments) series seeks feedback on the interfaces, with the
directory tree's location being a secondary concern. Further details can be
found in Patch 1.
Patch 2 introduces event log support for RTMRs, addressing the fact that the
standalone values of RTMRs, which represent the cumulative digests of
sequential events, are not fully informative on their own.
[1]: https://patchwork.kernel.org/project/linux-integrity/cover/20240128212532.2754325-1-sameo@rivosinc.com/
Signed-off-by: Cedric Xing <cedric.xing@intel.com>
---
Cedric Xing (3):
tsm: Add TVM Measurement Register Support
tsm: Add RTMR event logging
tsm: Add TVM Measurement Sample Code
drivers/virt/coco/Kconfig | 4 +-
drivers/virt/coco/tsm.c | 598 +++++++++++++++++++++++++++++++++++++-
include/linux/tsm.h | 62 ++++
samples/Kconfig | 4 +
samples/Makefile | 1 +
samples/tsm/Makefile | 2 +
samples/tsm/measurement-example.c | 116 ++++++++
7 files changed, 777 insertions(+), 10 deletions(-)
---
base-commit: 431c1646e1f86b949fa3685efc50b660a364c2b6
change-id: 20240904-tsm-rtmr-7a45859d2a96
Best regards,
--
Cedric Xing <cedric.xing@intel.com>
Hi Cedric,
On Sat, Sep 07, 2024 at 11:56:18PM -0500, Cedric Xing wrote:
> Patch 2 introduces event log support for RTMRs, addressing the fact that the
> standalone values of RTMRs, which represent the cumulative digests of
> sequential events, are not fully informative on their own.
Would each event_log include the events that firmware wrote before Linux?
I'm wondering how this coexists with /sys/firmware/acpi/tables/data/CCEL.
Maybe something like: CCEL only contains pre-Linux events. The TSM driver
parses CCEL (using a format specific to the arch, for example TCG2),
separates the events by MR and produces event_log files in
/sys/kernel/tsm/, possibly in a different format like CEL-TLV. Is that
what you envision for TDX?
I ask because I've been looking into this interface for Arm CCA, and
having unified event logs available somewhere in /sys/kernel/confg/tsm
would be very convenient for users (avoids having to parse and convert
different /sys/firmware interfaces along with Linux event logs). I would
have put a single event_log in /sys/kernel/config/tsm/report/ but
splitting it by MR should work too.
As Alex I believe we need more similarity between the interfaces of static
and runtime measurements, because verifiers may benefit from an event log
of static measurements. For example Arm could have a configuration like
this:
struct tsm_measurement_register arm_cca_mrs[] = {
{ MR_(rim) | TSM_MR_F_R | TSM_MR_F_LOG, HA },
{ MR_(rem0) | TSM_MR_F_R | TSM_MR_F_X | TSM_MR_F_LOG, HA },
...
{ MR_(rem3) | TSM_MR_F_R | TSM_MR_F_X | TSM_MR_F_LOG, HA },
};
Here rim is a static measurement of the initial VM state, impossible to
extend but could have an event log. rem0-3 are runtime measurements,
extensible by firmware and then Linux. None of the digests can be written
directly, only extended and read with calls to the upper layer. The tree
would be:
/sys/kernel/config/tsm/
├── rim
│ ├── digest
│ ├── event_log
│ └── hash_algo
├── rem0
│ ├── digest
│ ├── append_event
│ ├── event_log
│ └── hash_algo
...
├── rem3
│ ├── digest
│ ├── append_event
│ ├── event_log
│ └── hash_algo
└── report/$name
├── inblob
└── outblob
Thanks,
Jean
> On 10 Sep 2024, at 19:09, Jean-Philippe Brucker <jean-philippe@linaro.org> wrote:
>
> Hi Cedric,
>
> On Sat, Sep 07, 2024 at 11:56:18PM -0500, Cedric Xing wrote:
>> Patch 2 introduces event log support for RTMRs, addressing the fact that the
>> standalone values of RTMRs, which represent the cumulative digests of
>> sequential events, are not fully informative on their own.
>
> Would each event_log include the events that firmware wrote before Linux?
> I'm wondering how this coexists with /sys/firmware/acpi/tables/data/CCEL.
> Maybe something like: CCEL only contains pre-Linux events. The TSM driver
> parses CCEL (using a format specific to the arch, for example TCG2),
> separates the events by MR and produces event_log files in
> /sys/kernel/tsm/, possibly in a different format like CEL-TLV. Is that
> what you envision for TDX?
>
> I ask because I've been looking into this interface for Arm CCA, and
> having unified event logs available somewhere in /sys/kernel/confg/tsm
> would be very convenient for users (avoids having to parse and convert
> different /sys/firmware interfaces along with Linux event logs). I would
> have put a single event_log in /sys/kernel/config/tsm/report/ but
> splitting it by MR should work too.
>
> As Alex I believe we need more similarity between the interfaces of static
> and runtime measurements, because verifiers may benefit from an event log
> of static measurements. For example Arm could have a configuration like
> this:
>
> struct tsm_measurement_register arm_cca_mrs[] = {
> { MR_(rim) | TSM_MR_F_R | TSM_MR_F_LOG, HA },
> { MR_(rem0) | TSM_MR_F_R | TSM_MR_F_X | TSM_MR_F_LOG, HA },
> ...
> { MR_(rem3) | TSM_MR_F_R | TSM_MR_F_X | TSM_MR_F_LOG, HA },
> };
>
> Here rim is a static measurement of the initial VM state, impossible to
> extend but could have an event log. rem0-3 are runtime measurements,
> extensible by firmware and then Linux. None of the digests can be written
> directly, only extended and read with calls to the upper layer. The tree
> would be:
>
> /sys/kernel/config/tsm/
> ├── rim
> │ ├── digest
> │ ├── event_log
> │ └── hash_algo
> ├── rem0
> │ ├── digest
> │ ├── append_event
> │ ├── event_log
> │ └── hash_algo
> ...
> ├── rem3
> │ ├── digest
> │ ├── append_event
> │ ├── event_log
> │ └── hash_algo
> └── report/$name
> ├── inblob
> └── outblob
It’s nice to have a similar structure between ARM and x86, but how does
user space know what each register holds? For example, say that I want
a digest of the initial VM state, of the boot configuration, of the
command line, or of the firmware, where do I get that? When using a TPM,
there are conventions on which PCR stores which particular piece of
information.
Is the idea to defer that to user space, or should we also have some
symlinks exposing this or that specific register when it exists under
a common, platform-agnostic name? e.g. on ARM you would have
/sys/kernel/config/tsm/initial_vm_state -> ./rim
It looks to me like this could simplify the writing of user-space
attestation agents, for example. But then, maybe I’m too optimistic
and such agents would always be platform-dependent anyway.
One data point is that about one year ago, CoCo has already split the
platform dependencies away in their attestation stack, at the time
mostly to cover differences between AMD and Intel.
>
> Thanks,
> Jean
>
>
Cheers,
Christophe de Dinechin (https://c3d.github.io)
Freedom Covenant (https://github.com/c3d/freedom-covenant)
Theory of Incomplete Measurements (https://c3d.github.io/TIM)
On 9/12/2024 5:03 AM, Christophe de Dinechin wrote:
>
>
>> On 10 Sep 2024, at 19:09, Jean-Philippe Brucker <jean-philippe@linaro.org> wrote:
>>
>> Hi Cedric,
>>
>> On Sat, Sep 07, 2024 at 11:56:18PM -0500, Cedric Xing wrote:
>>> Patch 2 introduces event log support for RTMRs, addressing the fact that the
>>> standalone values of RTMRs, which represent the cumulative digests of
>>> sequential events, are not fully informative on their own.
>>
>> Would each event_log include the events that firmware wrote before Linux?
>> I'm wondering how this coexists with /sys/firmware/acpi/tables/data/CCEL.
>> Maybe something like: CCEL only contains pre-Linux events. The TSM driver
>> parses CCEL (using a format specific to the arch, for example TCG2),
>> separates the events by MR and produces event_log files in
>> /sys/kernel/tsm/, possibly in a different format like CEL-TLV. Is that
>> what you envision for TDX?
>>
>> I ask because I've been looking into this interface for Arm CCA, and
>> having unified event logs available somewhere in /sys/kernel/confg/tsm
>> would be very convenient for users (avoids having to parse and convert
>> different /sys/firmware interfaces along with Linux event logs). I would
>> have put a single event_log in /sys/kernel/config/tsm/report/ but
>> splitting it by MR should work too.
>>
>> As Alex I believe we need more similarity between the interfaces of static
>> and runtime measurements, because verifiers may benefit from an event log
>> of static measurements. For example Arm could have a configuration like
>> this:
>>
>> struct tsm_measurement_register arm_cca_mrs[] = {
>> { MR_(rim) | TSM_MR_F_R | TSM_MR_F_LOG, HA },
>> { MR_(rem0) | TSM_MR_F_R | TSM_MR_F_X | TSM_MR_F_LOG, HA },
>> ...
>> { MR_(rem3) | TSM_MR_F_R | TSM_MR_F_X | TSM_MR_F_LOG, HA },
>> };
>>
>> Here rim is a static measurement of the initial VM state, impossible to
>> extend but could have an event log. rem0-3 are runtime measurements,
>> extensible by firmware and then Linux. None of the digests can be written
>> directly, only extended and read with calls to the upper layer. The tree
>> would be:
>>
>> /sys/kernel/config/tsm/
>> ├── rim
>> │ ├── digest
>> │ ├── event_log
>> │ └── hash_algo
>> ├── rem0
>> │ ├── digest
>> │ ├── append_event
>> │ ├── event_log
>> │ └── hash_algo
>> ...
>> ├── rem3
>> │ ├── digest
>> │ ├── append_event
>> │ ├── event_log
>> │ └── hash_algo
>> └── report/$name
>> ├── inblob
>> └── outblob
>
> It’s nice to have a similar structure between ARM and x86, but how does
> user space know what each register holds? For example, say that I want
> a digest of the initial VM state, of the boot configuration, of the
> command line, or of the firmware, where do I get that? When using a TPM,
> there are conventions on which PCR stores which particular piece of
> information.
> > Is the idea to defer that to user space, or should we also have some
> symlinks exposing this or that specific register when it exists under
> a common, platform-agnostic name? e.g. on ARM you would have
>
> /sys/kernel/config/tsm/initial_vm_state -> ./rim
> On the surface, a convention + symlinks could be a solution to the problem.
But if we dig deeper, a conventions will be difficult to establish
because different users/tenants/applications have different needs in
passing configurations/policies (or additional whatever). A more generic
model is to allow upper layer software to specify arbitrary number of
measurements in the form of name/value pairs. For example, say `rim` is
the only static MR on Arm but the tenant wants to pass in a policy file
along with the tenant's public key. We could put the following 2 lines
into rim's log (more like a manifest because the MR is static):
kernel.org/tsm/static_mr mr_policy <policy digest>
kernel.org/tsm/static_mr mr_pubkey <public key digest>
Then, assuming Arm CCA guest driver also understands the log format
above, it would create 2 virtual/pseudo-MRs, namely `mr_policy` and
`mr_pubkey`, to expose those digests to applications.
Then say, if the tenant wants the same application to run on Intel TDX,
whose MRTD doesn't support the same semantics as rim, MROWNERCONFIG
could be used instead - the same log entries but for MROWNERCONFIG this
time. The TDX guest would then create the same `mr_policy` and
`mr_pubkey` for those same applications to consume. Please note that
those applications are CC arch agnostic (at source level).
During attestation/verification, the verifier is supposed to consist of
a buttom (CC arch specific) layer and a top (CC arch agnostic) layer.
The bottom would verify the integrity of the log using different MRs
(rim on Arm CCA or MROWNERCONFIG on Intel TDX), then the top layer would
extract and verify `mr_policy`/`mr_pubkey` against the reference values
set forth by the tenant.
> It looks to me like this could simplify the writing of user-space
> attestation agents, for example. But then, maybe I’m too optimistic
> and such agents would always be platform-dependent anyway.
>
I believe portable (CC arch agnostic) applications can be done, but
there's still some way to go.
-Cedric
On Thu, Sep 12, 2024 at 12:03:05PM +0200, Christophe de Dinechin wrote: > It’s nice to have a similar structure between ARM and x86, but how does > user space know what each register holds? For example, say that I want > a digest of the initial VM state, of the boot configuration, of the > command line, or of the firmware, where do I get that? When using a TPM, > there are conventions on which PCR stores which particular piece of > information. It's early days for Arm and this is still something we need to formalize. The initial VM state always goes in the RIM (~MRTD) and REM[0-3] (~RTMR) contain runtime measurements. TDX already defined a correspondence between PCR and RTMR in UEFI: https://uefi.org/specs/UEFI/2.10/38_Confidential_Computing.html#intel-trust-domain-extension TPM PCR Index | TDX-measurement register --------------------------------------- 0 | MRTD 1, 7 | RTMR[0] 2~6 | RTMR[1] 8~15 | RTMR[2] It would make sense for Arm to follow the same convention. This way, FW knows where to put new measurements. And extending this mapping, remaining PCRs could for example all go in RTMR[3]. Verifiers and other consumers don't need to know any of these conventions, they can just read the event log to know where each component was measured. > Is the idea to defer that to user space, or should we also have some > symlinks exposing this or that specific register when it exists under > a common, platform-agnostic name? e.g. on ARM you would have > > /sys/kernel/config/tsm/initial_vm_state -> ./rim > > It looks to me like this could simplify the writing of user-space > attestation agents, for example. But then, maybe I’m too optimistic > and such agents would always be platform-dependent anyway. I agree, it may be useful to have a single platform-agnostic link for generic applications that need to extend measurements. For example one RTMR could be picked by the TSM driver: /sys/kernel/config/tsm/extend_measurement -> ./rtmr3 I'm not sure it's useful to provide a shortcut to initial_vm_state however, because as I understand it an attestation agent just wants to bundle all digests and send them to a verifier, something already provided in a platform-agnostic way by configfs-tsm report/ Thanks, Jean > > One data point is that about one year ago, CoCo has already split the > platform dependencies away in their attestation stack, at the time > mostly to cover differences between AMD and Intel. > > > > > Thanks, > > Jean > > > > > > Cheers, > Christophe de Dinechin (https://c3d.github.io) > Freedom Covenant (https://github.com/c3d/freedom-covenant) > Theory of Incomplete Measurements (https://c3d.github.io/TIM) >
On 9/10/2024 12:09 PM, Jean-Philippe Brucker wrote:
> Hi Cedric,
>
> On Sat, Sep 07, 2024 at 11:56:18PM -0500, Cedric Xing wrote:
>> Patch 2 introduces event log support for RTMRs, addressing the fact that the
>> standalone values of RTMRs, which represent the cumulative digests of
>> sequential events, are not fully informative on their own.
>
> Would each event_log include the events that firmware wrote before Linux?
No. The log format proposed here is textual and incompatible with TCG2
log format.
The proposed log format is based on the CoCo event log -
https://github.com/confidential-containers/guest-components/issues/495.
> I'm wondering how this coexists with /sys/firmware/acpi/tables/data/CCEL.
The proposed log will take over after booting to Linux. The `SYNC` line
in the log captures the RTMR value before it, which can be used to
verify CCEL left off by the virtual firmware.
> Maybe something like: CCEL only contains pre-Linux events. The TSM driver
> parses CCEL (using a format specific to the arch, for example TCG2),
> separates the events by MR and produces event_log files in
> /sys/kernel/tsm/, possibly in a different format like CEL-TLV. Is that
> what you envision for TDX?
>
CCEL will be pre-Linux only. Given the proposed format is incompatible
with TCG2 format, I don't think those 2 logs will be merged. But if we
get any success in this new log format, we may influence the UEFI/OVMF
community to adopt this new format in future.
We have evaluated both TCG2 and CEL formats but arrived in this new
format because we'd like to support ALL applications. And the only sane
way I could figure out is to separate the log into 2 layers - an
application specific semantics layer (a contract between the application
and the verifier), and an application agnostic storage layer
(implemented by the kernel). The common problem of TCG2 and CEL is that
the event/content tag/type dictates which part of the event data/content
to hash, meaning the kernel must understand an event record before
hashing it. And that has prevented an application agnostic storage design.
Anyway, this new log can be encapsulated in both CEL-JSON (like what
systemd is doing today) and TCG2 (using the EV_ACTION event type)
formats. Please see the CoCo issue (link given above) for more details.
> I ask because I've been looking into this interface for Arm CCA, and
> having unified event logs available somewhere in /sys/kernel/confg/tsm
> would be very convenient for users (avoids having to parse and convert
> different /sys/firmware interfaces along with Linux event logs). I would
> have put a single event_log in /sys/kernel/config/tsm/report/ but
> splitting it by MR should work too.
>
We have considered one global log vs. per-MR logs. In fact, a global log
is equivalent to the concatenation of all per-MR logs. We've adopted the
per-MR approach to keep the log optional - i.e., an RTMR can be extended
directly (by writing to its `digest` attribute) without a log.
With regard to the location of the MR tree, we picked sysfs because the
MRs (and associated logs) are global and fit more into the semantics of
sysfs than configfs. Dan W. and I are also considering moving both
report/ and measurement/ trees into securityfs. It'll be highly
appreciated if you (and Alex, and everyone) can share your insights.
> As Alex I believe we need more similarity between the interfaces of static
> and runtime measurements, because verifiers may benefit from an event log
> of static measurements. For example Arm could have a configuration like
> this:
>
> struct tsm_measurement_register arm_cca_mrs[] = {
> { MR_(rim) | TSM_MR_F_R | TSM_MR_F_LOG, HA },
> { MR_(rem0) | TSM_MR_F_R | TSM_MR_F_X | TSM_MR_F_LOG, HA },
> ...
> { MR_(rem3) | TSM_MR_F_R | TSM_MR_F_X | TSM_MR_F_LOG, HA },
> };
>
> Here rim is a static measurement of the initial VM state, impossible to
> extend but could have an event log. rem0-3 are runtime measurements,
> extensible by firmware and then Linux. None of the digests can be written
> directly, only extended and read with calls to the upper layer. The tree
> would be:
>
> /sys/kernel/config/tsm/
> ├── rim
> │ ├── digest
> │ ├── event_log
> │ └── hash_algo
> ├── rem0
> │ ├── digest
> │ ├── append_event
> │ ├── event_log
> │ └── hash_algo
> ...
> ├── rem3
> │ ├── digest
> │ ├── append_event
> │ ├── event_log
> │ └── hash_algo
> └── report/$name
> ├── inblob
> └── outblob
>
I see. The desired/missing feature here I think is to allow a CC guest
driver to supply an "initial log". I can define a LOG bit, which if set,
will make the MR its own dir with `hash_algo` and `event_log`. And if X
is also set, then `append_event` will appear as well. Does this sound
like what Alex and you are looking for?
-Cedric
On Tue, Sep 10, 2024 at 11:01:59PM -0500, Xing, Cedric wrote:
> On 9/10/2024 12:09 PM, Jean-Philippe Brucker wrote:
> > Hi Cedric,
> >
> > On Sat, Sep 07, 2024 at 11:56:18PM -0500, Cedric Xing wrote:
> > > Patch 2 introduces event log support for RTMRs, addressing the fact that the
> > > standalone values of RTMRs, which represent the cumulative digests of
> > > sequential events, are not fully informative on their own.
> >
> > Would each event_log include the events that firmware wrote before Linux?
> No. The log format proposed here is textual and incompatible with TCG2 log
> format.
>
> The proposed log format is based on the CoCo event log -
> https://github.com/confidential-containers/guest-components/issues/495.
>
> > I'm wondering how this coexists with /sys/firmware/acpi/tables/data/CCEL.
> The proposed log will take over after booting to Linux. The `SYNC` line in
> the log captures the RTMR value before it, which can be used to verify CCEL
> left off by the virtual firmware.
>
> > Maybe something like: CCEL only contains pre-Linux events. The TSM driver
> > parses CCEL (using a format specific to the arch, for example TCG2),
> > separates the events by MR and produces event_log files in
> > /sys/kernel/tsm/, possibly in a different format like CEL-TLV. Is that
> > what you envision for TDX?
> >
> CCEL will be pre-Linux only. Given the proposed format is incompatible with
> TCG2 format, I don't think those 2 logs will be merged. But if we get any
> success in this new log format, we may influence the UEFI/OVMF community to
> adopt this new format in future.
>
> We have evaluated both TCG2 and CEL formats but arrived in this new format
> because we'd like to support ALL applications. And the only sane way I could
> figure out is to separate the log into 2 layers - an application specific
> semantics layer (a contract between the application and the verifier), and
> an application agnostic storage layer (implemented by the kernel). The
> common problem of TCG2 and CEL is that the event/content tag/type dictates
> which part of the event data/content to hash, meaning the kernel must
> understand an event record before hashing it. And that has prevented an
> application agnostic storage design.
>
> Anyway, this new log can be encapsulated in both CEL-JSON (like what systemd
> is doing today) and TCG2 (using the EV_ACTION event type) formats. Please
> see the CoCo issue (link given above) for more details.
Thank you for the explanation. In our case I'm guessing we'd then have a
userspace library to:
1. read the CCEL (from multiple FW interfaces unfortunately: ACPI,
devicetree, maybe EFI)
2. read each event_log from your proposed interface
3. collate everything into a single log, using eg. CEL-CBOR, and send it
to the verifier.
There may be some value in having the kernel TSM module do all of this,
but userspace seems like the right place for this sort of complexity,
especially the log format conversion.
>
> > I ask because I've been looking into this interface for Arm CCA, and
> > having unified event logs available somewhere in /sys/kernel/confg/tsm
> > would be very convenient for users (avoids having to parse and convert
> > different /sys/firmware interfaces along with Linux event logs). I would
> > have put a single event_log in /sys/kernel/config/tsm/report/ but
> > splitting it by MR should work too.
> >
> We have considered one global log vs. per-MR logs. In fact, a global log is
> equivalent to the concatenation of all per-MR logs. We've adopted the per-MR
> approach to keep the log optional - i.e., an RTMR can be extended directly
> (by writing to its `digest` attribute) without a log.
>
> With regard to the location of the MR tree, we picked sysfs because the MRs
> (and associated logs) are global and fit more into the semantics of sysfs
> than configfs. Dan W. and I are also considering moving both report/ and
> measurement/ trees into securityfs. It'll be highly appreciated if you (and
> Alex, and everyone) can share your insights.
I agree with Dan about keeping report/ in configfs. It would be nice to
have both in the same place, but no strong opinion.
>
> > As Alex I believe we need more similarity between the interfaces of static
> > and runtime measurements, because verifiers may benefit from an event log
> > of static measurements. For example Arm could have a configuration like
> > this:
> >
> > struct tsm_measurement_register arm_cca_mrs[] = {
> > { MR_(rim) | TSM_MR_F_R | TSM_MR_F_LOG, HA },
> > { MR_(rem0) | TSM_MR_F_R | TSM_MR_F_X | TSM_MR_F_LOG, HA },
> > ...
> > { MR_(rem3) | TSM_MR_F_R | TSM_MR_F_X | TSM_MR_F_LOG, HA },
> > };
> >
> > Here rim is a static measurement of the initial VM state, impossible to
> > extend but could have an event log. rem0-3 are runtime measurements,
> > extensible by firmware and then Linux. None of the digests can be written
> > directly, only extended and read with calls to the upper layer. The tree
> > would be:
> >
> > /sys/kernel/config/tsm/
> > ├── rim
> > │ ├── digest
> > │ ├── event_log
> > │ └── hash_algo
> > ├── rem0
> > │ ├── digest
> > │ ├── append_event
> > │ ├── event_log
> > │ └── hash_algo
> > ...
> > ├── rem3
> > │ ├── digest
> > │ ├── append_event
> > │ ├── event_log
> > │ └── hash_algo
> > └── report/$name
> > ├── inblob
> > └── outblob
> >
> I see. The desired/missing feature here I think is to allow a CC guest
> driver to supply an "initial log".
Yes, although that would only be necessary if this new interface is able
to include the pre-Linux events in the log, otherwise the event_log for
static measurements here wouldn't contain anything.
If firmware events aren't included in this new interface, then presenting
static measurements doesn't seem useful for Arm CCA, since by definition
they can't be extended. In my example I added 'digest' files only because
our interface allows to read them directly from the upper layer, but the
normal way to obtain digests is through /sys/kernel/config/tsm/report/,
where outblob contains all digests, signed by the platform. So for CCA the
tree would look more like:
/sys/kernel/config/tsm/
├── rem0
│ ├── append_event
│ ├── event_log
│ └── hash_algo
...
├── rem3
│ ├── append_event
│ ├── event_log
│ └── hash_algo
└── report/$name
├── inblob
└── outblob
But I understand other archs could have a use for presenting the static
measurements here, in which case presenting them in their own dir with a
fine-grained selection of files like you suggest below would make sense.
Thanks,
Jean
> I can define a LOG bit, which if set,
> will make the MR its own dir with `hash_algo` and `event_log`. And if X is
> also set, then `append_event` will appear as well. Does this sound like what
> Alex and you are looking for?
>
> -Cedric
Xing, Cedric wrote: [..] > With regard to the location of the MR tree, we picked sysfs because the > MRs (and associated logs) are global and fit more into the semantics of > sysfs than configfs. Dan W. and I are also considering moving both > report/ and measurement/ trees into securityfs. It'll be highly > appreciated if you (and Alex, and everyone) can share your insights. I would only expect this new measurement interface is suitable for considering securityfs. The tsm_report uAPI is already baked and has a need for the multi-instance support of configfs. The rationale for RTMR measurements in securityfs is because the IMA measurement uAPI already lives there. So it is more about following precedent for co-locating a new ASCII RTMR measurement log in the same filesystem that provides ima/ascii_runtime_measurements. A multi-instance interface for virtual RTMRs might be suitable to live in configfs alongside reports/, and use this native singleton log as a backend.
On Tue, 2024-09-10 at 23:01 -0500, Xing, Cedric wrote: > On 9/10/2024 12:09 PM, Jean-Philippe Brucker wrote: > > Hi Cedric, > > > > On Sat, Sep 07, 2024 at 11:56:18PM -0500, Cedric Xing wrote: > > > Patch 2 introduces event log support for RTMRs, addressing the > > > fact that the standalone values of RTMRs, which represent the > > > cumulative digests of sequential events, are not fully > > > informative on their own. > > > > Would each event_log include the events that firmware wrote before > > Linux? > > No. The log format proposed here is textual and incompatible with > TCG2 log format. > > The proposed log format is based on the CoCo event log - > https://github.com/confidential-containers/guest-components/issues/495 > . Given that AMD is planning to use the SVSM-vTPM for post launch measurements, not supporting TPMs in any form would make this Intel only on x86 and thus not very "unified". Microsoft also tends to do attestations partly via the vTPM in its L1 openHCL component (even for TDX) and thus would also have difficulty adopting this proposal. Regards, James
James Bottomley wrote: > On Tue, 2024-09-10 at 23:01 -0500, Xing, Cedric wrote: > > On 9/10/2024 12:09 PM, Jean-Philippe Brucker wrote: > > > Hi Cedric, > > > > > > On Sat, Sep 07, 2024 at 11:56:18PM -0500, Cedric Xing wrote: > > > > Patch 2 introduces event log support for RTMRs, addressing the > > > > fact that the standalone values of RTMRs, which represent the > > > > cumulative digests of sequential events, are not fully > > > > informative on their own. > > > > > > Would each event_log include the events that firmware wrote before > > > Linux? > > > > No. The log format proposed here is textual and incompatible with > > TCG2 log format. > > > > The proposed log format is based on the CoCo event log - > > https://github.com/confidential-containers/guest-components/issues/495 > > . > > Given that AMD is planning to use the SVSM-vTPM for post launch > measurements, not supporting TPMs in any form would make this Intel > only on x86 and thus not very "unified". Microsoft also tends to do > attestations partly via the vTPM in its L1 openHCL component (even for > TDX) and thus would also have difficulty adopting this proposal. When I reviewed this with Cedric before hand I had been convinced that this need not immediately trigger the "TPM vs RTMR" debate. Cedric can jump in here where I get this wrong, but the thought is that once we have this native RTMR interface with a cross-RTMR-vendor (Intel, RISCV, ARM) common event-log it can be used to build virtual RTMRs / vTPM for applications to use. In other words, use something like vtpm_proxy to provide TPM services to applications, but proxy those those events to this native RTMR backend.
On Wed, Sep 11, 2024 at 8:06 PM James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > > On Tue, 2024-09-10 at 23:01 -0500, Xing, Cedric wrote: > > On 9/10/2024 12:09 PM, Jean-Philippe Brucker wrote: > > > Hi Cedric, > > > > > > On Sat, Sep 07, 2024 at 11:56:18PM -0500, Cedric Xing wrote: > > > > Patch 2 introduces event log support for RTMRs, addressing the > > > > fact that the standalone values of RTMRs, which represent the > > > > cumulative digests of sequential events, are not fully > > > > informative on their own. > > > > > > Would each event_log include the events that firmware wrote before > > > Linux? > > > > No. The log format proposed here is textual and incompatible with > > TCG2 log format. > > > > The proposed log format is based on the CoCo event log - > > https://github.com/confidential-containers/guest-components/issues/495 > > . > > Given that AMD is planning to use the SVSM-vTPM for post launch > measurements, not supporting TPMs in any form would make this Intel > only on x86 and thus not very "unified". Microsoft also tends to do > attestations partly via the vTPM in its L1 openHCL component (even for > TDX) and thus would also have difficulty adopting this proposal. > Hi James, I don't think the patch should be blocked for not supporting the SVSM-vTPM and it is not an Intel only patch. 1. Not everyone prefers the SVSM-vTPM as it lacks the persistent storage and does not comply with TCG's TPM specifications. TPM is not just about the measurement. Sealing and unsealing data is also a critical functionality for TPM. Treating thenSVSM-vTPM as a TPM misleads users and disrupts existing software based on TPMs. The SVSM-vTPM is not TPM. Just like Javascript is not Java. 2. If our goal is to measure the boot chain and post-launch, the RTMR is an effective and straightforward method. We already support RTMR for TDX. For SNP, simulating the RTMRs in SVSM is very simple while implementing the SVSM-vTPM needs a lot of changes. The SVSM-vTPM significantly expands the TCB while offering limited security value enhancements compared to the RTMR. 3. RTMR as a technology has been adopted widely. It is not an Intel only technology. The TDX CVMs on Google Cloud already support RTMRs. The TDX CVMs [1] on Alibaba Cloud supports RTMR as well. In terms of the attestation verifiers, the token from Intel ITA [2] and Microsoft Attestation Service [3] indicate they support RTMRs. The Ubuntu image [4] from Canonical enables RTMR by default. Link: [1] https://www.alibabacloud.com/help/en/ecs/user-guide/build-a-tdx-confidential-computing-environment [2] https://docs.trustauthority.intel.com/main/restapi/attestation-v2.html [3] https://learn.microsoft.com/en-us/azure/attestation/attestation-token-examples [4] https://ubuntu.com/blog/deploy-confidential-computing-intel-tdx-ubuntu-2404 Thanks, Qinkun
On Wed, 2024-09-11 at 21:46 +0800, Qinkun Bao wrote: > On Wed, Sep 11, 2024 at 8:06 PM James Bottomley > <James.Bottomley@hansenpartnership.com> wrote: > > > > On Tue, 2024-09-10 at 23:01 -0500, Xing, Cedric wrote: > > > On 9/10/2024 12:09 PM, Jean-Philippe Brucker wrote: > > > > Hi Cedric, > > > > > > > > On Sat, Sep 07, 2024 at 11:56:18PM -0500, Cedric Xing wrote: > > > > > Patch 2 introduces event log support for RTMRs, addressing > > > > > the fact that the standalone values of RTMRs, which represent > > > > > the cumulative digests of sequential events, are not fully > > > > > informative on their own. > > > > > > > > Would each event_log include the events that firmware wrote > > > > before Linux? > > > > > > No. The log format proposed here is textual and incompatible with > > > TCG2 log format. > > > > > > The proposed log format is based on the CoCo event log - > > > https://github.com/confidential-containers/guest-components/issues/495 > > > . > > > > Given that AMD is planning to use the SVSM-vTPM for post launch > > measurements, not supporting TPMs in any form would make this Intel > > only on x86 and thus not very "unified". Microsoft also tends to > > do attestations partly via the vTPM in its L1 openHCL component > > (even for TDX) and thus would also have difficulty adopting this > > proposal. > > > > Hi James, > > I don't think the patch should be blocked for not supporting the > SVSM-vTPM and it is not an Intel only patch. Actually, I'm not objecting to the patch not supporting the TPM, I'm objecting to design choices, like the log, that make it much harder to add TPM support later. Realistically if you want a universal measurement ABI, it has to work for physical systems as well, which means TPM or DICE, since RTMR is a bit non-standard. > 1. Not everyone prefers the SVSM-vTPM as it lacks the persistent > storage and does not comply with TCG's TPM specifications. TPM is not > just about the measurement. I think you'll find an ephemeral TPM is TCG compliant: the NV is actually an additional profile in the TCG specifications. > Sealing and unsealing data is also a critical functionality for TPM. > Treating thenSVSM-vTPM as a TPM misleads users and disrupts existing > software based on TPMs. The SVSM-vTPM is not TPM. Just like > Javascript is not Java. I've already explained several times how sealing and unsealing can be done with an ephemeral TPM. I'm not going to get into prejudices about naming. > 2. If our goal is to measure the boot chain and post-launch, the RTMR > is an effective and straightforward method. We already support RTMR > for TDX. For SNP, simulating the RTMRs in SVSM is very simple while > implementing the SVSM-vTPM needs a lot of changes. in the upstream, the vTPM is already done. There's no current pull request for RTMR emulation. > The SVSM-vTPM significantly expands the TCB while offering limited > security value enhancements compared to the RTMR. So would every other feature on the coconut roadmap. > 3. RTMR as a technology has been adopted widely. It is not an Intel > only technology. The TDX CVMs on Google Cloud already support RTMRs. > The TDX CVMs [1] on Alibaba Cloud supports RTMR as well. In terms of > the attestation verifiers, the token from Intel ITA [2] and Microsoft > Attestation Service [3] indicate they support RTMRs. The Ubuntu image > [4] from Canonical enables RTMR by default. So you think Intel should abandon its work on ephemeral vTPMs for TDX? Regards, James
Hi James, I would like to clarify that, even though the log format is incompatible with the existing TCG2 log format, nothing prevents TPM PCRs from being exposed through the TSM measurement framework. Please note that the existing event types in the TCG2 log format are predominantly BIOS/firmware-oriented, which seldom makes sense for applications in OS runtime. Consequently, most application-specific events have to come under the EV_EVENT_TAG umbrella, which is essentially arbitrary binary data with no specific format. Thus, I don't see much value in continuing the TCG2 log into OS runtime IMHO. The proposed log format aims to provide a framework for unambiguous hashing while allowing application-defined events. Its primary design objective is to enable application-agnostic kernel/verifier to hash/verify logs without understanding the event records, allowing application-specific appraisers to be built on top (i.e., semantics/storage separation). Both TCG2 and CEL formats rely on event/content type to dictate what part of event data to hash, making semantics/storage separation impossible. Therefore, this proposed log format cannot accommodate entries from TCG2 or CEL logs due to that design conflict. However, entries of this log can easily be encapsulated in TCG2 (as EV_ACTION entries) or CEL-JSON (a new content type string needs to be defined, like what systemd is doing today) logs. -Cedric On 9/11/2024 9:10 AM, James Bottomley wrote: > On Wed, 2024-09-11 at 21:46 +0800, Qinkun Bao wrote: >> On Wed, Sep 11, 2024 at 8:06 PM James Bottomley >> <James.Bottomley@hansenpartnership.com> wrote: >>> >>> On Tue, 2024-09-10 at 23:01 -0500, Xing, Cedric wrote: >>>> On 9/10/2024 12:09 PM, Jean-Philippe Brucker wrote: >>>>> Hi Cedric, >>>>> >>>>> On Sat, Sep 07, 2024 at 11:56:18PM -0500, Cedric Xing wrote: >>>>>> Patch 2 introduces event log support for RTMRs, addressing >>>>>> the fact that the standalone values of RTMRs, which represent >>>>>> the cumulative digests of sequential events, are not fully >>>>>> informative on their own. >>>>> >>>>> Would each event_log include the events that firmware wrote >>>>> before Linux? >>>> >>>> No. The log format proposed here is textual and incompatible with >>>> TCG2 log format. >>>> >>>> The proposed log format is based on the CoCo event log - >>>> https://github.com/confidential-containers/guest-components/issues/495 >>>> . >>> >>> Given that AMD is planning to use the SVSM-vTPM for post launch >>> measurements, not supporting TPMs in any form would make this Intel >>> only on x86 and thus not very "unified". Microsoft also tends to >>> do attestations partly via the vTPM in its L1 openHCL component >>> (even for TDX) and thus would also have difficulty adopting this >>> proposal. >>> >> >> Hi James, >> >> I don't think the patch should be blocked for not supporting the >> SVSM-vTPM and it is not an Intel only patch. > > Actually, I'm not objecting to the patch not supporting the TPM, I'm > objecting to design choices, like the log, that make it much harder to > add TPM support later. Realistically if you want a universal > measurement ABI, it has to work for physical systems as well, which > means TPM or DICE, since RTMR is a bit non-standard. > >> 1. Not everyone prefers the SVSM-vTPM as it lacks the persistent >> storage and does not comply with TCG's TPM specifications. TPM is not >> just about the measurement. > > I think you'll find an ephemeral TPM is TCG compliant: the NV is > actually an additional profile in the TCG specifications. > >> Sealing and unsealing data is also a critical functionality for TPM. >> Treating thenSVSM-vTPM as a TPM misleads users and disrupts existing >> software based on TPMs. The SVSM-vTPM is not TPM. Just like >> Javascript is not Java. > > I've already explained several times how sealing and unsealing can be > done with an ephemeral TPM. I'm not going to get into prejudices about > naming. > >> 2. If our goal is to measure the boot chain and post-launch, the RTMR >> is an effective and straightforward method. We already support RTMR >> for TDX. For SNP, simulating the RTMRs in SVSM is very simple while >> implementing the SVSM-vTPM needs a lot of changes. > > in the upstream, the vTPM is already done. There's no current pull > request for RTMR emulation. > >> The SVSM-vTPM significantly expands the TCB while offering limited >> security value enhancements compared to the RTMR. > > So would every other feature on the coconut roadmap. > >> 3. RTMR as a technology has been adopted widely. It is not an Intel >> only technology. The TDX CVMs on Google Cloud already support RTMRs. >> The TDX CVMs [1] on Alibaba Cloud supports RTMR as well. In terms of >> the attestation verifiers, the token from Intel ITA [2] and Microsoft >> Attestation Service [3] indicate they support RTMRs. The Ubuntu image >> [4] from Canonical enables RTMR by default. > > So you think Intel should abandon its work on ephemeral vTPMs for TDX? > > Regards, > > James > >
On Wed, 2024-09-11 at 22:23 -0500, Xing, Cedric wrote: > Hi James, > > I would like to clarify that, even though the log format is > incompatible with the existing TCG2 log format, nothing prevents TPM > PCRs from being exposed through the TSM measurement framework. Well, the PCRs are already exposed through /sys/class/tpm/tpm0/pcr-<algo>/<n> but they don't have much meaning without the log. > Please note that the existing event types in the TCG2 log format are > predominantly BIOS/firmware-oriented, which seldom makes sense for > applications in OS runtime. Consequently, most application-specific > events have to come under the EV_EVENT_TAG umbrella, which is > essentially arbitrary binary data with no specific format. Thus, I > don't see much value in continuing the TCG2 log into OS runtime IMHO. And the IMA log, which is runtime and isn't TCG2? > The proposed log format aims to provide a framework for unambiguous > hashing while allowing application-defined events. Its primary design > objective is to enable application-agnostic kernel/verifier to > hash/verify logs without understanding the event records, allowing > application-specific appraisers to be built on top (i.e., > semantics/storage separation). Both TCG2 and CEL formats rely on > event/content type to dictate what part of event data to hash, making > semantics/storage separation impossible. Therefore, this proposed log > format cannot accommodate entries from TCG2 or CEL logs due to that > design conflict. However, entries of this log can easily be > encapsulated in TCG2 (as EV_ACTION entries) or CEL-JSON (a new > content type string needs to be defined, like what systemd is doing > today) logs. But that's my complaint. This specification: - Records are lines ending with `\n`. - Each record (line) is hashed in its entirety (excluding the trailing `\n`) and extended to the RTMR. - The log for an RTMR is stored at `/sys/kernel/tsm/<MR group name>/<RTMR name>/event_log` and consists of these delineated records. - Lines that are empty (containing only `\n`) or start with `#` are skipped (not hashed or extended). Is completely incompatible with pretty much every current log format. Given you have fairly elaborate decorations for the register formats, what's the problem with simply having a decoration for the log format? That way you can use the above incompatible log for your purpose but this framework can support existing logs and expand to future ones as they come along. All this would mean initially to the code is adding the decoration file (easy) and ensuring that append_event is handled by a log format specific component, allowing for expansion. James
On 9/12/2024 7:15 AM, James Bottomley wrote:
> On Wed, 2024-09-11 at 22:23 -0500, Xing, Cedric wrote:
>> Hi James,
>>
>> I would like to clarify that, even though the log format is
>> incompatible with the existing TCG2 log format, nothing prevents TPM
>> PCRs from being exposed through the TSM measurement framework.
>
> Well, the PCRs are already exposed through
>
TPM predates TSM so has an existing implementation for sure.
> /sys/class/tpm/tpm0/pcr-<algo>/<n>
>
> but they don't have much meaning without the log.
>
Consolidating PCRs under TSM is not a requirement. But if it's
desirable, it could be done. When it comes to the log, the assumption
here is that we will switch log format after TSM takes over. The preboot
log can stay where it is today. Yeah, it would be kinda ugly without a
unified log, but the separation of semantics/storage is more important,
because otherwise it will be very difficult to enable new applications.
>> Please note that the existing event types in the TCG2 log format are
>> predominantly BIOS/firmware-oriented, which seldom makes sense for
>> applications in OS runtime. Consequently, most application-specific
>> events have to come under the EV_EVENT_TAG umbrella, which is
>> essentially arbitrary binary data with no specific format. Thus, I
>> don't see much value in continuing the TCG2 log into OS runtime IMHO.
>
> And the IMA log, which is runtime and isn't TCG2?
>
By "TCG2", I refer to the TPM PC client profile that defines the EV_*
event types. I could be very wrong but I thought IMA content/event types
had not been defined until CEL came along. Though both TCG2 and CEL were
designed to be extensible, adding new event/content types would require
revising the specs, which is a very high bar for new applications, and
is one of the major reasons for introducing this new log format.
Regarding the IMA log, there are several options to integrate it into
the TSM framework:
One straight forward option is to dedicate a RTMR for IMA use. This
series allows off-log extension so nothing else (except mapping the PCR
to the dedicated RTMR) needs changes.
The second option is to change IMA to use the new log format proposed
here. Of course, it'd require more changes than the first option - I
don't believe many people would like it at the moment.
The third option is "virtual measurement". We can define a virtual MR -
say "mr_ima", to replace the current PCR. Then we back mr_ima by a real
RTMR by logging the value extended to mr_ima. That is: when mr_ima is
extended by value XYZ, an entry like "mr_ima extend <hash_algo>/XYZ" is
logged to some native RTMR. Later on, the verifier can replay the RTMR
log to calculate an mr_ima value that matches the IMA's log. This is
actually an example of sharing an RTMR among multiple arbitrary
applications. Events from different applications can be distinguished by
the prefix ("mr_ima" in this example), and a layered verifier can be
built - the bottom CC-specific layer verifies the integrity of the log
without understanding IMA, then the top (CC-agnostic) layer verifies the
IMA log using calculated "mr_ima" value by the bottom layer.
>> The proposed log format aims to provide a framework for unambiguous
>> hashing while allowing application-defined events. Its primary design
>> objective is to enable application-agnostic kernel/verifier to
>> hash/verify logs without understanding the event records, allowing
>> application-specific appraisers to be built on top (i.e.,
>> semantics/storage separation). Both TCG2 and CEL formats rely on
>> event/content type to dictate what part of event data to hash, making
>> semantics/storage separation impossible. Therefore, this proposed log
>> format cannot accommodate entries from TCG2 or CEL logs due to that
>> design conflict. However, entries of this log can easily be
>> encapsulated in TCG2 (as EV_ACTION entries) or CEL-JSON (a new
>> content type string needs to be defined, like what systemd is doing
>> today) logs.
>
> But that's my complaint. This specification:
>
> - Records are lines ending with `\n`.
> - Each record (line) is hashed in its entirety (excluding the
> trailing `\n`) and extended to the RTMR.
> - The log for an RTMR is stored at
> `/sys/kernel/tsm/<MR group name>/<RTMR name>/event_log` and consists
> of these delineated records.
> - Lines that are empty (containing only `\n`) or start with `#` are
> skipped (not hashed or extended).
>
> Is completely incompatible with pretty much every current log format.
Unfortunately this is true, because this log format has different design
objectives than pretty much all existing log formats. Another notable
difference is this ABI is log oriented, vs. most existing log formats
are digest oriented. A log oriented design allows applications to
generate identical logs regardless of the underlying CC arch.
> Given you have fairly elaborate decorations for the register formats,
> what's the problem with simply having a decoration for the log format?
> That way you can use the above incompatible log for your purpose but this
> framework can support existing logs and expand to future ones as they come
> along. All this would mean initially to the code is adding the decoration
> file (easy) and ensuring that append_event is handled by a log format
> specific component, allowing for expansion.
>
Using CEL terms, ELCD (Event Log Critical Data) could be easily
encapsulated in both TCG2 and CEL, but ELID (Event Log Informative Data
- i.e., lines starting with '#') is not. One use of ELID is to support
off-log extension, designed to help migrating existing applications. The
`SYNC` lines (necessary after off-log extensions, see Patch 2 for
details) would also require special treatments from the verifier.
Therefore, converting this log to a TCG2 or CEL log is NOT always
doable. It'll be better to convert log format only when needed (and
before any off-log extensions have been done).
-Cedric
On Thu, 2024-09-12 at 14:00 -0500, Xing, Cedric wrote: > On 9/12/2024 7:15 AM, James Bottomley wrote: > > On Wed, 2024-09-11 at 22:23 -0500, Xing, Cedric wrote: [...] > > > The proposed log format aims to provide a framework for > > > unambiguous hashing while allowing application-defined events. > > > Its primary design objective is to enable application-agnostic > > > kernel/verifier to hash/verify logs without understanding the > > > event records, allowing application-specific appraisers to be > > > built on top (i.e., semantics/storage separation). Both TCG2 and > > > CEL formats rely on event/content type to dictate what part of > > > event data to hash, making semantics/storage separation > > > impossible. Therefore, this proposed log format cannot > > > accommodate entries from TCG2 or CEL logs due to that > > > design conflict. However, entries of this log can easily be > > > encapsulated in TCG2 (as EV_ACTION entries) or CEL-JSON (a new > > > content type string needs to be defined, like what systemd is > > > doing today) logs. > > > > But that's my complaint. This specification: > > > > - Records are lines ending with `\n`. > > - Each record (line) is hashed in its entirety (excluding the > > trailing `\n`) and extended to the RTMR. > > - The log for an RTMR is stored at > > `/sys/kernel/tsm/<MR group name>/<RTMR name>/event_log` and > > consists > > of these delineated records. > > - Lines that are empty (containing only `\n`) or start with `#` > > are > > skipped (not hashed or extended). > > > > Is completely incompatible with pretty much every current log > > format. > > Unfortunately this is true, because this log format has different > design objectives than pretty much all existing log formats. Another > notable difference is this ABI is log oriented, vs. most existing log > formats are digest oriented. A log oriented design allows > applications to generate identical logs regardless of the underlying > CC arch. So you're saying in order to get this to work successfully you have to design a better log. I'm afraid I now have to quote xkcd 927 to you: https://xkcd.com/927/ > > Given you have fairly elaborate decorations for the register > > formats, what's the problem with simply having a decoration for the > > log format? That way you can use the above incompatible log for > > your purpose but this framework can support existing logs and > > expand to future ones as they come along. All this would mean > > initially to the code is adding the decoration file (easy) and > > ensuring that append_event is handled by a log format specific > > component, allowing for expansion. > > > Using CEL terms, ELCD (Event Log Critical Data) could be easily > encapsulated in both TCG2 and CEL, but ELID (Event Log Informative > Data - i.e., lines starting with '#') is not. One use of ELID is to > support off-log extension, designed to help migrating existing > applications. The `SYNC` lines (necessary after off-log extensions, > see Patch 2 for details) would also require special treatments from > the verifier. Therefore, converting this log to a TCG2 or CEL log is > NOT always doable. It'll be better to convert log format only when > needed (and before any off-log extensions have been done). You seem to be hung up on requiring a single log format. That horse left the stable decades ago and isn't coming back (the CEL attempt to corral it was ultimately not successful). I'm saying we accept that fact and simply expose and extend logs in whatever format they exist in today without forcing them to change. I proposed a mechanism for doing that here: https://lore.kernel.org/linux-coco/86e6659bc8dd135491dc34bdb247caf05d8d2ad8.camel@HansenPartnership.com/ Which seems like it would work with pretty much every current measurement tool (with minor modifications to change a few paths) and even allow you to add your new log format if you insist. Regards, James
On 9/13/2024 7:58 AM, James Bottomley wrote: > On Thu, 2024-09-12 at 14:00 -0500, Xing, Cedric wrote: >> Unfortunately this is true, because this log format has different >> design objectives than pretty much all existing log formats. Another >> notable difference is this ABI is log oriented, vs. most existing log >> formats are digest oriented. A log oriented design allows >> applications to generate identical logs regardless of the underlying >> CC arch. > > So you're saying in order to get this to work successfully you have to > design a better log. I'm afraid I now have to quote xkcd 927 to you: > > https://xkcd.com/927/ > I read that long time ago. Really a great article! Am I defining a new log format? Well, yes and no. I hope my response to another email from you could be helpful. My intention is to separate semantics from storage of logs. So yes, I'm defining a new format for storing event records. But no, I'm not trying to impose any specific semantics. In fact, with the shared storage layer, we will be able to support a diverse range of semantics from various applications with just a single RTMR. >> Using CEL terms, ELCD (Event Log Critical Data) could be easily >> encapsulated in both TCG2 and CEL, but ELID (Event Log Informative >> Data - i.e., lines starting with '#') is not. One use of ELID is to >> support off-log extension, designed to help migrating existing >> applications. The `SYNC` lines (necessary after off-log extensions, >> see Patch 2 for details) would also require special treatments from >> the verifier. Therefore, converting this log to a TCG2 or CEL log is >> NOT always doable. It'll be better to convert log format only when >> needed (and before any off-log extensions have been done). > > You seem to be hung up on requiring a single log format. That horse > left the stable decades ago and isn't coming back (the CEL attempt to > corral it was ultimately not successful). I'm saying we accept that > fact and simply expose and extend logs in whatever format they exist in > today without forcing them to change. Can't agree more. Therefore, to allow even more log formats (semantics), a common storage layer is desired to allow event records of different semantics to be mixed and separated at the same time. This is like a filesystem, on which data from different applications are mixed (on the block device) but still separated (at the file level). -Cedric
On Thu, 2024-09-12 at 14:00 -0500, Xing, Cedric wrote:
> On 9/12/2024 7:15 AM, James Bottomley wrote:
> > On Wed, 2024-09-11 at 22:23 -0500, Xing, Cedric wrote:
> > > Hi James,
> > >
> > > I would like to clarify that, even though the log format is
> > > incompatible with the existing TCG2 log format, nothing prevents
> > > TPM
> > > PCRs from being exposed through the TSM measurement framework.
> >
> > Well, the PCRs are already exposed through
> >
> TPM predates TSM so has an existing implementation for sure.
>
> > /sys/class/tpm/tpm0/pcr-<algo>/<n>
> >
> > but they don't have much meaning without the log.
> >
> Consolidating PCRs under TSM is not a requirement.
As I keep saying I'm not expecting you to do it. However, it will be a
requirement for consolidating AMD SNP under this using the SVSM-vTPM,
so I do expect someone will do it.
> But if it's desirable, it could be done. When it comes to the log,
> the assumption here is that we will switch log format after TSM takes
> over. The preboot log can stay where it is today. Yeah, it would be
> kinda ugly without a unified log, but the separation of
> semantics/storage is more important, because otherwise it will be
> very difficult to enable new applications.
I really don't think you'd want to do that because it creates a bigger
mess for all the tools if you keep using the same PCRs because now they
have to know where the log switches and how to change the extensions.
There's no tool today that can do this.
> > > Please note that the existing event types in the TCG2 log format
> > > are predominantly BIOS/firmware-oriented, which seldom makes
> > > sense for applications in OS runtime. Consequently, most
> > > application-specific events have to come under the EV_EVENT_TAG
> > > umbrella, which is essentially arbitrary binary data with no
> > > specific format. Thus, I don't see much value in continuing the
> > > TCG2 log into OS runtime IMHO.
> >
> > And the IMA log, which is runtime and isn't TCG2?
> >
> By "TCG2", I refer to the TPM PC client profile that defines the EV_*
> event types. I could be very wrong but I thought IMA content/event
> types had not been defined until CEL came along.
The IMA log has always been defined in
Documentation/security/IMA-templates
Even before CEL tried to add it as a format.
> Though both TCG2 and CEL were designed to be extensible, adding new
> event/content types would require revising the specs, which is a very
> high bar for new applications, and is one of the major reasons for
> introducing this new log format.
>
> Regarding the IMA log, there are several options to integrate it into
> the TSM framework:
>
> One straight forward option is to dedicate a RTMR for IMA use. This
> series allows off-log extension so nothing else (except mapping the
> PCR to the dedicated RTMR) needs changes.
I don't see how that would help: From the IMA point of view there's no
practical difference between extending a PCR and extending a RTMR (it's
the same mathematical operation). The difference is how you get the
quote and verify the log matches it.
I do note that since the whole problem boils down to the different
quoting mechanism between TPM and RTMR, it is entirely possible, since
the Quoting Enclave is all in software, for them to produce a TPM quote
even for RTMR measurements that could be verified against some external
key. That way all the IMA tools would just work for RTMRs (which would
seem to me to be a much easier way of getting them to work with RTMRs).
It's always baffled me why Intel is so adamant that every existing
measurement tool and pathway should be rewritten for the RTMR approach
instead of simply being compatible enough to get existing tools to work
with RTMRs. You can still keep the current RTMR quote format and the
certificate chain, simply add the ability to produce a signature that
matches the usual TPM quote. Since a quote is only a signature over a
public key, the tools would work and the only difference is how you
confirm the certificate chain.
> The second option is to change IMA to use the new log format proposed
> here. Of course, it'd require more changes than the first option - I
> don't believe many people would like it at the moment.
I think that's true, yes. And that's precisely the problem with this
proposal: you're completely pejorative about log format but know that
no-one is going to change to the format you're trying to mandate.
> The third option is "virtual measurement". We can define a virtual MR
> -
> say "mr_ima", to replace the current PCR. Then we back mr_ima by a
> real RTMR by logging the value extended to mr_ima. That is: when
> mr_ima is extended by value XYZ, an entry like "mr_ima extend
> <hash_algo>/XYZ" is logged to some native RTMR. Later on, the
> verifier can replay the RTMR log to calculate an mr_ima value that
> matches the IMA's log. This is actually an example of sharing an RTMR
> among multiple arbitrary applications. Events from different
> applications can be distinguished by the prefix ("mr_ima" in this
> example), and a layered verifier can be built - the bottom CC-
> specific layer verifies the integrity of the log without
> understanding IMA, then the top (CC-agnostic) layer verifies
> the IMA log using calculated "mr_ima" value by the bottom layer.
But this sounds even worse. You're adding an extra layer and an extra
logging tool simply to verify the PCR/RTMR quote and then after that
you need to us IMA tools to verify the log.
James
On 9/13/2024 7:55 AM, James Bottomley wrote:
> On Thu, 2024-09-12 at 14:00 -0500, Xing, Cedric wrote:
>> By "TCG2", I refer to the TPM PC client profile that defines the EV_*
>> event types. I could be very wrong but I thought IMA content/event
>> types had not been defined until CEL came along.
>
> The IMA log has always been defined in
>
> Documentation/security/IMA-templates
>
> Even before CEL tried to add it as a format.
>
We are on the same page. The TCG PC client profile spec didn't define
IMA specific events. So IMA invented its own, and then was included into
CEL.
>> Though both TCG2 and CEL were designed to be extensible, adding new
>> event/content types would require revising the specs, which is a very
>> high bar for new applications, and is one of the major reasons for
>> introducing this new log format.
>>
>> Regarding the IMA log, there are several options to integrate it into
>> the TSM framework:
>>
>> One straight forward option is to dedicate a RTMR for IMA use. This
>> series allows off-log extension so nothing else (except mapping the
>> PCR to the dedicated RTMR) needs changes.
>
> I don't see how that would help: From the IMA point of view there's no
> practical difference between extending a PCR and extending a RTMR (it's
> the same mathematical operation). The difference is how you get the
> quote and verify the log matches it.
>
> I do note that since the whole problem boils down to the different
> quoting mechanism between TPM and RTMR, it is entirely possible, since
> the Quoting Enclave is all in software, for them to produce a TPM quote
> even for RTMR measurements that could be verified against some external
> key. That way all the IMA tools would just work for RTMRs (which would
> seem to me to be a much easier way of getting them to work with RTMRs).
> It's always baffled me why Intel is so adamant that every existing
> measurement tool and pathway should be rewritten for the RTMR approach
> instead of simply being compatible enough to get existing tools to work
> with RTMRs. You can still keep the current RTMR quote format and the
> certificate chain, simply add the ability to produce a signature that
> matches the usual TPM quote. Since a quote is only a signature over a
> public key, the tools would work and the only difference is how you
> confirm the certificate chain.
>
There's significant difference in the trust model betweem TPM and CC
TEEs. Specifically, in the TPM case the CRTM (usually the BIOS boot
block) is simply trusted, while in the case of CC TEEs the CRTM (pretty
much equivalent to the initial memory image) is measured. Additionally,
TPM is soldered to a physical platform while TEEs can be migrated from
platform to platform. Moreover, certain TEE implementations, like Intel
TDX, rely on additional modules for security (e.g., TDX module, SEAM
loader ACM, microcode), and some of those can be updated without
rebooting (i.e., without tearing down TDs). Therefore, a "full" TD quote
(which is still a work in progress) will have to convey more evidence
than the current TPM quote format can possibly accommodate. That is,
even if the Quoting Enclave (or Quoting TD in future) can sign a TPM
quote (e.g., by striping off everything other than RTMRs), an
attestation service would still have to verify/appraise other evidence
conveyed outside of the TPM quote to establish trust in the TPM quote. I
believe there are similar problems in other CC archs/implementations.
>> The second option is to change IMA to use the new log format proposed
>> here. Of course, it'd require more changes than the first option - I
>> don't believe many people would like it at the moment.
>
> I think that's true, yes. And that's precisely the problem with this
> proposal: you're completely pejorative about log format but know that
> no-one is going to change to the format you're trying to mandate.
>
I'm not trying to mandate the format. I presented this option briefly to
show that I had considered all possibilities. Also, see my response to
your comment on the 3rd option below.
>> The third option is "virtual measurement". We can define a virtual MR
>> -
>> say "mr_ima", to replace the current PCR. Then we back mr_ima by a
>> real RTMR by logging the value extended to mr_ima. That is: when
>> mr_ima is extended by value XYZ, an entry like "mr_ima extend
>> <hash_algo>/XYZ" is logged to some native RTMR. Later on, the
>> verifier can replay the RTMR log to calculate an mr_ima value that
>> matches the IMA's log. This is actually an example of sharing an RTMR
>> among multiple arbitrary applications. Events from different
>> applications can be distinguished by the prefix ("mr_ima" in this
>> example), and a layered verifier can be built - the bottom CC-
>> specific layer verifies the integrity of the log without
>> understanding IMA, then the top (CC-agnostic) layer verifies
>> the IMA log using calculated "mr_ima" value by the bottom layer.
>
> But this sounds even worse. You're adding an extra layer and an extra
> logging tool simply to verify the PCR/RTMR quote and then after that
> you need to us IMA tools to verify the log.
>
We are facing a challenge similar to what the TCP/IP stack solved many
years ago. Think of it like this: the IMA log is the "application
layer", where the actual data resides. The specific record syntax/format
in the example (i.e., "ima_mr extend <hash_algo>/XYZ") acts like TCP,
with `mr_ima` being a "TCP port". The rules introduced in this series
for identifying event record boundaries and hashing, serve as the "link
layer" to provide data integrity. The ultimate objective of this
"layered measurement/attestation stack" is to allow multiple
applications to share the same physical RTMR without interfering with
each other.
Just as the TCP/IP stack requires different layers to handle various
aspects of data communication, this approach do require additional
tools, especially on the "attestation service" side. Given that we are
just laying the groundwork, I believe the first option will have the
least impact to existing s/w and will suffice for now.
-Cedric
On 11.09.24 06:01, Xing, Cedric wrote:
>
> On 9/10/2024 12:09 PM, Jean-Philippe Brucker wrote:
>> Hi Cedric,
>>
>> On Sat, Sep 07, 2024 at 11:56:18PM -0500, Cedric Xing wrote:
>>> Patch 2 introduces event log support for RTMRs, addressing the fact
>>> that the
>>> standalone values of RTMRs, which represent the cumulative digests of
>>> sequential events, are not fully informative on their own.
>>
>> Would each event_log include the events that firmware wrote before
>> Linux?
> No. The log format proposed here is textual and incompatible with TCG2
> log format.
>
> The proposed log format is based on the CoCo event log -
> https://github.com/confidential-containers/guest-components/issues/495.
>
>> I'm wondering how this coexists with
>> /sys/firmware/acpi/tables/data/CCEL.
> The proposed log will take over after booting to Linux. The `SYNC` line
> in the log captures the RTMR value before it, which can be used to
> verify CCEL left off by the virtual firmware.
>
>> Maybe something like: CCEL only contains pre-Linux events. The TSM
>> driver
>> parses CCEL (using a format specific to the arch, for example TCG2),
>> separates the events by MR and produces event_log files in
>> /sys/kernel/tsm/, possibly in a different format like CEL-TLV. Is that
>> what you envision for TDX?
>>
> CCEL will be pre-Linux only. Given the proposed format is incompatible
> with TCG2 format, I don't think those 2 logs will be merged. But if we
> get any success in this new log format, we may influence the UEFI/OVMF
> community to adopt this new format in future.
>
> We have evaluated both TCG2 and CEL formats but arrived in this new
> format because we'd like to support ALL applications. And the only sane
> way I could figure out is to separate the log into 2 layers - an
> application specific semantics layer (a contract between the application
> and the verifier), and an application agnostic storage layer
> (implemented by the kernel). The common problem of TCG2 and CEL is that
> the event/content tag/type dictates which part of the event data/content
> to hash, meaning the kernel must understand an event record before
> hashing it. And that has prevented an application agnostic storage
> design.
>
> Anyway, this new log can be encapsulated in both CEL-JSON (like what
> systemd is doing today) and TCG2 (using the EV_ACTION event type)
> formats. Please see the CoCo issue (link given above) for more details.
>
>> I ask because I've been looking into this interface for Arm CCA, and
>> having unified event logs available somewhere in /sys/kernel/confg/tsm
>> would be very convenient for users (avoids having to parse and convert
>> different /sys/firmware interfaces along with Linux event logs). I would
>> have put a single event_log in /sys/kernel/config/tsm/report/ but
>> splitting it by MR should work too.
>>
> We have considered one global log vs. per-MR logs. In fact, a global log
> is equivalent to the concatenation of all per-MR logs. We've adopted the
> per-MR approach to keep the log optional - i.e., an RTMR can be extended
> directly (by writing to its `digest` attribute) without a log.
>
> With regard to the location of the MR tree, we picked sysfs because the
> MRs (and associated logs) are global and fit more into the semantics of
> sysfs than configfs. Dan W. and I are also considering moving both
> report/ and measurement/ trees into securityfs. It'll be highly
> appreciated if you (and Alex, and everyone) can share your insights.
>
>> As Alex I believe we need more similarity between the interfaces of
>> static
>> and runtime measurements, because verifiers may benefit from an event
>> log
>> of static measurements. For example Arm could have a configuration like
>> this:
>>
>> struct tsm_measurement_register arm_cca_mrs[] = {
>> { MR_(rim) | TSM_MR_F_R | TSM_MR_F_LOG, HA },
>> { MR_(rem0) | TSM_MR_F_R | TSM_MR_F_X | TSM_MR_F_LOG, HA },
>> ...
>> { MR_(rem3) | TSM_MR_F_R | TSM_MR_F_X | TSM_MR_F_LOG, HA },
>> };
>>
>> Here rim is a static measurement of the initial VM state, impossible to
>> extend but could have an event log. rem0-3 are runtime measurements,
>> extensible by firmware and then Linux. None of the digests can be
>> written
>> directly, only extended and read with calls to the upper layer. The tree
>> would be:
>>
>> /sys/kernel/config/tsm/
>> ├── rim
>> │ ├── digest
>> │ ├── event_log
>> │ └── hash_algo
>> ├── rem0
>> │ ├── digest
>> │ ├── append_event
>> │ ├── event_log
>> │ └── hash_algo
>> ...
>> ├── rem3
>> │ ├── digest
>> │ ├── append_event
>> │ ├── event_log
>> │ └── hash_algo
>> └── report/$name
>> ├── inblob
>> └── outblob
>>
> I see. The desired/missing feature here I think is to allow a CC guest
> driver to supply an "initial log". I can define a LOG bit, which if set,
> will make the MR its own dir with `hash_algo` and `event_log`. And if X
> is also set, then `append_event` will appear as well. Does this sound
> like what Alex and you are looking for?
I don't understand why we want to have 2 separate representations for a
"measurement object": flat file as well as directory. Could you please
elaborate on the rationale why you think it would be desirable to have a
non-directory representation at all? I feel like I'm missing something :)
What if for example next-next-gen SEV-SNP suddenly gains event log
support for its launch digest? We would create needless churn on user
space to dynamically determine whether it should read things as
directory or as file. Or even worse: Newer kernels would simply always
set the LOG bit and we suddenly break the user space ABI for existing
environments that run on current-gen SEV-SNP.
Alex
Amazon Web Services Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597
On 9/11/2024 1:56 AM, Alexander Graf wrote:
>
> On 11.09.24 06:01, Xing, Cedric wrote:
>>
>> On 9/10/2024 12:09 PM, Jean-Philippe Brucker wrote:
>>> Hi Cedric,
>>>
>>> On Sat, Sep 07, 2024 at 11:56:18PM -0500, Cedric Xing wrote:
>>>> Patch 2 introduces event log support for RTMRs, addressing the fact
>>>> that the
>>>> standalone values of RTMRs, which represent the cumulative digests of
>>>> sequential events, are not fully informative on their own.
>>>
>>> Would each event_log include the events that firmware wrote before
>>> Linux?
>> No. The log format proposed here is textual and incompatible with TCG2
>> log format.
>>
>> The proposed log format is based on the CoCo event log -
>> https://github.com/confidential-containers/guest-components/issues/495.
>>
>>> I'm wondering how this coexists with /sys/firmware/acpi/tables/data/
>>> CCEL.
>> The proposed log will take over after booting to Linux. The `SYNC` line
>> in the log captures the RTMR value before it, which can be used to
>> verify CCEL left off by the virtual firmware.
>>
>>> Maybe something like: CCEL only contains pre-Linux events. The TSM
>>> driver
>>> parses CCEL (using a format specific to the arch, for example TCG2),
>>> separates the events by MR and produces event_log files in
>>> /sys/kernel/tsm/, possibly in a different format like CEL-TLV. Is that
>>> what you envision for TDX?
>>>
>> CCEL will be pre-Linux only. Given the proposed format is incompatible
>> with TCG2 format, I don't think those 2 logs will be merged. But if we
>> get any success in this new log format, we may influence the UEFI/OVMF
>> community to adopt this new format in future.
>>
>> We have evaluated both TCG2 and CEL formats but arrived in this new
>> format because we'd like to support ALL applications. And the only sane
>> way I could figure out is to separate the log into 2 layers - an
>> application specific semantics layer (a contract between the application
>> and the verifier), and an application agnostic storage layer
>> (implemented by the kernel). The common problem of TCG2 and CEL is that
>> the event/content tag/type dictates which part of the event data/content
>> to hash, meaning the kernel must understand an event record before
>> hashing it. And that has prevented an application agnostic storage
>> design.
>>
>> Anyway, this new log can be encapsulated in both CEL-JSON (like what
>> systemd is doing today) and TCG2 (using the EV_ACTION event type)
>> formats. Please see the CoCo issue (link given above) for more details.
>>
>>> I ask because I've been looking into this interface for Arm CCA, and
>>> having unified event logs available somewhere in /sys/kernel/confg/tsm
>>> would be very convenient for users (avoids having to parse and convert
>>> different /sys/firmware interfaces along with Linux event logs). I would
>>> have put a single event_log in /sys/kernel/config/tsm/report/ but
>>> splitting it by MR should work too.
>>>
>> We have considered one global log vs. per-MR logs. In fact, a global log
>> is equivalent to the concatenation of all per-MR logs. We've adopted the
>> per-MR approach to keep the log optional - i.e., an RTMR can be extended
>> directly (by writing to its `digest` attribute) without a log.
>>
>> With regard to the location of the MR tree, we picked sysfs because the
>> MRs (and associated logs) are global and fit more into the semantics of
>> sysfs than configfs. Dan W. and I are also considering moving both
>> report/ and measurement/ trees into securityfs. It'll be highly
>> appreciated if you (and Alex, and everyone) can share your insights.
>>
>>> As Alex I believe we need more similarity between the interfaces of
>>> static
>>> and runtime measurements, because verifiers may benefit from an event
>>> log
>>> of static measurements. For example Arm could have a configuration like
>>> this:
>>>
>>> struct tsm_measurement_register arm_cca_mrs[] = {
>>> { MR_(rim) | TSM_MR_F_R | TSM_MR_F_LOG, HA },
>>> { MR_(rem0) | TSM_MR_F_R | TSM_MR_F_X | TSM_MR_F_LOG, HA },
>>> ...
>>> { MR_(rem3) | TSM_MR_F_R | TSM_MR_F_X | TSM_MR_F_LOG, HA },
>>> };
>>>
>>> Here rim is a static measurement of the initial VM state, impossible to
>>> extend but could have an event log. rem0-3 are runtime measurements,
>>> extensible by firmware and then Linux. None of the digests can be
>>> written
>>> directly, only extended and read with calls to the upper layer. The tree
>>> would be:
>>>
>>> /sys/kernel/config/tsm/
>>> ├── rim
>>> │ ├── digest
>>> │ ├── event_log
>>> │ └── hash_algo
>>> ├── rem0
>>> │ ├── digest
>>> │ ├── append_event
>>> │ ├── event_log
>>> │ └── hash_algo
>>> ...
>>> ├── rem3
>>> │ ├── digest
>>> │ ├── append_event
>>> │ ├── event_log
>>> │ └── hash_algo
>>> └── report/$name
>>> ├── inblob
>>> └── outblob
>>>
>> I see. The desired/missing feature here I think is to allow a CC guest
>> driver to supply an "initial log". I can define a LOG bit, which if set,
>> will make the MR its own dir with `hash_algo` and `event_log`. And if X
>> is also set, then `append_event` will appear as well. Does this sound
>> like what Alex and you are looking for?
>
>
> I don't understand why we want to have 2 separate representations for a
> "measurement object": flat file as well as directory. Could you please
> elaborate on the rationale why you think it would be desirable to have a
> non-directory representation at all? I feel like I'm missing something :)
>
The intention is to make a cleaner user interface. Generally, the flat
files contain information ready to be consumed by applications, while
those in directories are less ready - e.g., the log may have to be
parsed to extract the measurements of interest. In the case of TDX,
MRCONFIGID, MROWNER, and MROWNERCONFIG are essentially 3 arbitrary
48-byte values and would be more straightforward to be presented as 3 files.
The necessity for a log associated with any MR arises from the need to
"share" the MR - i.e., there are more measurements than MRs and there's
a need for those measurements to be assessed/processed individually.
Rather than asking individual applications to parse a log, it'd be
desirable for CC guest drivers to "unpack" the log into a set of
"artificial" MRs consumable by applications. E.g., if a standardized
method for conveying boot time configuration/policies to CVMs were
established to be an array of "artificial" CCR0..CCRn (Cvm Config
Register), a potential implementation could be to store the array within
some static MR's log to be extracted then exposed by the CC guest driver
as a set of flat files. This example of course doesn't mandate flat
files. It simply showcases that there are both simple values and more
complex data in the "measurement tree", and the idea here is to offer an
option to differentiate them (wherever/whenever the CC guest driver sees
fit), with the intention to simplify navigation for users and/or
application developers.
> What if for example next-next-gen SEV-SNP suddenly gains event log
> support for its launch digest? We would create needless churn on user
> space to dynamically determine whether it should read things as
> directory or as file. Or even worse: Newer kernels would simply always
> set the LOG bit and we suddenly break the user space ABI for existing
> environments that run on current-gen SEV-SNP.
>
This is a great point! I'd say, if the log was on the product road map,
the CC guest driver should opt for a directory on day 1. Otherwise, I'd
expect an MR name change with such a semantic shift, and the CC guest
driver could then extract the "old" digest from the log per the original
semantics, and present it under its original name.
Finally, I don't mean to force flat files for static MRs (I once did,
but Jean and you have me convinced :)). It will be just an option.
-Cedric
On 12.09.24 17:43, Xing, Cedric wrote:
>
> On 9/11/2024 1:56 AM, Alexander Graf wrote:
>>
>> On 11.09.24 06:01, Xing, Cedric wrote:
>>>
>>> On 9/10/2024 12:09 PM, Jean-Philippe Brucker wrote:
>>>> Hi Cedric,
>>>>
>>>> On Sat, Sep 07, 2024 at 11:56:18PM -0500, Cedric Xing wrote:
>>>>> Patch 2 introduces event log support for RTMRs, addressing the fact
>>>>> that the
>>>>> standalone values of RTMRs, which represent the cumulative digests of
>>>>> sequential events, are not fully informative on their own.
>>>>
>>>> Would each event_log include the events that firmware wrote before
>>>> Linux?
>>> No. The log format proposed here is textual and incompatible with TCG2
>>> log format.
>>>
>>> The proposed log format is based on the CoCo event log -
>>> https://github.com/confidential-containers/guest-components/issues/495.
>>>
>>>> I'm wondering how this coexists with /sys/firmware/acpi/tables/data/
>>>> CCEL.
>>> The proposed log will take over after booting to Linux. The `SYNC` line
>>> in the log captures the RTMR value before it, which can be used to
>>> verify CCEL left off by the virtual firmware.
>>>
>>>> Maybe something like: CCEL only contains pre-Linux events. The TSM
>>>> driver
>>>> parses CCEL (using a format specific to the arch, for example TCG2),
>>>> separates the events by MR and produces event_log files in
>>>> /sys/kernel/tsm/, possibly in a different format like CEL-TLV. Is that
>>>> what you envision for TDX?
>>>>
>>> CCEL will be pre-Linux only. Given the proposed format is incompatible
>>> with TCG2 format, I don't think those 2 logs will be merged. But if we
>>> get any success in this new log format, we may influence the UEFI/OVMF
>>> community to adopt this new format in future.
>>>
>>> We have evaluated both TCG2 and CEL formats but arrived in this new
>>> format because we'd like to support ALL applications. And the only sane
>>> way I could figure out is to separate the log into 2 layers - an
>>> application specific semantics layer (a contract between the
>>> application
>>> and the verifier), and an application agnostic storage layer
>>> (implemented by the kernel). The common problem of TCG2 and CEL is that
>>> the event/content tag/type dictates which part of the event
>>> data/content
>>> to hash, meaning the kernel must understand an event record before
>>> hashing it. And that has prevented an application agnostic storage
>>> design.
>>>
>>> Anyway, this new log can be encapsulated in both CEL-JSON (like what
>>> systemd is doing today) and TCG2 (using the EV_ACTION event type)
>>> formats. Please see the CoCo issue (link given above) for more details.
>>>
>>>> I ask because I've been looking into this interface for Arm CCA, and
>>>> having unified event logs available somewhere in /sys/kernel/confg/tsm
>>>> would be very convenient for users (avoids having to parse and convert
>>>> different /sys/firmware interfaces along with Linux event logs). I
>>>> would
>>>> have put a single event_log in /sys/kernel/config/tsm/report/ but
>>>> splitting it by MR should work too.
>>>>
>>> We have considered one global log vs. per-MR logs. In fact, a global
>>> log
>>> is equivalent to the concatenation of all per-MR logs. We've adopted
>>> the
>>> per-MR approach to keep the log optional - i.e., an RTMR can be
>>> extended
>>> directly (by writing to its `digest` attribute) without a log.
>>>
>>> With regard to the location of the MR tree, we picked sysfs because the
>>> MRs (and associated logs) are global and fit more into the semantics of
>>> sysfs than configfs. Dan W. and I are also considering moving both
>>> report/ and measurement/ trees into securityfs. It'll be highly
>>> appreciated if you (and Alex, and everyone) can share your insights.
>>>
>>>> As Alex I believe we need more similarity between the interfaces of
>>>> static
>>>> and runtime measurements, because verifiers may benefit from an event
>>>> log
>>>> of static measurements. For example Arm could have a configuration
>>>> like
>>>> this:
>>>>
>>>> struct tsm_measurement_register arm_cca_mrs[] = {
>>>> { MR_(rim) | TSM_MR_F_R | TSM_MR_F_LOG, HA },
>>>> { MR_(rem0) | TSM_MR_F_R | TSM_MR_F_X | TSM_MR_F_LOG, HA },
>>>> ...
>>>> { MR_(rem3) | TSM_MR_F_R | TSM_MR_F_X | TSM_MR_F_LOG, HA },
>>>> };
>>>>
>>>> Here rim is a static measurement of the initial VM state,
>>>> impossible to
>>>> extend but could have an event log. rem0-3 are runtime measurements,
>>>> extensible by firmware and then Linux. None of the digests can be
>>>> written
>>>> directly, only extended and read with calls to the upper layer. The
>>>> tree
>>>> would be:
>>>>
>>>> /sys/kernel/config/tsm/
>>>> ├── rim
>>>> │ ├── digest
>>>> │ ├── event_log
>>>> │ └── hash_algo
>>>> ├── rem0
>>>> │ ├── digest
>>>> │ ├── append_event
>>>> │ ├── event_log
>>>> │ └── hash_algo
>>>> ...
>>>> ├── rem3
>>>> │ ├── digest
>>>> │ ├── append_event
>>>> │ ├── event_log
>>>> │ └── hash_algo
>>>> └── report/$name
>>>> ├── inblob
>>>> └── outblob
>>>>
>>> I see. The desired/missing feature here I think is to allow a CC guest
>>> driver to supply an "initial log". I can define a LOG bit, which if
>>> set,
>>> will make the MR its own dir with `hash_algo` and `event_log`. And if X
>>> is also set, then `append_event` will appear as well. Does this sound
>>> like what Alex and you are looking for?
>>
>>
>> I don't understand why we want to have 2 separate representations for a
>> "measurement object": flat file as well as directory. Could you please
>> elaborate on the rationale why you think it would be desirable to have a
>> non-directory representation at all? I feel like I'm missing
>> something :)
>>
> The intention is to make a cleaner user interface. Generally, the flat
> files contain information ready to be consumed by applications, while
> those in directories are less ready - e.g., the log may have to be
> parsed to extract the measurements of interest. In the case of TDX,
> MRCONFIGID, MROWNER, and MROWNERCONFIG are essentially 3 arbitrary
> 48-byte values and would be more straightforward to be presented as 3
> files.
>
> The necessity for a log associated with any MR arises from the need to
> "share" the MR - i.e., there are more measurements than MRs and there's
> a need for those measurements to be assessed/processed individually.
> Rather than asking individual applications to parse a log, it'd be
> desirable for CC guest drivers to "unpack" the log into a set of
> "artificial" MRs consumable by applications. E.g., if a standardized
> method for conveying boot time configuration/policies to CVMs were
> established to be an array of "artificial" CCR0..CCRn (Cvm Config
> Register), a potential implementation could be to store the array within
> some static MR's log to be extracted then exposed by the CC guest driver
> as a set of flat files. This example of course doesn't mandate flat
> files. It simply showcases that there are both simple values and more
> complex data in the "measurement tree", and the idea here is to offer an
> option to differentiate them (wherever/whenever the CC guest driver sees
> fit), with the intention to simplify navigation for users and/or
> application developers.
I don't follow your argumentation line. Let's look at the SEV-SNP launch
digest. It calculates its "launch digest" hash based on
* Initial page hashes
* Initial VMSA state for vCPUs
Today that means that when you spawn a VM with multiple vCPUs, your
launch digest differs. With an event log, SNP could give you individual
operations that make up the launch digest so you can validate
* memory content is what I want
* vCPU0 state is what I want
* vCPUn state is what I want
while staying completely flexible to the number of initial vCPUs.
Another example: Nitro Enclaves PCRs [1]. While we try hard to not
conflate too many fields into a single PCR, we some times still do. PCR1
for example contains kernel as well as "first initramfs". Maybe you want
to actually have different policies on each of those. Maybe you want to
allow 5 different kernels and 3 different "initial initramfs version" in
any permutation.
Again, you would need an event log to get that.
So even when what we call "boot measurements" are only consumed as final
hashes today, there could absolutely be value in an event log for them.
Since you are proposing a generic mechanism to expose registers + logs,
I still fail to see why we would treat boot measurements different from
runtime measurements.
>
>> What if for example next-next-gen SEV-SNP suddenly gains event log
>> support for its launch digest? We would create needless churn on user
>> space to dynamically determine whether it should read things as
>> directory or as file. Or even worse: Newer kernels would simply always
>> set the LOG bit and we suddenly break the user space ABI for existing
>> environments that run on current-gen SEV-SNP.
>>
> This is a great point! I'd say, if the log was on the product road map,
> the CC guest driver should opt for a directory on day 1. Otherwise, I'd
The great thing about product road maps is that they keep changing.
You're building a generic ABI for user space here that should be able to
be flexible enough to survive for the next 10-20 years. You can't assume
you know everything already.
> expect an MR name change with such a semantic shift, and the CC guest
There is no semantic shift. In the SNP case, we'd still be talking about
the exact same launch digest, just that now we would also learn sub-hash
information.
> driver could then extract the "old" digest from the log per the original
> semantics, and present it under its original name.
>
> Finally, I don't mean to force flat files for static MRs (I once did,
> but Jean and you have me convinced :)). It will be just an option.
I think even allowing flat files in a world where you already identified
multiple uses for a directory structure for objects of similar semantic
is just a bad idea and will lead to pain down the road :)
Alex
[1] https://docs.aws.amazon.com/enclaves/latest/user/set-up-attestation.html
Amazon Web Services Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597
Hey Cedric, On 08.09.24 06:56, Cedric Xing wrote: > NOTE: This patch series introduces the Measurement Register (MR) ABI, and is > largely a continuation of Samuel Ortiz’s previous work on the RTMR ABI [1]. > > This patch series adds a unified interface to TSM core for confidential > computing (CC) guest drivers to provide access to measurement registers (MRs), > which are essential for relying parties (RPs) to verify the integrity of the > computing environment. The interface is structured around > `struct tsm_measurement_provider`, which holds an array of > `struct tsm_measurement_register` and includes operations for reading and > updating MRs. > > The MRs come in two varieties: static and runtime. Static MRs are determined at > the TEE VM (TVM) build time and capture the initial memory image or the > configuration/policy specified by the TVM's owner. In contrast, Runtime MRs > (RTMRs) start with known values, such as all zeros, at TVM build time and are > extended with measurements of loaded code, data, configuration, or executed > actions by the TVM guest during runtime. Is there a particular reason to treat runtime and static measurements separately? In Nitro Enclaves (which I still need to add tsm integration for), both are simply NSM PCRs. "Static" measurements get locked by the initial boot code. "Runtime" measurements can get locked by guest code later in the boot process. But technically, both are the same type of measurement. In fact, other attributes like an additional "hash_algo" to the measurement itself can be useful in general. If the underlying infrastructure allows for a generic event log mechanism, having that easily available here is useful too. So I don't really understand why we would treat static and runtime measurements differently. Can't we just make all of them directories and indicate whether they are (im-)mutable via a file? Alex Amazon Web Services Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597
Hi Alex, Thanks for you comments! On 9/8/2024 12:37 PM, Alexander Graf wrote: > Hey Cedric, > > On 08.09.24 06:56, Cedric Xing wrote: >> NOTE: This patch series introduces the Measurement Register (MR) ABI, >> and is >> largely a continuation of Samuel Ortiz’s previous work on the RTMR ABI >> [1]. >> >> This patch series adds a unified interface to TSM core for confidential >> computing (CC) guest drivers to provide access to measurement >> registers (MRs), >> which are essential for relying parties (RPs) to verify the integrity >> of the >> computing environment. The interface is structured around >> `struct tsm_measurement_provider`, which holds an array of >> `struct tsm_measurement_register` and includes operations for reading and >> updating MRs. >> >> The MRs come in two varieties: static and runtime. Static MRs are >> determined at >> the TEE VM (TVM) build time and capture the initial memory image or the >> configuration/policy specified by the TVM's owner. In contrast, >> Runtime MRs >> (RTMRs) start with known values, such as all zeros, at TVM build time >> and are >> extended with measurements of loaded code, data, configuration, or >> executed >> actions by the TVM guest during runtime. > > > Is there a particular reason to treat runtime and static measurements > separately? In Nitro Enclaves (which I still need to add tsm integration > for), both are simply NSM PCRs. "Static" measurements get locked by the > initial boot code. "Runtime" measurements can get locked by guest code > later in the boot process. But technically, both are the same type of > measurement. > My apologies for the confusion! They are in fact treated in the same way from the CC guest driver's perspective. Here I meant to describe that static and runtime MRs have different properties (like "locked" as you mentioned) so in order to treat them in the same way, we'd have to define the properties in code (i.e., `enum tsm_measurement_register_flag` in include/linux/tsm.h). > In fact, other attributes like an additional "hash_algo" to the > measurement itself can be useful in general. If the underlying > infrastructure allows for a generic event log mechanism, having that > easily available here is useful too. > `hash_algo` is indeed a member of `struct tsm_measurement_register`. > So I don't really understand why we would treat static and runtime > measurements differently. Can't we just make all of them directories and > indicate whether they are (im-)mutable via a file? > Distinguishing them in the user interface makes enumeration of RTMRs easier. Also, there are RTMR specific artifacts that static MRs don't have. The most obvious is the `event_log`. `hash_algo` is less obvious but it is in fact applicable to RTMRs only (the only thing that a static MR has is its value). Adding those to static MRs would confuse users. -Cedric
On 09.09.24 16:55, Xing, Cedric wrote: > Hi Alex, > > Thanks for you comments! > > On 9/8/2024 12:37 PM, Alexander Graf wrote: >> Hey Cedric, >> >> On 08.09.24 06:56, Cedric Xing wrote: >>> NOTE: This patch series introduces the Measurement Register (MR) ABI, >>> and is >>> largely a continuation of Samuel Ortiz’s previous work on the RTMR ABI >>> [1]. >>> >>> This patch series adds a unified interface to TSM core for confidential >>> computing (CC) guest drivers to provide access to measurement >>> registers (MRs), >>> which are essential for relying parties (RPs) to verify the integrity >>> of the >>> computing environment. The interface is structured around >>> `struct tsm_measurement_provider`, which holds an array of >>> `struct tsm_measurement_register` and includes operations for >>> reading and >>> updating MRs. >>> >>> The MRs come in two varieties: static and runtime. Static MRs are >>> determined at >>> the TEE VM (TVM) build time and capture the initial memory image or the >>> configuration/policy specified by the TVM's owner. In contrast, >>> Runtime MRs >>> (RTMRs) start with known values, such as all zeros, at TVM build time >>> and are >>> extended with measurements of loaded code, data, configuration, or >>> executed >>> actions by the TVM guest during runtime. >> >> >> Is there a particular reason to treat runtime and static measurements >> separately? In Nitro Enclaves (which I still need to add tsm integration >> for), both are simply NSM PCRs. "Static" measurements get locked by the >> initial boot code. "Runtime" measurements can get locked by guest code >> later in the boot process. But technically, both are the same type of >> measurement. >> > My apologies for the confusion! They are in fact treated in the same way > from the CC guest driver's perspective. I'm not worried about the driver's perspective to be honest; I'm much more interested in the user space ABI and to ensure it's consistent and flexible :). > Here I meant to describe that static and runtime MRs have different > properties (like "locked" as you mentioned) so in order to treat them in > the same way, we'd have to define the properties in code (i.e., `enum > tsm_measurement_register_flag` in include/linux/tsm.h). > >> In fact, other attributes like an additional "hash_algo" to the >> measurement itself can be useful in general. If the underlying >> infrastructure allows for a generic event log mechanism, having that >> easily available here is useful too. >> > `hash_algo` is indeed a member of `struct tsm_measurement_register`. > >> So I don't really understand why we would treat static and runtime >> measurements differently. Can't we just make all of them directories and >> indicate whether they are (im-)mutable via a file? >> > Distinguishing them in the user interface makes enumeration of RTMRs > easier. Also, there are RTMR specific artifacts that static MRs don't > have. The most obvious is the `event_log`. `hash_algo` is less obvious > but it is in fact applicable to RTMRs only (the only thing that a static > MR has is its value). Adding those to static MRs would confuse users. I think that this statement is looking too much at the problem with TDX glasses on. Conceptually, measurements can happen at any time by any component and then get locked going forward. Let's look a bit at what different solutions do: TDX static - special registers that get written by the secure module and are locked at launch (?); SHA256? No event log; order defined by platform. dynamic - special registers that are mutable at runtime SEV-SNP static - launch digest generated by ASP at launch time using a SEV-SNP specific algorithm. No event log; order defined by platform. dynamic - not specified, would be implemented by an SVSM Nitro Enclaves static - PCR0-15 get calculated and then locked by the boot loader. SHA384. No event log; mechanics to reproduce are defined in docs. dynamic - PCR16-31 are up for customer use and can be locked at any later stage. SHA384. Event log is undefined and up to customer code. All static calculations are based on some algorithm. Yes, the algorithm isn't necessarily a standard digest, but they can all have a name. I can also absolutely see how any of the solutions above gain event log support for static or dynamic measurements. At the end of the day, an event log for static measurements is just a matter of writing it out at launch time. So what I'm trying to say is: In the user space ABI (file system layout), please treat static and dynamic registers identically. There really is no difference between them apart from the fact that some are read-only and others are read-write. Alex Amazon Web Services Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597
On 9/10/2024 2:47 AM, Alexander Graf wrote: > On 09.09.24 16:55, Xing, Cedric wrote: >> Distinguishing them in the user interface makes enumeration of RTMRs >> easier. Also, there are RTMR specific artifacts that static MRs don't >> have. The most obvious is the `event_log`. `hash_algo` is less obvious >> but it is in fact applicable to RTMRs only (the only thing that a static >> MR has is its value). Adding those to static MRs would confuse users. > > > I think that this statement is looking too much at the problem with TDX > glasses on. Conceptually, measurements can happen at any time by any > component and then get locked going forward. Let's look a bit at what > different solutions do: > > TDX > > static - special registers that get written by the secure module and are > locked at launch (?); SHA256? No event log; order defined by platform. > dynamic - special registers that are mutable at runtime > > SEV-SNP > > static - launch digest generated by ASP at launch time using a SEV-SNP > specific algorithm. No event log; order defined by platform. > dynamic - not specified, would be implemented by an SVSM > > Nitro Enclaves > > static - PCR0-15 get calculated and then locked by the boot loader. > SHA384. No event log; mechanics to reproduce are defined in docs. > dynamic - PCR16-31 are up for customer use and can be locked at any > later stage. SHA384. Event log is undefined and up to customer code. > > > All static calculations are based on some algorithm. Yes, the algorithm > isn't necessarily a standard digest, but they can all have a name. I can > also absolutely see how any of the solutions above gain event log > support for static or dynamic measurements. At the end of the day, an > event log for static measurements is just a matter of writing it out at > launch time. > > So what I'm trying to say is: In the user space ABI (file system > layout), please treat static and dynamic registers identically. There > really is no difference between them apart from the fact that some are > read-only and others are read-write. > You are absolute right that all MRs are the same thing, and that's why they are modeled in the same way at the CC guest driver level. In fact, if a CC guest wants to expose all MRs in their own dirs, it could set `TSM_MR_F_X` for all MRs and returns an error from `extend` for static/non-extensible ones. For example, PCR0~31 may all be exposed this way on Nitro. I hope this addresses your concerns.
© 2016 - 2025 Red Hat, Inc.