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

tpm: fix handling of the TPM 2.0 event logs

2017-05-25T13:46:10+00:00

commit fd5c78694f3f1c875e293de7a641ba8a3d60d00d upstream. When TPM2 log has entries with more than 3 digests, or with digests not listed in the log header, log gets misparsed, eventually leading to kernel complaint that code tried to vmalloc 512MB of memory (I have no idea what would happen on bigger system). So code should not parse only first 3 digests: both event header and event itself are already in memory, so we can parse any number of digests, as long as we do not try to parse whole memory when given count of 0xFFFFFFFF. So this change: * Rejects event entry with more digests than log header describes. Digest types should be unique, and all should be described in log header, so there cannot be more digests in the event than in the header. * Reject event entry with digest that is not described in the log header. In theory code could hardcode information about digest IDs already assigned by TCG, but if firmware authors cannot get event log format right, why should anyone believe that they got event log content right. Fixes: 4d23cc323cdb ("tpm: add securityfs support for TPM 2.0 firmware event log") Signed-off-by: Petr Vandrovec Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman

vTPM: Fix missing NULL check

2017-05-25T13:46:10+00:00

commit 31574d321c70f6d3b40fe98f9b2eafd9a903fef9 upstream. The current code passes the address of tpm_chip as the argument to dev_get_drvdata() without prior NULL check in tpm_ibmvtpm_get_desired_dma. This resulted an oops during kernel boot when vTPM is enabled in Power partition configured in active memory sharing mode. The vio_driver's get_desired_dma() is called before the probe(), which for vtpm is tpm_ibmvtpm_probe, and it's this latter function that initializes the driver and set data. Attempting to get data before the probe() caused the problem. This patch adds a NULL check to the tpm_ibmvtpm_get_desired_dma. fixes: 9e0d39d8a6a0 ("tpm: Remove useless priv field in struct tpm_vendor_specific") Signed-off-by: Hon Ching(Vicky) Lo Reviewed-by: Jarkko Sakkine Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman

tpm_crb: check for bad response size

2017-05-25T13:46:10+00:00

commit 8569defde8057258835c51ce01a33de82e14b148 upstream. Make sure size of response buffer is at least 6 bytes, or we will underflow and pass large size_t to memcpy_fromio(). This was encountered while testing earlier version of locality patchset. Fixes: 30fc8d138e912 ("tpm: TPM 2.0 CRB Interface") Signed-off-by: Jerry Snitselaar Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman

tpm: add sleep only for retry in i2c_nuvoton_write_status()

2017-05-25T13:46:10+00:00

commit 0afb7118ae021e80ecf70f5a3336e0935505518a upstream. Currently, there is an unnecessary 1 msec delay added in i2c_nuvoton_write_status() for the successful case. This function is called multiple times during send() and recv(), which implies adding multiple extra delays for every TPM operation. This patch calls usleep_range() only if retry is to be done. Signed-off-by: Nayna Jain Reviewed-by: Mimi Zohar Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman

tpm: msleep() delays - replace with usleep_range() in i2c nuvoton driver

2017-05-25T13:46:10+00:00

commit a233a0289cf9a96ef9b42c730a7621ccbf9a6f98 upstream. Commit 500462a9de65 "timers: Switch to a non-cascading wheel" replaced the 'classic' timer wheel, which aimed for near 'exact' expiry of the timers. Their analysis was that the vast majority of timeout timers are used as safeguards, not as real timers, and are cancelled or rearmed before expiration. The only exception noted to this were networking timers with a small expiry time. Not included in the analysis was the TPM polling timer, which resulted in a longer normal delay and, every so often, a very long delay. The non-cascading wheel delay is based on CONFIG_HZ. For a description of the different rings and their delays, refer to the comments in kernel/time/timer.c. Below are the delays given for rings 0 - 2, which explains the longer "normal" delays and the very, long delays as seen on systems with CONFIG_HZ 250. * HZ 1000 steps * Level Offset Granularity Range * 0 0 1 ms 0 ms - 63 ms * 1 64 8 ms 64 ms - 511 ms * 2 128 64 ms 512 ms - 4095 ms (512ms - ~4s) * HZ 250 * Level Offset Granularity Range * 0 0 4 ms 0 ms - 255 ms * 1 64 32 ms 256 ms - 2047 ms (256ms - ~2s) * 2 128 256 ms 2048 ms - 16383 ms (~2s - ~16s) Below is a comparison of extending the TPM with 1000 measurements, using msleep() vs. usleep_delay() when configured for 1000 hz vs. 250 hz, before and after commit 500462a9de65. linux-4.7 | msleep() usleep_range() 1000 hz: 0m44.628s | 1m34.497s 29.243s 250 hz: 1m28.510s | 4m49.269s 32.386s linux-4.7 | min-max (msleep) min-max (usleep_range) 1000 hz: 0:017 - 2:760s | 0:015 - 3:967s 0:014 - 0:418s 250 hz: 0:028 - 1:954s | 0:040 - 4:096s 0:016 - 0:816s This patch replaces the msleep() with usleep_range() calls in the i2c nuvoton driver with a consistent max range value. Signed-of-by: Mimi Zohar Signed-off-by: Nayna Jain Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman

tpm_tis_spi: Add small delay after last transfer

2017-05-25T13:46:10+00:00

commit 5cc0101d1f88500f8901d01b035af743215d4c3a upstream. Testing the implementation with a Raspberry Pi 2 showed that under some circumstances its SPI master erroneously releases the CS line before the transfer is complete, i.e. before the end of the last clock. In this case the TPM ignores the transfer and misses for example the GO command. The driver is unable to detect this communication problem and will wait for a command response that is never going to arrive, timing out eventually. As a workaround, the small delay ensures that the CS line is held long enough, even with a faulty SPI master. Other SPI masters are not affected, except for a negligible performance penalty. Fixes: 0edbfea537d1 ("tpm/tpm_tis_spi: Add support for spi phy") Signed-off-by: Alexander Steffen Signed-off-by: Peter Huewe Reviewed-by: Jarkko Sakkinen Tested-by: Benoit Houyere Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman

tpm_tis_spi: Remove limitation of transfers to MAX_SPI_FRAMESIZE bytes

2017-05-25T13:46:10+00:00

commit 591e48c26ced7c455751eef27fb5963e902c2137 upstream. Limiting transfers to MAX_SPI_FRAMESIZE was not expected by the upper layers, as tpm_tis has no such limitation. Add a loop to hide that limitation. v2: Moved scope of spi_message to the top as requested by Jarkko Fixes: 0edbfea537d1 ("tpm/tpm_tis_spi: Add support for spi phy") Signed-off-by: Alexander Steffen Signed-off-by: Peter Huewe Reviewed-by: Jarkko Sakkinen Tested-by: Benoit Houyere Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman

tpm_tis_spi: Check correct byte for wait state indicator

2017-05-25T13:46:09+00:00

commit e110cc69dc2ad679d6d478df636b99b14e6fbbc9 upstream. Wait states are signaled in the last byte received from the TPM in response to the header, not the first byte. Check rx_buf[3] instead of rx_buf[0]. Fixes: 0edbfea537d1 ("tpm/tpm_tis_spi: Add support for spi phy") Signed-off-by: Alexander Steffen Signed-off-by: Peter Huewe Reviewed-by: Jarkko Sakkinen Tested-by: Benoit Houyere Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman

tpm_tis_spi: Abort transfer when too many wait states are signaled

2017-05-25T13:46:09+00:00

commit 975094ddc369a32f27210248bdd9bbd153061b00 upstream. Abort the transfer with ETIMEDOUT when the TPM signals more than TPM_RETRY wait states. Continuing with the transfer in this state will only lead to arbitrary failures in other parts of the code. Fixes: 0edbfea537d1 ("tpm/tpm_tis_spi: Add support for spi phy") Signed-off-by: Alexander Steffen Signed-off-by: Peter Huewe Reviewed-by: Jarkko Sakkinen Tested-by: Benoit Houyere Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman

tpm_tis_spi: Use single function to transfer data

2017-05-25T13:46:09+00:00

commit f848f2143ae42dc0918400039257a893835254d1 upstream. The algorithm for sending data to the TPM is mostly identical to the algorithm for receiving data from the TPM, so a single function is sufficient to handle both cases. This is a prequisite for all the other fixes, so we don't have to fix everything twice (send/receive) v2: u16 instead of u8 for the length. Fixes: 0edbfea537d1 ("tpm/tpm_tis_spi: Add support for spi phy") Signed-off-by: Alexander Steffen Signed-off-by: Peter Huewe Reviewed-by: Jarkko Sakkinen Tested-by: Benoit Houyere Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman