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

tpm_tis: Fix incorrect arguments in tpm_tis_probe_irq_single

2025-10-19T14:37:15+00:00

[ Upstream commit 8a81236f2cb0882c7ea6c621ce357f7f3f601fe5 ] The tpm_tis_write8() call specifies arguments in wrong order. Should be (data, addr, value) not (data, value, addr). The initial correct order was changed during the major refactoring when the code was split. Fixes: 41a5e1cf1fe1 ("tpm/tpm_tis: Split tpm_tis driver into a core and TCG TIS compliant phy") Signed-off-by: Gunnar Kudrjavets Reviewed-by: Justinien Bouron Reviewed-by: Jarkko Sakkinen Reviewed-by: Paul Menzel Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin

tpm: Disable TPM2_TCG_HMAC by default

2025-10-15T10:04:15+00:00

commit 4bddf4587c131d7b8ce8952cd32b284dcda0dd1f upstream. After reading all the feedback, right now disabling the TPM2_TCG_HMAC is the right call. Other views discussed: A. Having a kernel command-line parameter or refining the feature otherwise. This goes to the area of improvements. E.g., one example is my own idea where the null key specific code would be replaced with a persistent handle parameter (which can be *unambigously* defined as part of attestation process when done correctly). B. Removing the code. I don't buy this because that is same as saying that HMAC encryption cannot work at all (if really nitpicking) in any form. Also I disagree on the view that the feature could not be refined to something more reasoable. Also, both A and B are worst options in terms of backporting. Thuss, this is the best possible choice. Cc: stable@vger.kernel.or # v6.10+ Fixes: d2add27cf2b8 ("tpm: Add NULL primary creation") Suggested-by: Chris Fenner Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman

Merge tag 'tpmdd-next-6.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd

2025-07-29T01:18:16+00:00

Pull tpm updates from Jarkko Sakkinen: "Quite a few commits but nothing really that would be worth of spending too much time for, or would want to emphasize in particular" * tag 'tpmdd-next-6.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd: tpm_crb_ffa: handle tpm busy return code tpm_crb_ffa: Remove memset usage tpm_crb_ffa: Fix typos in function name tpm: Check for completion after timeout tpm: Use of_reserved_mem_region_to_resource() for "memory-region" tpm: Replace scnprintf() with sysfs_emit() and sysfs_emit_at() in sysfs show functions tpm_crb_ffa: Remove unused export tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's built-in firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall tpm/tpm_svsm: support TPM_CHIP_FLAG_SYNC tpm/tpm_ftpm_tee: support TPM_CHIP_FLAG_SYNC tpm: support devices with synchronous send() tpm: add bufsiz parameter in the .send callback

Merge tag 'libcrypto-updates-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux

2025-07-29T00:58:52+00:00

Pull crypto library updates from Eric Biggers: "This is the main crypto library pull request for 6.17. The main focus this cycle is on reorganizing the SHA-1 and SHA-2 code, providing high-quality library APIs for SHA-1 and SHA-2 including HMAC support, and establishing conventions for lib/crypto/ going forward: - Migrate the SHA-1 and SHA-512 code (and also SHA-384 which shares most of the SHA-512 code) into lib/crypto/. This includes both the generic and architecture-optimized code. Greatly simplify how the architecture-optimized code is integrated. Add an easy-to-use library API for each SHA variant, including HMAC support. Finally, reimplement the crypto_shash support on top of the library API. - Apply the same reorganization to the SHA-256 code (and also SHA-224 which shares most of the SHA-256 code). This is a somewhat smaller change, due to my earlier work on SHA-256. But this brings in all the same additional improvements that I made for SHA-1 and SHA-512. There are also some smaller changes: - Move the architecture-optimized ChaCha, Poly1305, and BLAKE2s code from arch/$(SRCARCH)/lib/crypto/ to lib/crypto/$(SRCARCH)/. For these algorithms it's just a move, not a full reorganization yet. - Fix the MIPS chacha-core.S to build with the clang assembler. - Fix the Poly1305 functions to work in all contexts. - Fix a performance regression in the x86_64 Poly1305 code. - Clean up the x86_64 SHA-NI optimized SHA-1 assembly code. Note that since the new organization of the SHA code is much simpler, the diffstat of this pull request is negative, despite the addition of new fully-documented library APIs for multiple SHA and HMAC-SHA variants. These APIs will allow further simplifications across the kernel as users start using them instead of the old-school crypto API. (I've already written a lot of such conversion patches, removing over 1000 more lines of code. But most of those will target 6.18 or later)" * tag 'libcrypto-updates-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux: (67 commits) lib/crypto: arm64/sha512-ce: Drop compatibility macros for older binutils lib/crypto: x86/sha1-ni: Convert to use rounds macros lib/crypto: x86/sha1-ni: Minor optimizations and cleanup crypto: sha1 - Remove sha1_base.h lib/crypto: x86/sha1: Migrate optimized code into library lib/crypto: sparc/sha1: Migrate optimized code into library lib/crypto: s390/sha1: Migrate optimized code into library lib/crypto: powerpc/sha1: Migrate optimized code into library lib/crypto: mips/sha1: Migrate optimized code into library lib/crypto: arm64/sha1: Migrate optimized code into library lib/crypto: arm/sha1: Migrate optimized code into library crypto: sha1 - Use same state format as legacy drivers crypto: sha1 - Wrap library and add HMAC support lib/crypto: sha1: Add HMAC support lib/crypto: sha1: Add SHA-1 library functions lib/crypto: sha1: Rename sha1_init() to sha1_init_raw() crypto: x86/sha1 - Rename conflicting symbol lib/crypto: sha2: Add hmac_sha*_init_usingrawkey() lib/crypto: arm/poly1305: Remove unneeded empty weak function lib/crypto: x86/poly1305: Fix performance regression on short messages ...

tpm_crb_ffa: handle tpm busy return code

2025-07-22T23:32:00+00:00

Platforms supporting direct message request v2 [1] can support secure partitions that support multiple services. For CRB over FF-A interface, if the firmware TPM or TPM service [1] shares its Secure Partition (SP) with another service, message requests may fail with a -EBUSY error. To handle this, replace the single check and call with a retry loop that attempts the TPM message send operation until it succeeds or a configurable timeout is reached. Implement a _try_send_receive function to do a single send/receive and modify the existing send_receive to add this retry loop. The retry mechanism introduces a module parameter (`busy_timeout_ms`, default: 2000ms) to control how long to keep retrying on -EBUSY responses. Between retries, the code waits briefly (50-100 microseconds) to avoid busy-waiting and handling TPM BUSY conditions more gracefully. The parameter can be modified at run-time as such: echo 3000 | tee /sys/module/tpm_crb_ffa/parameters/busy_timeout_ms This changes the timeout from the default 2000ms to 3000ms. [1] TPM Service Command Response Buffer Interface Over FF-A https://developer.arm.com/documentation/den0138/latest/ Signed-off-by: Prachotan Bathi Signed-off-by: Jarkko Sakkinen

tpm_crb_ffa: Remove memset usage

2025-07-22T23:31:29+00:00

Simplify initialization of `ffa_send_direct_data2` and `ffa_send_direct_data` structures by using designated initializers instead of `memset()` followed by field assignments, reducing code size and improving readability. Signed-off-by: Prachotan Bathi Suggested-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen

tpm_crb_ffa: Fix typos in function name

2025-07-22T23:30:05+00:00

Rename *recieve as __tpm_crb_ffa_send_receive [jarkko: polished commit message] Signed-off-by: Prachotan Bathi Signed-off-by: Jarkko Sakkinen

tpm: Check for completion after timeout

2025-07-22T23:23:18+00:00

The current implementation of timeout detection works in the following way: 1. Read completion status. If completed, return the data 2. Sleep for some time (usleep_range) 3. Check for timeout using current jiffies value. Return an error if timed out 4. Goto 1 usleep_range doesn't guarantee it's always going to wake up strictly in (min, max) range, so such a situation is possible: 1. Driver reads completion status. No completion yet 2. Process sleeps indefinitely. In the meantime, TPM responds 3. We check for timeout without checking for the completion again. Result is lost. Such a situation also happens for the guest VMs: if vCPU goes to sleep and doesn't get scheduled for some time, the guest TPM driver will timeout instantly after waking up without checking for the completion (which may already be in place). Perform the completion check once again after exiting the busy loop in order to give the device the last chance to send us some data. Since now we check for completion in two places, extract this check into a separate function. Signed-off-by: Ivan Orlov Reviewed-by: Jonathan McDowell Signed-off-by: Jarkko Sakkinen

tpm: Use of_reserved_mem_region_to_resource() for "memory-region"

2025-07-22T23:23:18+00:00

Use the newly added of_reserved_mem_region_to_resource() function to handle "memory-region" properties. Signed-off-by: Rob Herring Signed-off-by: Jarkko Sakkinen

tpm: Replace scnprintf() with sysfs_emit() and sysfs_emit_at() in sysfs show functions

2025-07-22T23:23:18+00:00

Documentation/filesystems/sysfs.rst mentions that show() should only use sysfs_emit() or sysfs_emit_at() when formating the value to be returned to user space. So replace scnprintf() with sysfs_emit(). Signed-off-by: Chelsy Ratnawat Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen