On Sun Dec 22, 2024 at 7:41 PM EET, James Bottomley wrote: > 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. Have you verified this with the failing system? > > Regards, > > James BR, Jarkko
