linux-stable.git/drivers/crypto/caam, branch linux-6.3.y

crypto: caam - Clear some memory in instantiate_rng

2023-05-11T14:17:14+00:00

[ Upstream commit 9c19fb86a8cb2ee82a832c95e139f29ea05c4d08 ]

According to the comment at the end of the 'for' loop just a few lines
below, it looks needed to clear 'desc'.

So it should also be cleared for the first iteration.

Move the memset() to the beginning of the loop to be safe.

Fixes: 281922a1d4f5 ("crypto: caam - add support for SEC v5.x RNG4")
Signed-off-by: Christophe JAILLET 
Reviewed-by: Gaurav Jain 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

crypto: caam - Fix edesc/iv ordering mixup

2023-02-28T08:30:58+00:00

The attempt to add DMA alignment padding by moving IV to the front
of edesc was completely broken as it didn't change the places where
edesc was freed.

It's also wrong as the IV may still share a cache-line with the
edesc.

Fix this by restoring the original layout and simply reserving
enough memmory so that the IV is on a DMA cache-line by itself.

Reported-by: Meenakshi Aggarwal 
Fixes: 199354d7fb6e ("crypto: caam - Remove GFP_DMA and add DMA alignment padding")
Signed-off-by: Herbert Xu

crypto: caam - Use ahash_request_complete

2023-01-27T10:58:09+00:00

Instead of calling the base completion function directly, use the
correct ahash helper which is ahash_request_complete.

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

crypto: caam - Remove GFP_DMA and add DMA alignment padding

2023-01-06T09:15:47+00:00

GFP_DMA does not guarantee that the returned memory is aligned
for DMA.  It should be removed where it is superfluous.

However, kmalloc may start returning DMA-unaligned memory in future
so fix this by adding the alignment by hand.

Signed-off-by: Herbert Xu

crypto: caam - Avoid GCC memset bug warning

2023-01-06T09:15:46+00:00

Certain versions of gcc don't like the memcpy with a NULL dst
(which only happens with a zero length).  This only happens
when debugging is enabled so add an if clause to work around
these warnings.

A similar warning used to be generated by sparse but that was
fixed years ago.

Link: https://lore.kernel.org/lkml/202210290446.qBayTfzl-lkp@intel.com
Reported-by: kernel test robot 
Reported-by: Kees Cook 
Reported-by: Uwe Kleine-König 
Tested-by: Uwe Kleine-König 
Signed-off-by: Herbert Xu

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