kernel/linux.git/drivers/char/tpm, branch linux-4.20.y

tpm: tpm_i2c_nuvoton: use correct command duration for TPM 2.x

2019-01-09T16:46:05+00:00

commit 2ba5780ce30549cf57929b01d8cba6fe656e31c5 upstream. tpm_i2c_nuvoton calculated commands duration using TPM 1.x values via tpm_calc_ordinal_duration() also for TPM 2.x chips. Call tpm2_calc_ordinal_duration() for retrieving ordinal duration for TPM 2.X chips. Cc: stable@vger.kernel.org Cc: Nayna Jain Signed-off-by: Tomas Winkler Reviewed-by: Nayna Jain Tested-by: Nayna Jain (For TPM 2.0) Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman

tpm: tpm_try_transmit() refactor error flow.

2019-01-09T16:46:05+00:00

commit 01f54664a4db0d612de0ece8e0022f21f9374e9b upstream. First, rename out_no_locality to out_locality for bailing out on both tpm_cmd_ready() and tpm_request_locality() failure. Second, ignore the return value of go_to_idle() as it may override the return value of the actual tpm operation, the go_to_idle() error will be caught on any consequent command. Last, fix the wrong 'goto out', that jumped back instead of forward. Cc: stable@vger.kernel.org Fixes: 627448e85c76 ("tpm: separate cmd_ready/go_idle from runtime_pm") Signed-off-by: Tomas Winkler Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman

tpm: Restore functionality to xen vtpm driver.

2018-10-05T10:47:34+00:00

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 [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: add support for nonblocking operation

2018-10-05T10:47:33+00:00

Currently the TPM driver only supports blocking calls, which doesn't allow asynchronous IO operations to the TPM hardware. This patch changes it and adds support for nonblocking write and a new poll function to enable applications, which want to take advantage of this. Tested-by: Philip Tricca Signed-off-by: Tadeusz Struk Reviewed-by: Jarkko Sakkinen Signed-off--by: Jarkko Sakkinen

tpm: add ptr to the tpm_space struct to file_priv

2018-10-05T10:47:33+00:00

Add a ptr to struct tpm_space to the file_priv and consolidate of the write operations for the two interfaces. Signed-off-by: Tadeusz Struk Tested-by: Philip Tricca Reviewed-by: Jarkko Sakkinen Signed-off--by: Jarkko Sakkinen

tpm: Make SECURITYFS a weak dependency

2018-10-05T10:47:33+00:00

While having SECURITYFS enabled for the tpm subsystem is beneficial in most cases, it is not strictly necessary to have it enabled at all. Especially on platforms without any boot firmware integration of the TPM (e.g. raspberry pi) it does not add any value for the tpm subsystem, as there is no eventlog present. By turning it from 'select' to 'imply' it still gets selected per default, but enables users who want to save some kb of ram by turning SECURITYFS off. Signed-off-by: Peter Huewe Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen

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

2018-10-05T10:47:33+00:00

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

tpm: fix response size validation in tpm_get_random()

2018-10-05T10:47:33+00:00

When checking whether the response is large enough to be able to contain the received random bytes in tpm_get_random() and tpm2_get_random(), they fail to take account the header size, which should be added to the minimum size. This commit fixes this issue. Cc: stable@vger.kernel.org Fixes: c659af78eb7b ("tpm: Check size of response before accessing data") Signed-off-by: Jarkko Sakkinen

tpm: replace TPM_TRANSMIT_RAW with TPM_TRANSMIT_NESTED

2018-07-28T14:03:11+00:00

As TPM_TRANSMIT_RAW always requires also not to take locks for obvious reasons (deadlock), this commit renames the flag as TPM_TRANSMIT_NESTED and prevents taking tpm_mutex when the flag is given to tpm_transmit(). Suggested-by: Tomas Winkler Signed-off-by: Jarkko Sakkinen

tpm: Convert tpm_find_get_ops() to use tpm_default_chip()

2018-07-28T14:03:11+00:00

Convert tpm_find_get_ops() to use tpm_default_chip() in case no chip is passed in. Signed-off-by: Stefan Berger Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen