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
