linux-stable.git/drivers/crypto/allwinner, branch linux-6.2.y

crypto: sun8i-ss - Fix a test in sun8i_ss_setup_ivs()

2023-05-17T11:58:53+00:00

[ Upstream commit 8fd91151ebcb21b3f2f2bf158ac6092192550b2b ]

SS_ENCRYPTION is (0 << 7 = 0), so the test can never be true.
Use a direct comparison to SS_ENCRYPTION instead.

The same king of test is already done the same way in sun8i_ss_run_task().

Fixes: 359e893e8af4 ("crypto: sun8i-ss - rework handling of IV")
Signed-off-by: Christophe JAILLET 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

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: sun8i-ss - use dma_addr instead u32

2022-10-21T11:05:24+00:00

The DMA address need to be stored in a dma_addr_t

Fixes: 359e893e8af4 ("crypto: sun8i-ss - rework handling of IV")
Reported-by: Dan Carpenter 
Signed-off-by: Corentin Labbe 
Signed-off-by: Herbert Xu

crypto: sun4i-ss - use DEFINE_SHOW_ATTRIBUTE to simplify sun4i_ss_debugfs

2022-09-24T08:14:44+00:00

Use DEFINE_SHOW_ATTRIBUTE helper macro to simplify the code.

Signed-off-by: Liu Shixin 
Acked-by: Corentin Labbe 
Tested-by: Corentin Labbe 
Signed-off-by: Herbert Xu

Revert "crypto: allwinner - Fix dma_map_sg error check"

2022-09-02T10:19:27+00:00

This reverts commit 2b02187bdb0bb75000850bd0309e70eb8664159e.

The original code was correct and arguably more robust than the
patched version.

Signed-off-by: Herbert Xu

crypto: allwinner - Fix dma_map_sg error check

2022-08-26T10:50:40+00:00

dma_map_sg return 0 on error.

Cc: Corentin Labbe 
Cc: Herbert Xu 
Cc: "David S. Miller" 
Cc: Chen-Yu Tsai 
Cc: Jernej Skrabec 
Cc: Samuel Holland 
Cc: Dan Carpenter 
Cc: Minghao Chi 
Cc: Peng Wu 
Cc: Alexey Khoroshilov 
Cc: linux-crypto@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-sunxi@lists.linux.dev
Cc: linux-kernel@vger.kernel.org

Signed-off-by: Jack Wang 
Signed-off-by: Herbert Xu

crypto: sun8i-ce - using the pm_runtime_resume_and_get to simplify the code

2022-08-19T10:39:36+00:00

Using pm_runtime_resume_and_get() to instade of  pm_runtime_get_sync
and pm_runtime_put_noidle.

Reported-by: Zeal Robot 
Signed-off-by: ye xingchen 
Acked-by: Jernej Skrabec 
Signed-off-by: Herbert Xu

crypto: sun8i-ss - fix infinite loop in sun8i_ss_setup_ivs()

2022-06-17T09:19:20+00:00

There is no i decrement in while (i >= 0) loop.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Signed-off-by: Alexey Khoroshilov 
Fixes: 359e893e8af4 ("crypto: sun8i-ss - rework handling of IV")
Acked-by: Corentin Labbe 
Tested-by: Corentin Labbe 
Signed-off-by: Herbert Xu

crypto: sun8i-ss - fix a NULL vs IS_ERR() check in sun8i_ss_hashkey

2022-06-10T08:43:50+00:00

The crypto_alloc_shash() function never returns NULL. It returns error
pointers.

Fixes: 801b7d572c0a ("crypto: sun8i-ss - add hmac(sha1)")
Signed-off-by: Peng Wu 
Reported-by: Hulk Robot 
Signed-off-by: Herbert Xu

crypto: sun8i-ss - Fix error codes for dma_mapping_error()

2022-06-10T08:40:16+00:00

If there is a dma_mapping_error() then return negative error codes.
Currently this code returns success.

Fixes: 801b7d572c0a ("crypto: sun8i-ss - add hmac(sha1)")
Signed-off-by: Dan Carpenter 
Acked-by: Corentin Labbe 
Tested-by: Corentin Labbe 
Signed-off-by: Herbert Xu