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
