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

["Xing, Cedric" <cedric.xing@intel.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
> 
> 
>