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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMj1kXHTJ_=g1dnuGV2PWiNC1o=wKFOkZxEAcrMWYbUNWkxKNg@mail.gmail.com>
Date: Mon, 6 Jan 2025 18:23:40 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Jarkko Sakkinen <jarkko@...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 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?

-- 
Ard.