Messages in this thread | | | Date | Mon, 4 Mar 2024 17:19:05 -0800 | Subject | Re: [RFC PATCH v2 0/4] tsm: Runtime measurement registers ABI | From | "Xing, Cedric" <> |
| |
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 > > >
| |