tpm: Map the ACPI provided event log
Subsystems (3)
Jarkko Sakkinen
maintainerPATCH v9 1/1 tpm: Map the ACPI provided event log
The following failure was reported:
[ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0) [ 10.848132][ T1] ------------[ cut here ]------------ [ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330 [ 10.862827][ T1] Modules linked in: [ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375 [ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024 [ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330 [ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1 [ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246 [ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000 [ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0
Above shows that ACPI pointed a 16 MiB buffer for the log events because RSI maps to the 'order' parameter of __alloc_pages_noprof(). Address the bug with kvmalloc() and devm_add_action_or_reset().
---
v9:
* Call devm_add_action() as the last step and execute the plain action in the fallback path:
https://lore.kernel.org/linux-integrity/[email protected]/
v8:
* Reduced to only to this quick fix. Let HPE reserve 16 MiB if they want to. We have mapping approach backed up in lore.
v7:
* Use devm_add_action_or_reset().
* Fix tags.
v6:
* A new patch.
--- drivers/char/tpm/eventlog/acpi.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
drivers/char/tpm/eventlog/acpi.c +13 -2
@@ -63,6 +63,11 @@ static bool tpm_is_tpm2_log(void *bios_event_log, u64 len)return n ==0 ; } +static void tpm_bios_log_free (void *data) +{ +kvfree (data); +} +/* read binary bios log */ int tpm_read_log_acpi (struct tpm_chip *chip) {
@@ -136,7 +141,7 @@ int tpm_read_log_acpi(struct tpm_chip *chip) }/* malloc EventLog space */ - log->bios_event_log =devm_kmalloc (&chip->dev, len,GFP_KERNEL ); + log->bios_event_log =kvmalloc (len,GFP_KERNEL );if (!log->bios_event_log)return -ENOMEM ;
@@ -161,10 +166,16 @@ int tpm_read_log_acpi(struct tpm_chip *chip) goto err; } + ret =devm_add_action (&chip->dev, tpm_bios_log_free, log->bios_event_log); +if (ret) { + log->bios_event_log =NULL ; + goto err; + } +return format; err: -devm_kfree (&chip->dev, log->bios_event_log); +tpm_bios_log_free (log->bios_event_log); log->bios_event_log =NULL ;return ret; }
Signature · 1 line
2.48.0
Quoted 14 lines · Jarkko Sakkinen
The following failure was reported:
[ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0) [ 10.848132][ T1] ------------[ cut here ]------------ [ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330 [ 10.862827][ T1] Modules linked in: [ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375 [ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024 [ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330 [ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1 [ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246 [ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000 [ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0
Quoted 3 lines
Above shows that ACPI pointed a 16 MiB buffer for the log events because RSI maps to the 'order' parameter of
__alloc_pages_noprof(). Address the bug withkvmalloc()anddevm_add_action_or_reset().
Before at it was (at least) failing when the BIOS requested an excessive size. Now since you don't want to limit the size of the log I suppose you wouldn't also want to set a size of what is excessive so that the driver could dev_warn() the user of an excessive-sized buffer ...
Quoted 7 lines
Suggested-by Ard Biesheuvel <[email protected]>Cc [email protected] # v2.6.16+Fixes 55a82ab3181b ("[PATCH] tpm: add bios measurement log")Reported-by Andy Liang <[email protected]>Signed-off-by Jarkko Sakkinen <[email protected]>
Quoted 59 lines
---
v9:
* Calldevm_add_action()as the last step and execute the plain action in the fallback path:
https://lore.kernel.org/linux-integrity/[email protected]/
v8:
* Reduced to only to this quick fix. Let HPE reserve 16 MiB if they want to. We have mapping approach backed up in lore.
v7:
* Usedevm_add_action_or_reset().
* Fix tags.
v6:
* A new patch.--- drivers/char/tpm/eventlog/acpi.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)drivers/char/tpm/eventlog/acpi.c +13
-2@@ -63,6 +63,11 @@ static bool tpm_is_tpm2_log(void *bios_event_log, u64 len)return n ==0 ; } +static void tpm_bios_log_free (void *data) +{ +kvfree (data); +} +/* read binary bios log */ int tpm_read_log_acpi (struct tpm_chip *chip) {@@ -136,7 +141,7 @@ int tpm_read_log_acpi(struct tpm_chip *chip) }/* malloc EventLog space */ - log->bios_event_log =devm_kmalloc (&chip->dev, len,GFP_KERNEL ); + log->bios_event_log =kvmalloc (len,GFP_KERNEL ); if (!log->bios_event_log)> return -ENOMEM;@@ -161,10 +166,16 @@ int tpm_read_log_acpi(struct tpm_chip *chip) goto err; } + ret =devm_add_action (&chip->dev, tpm_bios_log_free, log->bios_event_log); +if (ret) { + log->bios_event_log =NULL ; + goto err; + } +return format; err: -devm_kfree (&chip->dev, log->bios_event_log); +tpm_bios_log_free (log->bios_event_log); log->bios_event_log =NULL ;return ret; }
Jarkko Sakkinen
maintainerQuoted 27 lines · Stefan Berger
Quoted 14 lines · Jarkko Sakkinen
The following failure was reported:
[ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0) [ 10.848132][ T1] ------------[ cut here ]------------ [ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330 [ 10.862827][ T1] Modules linked in: [ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375 [ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024 [ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330 [ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1 [ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246 [ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000 [ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0Quoted 3 lines
Above shows that ACPI pointed a 16 MiB buffer for the log events because RSI maps to the 'order' parameter of
__alloc_pages_noprof(). Address the bug withkvmalloc()anddevm_add_action_or_reset().Before at it was (at least) failing when the BIOS requested an excessive size. Now since you don't want to limit the size of the log I suppose you wouldn't also want to set a size of what is excessive so that the driver could
dev_warn()the user of an excessive-sized buffer ...Quoted 1 line
Quoted 8 lines
Quoted 6 lines
Suggested-by Ard Biesheuvel <[email protected]>Cc [email protected] # v2.6.16+Fixes 55a82ab3181b ("[PATCH] tpm: add bios measurement log")Reported-by Andy Liang <[email protected]>Signed-off-by Jarkko Sakkinen <[email protected]>Reviewed-by Stefan Berger <[email protected]>
Sorry there was small glitch because I had a small diff unamended to the commit. See the last diff:
https://lore.kernel.org/linux-integrity/[email protected]/T/#u
I guess the reviewed-by still holds, right? :-)
BR, Jarkko