Re: [RFC PATCH v2 0/4] tsm: Runtime measurement registers ABI

Xing, Cedric
2024-03-05T01:19:15Z

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
>
>
>