Commit 7cf6a8a1 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge tag 'tpmdd-next-v5.19-rc1' of... 

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

Pull tpm updates from Jarkko Sakkinen:

 - Tightened validation of key hashes for SYSTEM_BLACKLIST_HASH_LIST. An
   invalid hash format causes a compilation error. Previously, they got
   included to the kernel binary but were silently ignored at run-time.

 - Allow root user to append new hashes to the blacklist keyring.

 - Trusted keys backed with Cryptographic Acceleration and Assurance
   Module (CAAM), which part of some of the new NXP's SoC's. Now there
   is total three hardware backends for trusted keys: TPM, ARM TEE and
   CAAM.

 - A scattered set of fixes and small improvements for the TPM driver.

* tag 'tpmdd-next-v5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd:
  MAINTAINERS: add KEYS-TRUSTED-CAAM
  doc: trusted-encrypted: describe new CAAM trust source
  KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
  crypto: caam - add in-kernel interface for blob generator
  crypto: caam - determine whether CAAM supports blob encap/decap
  KEYS: trusted: allow use of kernel RNG for key material
  KEYS: trusted: allow use of TEE as backend without TCG_TPM support
  tpm: Add field upgrade mode support for Infineon TPM2 modules
  tpm: Fix buffer access in tpm2_get_tpm_pt()
  char: tpm: cr50_i2c: Suppress duplicated error message in .remove()
  tpm: cr50: Add new device/vendor ID 0x504a6666
  tpm: Remove read16/read32/write32 calls from tpm_tis_phy_ops
  tpm: ibmvtpm: Correct the return value in tpm_ibmvtpm_probe()
  tpm/tpm_ftpm_tee: Return true/false (not 1/0) from bool functions
  certs: Explain the rationale to call panic()
  certs: Allow root user to append signed hashes to the blacklist keyring
  certs: Check that builtin blacklist hashes are valid
  certs: Make blacklist_vet_description() more strict
  certs: Factor out the blacklist hash creation
  tools/certs: Add print-cert-tbs-hash.sh
parents a9d1046a 7f3113e3

Documentation/admin-guide/kernel-parameters.txt

+11 −0
Original line number Diff line number Diff line
@@ -6081,11 +6081,22 @@ 
			sources:

			- "tpm"

			- "tee"

			- "caam"

			If not specified then it defaults to iterating through

			the trust source list starting with TPM and assigns the

			first trust source as a backend which is initialized

			successfully during iteration.



	trusted.rng=	[KEYS]

			Format: <string>

			The RNG used to generate key material for trusted keys.

			Can be one of:

			- "kernel"

			- the same value as trusted.source: "tpm" or "tee"

			- "default"

			If not specified, "default" is used. In this case,

			the RNG's choice is left to each individual trust source.



	tsc=		Disable clocksource stability checks for TSC.

			Format: <string>

			[x86] reliable: mark tsc clocksource as reliable, this

Documentation/security/keys/trusted-encrypted.rst

+51 −9
Original line number Diff line number Diff line
@@ -35,6 +35,13 @@ safe. 
         Rooted to Hardware Unique Key (HUK) which is generally burnt in on-chip

         fuses and is accessible to TEE only.



     (3) CAAM (Cryptographic Acceleration and Assurance Module: IP on NXP SoCs)



         When High Assurance Boot (HAB) is enabled and the CAAM is in secure

         mode, trust is rooted to the OTPMK, a never-disclosed 256-bit key

         randomly generated and fused into each SoC at manufacturing time.

         Otherwise, a common fixed test key is used instead.



  *  Execution isolation



     (1) TPM
@@ -46,6 +53,10 @@ safe. 
         Customizable set of operations running in isolated execution

         environment verified via Secure/Trusted boot process.



     (3) CAAM



         Fixed set of operations running in isolated execution environment.



  * Optional binding to platform integrity state



     (1) TPM
@@ -63,6 +74,11 @@ safe. 
         Relies on Secure/Trusted boot process for platform integrity. It can

         be extended with TEE based measured boot process.



     (3) CAAM



         Relies on the High Assurance Boot (HAB) mechanism of NXP SoCs

         for platform integrity.



  *  Interfaces and APIs



     (1) TPM
@@ -74,10 +90,13 @@ safe. 
         TEEs have well-documented, standardized client interface and APIs. For

         more details refer to ``Documentation/staging/tee.rst``.



     (3) CAAM



         Interface is specific to silicon vendor.



  *  Threat model



     The strength and appropriateness of a particular TPM or TEE for a given

     The strength and appropriateness of a particular trust source for a given

     purpose must be assessed when using them to protect security-relevant data.
@@ -87,22 +106,32 @@ Key Generation 
Trusted Keys

------------



New keys are created from random numbers generated in the trust source. They

are encrypted/decrypted using a child key in the storage key hierarchy.

Encryption and decryption of the child key must be protected by a strong

access control policy within the trust source.

New keys are created from random numbers. They are encrypted/decrypted using

a child key in the storage key hierarchy. Encryption and decryption of the

child key must be protected by a strong access control policy within the

trust source. The random number generator in use differs according to the

selected trust source:



  *  TPM (hardware device) based RNG

  *  TPM: hardware device based RNG



     Strength of random numbers may vary from one device manufacturer to

     another.

     Keys are generated within the TPM. Strength of random numbers may vary

     from one device manufacturer to another.



  *  TEE (OP-TEE based on Arm TrustZone) based RNG

  *  TEE: OP-TEE based on Arm TrustZone based RNG



     RNG is customizable as per platform needs. It can either be direct output

     from platform specific hardware RNG or a software based Fortuna CSPRNG

     which can be seeded via multiple entropy sources.



  *  CAAM: Kernel RNG



     The normal kernel random number generator is used. To seed it from the

     CAAM HWRNG, enable CRYPTO_DEV_FSL_CAAM_RNG_API and ensure the device

     is probed.



Users may override this by specifying ``trusted.rng=kernel`` on the kernel

command-line to override the used RNG with the kernel's random number pool.



Encrypted Keys

--------------
@@ -189,6 +218,19 @@ Usage:: 
specific to TEE device implementation.  The key length for new keys is always

in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits).



Trusted Keys usage: CAAM

------------------------



Usage::



    keyctl add trusted name "new keylen" ring

    keyctl add trusted name "load hex_blob" ring

    keyctl print keyid



"keyctl print" returns an ASCII hex copy of the sealed key, which is in a

CAAM-specific format.  The key length for new keys is always in bytes.

Trusted Keys can be 32 - 128 bytes (256 - 1024 bits).



Encrypted Keys usage

--------------------

MAINTAINERS

+11 −0
Original line number Diff line number Diff line
@@ -4575,7 +4575,9 @@ L: keyrings@vger.kernel.org 
S:	Maintained

F:	Documentation/admin-guide/module-signing.rst

F:	certs/

F:	scripts/check-blacklist-hashes.awk

F:	scripts/sign-file.c

F:	tools/certs/









CFAG12864B LCD DRIVER









M:	Miguel Ojeda <ojeda@kernel.org>








@@ -10865,6 +10867,15 @@ S:	Supported







F:	include/keys/trusted_tee.h









F:	security/keys/trusted-keys/trusted_tee.c

















KEYS-TRUSTED-CAAM









M:	Ahmad Fatoum <a.fatoum@pengutronix.de>









R:	Pengutronix Kernel Team <kernel@pengutronix.de>









L:	linux-integrity@vger.kernel.org









L:	keyrings@vger.kernel.org









S:	Maintained









F:	include/keys/trusted_caam.h









F:	security/keys/trusted-keys/trusted_caam.c

















KEYS/KEYRINGS









M:	David Howells <dhowells@redhat.com>









M:	Jarkko Sakkinen <jarkko@kernel.org>
































certs/.gitignore



+1
−0






























Original line number
Diff line number
Diff line









# SPDX-License-Identifier: GPL-2.0-only









/blacklist_hashes_checked









/extract-cert









/x509_certificate_list









/x509_revocation_list
























certs/Kconfig



+15
−2






























Original line number
Diff line number
Diff line







@@ -104,8 +104,11 @@ config SYSTEM_BLACKLIST_HASH_LIST







	help









	  If set, this option should be the filename of a list of hashes in the









	  form "<hash>", "<hash>", ... .  This will be included into a C









	  wrapper to incorporate the list into the kernel.  Each <hash> should









	  be a string of hex digits.









	  wrapper to incorporate the list into the kernel.  Each <hash> must be a









	  string starting with a prefix ("tbs" or "bin"), then a colon (":"), and









	  finally an even number of hexadecimal lowercase characters (up to 128).









	  Certificate hashes can be generated with









	  tools/certs/print-cert-tbs-hash.sh .



















config SYSTEM_REVOCATION_LIST









	bool "Provide system-wide ring of revocation certificates"








@@ -124,4 +127,14 @@ config SYSTEM_REVOCATION_KEYS







	  containing X.509 certificates to be included in the default blacklist









	  keyring.



















config SYSTEM_BLACKLIST_AUTH_UPDATE









	bool "Allow root to add signed blacklist keys"









	depends on SYSTEM_BLACKLIST_KEYRING









	depends on SYSTEM_DATA_VERIFICATION









	help









	  If set, provide the ability to load new blacklist keys at run time if









	  they are signed and vouched by a certificate from the builtin trusted









	  keyring.  The PKCS#7 signature of the description is set in the key









	  payload.  Blacklist keys cannot be removed.



















endmenu