Re: [PATCH] tpm: Map the ACPI provided event log

[James Bottomley]

On Sun, 2024-12-22 at 17:33 +0200, Jarkko Sakkinen wrote:
> On Sun Dec 22, 2024 at 5:23 PM EET, Jarkko Sakkinen wrote:
> > On Sun Dec 22, 2024 at 5:00 PM EET, James Bottomley wrote:
> > > If event logs grow to greater than KMALLOC_MAX_SIZE then
> > > absolutely it makes sense to map them instead of copying them. 
> > > But we'd have to do that for all event log locators: ACPI, EFI
> > > and OF, because event log size should be independent of the
> > > mechanism used to locate it.  So, even as a long term fix
> > > (assuming we think there's a possibility of logs expanding by
> > > 50x), this patch doesn't do the right thing because it only maps
> > > ACPI logs.
> > 
> > Because we have a test target only on ACPI where this happens fix
> > should still fix only ACPI. It's not hard to reiterate this but 
> > precursory iteration is a bad idea.
> 
> Also, "event log size should be independent of the mechanism used to
> locate it" is a sentence that is sky high too abstract to say much.
> 
> I don't know what it means to be frank.

event log size means the number of bytes from the beginning to the end
of the event log.  Since the event log is created by the pre-boot
environment, there is a convention for how to communicate this
information from pre-boot to the kernel; this is the mechanism used to
locate it.  We decode three mechanisms: an ACPI table, an EFI table and
an OF entry.

The pre-boot environment generating the event log is supposed to
conform to the TCG standards for what events it contains; none of the
entries depends on the mechanism used to locate the log, which is why
the size also can't depend on the mechanis.  There are many optional
events, but even if the pre-boot took a maximalist approach the most it
could contain is a couple of hundred entries.  The variable entries are
mostly small but several types can contain device paths or
certificates, but even if you allow a 10k size for each entry, that's
still at most 2MB.  So I think if a pre-boot declared log area goes
over KMALLOC_MAX_SIZE (4MB on x86) it's safe to truncate the area
because the log will never fill all of it.

The corollary is that if we ever did find an actual log over 4MB, then
the EFI and OF mechanisms used to locate it would also fail in the
kmalloc, which is why KMALLOC_MAX_SIZE is the correct cap for the
declared size.

Regards,

James