From: "Xing, Cedric" <cedric.xing@intel.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
Dan Williams <dan.j.williams@intel.com>,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com>,
Dan Middleton <dan.middleton@linux.intel.com>,
Samuel Ortiz <sameo@rivosinc.com>
Cc: Qinkun Bao <qinkun@google.com>,
"Yao, Jiewen" <jiewen.yao@intel.com>,
Dionna Amalie Glaze <dionnaglaze@google.com>, <biao.lu@intel.com>,
<linux-coco@lists.linux.dev>, <linux-integrity@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH v2 0/4] tsm: Runtime measurement registers ABI
Date: Mon, 4 Mar 2024 17:19:05 -0800 [thread overview]
Message-ID: <3d5ffd62-beff-4394-91e7-715b348b7bae@intel.com> (raw)
In-Reply-To: <982e19fcd71c41a162ba664281eb0a68d9dc960c.camel@HansenPartnership.com>
Hi James,
In the past couple of weeks I've been thinking about what should be a
good log format that can be conformant to existing standards and
accommodate future applications at the same time. After discussing with
folks from Alibaba and Intel internally, I created this issue -
https://github.com/confidential-containers/guest-components/issues/495
to document what I've found. Although it was written for CoCo, the
design I believe is CEL (Canonical Event Log) conformant and generic
enough to be adopted by the kernel. Hence, I revive this thread to
solicit your opinion. Your valuable time and feedback will be highly
appreciated!
Thanks!
-Cedric
On 2/13/2024 8:05 AM, James Bottomley wrote:
> On Mon, 2024-02-12 at 23:36 -0800, Xing, Cedric wrote:
>> On 2/9/2024 12:58 PM, Dan Williams wrote:
>>> James Bottomley wrote:
>>>> Just to correct this: IMA uses its own log format, but I think
>>>> this was a mistake long ago and the new log should use TCG2
>>>> format so all the tools know how to parse it.
>>>
>>> Is this a chance to nudge IMA towards a standard log format? In
>>> other words, one of the goals alongside userspace consumers of the
>>> RTMR log would be for IMA to support it as well as an alternate in-
>>> kernel backend next to TPM. IMA-over-TPM continues with its current
>>> format, IMA-over-RTMR internally unifies with the log format that
>>> is shared with RTMR-user-ABI.
>>>
>> I'm not a TCG expert. As far as I know,
>> https://trustedcomputinggroup.org/wp-content/uploads/TCG-PC-Client-Platform-Firmware-Profile-Version-1.06-Revision-52_pub-1.pdf
>>
>> defines the event types for TCG2 logs for firmware uses only. I
>> cannot find a spec that defines event types for OS or applications.
>> We may reuse the firmware event types for Linux but I doubt they can
>> accommodate IMA.
>
> The TCG crypto agile log format is
>
> index (32 bit),
> event tag (32 bit),
> digests array,
> sized event entry (up to 4GB)
>
> So an IMA log entry can definitely be transformed into this format
> (providing someone agrees to the tag or set of tags). The slight
> problem would be that none of the current IMA tools would understand
> it, but that could be solved over time (the kernel could use the TCG
> format internally but transform to the IMA format for the current
> securityfs IMA log).
>
>> IMHO, we don't have to follow TCG2 format because TDX is never TPM,
>> nor are any other TEEs that support runtime measurements. The
>> existing TCG2 format looks to me somewhat like ASN.1 - well defined
>> but schema is needed to decode. In contrast, JSON is a lot more
>> popular than ASN.1 nowadays because it's human readable and doesn't
>> require a schema. I just wonder if we should introduce a text based
>> log format. We could make the log a text file, in which each line is
>> an event record and the digest of the line is extended to the
>> specified runtime measurement register. The content of each line
>> could be free-form at the ABI level, but we can still recommend a
>> convention for applications - e.g., the first word/column must be an
>> URL for readers to find out the format/syntax of the rest of the
>> line. Thoughts?
>
> https://xkcd.com/927/
>
>>> ...but be warned the above is a comment from someone who knows
>>> nothing about IMA internals, just reacting to the comment.
>>>
>>>
>>>>> I am wondering where will the event log be stored? Is it in the
>>>>> log_area region of CCEL table?
>>>>
>>>> IMA stores its log in kernel memory and makes it visible in
>>>> securityfs (in the smae place as the measured boot log). Since
>>>> this interface is using configfs, that's where I'd make the log
>>>> visible.
>>>>
>>>> Just to add a note about how UEFI works: the measured boot log is
>>>> effectively copied into kernel memory because the UEFI memory it
>>>> once occupied is freed after exit boot services, so no UEFI
>>>> interface will suffice for the log location.
>>>>
>>>> I'd make the file exporting it root owned but probably readable
>>>> by only the people who can also extend it (presumably enforced by
>>>> group?).
>>>
>>> I assume EFI copying into kernel memory is ok because that log has
>>> a limited number of entries. If this RTMR log gets large I assume
>>> it needs some way cull entries that have been moved to storage.
>>> Maybe this is a problem IMA has already solved.
>>
>> We don't have to, and are also not supposed to I guess, append to the
>> log generated by BIOS.
>
> We do actually: the EFI boot stub in the kernel appends entries for the
> initrd and command line.
>
>> The kernel can start a new log, and potentially in a different
>> format. I think the BIOS log is exposed via securityfs today. Am I
>> correct?
>
> I already said that, yes.
>
>> For the new TEE measurement log, I don't think it has to be
>> collocated with the BIOS log, because TEEs are never TPMs.
>
> This depends. Logs are separable by PCRs. As in every entry for the
> same PCR could be in a separate, correctly ordered, log. However, you
> can't have separate logs that both use the same PCR because they won't
> replay.
>
> James
>
>
>
next prev parent reply other threads:[~2024-03-05 1:19 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-28 21:25 [RFC PATCH v2 0/4] tsm: Runtime measurement registers ABI Samuel Ortiz
2024-01-28 21:25 ` [RFC PATCH v2 1/4] tsm: Runtime measurement register support Samuel Ortiz
2024-01-29 16:57 ` Dionna Amalie Glaze
2024-02-01 22:03 ` Jarkko Sakkinen
2024-01-28 21:25 ` [RFC PATCH v2 2/4] tsm: Add RTMRs to the configfs-tsm hierarchy Samuel Ortiz
2024-01-28 22:38 ` Kuppuswamy Sathyanarayanan
2024-02-01 22:05 ` Jarkko Sakkinen
2024-02-21 16:16 ` Mikko Ylinen
2024-01-28 21:25 ` [RFC PATCH v2 3/4] tsm: Map RTMRs to TCG TPM PCRs Samuel Ortiz
2024-01-28 22:44 ` Kuppuswamy Sathyanarayanan
2024-02-02 6:18 ` James Bottomley
2024-01-28 21:25 ` [RFC PATCH v2 4/4] tsm: Allow for extending and reading configured RTMRs Samuel Ortiz
2024-02-01 22:02 ` [RFC PATCH v2 0/4] tsm: Runtime measurement registers ABI Jarkko Sakkinen
2024-02-02 6:24 ` James Bottomley
2024-02-02 23:07 ` Dan Middleton
2024-02-03 6:03 ` James Bottomley
2024-02-03 7:13 ` Kuppuswamy Sathyanarayanan
2024-02-03 10:27 ` James Bottomley
2024-02-06 8:34 ` Xing, Cedric
2024-02-06 8:57 ` James Bottomley
2024-02-07 2:02 ` Dan Williams
2024-02-07 20:16 ` Xing, Cedric
2024-02-07 21:08 ` Kuppuswamy Sathyanarayanan
2024-02-07 21:46 ` James Bottomley
2024-02-09 20:58 ` Dan Williams
2024-02-13 7:36 ` Xing, Cedric
2024-02-13 16:05 ` James Bottomley
2024-02-14 8:54 ` Xing, Cedric
2024-02-15 6:14 ` Dan Williams
2024-02-16 2:05 ` Xing, Cedric
2024-03-05 1:19 ` Xing, Cedric [this message]
2024-04-17 20:23 ` Dan Middleton
2024-02-13 16:54 ` Mikko Ylinen
2024-02-15 22:44 ` Dr. Greg
2024-02-22 15:45 ` Lukas Wunner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3d5ffd62-beff-4394-91e7-715b348b7bae@intel.com \
--to=cedric.xing@intel.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=biao.lu@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dan.middleton@linux.intel.com \
--cc=dionnaglaze@google.com \
--cc=jiewen.yao@intel.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=qinkun@google.com \
--cc=sameo@rivosinc.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.