Re: [PATCH v5] tpm: Map the ACPI provided event log

["Jarkko Sakkinen" <jarkko@kernel.org>]

On Mon Jan 6, 2025 at 7:23 PM EET, Ard Biesheuvel wrote:
> On Wed, 25 Dec 2024 at 16:31, Jarkko Sakkinen <jarkko@kernel.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@kernel.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