Message-ID: <515aa05c-8ee3-477d-9fca-8db9b186880d@amazon.com>
Date: Fri, 13 Sep 2024 11:43:59 +0200
From: Alexander Graf <graf@...zon.com>
To: "Xing, Cedric" <cedric.xing@...el.com>, Jean-Philippe Brucker
	<jean-philippe@...aro.org>
CC: Dan Williams <dan.j.williams@...el.com>, Samuel Ortiz
	<sameo@...osinc.com>, James Bottomley
	<James.Bottomley@...senpartnership.com>, Lukas Wunner <lukas@...ner.de>,
	Dionna Amalie Glaze <dionnaglaze@...gle.com>, Qinkun Bao <qinkun@...gle.com>,
	Mikko Ylinen <mikko.ylinen@...ux.intel.com>, Kuppuswamy Sathyanarayanan
	<sathyanarayanan.kuppuswamy@...ux.intel.com>, <linux-kernel@...r.kernel.org>,
	<linux-coco@...ts.linux.dev>, <suzuki.poulose@....com>,
	<sami.mujawar@....com>
Subject: Re: [PATCH RFC 0/3] tsm: Unified Measurement Register ABI for TVMs


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

Powered by blists - more mailing lists