On 11/7/24 2:06 PM, Stefan Berger wrote:
On 11/7/24 7:38 AM, Takashi Iwai wrote:
On Thu, 07 Nov 2024 13:17:33 +0100,
Paul Menzel wrote:
Dear Takashi,
Thank you for the patch.
Am 07.11.24 um 12:18 schrieb Takashi Iwai:
The TPM2 ACPI table may request a large size for the event log, and it
may be over the max size of kmalloc(). When this happens, the driver
What is kmalloc()’s maximum size?
128kB or so, IIRC.
And according Andy, the table can be over 4MB.
Can you copy the contents of the file on that machine and tell us what
size it has:
cp /sys/kernel/security/tpm0/binary_bios_measurements ./
Actually, you may need to have the contents parsed by a user space tool
since the driver does not detect where the actual end may be:
tsseventextend -if ./binary_bios_measurements -sim -v
This may give you a feeling for how much is in that file and then you'd
have to truncate it into half for example and see whether it still
parses the same. My point is that we haven't seen such excessive-sized
logs so far and following the parsing above we may find something like
this more useful than allocating possibly large amounts of memory that a
buggy ACPI table indicates (+ notify manufacturer):
if (len > MAX_TPM_LOG_SIZE) {
dev_err(&chip->dev, "Truncated excessive-sized TPM log of %d
bytes\n", len);
len = MAX_TPM_LOG_SIZE;
}
If you send me the log I'd look at it.
I wonder what the BIOS on that system writes into this file and wouldn't
exclude a buggy BIOS indicating wrong size and producing a much smaller
log.
