On Mon, Feb 12, 2024 at 11:36:27PM -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. > > 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? There's also the 'Canonical Event Log' format from TCG. It covers IMA but it looks it's PC/client specific otherwise. systemd seems to be following this format for its systemd-pcr* services and exposing the log in JSON format under /run/log [1]. [1] https://www.freedesktop.org/software/systemd/man/latest/systemd-pcrphase.service.html > > > ...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. 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? For the new TEE measurement log, I don't think it has to be > collocated with the BIOS log, because TEEs are never TPMs. -- Regards, Mikko
