kernel/linux.git/drivers/char/tpm, branch v5.4.113

tpm, tpm_tis: Decorate tpm_get_timeouts() with request_locality()

2021-03-09T10:09:36+00:00

commit a5665ec2affdba21bff3b0d4d3aed83b3951e8ff upstream. This is shown with Samsung Chromebook Pro (Caroline) with TPM 1.2 (SLB 9670): [ 4.324298] TPM returned invalid status [ 4.324806] WARNING: CPU: 2 PID: 1 at drivers/char/tpm/tpm_tis_core.c:275 tpm_tis_status+0x86/0x8f Background ========== TCG PC Client Platform TPM Profile (PTP) Specification, paragraph 6.1 FIFO Interface Locality Usage per Register, Table 39 Register Behavior Based on Locality Setting for FIFO - a read attempt to TPM_STS_x Registers returns 0xFF in case of lack of locality. The fix ======= Decorate tpm_get_timeouts() with request_locality() and release_locality(). Fixes: a3fbfae82b4c ("tpm: take TPM chip power gating out of tpm_transmit()") Cc: James Bottomley Cc: Guenter Roeck Cc: Laurent Bigonville Cc: stable@vger.kernel.org Reported-by: Lukasz Majczak Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman

tpm, tpm_tis: Decorate tpm_tis_gen_interrupt() with request_locality()

2021-03-09T10:09:36+00:00

commit d53a6adfb553969809eb2b736a976ebb5146cd95 upstream. This is shown with Samsung Chromebook Pro (Caroline) with TPM 1.2 (SLB 9670): [ 4.324298] TPM returned invalid status [ 4.324806] WARNING: CPU: 2 PID: 1 at drivers/char/tpm/tpm_tis_core.c:275 tpm_tis_status+0x86/0x8f Background ========== TCG PC Client Platform TPM Profile (PTP) Specification, paragraph 6.1 FIFO Interface Locality Usage per Register, Table 39 Register Behavior Based on Locality Setting for FIFO - a read attempt to TPM_STS_x Registers returns 0xFF in case of lack of locality. The fix ======= Decorate tpm_tis_gen_interrupt() with request_locality() and release_locality(). Cc: Laurent Bigonville Cc: James Bottomley Cc: Guenter Roeck Cc: stable@vger.kernel.org Fixes: a3fbfae82b4c ("tpm: take TPM chip power gating out of tpm_transmit()") Signed-off-by: Lukasz Majczak Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman

tpm_tis: Clean up locality release

2021-03-04T09:26:43+00:00

commit e42acf104d6e0bd7ccd2f09103d5be5e6d3c637c upstream. The current release locality code seems to be based on the misunderstanding that the TPM interrupts when a locality is released: it doesn't, only when the locality is acquired. Furthermore, there seems to be no point in waiting for the locality to be released. All it does is penalize the last TPM user. However, if there's no next TPM user, this is a pointless wait and if there is a next TPM user, they'll pay the penalty waiting for the new locality (or possibly not if it's the same as the old locality). Fix the code by making release_locality as simple write to release with no waiting for completion. Cc: stable@ger.kernel.org Fixes: 33bafe90824b ("tpm_tis: verify locality released before returning from release_locality") Signed-off-by: James Bottomley Reviewed-by: Jerry Snitselaar Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman

tpm_tis: Fix check_locality for correct locality acquisition

2021-03-04T09:26:43+00:00

commit 3d9ae54af1d02a7c0edc55c77d7df2b921e58a87 upstream. The TPM TIS specification says the TPM signals the acquisition of locality when the TMP_ACCESS_REQUEST_USE bit goes to one *and* the TPM_ACCESS_REQUEST_USE bit goes to zero. Currently we only check the former not the latter, so check both. Adding the check on TPM_ACCESS_REQUEST_USE should fix the case where the locality is re-requested before the TPM has released it. In this case the locality may get released briefly before it is reacquired, which causes all sorts of problems. However, with the added check, TPM_ACCESS_REQUEST_USE should remain 1 until the second request for the locality is granted. Cc: stable@ger.kernel.org Fixes: 27084efee0c3 ("[PATCH] tpm: driver for next generation TPM chips") Signed-off-by: James Bottomley Reviewed-by: Jerry Snitselaar Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman

tpm_tis: Disable interrupts on ThinkPad T490s

2020-11-18T18:20:25+00:00

[ Upstream commit b154ce11ead925de6a94feb3b0317fafeefa0ebc ] There is a misconfiguration in the bios of the gpio pin used for the interrupt in the T490s. When interrupts are enabled in the tpm_tis driver code this results in an interrupt storm. This was initially reported when we attempted to enable the interrupt code in the tpm_tis driver, which previously wasn't setting a flag to enable it. Due to the reports of the interrupt storm that code was reverted and we went back to polling instead of using interrupts. Now that we know the T490s problem is a firmware issue, add code to check if the system is a T490s and disable interrupts if that is the case. This will allow us to enable interrupts for everyone else. If the user has a fixed bios they can force the enabling of interrupts with tpm_tis.interrupts=1 on the kernel command line. Cc: Peter Huewe Cc: Jason Gunthorpe Cc: Hans de Goede Signed-off-by: Jerry Snitselaar Reviewed-by: James Bottomley Reviewed-by: Hans de Goede Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin

tpm: efi: Don't create binary_bios_measurements file for an empty log

2020-11-18T18:20:20+00:00

[ Upstream commit 8ffd778aff45be760292225049e0141255d4ad6e ] Mimic the pre-existing ACPI and Device Tree event log behavior by not creating the binary_bios_measurements file when the EFI TPM event log is empty. This fixes the following NULL pointer dereference that can occur when reading /sys/kernel/security/tpm0/binary_bios_measurements after the kernel received an empty event log from the firmware: BUG: kernel NULL pointer dereference, address: 000000000000002c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 2 PID: 3932 Comm: fwupdtpmevlog Not tainted 5.9.0-00003-g629990edad62 #17 Hardware name: LENOVO 20LCS03L00/20LCS03L00, BIOS N27ET38W (1.24 ) 11/28/2019 RIP: 0010:tpm2_bios_measurements_start+0x3a/0x550 Code: 54 53 48 83 ec 68 48 8b 57 70 48 8b 1e 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 48 8b 82 c0 06 00 00 48 8b 8a c8 06 00 00 <44> 8b 60 1c 48 89 4d a0 4c 89 e2 49 83 c4 20 48 83 fb 00 75 2a 49 RSP: 0018:ffffa9c901203db0 EFLAGS: 00010246 RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000010 RDX: ffff8ba1eb99c000 RSI: ffff8ba1e4ce8280 RDI: ffff8ba1e4ce8258 RBP: ffffa9c901203e40 R08: ffffa9c901203dd8 R09: ffff8ba1ec443300 R10: ffffa9c901203e50 R11: 0000000000000000 R12: ffff8ba1e4ce8280 R13: ffffa9c901203ef0 R14: ffffa9c901203ef0 R15: ffff8ba1e4ce8258 FS: 00007f6595460880(0000) GS:ffff8ba1ef880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000002c CR3: 00000007d8d18003 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __kmalloc_node+0x113/0x320 ? kvmalloc_node+0x31/0x80 seq_read+0x94/0x420 vfs_read+0xa7/0x190 ksys_read+0xa7/0xe0 __x64_sys_read+0x1a/0x20 do_syscall_64+0x37/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xa9 In this situation, the bios_event_log pointer in the tpm_bios_log struct was not NULL but was equal to the ZERO_SIZE_PTR (0x10) value. This was due to the following kmemdup() in tpm_read_log_efi(): int tpm_read_log_efi(struct tpm_chip *chip) { ... /* malloc EventLog space */ log->bios_event_log = kmemdup(log_tbl->log, log_size, GFP_KERNEL); if (!log->bios_event_log) { ret = -ENOMEM; goto out; } ... } When log_size is zero, due to an empty event log from firmware, ZERO_SIZE_PTR is returned from kmemdup(). Upon a read of the binary_bios_measurements file, the tpm2_bios_measurements_start() function does not perform a ZERO_OR_NULL_PTR() check on the bios_event_log pointer before dereferencing it. Rather than add a ZERO_OR_NULL_PTR() check in functions that make use of the bios_event_log pointer, simply avoid creating the binary_bios_measurements_file as is done in other event log retrieval backends. Explicitly ignore all of the events in the final event log when the main event log is empty. The list of events in the final event log cannot be accurately parsed without referring to the first event in the main event log (the event log header) so the final event log is useless in such a situation. Fixes: 58cc1e4faf10 ("tpm: parse TPM event logs based on EFI table") Link: https://lore.kernel.org/linux-integrity/E1FDCCCB-CA51-4AEE-AC83-9CDE995EAE52@canonical.com/ Reported-by: Kai-Heng Feng Reported-by: Kenneth R. Crudup Reported-by: Mimi Zohar Cc: Thiébaud Weksteen Cc: Ard Biesheuvel Signed-off-by: Tyler Hicks Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin

tpm: ibmvtpm: Wait for buffer to be set before proceeding

2020-10-01T11:17:42+00:00

[ Upstream commit d8d74ea3c00214aee1e1826ca18e77944812b9b4 ] Synchronize with the results from the CRQs before continuing with the initialization. This avoids trying to send TPM commands while the rtce buffer has not been allocated, yet. This patch fixes an existing race condition that may occurr if the hypervisor does not quickly respond to the VTPM_GET_RTCE_BUFFER_SIZE request sent during initialization and therefore the ibmvtpm->rtce_buf has not been allocated at the time the first TPM command is sent. Fixes: 132f76294744 ("drivers/char/tpm: Add new device driver to support IBM vTPM") Signed-off-by: Stefan Berger Acked-by: Nayna Jain Tested-by: Nayna Jain Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin

tpm_crb: fix fTPM on AMD Zen+ CPUs

2020-10-01T11:17:17+00:00

[ Upstream commit 3ef193822b25e9ee629974f66dc1ff65167f770c ] Bug link: https://bugzilla.kernel.org/show_bug.cgi?id=195657 cmd/rsp buffers are expected to be in the same ACPI region. For Zen+ CPUs BIOS's might report two different regions, some of them also report region sizes inconsistent with values from TPM registers. Memory configuration on ASRock x470 ITX: db0a0000-dc59efff : Reserved dc57e000-dc57efff : MSFT0101:00 dc582000-dc582fff : MSFT0101:00 Work around the issue by storing ACPI regions declared for the device in a fixed array and adding an array for pointers to corresponding possibly allocated resources in crb_map_io function. This data was previously held for a single resource in struct crb_priv (iobase field) and local variable io_res in crb_map_io function. ACPI resources array is used to find index of corresponding region for each buffer and make the buffer size consistent with region's length. Array of pointers to allocated resources is used to map the region at most once. Signed-off-by: Ivan Lazeev Tested-by: Jerry Snitselaar Tested-by: Jarkko Sakkinen Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin

tpm: Unify the mismatching TPM space buffer sizes

2020-08-19T06:16:27+00:00

commit 6c4e79d99e6f42b79040f1a33cd4018f5425030b upstream. The size of the buffers for storing context's and sessions can vary from arch to arch as PAGE_SIZE can be anything between 4 kB and 256 kB (the maximum for PPC64). Define a fixed buffer size set to 16 kB. This should be enough for most use with three handles (that is how many we allow at the moment). Parametrize the buffer size while doing this, so that it is easier to revisit this later on if required. Cc: stable@vger.kernel.org Reported-by: Stefan Berger Fixes: 745b361e989a ("tpm: infrastructure for TPM spaces") Reviewed-by: Jerry Snitselaar Tested-by: Stefan Berger Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman

tpm_tis: extra chip->ops check on error path in tpm_tis_core_init

2020-07-22T07:32:53+00:00

[ Upstream commit ccf6fb858e17a8f8a914a1c6444d277cfedfeae6 ] Found by smatch: drivers/char/tpm/tpm_tis_core.c:1088 tpm_tis_core_init() warn: variable dereferenced before check 'chip->ops' (see line 979) 'chip->ops' is assigned in the beginning of function in tpmm_chip_alloc->tpm_chip_alloc and is used before first possible goto to error path. Signed-off-by: Vasily Averin Reviewed-by: Jerry Snitselaar Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin