James Bottomley wrote: > On Wed, 2024-02-07 at 13:08 -0800, Kuppuswamy Sathyanarayanan wrote: > > > > On 2/7/24 12:16 PM, Xing, Cedric wrote: > > > On 2/6/2024 6:02 PM, Dan Williams wrote: > > > > James Bottomley wrote: > > > > > There isn't really anything more complex about an interface > > > > > that takes a log entry, and does the record an extend, than an > > > > > interface which takes a PCR extension value. So best practice > > > > > would say that you should create the ABI that you can't get > > > > > wrong (log and record) rather than creating one that causes > > > > > additional problems for userspace. > > > > > > > > Agree, there's no need for the kernel to leave deliberately > > > > pointy edges for userspace to trip over. > > > > > > > > Cedric, almost every time we, kernel community, build an > > > > interface where userspace says "trust us, we know what we are > > > > doing" it inevitably results later in "whoops, turns out it would > > > > have helped if the kernel enforced structure here". So the log > > > > ABI adds that structure for the primary use cases. > > > > > > Dan, I agree with your statement generally. But with the precedent > > > of TPM module not maintaining a log, I just wonder if the addition > > > of log would cause problems or force more changes to existing > > > usages than necessary. For example, IMA has its own log and if > > > changed to use RTMR, how would those 2 logs interoperate? We would > > > also need to decide on a log format that can accommodate all > > > applications. > > > > > > IIUC, CC event logging in firmware uses TCG2 format. Since IMA > > internally uses TPM calls, I assume it also uses the TCG2 format. I > > think we can follow the same format for RTMR extension. > > 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.
