James Bottomley wrote: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.
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.
...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.