linux-kernel - Re: [PATCH v2 1/3] tpm: efi: Use local variable for calculating final log size

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: <YEuc2JV2YBzlQtB5@kernel.org>
Date:   Fri, 12 Mar 2021 18:54:48 +0200
From:   Jarkko Sakkinen <jarkko@...nel.org>
To:     Stefan Berger <stefanb@...ux.ibm.com>
Cc:     peterhuewe@....de, jgg@...pe.ca, linux-integrity@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        linux-kernel@...r.kernel.org, mjg59@...gle.com
Subject: Re: [PATCH v2 1/3] tpm: efi: Use local variable for calculating
 final log size

On Thu, Mar 11, 2021 at 09:02:38AM -0500, Stefan Berger wrote:
> 
> On 3/10/21 6:24 PM, Jarkko Sakkinen wrote:
> > On Thu, Mar 11, 2021 at 01:21:47AM +0200, Jarkko Sakkinen wrote:
> > > On Wed, Mar 10, 2021 at 05:19:14PM -0500, Stefan Berger wrote:
> > > > When tpm_read_log_efi is called multiple times, which happens when
> > > > one loads and unloads a TPM2 driver multiple times, then the global
> > > > variable efi_tpm_final_log_size will at some point become a negative
> > > > number due to the subtraction of final_events_preboot_size occurring
> > > > each time. Use a local variable to avoid this integer underflow.
> > > > 
> > > > The following issue is now resolved:
> > > > 
> > > > Mar  8 15:35:12 hibinst kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
> > > > Mar  8 15:35:12 hibinst kernel: Workqueue: tpm-vtpm vtpm_proxy_work [tpm_vtpm_proxy]
> > > > Mar  8 15:35:12 hibinst kernel: RIP: 0010:__memcpy+0x12/0x20
> > > > Mar  8 15:35:12 hibinst kernel: Code: 00 b8 01 00 00 00 85 d2 74 0a c7 05 44 7b ef 00 0f 00 00 00 c3 cc cc cc 66 66 90 66 90 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 <f3> 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3 a4
> > > > Mar  8 15:35:12 hibinst kernel: RSP: 0018:ffff9ac4c0fcfde0 EFLAGS: 00010206
> > > > Mar  8 15:35:12 hibinst kernel: RAX: ffff88f878cefed5 RBX: ffff88f878ce9000 RCX: 1ffffffffffffe0f
> > > > Mar  8 15:35:12 hibinst kernel: RDX: 0000000000000003 RSI: ffff9ac4c003bff9 RDI: ffff88f878cf0e4d
> > > > Mar  8 15:35:12 hibinst kernel: RBP: ffff9ac4c003b000 R08: 0000000000001000 R09: 000000007e9d6073
> > > > Mar  8 15:35:12 hibinst kernel: R10: ffff9ac4c003b000 R11: ffff88f879ad3500 R12: 0000000000000ed5
> > > > Mar  8 15:35:12 hibinst kernel: R13: ffff88f878ce9760 R14: 0000000000000002 R15: ffff88f77de7f018
> > > > Mar  8 15:35:12 hibinst kernel: FS:  0000000000000000(0000) GS:ffff88f87bd00000(0000) knlGS:0000000000000000
> > > > Mar  8 15:35:12 hibinst kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > > Mar  8 15:35:12 hibinst kernel: CR2: ffff9ac4c003c000 CR3: 00000001785a6004 CR4: 0000000000060ee0
> > > > Mar  8 15:35:12 hibinst kernel: Call Trace:
> > > > Mar  8 15:35:12 hibinst kernel: tpm_read_log_efi+0x152/0x1a7
> > > > Mar  8 15:35:12 hibinst kernel: tpm_bios_log_setup+0xc8/0x1c0
> > > > Mar  8 15:35:12 hibinst kernel: tpm_chip_register+0x8f/0x260
> > > > Mar  8 15:35:12 hibinst kernel: vtpm_proxy_work+0x16/0x60 [tpm_vtpm_proxy]
> > > > Mar  8 15:35:12 hibinst kernel: process_one_work+0x1b4/0x370
> > > > Mar  8 15:35:12 hibinst kernel: worker_thread+0x53/0x3e0
> > > > Mar  8 15:35:12 hibinst kernel: ? process_one_work+0x370/0x370
> > > > 
> > > > Signed-off-by: Stefan Berger <stefanb@...ux.ibm.com>
> > > Fixes tag for this one?
> > Or just sanity check, I think it is:
> > 
> > Fixes: 166a2809d65b ("tpm: Don't duplicate events from the final event log in the TCG2 log")
> Looks good.
> > 
> > Also, I guess all of the patches ought to have stable cc, right?
> 
> Yes, please. I think the maintainer has to add this 'at some point'.
> 
> Since you queued them already I won't send a v3.
> 
> 
> Thanks!
> 
>    Stefan

OK, I'll add cc's before I send the PR, thanks.

/Jarkko