linux-kernel - Re: [PATCH v8] 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: <D6V8TV20OP76.10AIALB0FV0HF@kernel.org>
Date: Mon, 06 Jan 2025 21:39:28 +0200
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Takashi Iwai" <tiwai@...e.de>
Cc: <linux-integrity@...r.kernel.org>, "Peter Huewe" <peterhuewe@....de>,
 "Jason Gunthorpe" <jgg@...pe.ca>, "Colin Ian King"
 <colin.i.king@...il.com>, "Stefan Berger" <stefanb@...ibm.com>, "Andrew
 Morton" <akpm@...l.org>, "Seiji Munetoh" <munetoh@...ibm.com>, "Kylene Jo
 Hall" <kjhall@...ibm.com>, "Reiner Sailer" <sailer@...ibm.com>, "Ard
 Biesheuvel" <ardb@...nel.org>, <stable@...r.kernel.org>, "Andy Liang"
 <andy.liang@....com>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v8] tpm: Map the ACPI provided event log

On Fri Jan 3, 2025 at 6:23 PM EET, Takashi Iwai wrote:
> On Fri, 27 Dec 2024 16:39:09 +0100,
> 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 with kvmalloc() and devm_add_action_or_reset().
>
> It looks like that the subject doesn't match with the patch
> description?
>
> (snip)
> > --- a/drivers/char/tpm/eventlog/acpi.c
> > +++ b/drivers/char/tpm/eventlog/acpi.c
> > @@ -63,6 +63,11 @@ static bool tpm_is_tpm2_log(void *bios_event_log, u64 len)
> >  	return n == 0;
> >  }
> >  
> > +static void tpm_bios_log_free(void *data)
> > +{
> > +	kvfree(data);
> > +}
> > +
> >  /* read binary bios log */
> >  int tpm_read_log_acpi(struct tpm_chip *chip)
> >  {
> > @@ -136,10 +141,16 @@ int tpm_read_log_acpi(struct tpm_chip *chip)
> >  	}
> >  
> >  	/* malloc EventLog space */
> > -	log->bios_event_log = devm_kmalloc(&chip->dev, len, GFP_KERNEL);
> > +	log->bios_event_log = kvmalloc(len, GFP_KERNEL);
> >  	if (!log->bios_event_log)
> >  		return -ENOMEM;
> >  
> > +	ret = devm_add_action_or_reset(&chip->dev, tpm_bios_log_free, log->bios_event_log);
> > +	if (ret) {
> > +		log->bios_event_log = NULL;
> > +		return ret;
> > +	}
> > +
> >  	log->bios_event_log_end = log->bios_event_log + len;
> >  
> >  	virt = acpi_os_map_iomem(start, len);
>
> I'm afraid that you forgot to correct the remaining devm_kfree() in
> the error path of this function.
>
> (I know it because I initially posted a similar fix in
>    https://lore.kernel.org/all/20241107112054.28448-1-tiwai@suse.de/
>  Your devm_add_action_or_reset() is a better choice, indeed, though
>  :-)

OK, thanks for the remark! I totally forgot your fix when I went on
tripping on over-engineering :-) [better to admit when you go over the
top]

I'll fix this up after I get back on track after holidays (later this
week or early next weeek).

>
>
> thanks,
>
> Takashi


BR, Jarkko