kernel/linux.git/drivers/char/tpm, branch v4.14.85

tpm: Restore functionality to xen vtpm driver.

2018-11-13T19:15:02+00:00

commit e487a0f52301293152a6f8c4e217f2a11dd808e3 upstream. Functionality of the xen-tpmfront driver was lost secondary to the introduction of xenbus multi-page support in commit ccc9d90a9a8b ("xenbus_client: Extend interface to support multi-page ring"). In this commit pointer to location of where the shared page address is stored was being passed to the xenbus_grant_ring() function rather then the address of the shared page itself. This resulted in a situation where the driver would attach to the vtpm-stubdom but any attempt to send a command to the stub domain would timeout. A diagnostic finding for this regression is the following error message being generated when the xen-tpmfront driver probes for a device: <3>vtpm vtpm-0: tpm_transmit: tpm_send: error -62 <3>vtpm vtpm-0: A TPM error (-62) occurred attempting to determine the timeouts This fix is relevant to all kernels from 4.1 forward which is the release in which multi-page xenbus support was introduced. Daniel De Graaf formulated the fix by code inspection after the regression point was located. Fixes: ccc9d90a9a8b ("xenbus_client: Extend interface to support multi-page ring") Signed-off-by: Dr. Greg Wettstein Signed-off-by: Greg Kroah-Hartman [boris: Updated commit message, added Fixes tag] Signed-off-by: Boris Ostrovsky Cc: stable@vger.kernel.org # v4.1+ Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen

tpm: suppress transmit cmd error logs when TPM 1.2 is disabled/deactivated

2018-11-13T19:14:58+00:00

[ Upstream commit 0d6d0d62d9505a9816716aa484ebd0b04c795063 ] For TPM 1.2 chips the system setup utility allows to set the TPM device in one of the following states: * Active: Security chip is functional * Inactive: Security chip is visible, but is not functional * Disabled: Security chip is hidden and is not functional When choosing the "Inactive" state, the TPM 1.2 device is enumerated and registered, but sending TPM commands fail with either TPM_DEACTIVATED or TPM_DISABLED depending if the firmware deactivated or disabled the TPM. Since these TPM 1.2 error codes don't have special treatment, inactivating the TPM leads to a very noisy kernel log buffer that shows messages like the following: tpm_tis 00:05: 1.2 TPM (device-id 0x0, rev-id 78) tpm tpm0: A TPM error (6) occurred attempting to read a pcr value tpm tpm0: TPM is disabled/deactivated (0x6) tpm tpm0: A TPM error (6) occurred attempting get random tpm tpm0: A TPM error (6) occurred attempting to read a pcr value ima: No TPM chip found, activating TPM-bypass! (rc=6) tpm tpm0: A TPM error (6) occurred attempting get random tpm tpm0: A TPM error (6) occurred attempting get random tpm tpm0: A TPM error (6) occurred attempting get random tpm tpm0: A TPM error (6) occurred attempting get random Let's just suppress error log messages for the TPM_{DEACTIVATED,DISABLED} return codes, since this is expected when the TPM 1.2 is set to Inactive. In that case the kernel log is cleaner and less confusing for users, i.e: tpm_tis 00:05: 1.2 TPM (device-id 0x0, rev-id 78) tpm tpm0: TPM is disabled/deactivated (0x6) ima: No TPM chip found, activating TPM-bypass! (rc=6) Reported-by: Hans de Goede Signed-off-by: Javier Martinez Canillas Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

tpm: tpm_crb: relinquish locality on error path.

2018-11-04T13:52:44+00:00

[ Upstream commit 1fbad3028664e114d210dc65d768947a3a553eaa ] In crb_map_io() function, __crb_request_locality() is called prior to crb_cmd_ready(), but if one of the consecutive function fails the flow bails out instead of trying to relinquish locality. This patch adds goto jump to __crb_relinquish_locality() on the error path. Fixes: 888d867df441 (tpm: cmd_ready command can be issued only after granting locality) Signed-off-by: Tomas Winkler Tested-by: Jarkko Sakkinen Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin

tpm: move the delay_msec increment after sleep in tpm_transmit()

2018-11-04T13:52:44+00:00

[ Upstream commit 92980756979a9c51be0275f395f4e89c42cf199a ] Commit e2fb992d82c6 ("tpm: add retry logic") introduced a new loop to handle the TPM2_RC_RETRY error. The loop retries the command after sleeping for the specified time, which is incremented exponentially in every iteration. Unfortunately, the loop doubles the time before sleeping, causing the initial sleep to be doubled. This patch fixes the initial sleep time. Fixes: commit e2fb992d82c6 ("tpm: add retry logic") Signed-off-by: Nayna Jain Reviewed-by: Mimi Zohar Tested-by: Jarkko Sakkinen Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin

tpm/tpm_i2c_infineon: switch to i2c_lock_bus(..., I2C_LOCK_SEGMENT)

2018-09-19T20:43:43+00:00

[ Upstream commit bb853aac2c478ce78116128263801189408ad2a8 ] Locking the root adapter for __i2c_transfer will deadlock if the device sits behind a mux-locked I2C mux. Switch to the finer-grained i2c_lock_bus with the I2C_LOCK_SEGMENT flag. If the device does not sit behind a mux-locked mux, the two locking variants are equivalent. Signed-off-by: Peter Rosin Reviewed-by: Jarkko Sakkinen Tested-by: Alexander Steffen Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

tpm_tis_spi: Pass the SPI IRQ down to the driver

2018-09-19T20:43:43+00:00

[ Upstream commit 1a339b658d9dbe1471f67b78237cf8fa08bbbeb5 ] An SPI TPM device managed directly on an embedded board using the SPI bus and some GPIO or similar line as IRQ handler will pass the IRQn from the TPM device associated with the SPI device. This is already handled by the SPI core, so make sure to pass this down to the core as well. (The TPM core habit of using -1 to signal no IRQ is dubious (as IRQ 0 is NO_IRQ) but I do not want to mess with that semantic in this patch.) Cc: Mark Brown Signed-off-by: Linus Walleij Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

tpm: separate cmd_ready/go_idle from runtime_pm

2018-09-19T20:43:38+00:00

commit 627448e85c766587f6fdde1ea3886d6615081c77 upstream. Fix tpm ptt initialization error: tpm tpm0: A TPM error (378) occurred get tpm pcr allocation. We cannot use go_idle cmd_ready commands via runtime_pm handles as with the introduction of localities this is no longer an optional feature, while runtime pm can be not enabled. Though cmd_ready/go_idle provides a power saving, it's also a part of TPM2 protocol and should be called explicitly. This patch exposes cmd_read/go_idle via tpm class ops and removes runtime pm support as it is not used by any driver. When calling from nested context always use both flags: TPM_TRANSMIT_UNLOCKED and TPM_TRANSMIT_RAW. Both are needed to resolve tpm spaces and locality request recursive calls to tpm_transmit(). TPM_TRANSMIT_RAW should never be used standalone as it will fail on double locking. While TPM_TRANSMIT_UNLOCKED standalone should be called from non-recursive locked contexts. New wrappers are added tpm_cmd_ready() and tpm_go_idle() to streamline tpm_try_transmit code. tpm_crb no longer needs own power saving functions and can drop using tpm_pm_suspend/resume. This patch cannot be really separated from the locality fix. Fixes: 888d867df441 (tpm: cmd_ready command can be issued only after granting locality) Cc: stable@vger.kernel.org Fixes: 888d867df441 (tpm: cmd_ready command can be issued only after granting locality) Signed-off-by: Tomas Winkler Tested-by: Jarkko Sakkinen Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman

tpm: Return the actual size when receiving an unsupported command

2018-09-05T07:26:41+00:00

commit 36a11029b07ee30bdc4553274d0efea645ed9d91 upstream. The userpace expects to read the number of bytes stated in the header. Returning the size of the buffer instead would be unexpected. Cc: stable@vger.kernel.org Fixes: 095531f891e6 ("tpm: return a TPM_RC_COMMAND_CODE response if command is not implemented") Signed-off-by: Ricardo Schwarzmeier Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman

tpm: fix race condition in tpm_common_write()

2018-07-03T09:24:53+00:00

commit 3ab2011ea368ec3433ad49e1b9e1c7b70d2e65df upstream. There is a race condition in tpm_common_write function allowing two threads on the same /dev/tpm, or two different applications on the same /dev/tpmrm to overwrite each other commands/responses. Fixed this by taking the priv->buffer_mutex early in the function. Also converted the priv->data_pending from atomic to a regular size_t type. There is no need for it to be atomic since it is only touched under the protection of the priv->buffer_mutex. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Tadeusz Struk Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman

tpm: fix use after free in tpm2_load_context()

2018-07-03T09:24:53+00:00

commit 8c81c24758ffbf17cf06c6835d361ffa57be2f0e upstream. If load context command returns with TPM2_RC_HANDLE or TPM2_RC_REFERENCE_H0 then we have use after free in line 114 and double free in 117. Fixes: 4d57856a21ed2 ("tpm2: add session handle context saving and restoring to the space code") Cc: stable@vger.kernel.org Signed-off-by: Tadeusz Struk Reviewed-by: Jarkko Sakkinen Signed-off--by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman