linux-kernel - Re: [PATCH v3] tpm: Map the ACPI provided event log

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <D6JAUP5NAXZ2.MU9167EXYHGM@kernel.org>
Date: Mon, 23 Dec 2024 20:42:36 +0200
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Jarkko Sakkinen" <jarkko@...nel.org>,
 <linux-integrity@...r.kernel.org>, "Peter Huewe" <peterhuewe@....de>,
 "Jason Gunthorpe" <jgg@...pe.ca>, "Colin Ian King"
 <colin.i.king@...il.com>, "Joe Hattori" <joe@...is.s.u-tokyo.ac.jp>, "James
 Bottomley" <James.Bottomley@...senPartnership.com>, "Stefan Berger"
 <stefanb@...ux.ibm.com>, "Ard Biesheuvel" <ardb@...nel.org>, "Mimi Zohar"
 <zohar@...ux.ibm.com>, "Al Viro" <viro@...iv.linux.org.uk>, "Kylene Jo
 Hall" <kjhall@...ibm.com>, "Seiji Munetoh" <munetoh@...ibm.com>, "Reiner
 Sailer" <sailer@...ibm.com>, "Andrew Morton" <akpm@...l.org>
Cc: <stable@...r.kernel.org>, "Andy Liang" <andy.liang@....com>, "Matthew
 Garrett" <mjg59@...f.ucam.org>, "Roberto Sassu" <roberto.sassu@...wei.com>,
 <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] tpm: Map the ACPI provided event log

On Sun Dec 22, 2024 at 4:30 PM EET, Jarkko Sakkinen wrote:
> 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 by mapping the region when needed instead of copying.
>
> Cc: stable@...r.kernel.org # v2.6.16+
> Fixes: 55a82ab3181b ("[PATCH] tpm: add bios measurement log")
> Reported-by: Andy Liang <andy.liang@....com>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219495
> Suggested-by: Matthew Garrett <mjg59@...f.ucam.org>
> Signed-off-by: Jarkko Sakkinen <jarkko@...nel.org>

As you can see from the bug comments clearly both v2 and v3 pass the
tests in the failing hardware. I don't think it is really a problem for
us to map 16 MB of address space, as that is zero cost of resources,
even if there is only some dozens of kilobytes of data. Since ACPI
does that it will never be available for general consumption anyway.

Also I've tested the following configurations in QEMU:

1. TPM2 FIFO (or TIS)
2. TPM2 CRB
3. TPM1 FIFO

95 insertions and 65 deletions is neither too bad figure, and as
side-effect makes tpm1.c and tpm2.c pretty much chip independent.

James earlier suggestion to "fix" also OF and other stuff is
purposely left out as we don't falling tree over there. They
should continue to use devm_kmalloc() for the moment although
in principle zero copy mapping is always better (but definitely
notin the scope of bug fix).

BR, Jarkko