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

["Jarkko Sakkinen" <jarkko.sakkinen@iki.fi>]

On Sat Dec 21, 2024 at 7:16 PM EET, James Bottomley wrote:
> On Sat, 2024-12-21 at 17:04 +0100, Ard Biesheuvel wrote:
> > On Sat, 21 Dec 2024 at 12:33, 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.
> > > 
> > > Reported-by: Andy Liang <andy.liang@hpe.com>
> > > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219495
> > > Suggested-by: Matthew Garrett <mjg59@srcf.ucam.org>
> > > Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
> > 
> > This is a very intrusive fix - care to provide some more context on
> > why all these changes are needed?
>
> Since the bug reports never found an actual log over a few tens of
> kilobytes this is caused by the BIOS implementation allocating a huge
> buffer that is mostly unused.
>
> There are two other possibilities for fixing this, which were both part
> of the original suggestions.  One would be to work out the size of the
> log and then allocate an exact size.  This would require implementing
> tpm1 and tpm2 parsers for log size.  However, since we can never go
> over KMALLOC_MAX_SIZE without an error even with this calculated size,
> the simplest straight line fix would be to cap the copy at
> KMALLOC_MAX_SIZE if it's over.  That would be a simple one liner.

All I'm saying is this.

I've got bunch of complains of this from mainly SUSE, and now I'm
here with a response to that feedback. So I don't care. You decide.

I'm 100% sure that the fix that Stefan proposed is not a sustainable
path in long-term, so I guess this was more like more long-term but
intrusive fix.

Ya, and also please test the changes, especially anything that can
reach of OF eventlogs would be welcome feedback.

BR, Jarkko