linux-kernel - Re: [PATCH v5] 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: <D6VAZGXPWLUY.31RHNWW6ROQMA@kernel.org>
Date: Mon, 06 Jan 2025 23:20:49 +0200
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Ard Biesheuvel" <ardb@...nel.org>
Cc: <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>, "Mimi Zohar" <zohar@...ux.ibm.com>, "Al Viro"
 <viro@...iv.linux.org.uk>, "Kylene Jo Hall" <kjhall@...ibm.com>, "Reiner
 Sailer" <sailer@...ibm.com>, "Seiji Munetoh" <munetoh@...ibm.com>, "Andrew
 Morton" <akpm@...l.org>, <stable@...r.kernel.org>, "Andy Liang"
 <andy.liang@....com>, "Matthew Garrett" <mjg59@...f.ucam.org>,
 <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5] tpm: Map the ACPI provided event log

On Mon Jan 6, 2025 at 7:23 PM EET, Ard Biesheuvel wrote:
> On Wed, 25 Dec 2024 at 16:31, Jarkko Sakkinen <jarkko@...nel.org> wrote:
> >
> > On Tue Dec 24, 2024 at 6:05 PM EET, Ard Biesheuvel wrote:
> > > On Tue, 24 Dec 2024 at 05:03, Jarkko Sakkinen <jarkko@...nel.org> 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.
> > > >
> > >
> > > How can you be sure the memory contents will be preserved? Does it say
> > > anywhere in the TCG spec that this needs to use a memory type that is
> > > preserved by default?
> >
> > TCG log calls the size as the minimum size for the log area but is not
> > too accurate on details [1]. I don't actually know what "minimum" even
> > means in this context as it is just a fixed size cut of the physical
> > address space.
> >
> > I don't think that can ever change. It would be oddballs if some
> > dynamic change would make ACPI tables show incorrect information
> > on memory ranges. Do you know any pre-existing example of such
> > behavior (not sarcasm, just interested)?
> >
> > Anyway considering this type of dynamics TCG spec is inaccurate.
> >
>
> Thanks for the context but that is not at all what I was asking.
>
> This change assumes that the contents of the memory region described
> by the ACPI table will be reserved in some way, and not be released to
> the kernel for general allocation.
>
> This is not always the case for firmware tables: EFI configuration
> tables need to be reserved explicitly unless the memory type is
> EfiRuntimeServicesData. For ACPI tables, the situation might be
> different but there is at least one example (BGRT) where the memory
> type typically used is not one that the kernel usually reserves by
> default.
>
> So my question is whether there is anything in the TCG platform spec
> (or whichever spec describes this ACPI table) that guarantees that the
> region that the TCPA or TPM2 table points to is of a type that does
> not require an explicit reservation?

I agree that we must assume that we cannot guarantee taht  since it is
open in the spec. I think I went over the top with this.

Let's go with the simpler devm_add_action_or_reset() fix.

BR, Jarkko