linux-stable.git/drivers/crypto/caam, branch v6.2.2

crypto: caam - fix CAAM io mem access in blob_gen

2022-12-30T09:57:42+00:00

IO memory access has to be done with accessors defined in caam/regs.h
as there are little-endian architectures with a big-endian CAAM unit.

Fixes: 6a83830f649a ("crypto: caam - warn if blob_gen key is insecure")
Signed-off-by: Nikolaus Voss 
Reviewed-by: Ahmad Fatoum 
Signed-off-by: Herbert Xu

crypto: caam - Set DMA alignment explicitly

2022-12-02T10:12:41+00:00

This driver has been implicitly relying on kmalloc alignment
to be sufficient for DMA.  This may no longer be the case with
upcoming arm64 changes.

This patch changes it to explicitly request DMA alignment from
the Crypto API.

Signed-off-by: Herbert Xu

crypto: caam - Use helper to set reqsize

2022-12-02T10:12:39+00:00

The value of reqsize must only be changed through the helper.

Signed-off-by: Herbert Xu 
Reviewed-by: Gaurav Jain 
Signed-off-by: Herbert Xu

crypto: caam - warn if blob_gen key is insecure

2022-12-02T10:12:39+00:00

If CAAM is not in "trusted" or "secure" state, a fixed non-volatile key
is used instead of the unique device key. This is the default mode of
operation without secure boot (HAB). In this scenario, CAAM encrypted
blobs should be used only for testing but not in a production
environment, so issue a warning.

Signed-off-by: Nikolaus Voss 
Reviewed-by: Ahmad Fatoum 
Signed-off-by: Herbert Xu

hwrng: core - treat default_quality as a maximum and default to 1024

2022-11-18T08:59:34+00:00

Most hw_random devices return entropy which is assumed to be of full
quality, but driver authors don't bother setting the quality knob. Some
hw_random devices return less than full quality entropy, and then driver
authors set the quality knob. Therefore, the entropy crediting should be
opt-out rather than opt-in per-driver, to reflect the actual reality on
the ground.

For example, the two Raspberry Pi RNG drivers produce full entropy
randomness, and both EDK2 and U-Boot's drivers for these treat them as
such. The result is that EFI then uses these numbers and passes the to
Linux, and Linux credits them as boot, thereby initializing the RNG.
Yet, in Linux, the quality knob was never set to anything, and so on the
chance that Linux is booted without EFI, nothing is ever credited.
That's annoying.

The same pattern appears to repeat itself throughout various drivers. In
fact, very very few drivers have bothered setting quality=1024.

Looking at the git history of existing drivers and corresponding mailing
list discussion, this conclusion tracks. There's been a decent amount of
discussion about drivers that set quality < 1024 -- somebody read and
interepreted a datasheet, or made some back of the envelope calculation
somehow. But there's been very little, if any, discussion about most
drivers where the quality is just set to 1024 or unset (or set to 1000
when the authors misunderstood the API and assumed it was base-10 rather
than base-2); in both cases the intent was fairly clear of, "this is a
hardware random device; it's fine."

So let's invert this logic. A hw_random struct's quality knob now
controls the maximum quality a driver can produce, or 0 to specify 1024.
Then, the module-wide switch called "default_quality" is changed to
represent the maximum quality of any driver. By default it's 1024, and
the quality of any particular driver is then given by:

    min(default_quality, rng->quality ?: 1024);

This way, the user can still turn this off for weird reasons (and we can
replace whatever driver-specific disabling hacks existed in the past),
yet we get proper crediting for relevant RNGs.

Cc: Dominik Brodowski 
Cc: Ard Biesheuvel 
Cc: Herbert Xu 
Signed-off-by: Jason A. Donenfeld 
Signed-off-by: Herbert Xu

crypto: caam/qi2 - switch to netif_napi_add_tx_weight()

2022-07-15T08:43:21+00:00

caam has its own special NAPI weights. It's also a crypto device
so presumably it can't be used for packet Rx. Switch to the (new)
correct API.

Signed-off-by: Jakub Kicinski 
Signed-off-by: Herbert Xu

crypto: caam - drop unexpected word 'for' in comments

2022-06-30T07:56:57+00:00

there is an unexpected word 'for' in the comments that need to be dropped

file - drivers/crypto/caam/caamhash_desc.c
line - 25

*              must be false for for ahash first and digest

changed to:

*              must be false for ahash first and digest

Signed-off-by: Jiang Jian 
Reviewed-by: Gaurav Jain 
Signed-off-by: Herbert Xu

crypto: caam - drop unexpected word 'a' in comments

2022-06-30T07:56:57+00:00

Drop the unexpected word 'a' in the comments that need to be dropped

* This is a a cache of buffers, from which the users of CAAM QI driver
-->
* This is a cache of buffers, from which the users of CAAM QI driver

Signed-off-by: Jiang Jian 
Reviewed-by: Gaurav Jain 
Signed-off-by: Herbert Xu

Merge tag 'v5.19-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6

2022-05-28T01:06:49+00:00

Pull crypto updates from Herbert Xu:
 "API:

   - Test in-place en/decryption with two sglists in testmgr

   - Fix process vs softirq race in cryptd

  Algorithms:

   - Add arm64 acceleration for sm4

   - Add s390 acceleration for chacha20

  Drivers:

   - Add polarfire soc hwrng support in mpsf

   - Add support for TI SoC AM62x in sa2ul

   - Add support for ATSHA204 cryptochip in atmel-sha204a

   - Add support for PRNG in caam

   - Restore support for storage encryption in qat

   - Restore support for storage encryption in hisilicon/sec"

* tag 'v5.19-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (116 commits)
  hwrng: omap3-rom - fix using wrong clk_disable() in omap_rom_rng_runtime_resume()
  crypto: hisilicon/sec - delete the flag CRYPTO_ALG_ALLOCATES_MEMORY
  crypto: qat - add support for 401xx devices
  crypto: qat - re-enable registration of algorithms
  crypto: qat - honor CRYPTO_TFM_REQ_MAY_SLEEP flag
  crypto: qat - add param check for DH
  crypto: qat - add param check for RSA
  crypto: qat - remove dma_free_coherent() for DH
  crypto: qat - remove dma_free_coherent() for RSA
  crypto: qat - fix memory leak in RSA
  crypto: qat - add backlog mechanism
  crypto: qat - refactor submission logic
  crypto: qat - use pre-allocated buffers in datapath
  crypto: qat - set to zero DH parameters before free
  crypto: s390 - add crypto library interface for ChaCha20
  crypto: talitos - Uniform coding style with defined variable
  crypto: octeontx2 - simplify the return expression of otx2_cpt_aead_cbc_aes_sha_setkey()
  crypto: cryptd - Protect per-CPU resource by disabling BH.
  crypto: sun8i-ce - do not fallback if cryptlen is less than sg length
  crypto: sun8i-ce - rework debugging
  ...

crypto: caam - add in-kernel interface for blob generator

2022-05-23T15:47:50+00:00

The NXP Cryptographic Acceleration and Assurance Module (CAAM)
can be used to protect user-defined data across system reboot:

  - When the system is fused and boots into secure state, the master
    key is a unique never-disclosed device-specific key
  - random key is encrypted by key derived from master key
  - data is encrypted using the random key
  - encrypted data and its encrypted random key are stored alongside
  - This blob can now be safely stored in non-volatile memory

On next power-on:
  - blob is loaded into CAAM
  - CAAM writes decrypted data either into memory or key register

Add functions to realize encrypting and decrypting into memory alongside
the CAAM driver.

They will be used in a later commit as a source for the trusted key
seal/unseal mechanism.

Reviewed-by: David Gstir 
Reviewed-by: Pankaj Gupta 
Tested-by: Tim Harvey 
Tested-by: Matthias Schiffer 
Tested-by: Pankaj Gupta 
Tested-by: Michael Walle  # on ls1028a (non-E and E)
Tested-by: John Ernberg  # iMX8QXP
Signed-off-by: Steffen Trumtrar 
Signed-off-by: Ahmad Fatoum 
Signed-off-by: Jarkko Sakkinen