linux/crypto/algapi.c, branch v5.17

crypto: api - Move cryptomgr soft dependency into algapi

2022-02-05T04:10:07Z

The soft dependency on cryptomgr is only needed in algapi because if algapi isn't present then no algorithms can be loaded. This also fixes the case where api is built-in but algapi is built as a module as the soft dependency would otherwise get lost. Fixes: 8ab23d547f65 ("crypto: api - Add softdep on cryptomgr") Reported-by: Jan Beulich Signed-off-by: Herbert Xu Tested-by: Jan Beulich Signed-off-by: Herbert Xu

crypto: api - Fix boot-up crash when crypto manager is disabled

2021-11-09T05:45:48Z

When the crypto manager is disabled, we need to explicitly set the crypto algorithms' tested status so that they can be used. Fixes: cad439fc040e ("crypto: api - Do not create test larvals if...") Reported-by: Geert Uytterhoeven Reported-by: Ido Schimmel Reported-by: Guenter Roeck Signed-off-by: Herbert Xu Tested-by: Ido Schimmel Tested-by: Geert Uytterhoeven Signed-off-by: Herbert Xu

crypto: api - Do not create test larvals if manager is disabled

2021-10-29T13:04:02Z

The delayed boot-time testing patch created a dependency loop between api.c and algapi.c because it added a crypto_alg_tested call to the former when the crypto manager is disabled. We could instead avoid creating the test larvals if the crypto manager is disabled. This avoids the dependency loop as well as saving some unnecessary work, albeit in a very unlikely case. Reported-by: Nathan Chancellor Reported-by: Naresh Kamboju Reported-by: kernel test robot Fixes: adad556efcdd ("crypto: api - Fix built-in testing dependency failures") Signed-off-by: Herbert Xu

crypto: api - Fix built-in testing dependency failures

2021-09-24T08:03:05Z

When complex algorithms that depend on other algorithms are built into the kernel, the order of registration must be done such that the underlying algorithms are ready before the ones on top are registered. As otherwise they would fail during the self-test which is required during registration. In the past we have used subsystem initialisation ordering to guarantee this. The number of such precedence levels are limited and they may cause ripple effects in other subsystems. This patch solves this problem by delaying all self-tests during boot-up for built-in algorithms. They will be tested either when something else in the kernel requests for them, or when we have finished registering all built-in algorithms, whichever comes earlier. Reported-by: Vladis Dronov Signed-off-by: Herbert Xu

crypto: api - remove CRYPTOA_U32 and related functions

2021-06-17T07:07:31Z

According to the advice of Eric and Herbert, type CRYPTOA_U32 has been unused for over a decade, so remove the code related to CRYPTOA_U32. After removing CRYPTOA_U32, the type of the variable attrs can be changed from union to struct. Signed-off-by: Liu Shixin Reviewed-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: algapi - use common mechanism for inheriting flags

2020-07-16T11:49:08Z

The flag CRYPTO_ALG_ASYNC is "inherited" in the sense that when a template is instantiated, the template will have CRYPTO_ALG_ASYNC set if any of the algorithms it uses has CRYPTO_ALG_ASYNC set. We'd like to add a second flag (CRYPTO_ALG_ALLOCATES_MEMORY) that gets "inherited" in the same way. This is difficult because the handling of CRYPTO_ALG_ASYNC is hardcoded everywhere. Address this by: - Add CRYPTO_ALG_INHERITED_FLAGS, which contains the set of flags that have these inheritance semantics. - Add crypto_algt_inherited_mask(), for use by template ->create() methods. It returns any of these flags that the user asked to be unset and thus must be passed in the 'mask' to crypto_grab_*(). - Also modify crypto_check_attr_type() to handle computing the 'mask' so that most templates can just use this. - Make crypto_grab_*() propagate these flags to the template instance being created so that templates don't have to do this themselves. Make crypto/simd.c propagate these flags too, since it "wraps" another algorithm, similar to a template. Based on a patch by Mikulas Patocka (https://lore.kernel.org/r/alpine.LRH.2.02.2006301414580.30526@file01.intranet.prod.int.rdu2.redhat.com). Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: algapi - create function to add request in front of queue

2020-05-08T05:30:40Z

Add crypto_enqueue_request_head function that enqueues a request in front of queue. This will be used in crypto-engine, on error path. In case a request was not executed by hardware, enqueue it back in front of queue (to keep the order of requests). Signed-off-by: Iuliana Prodan Signed-off-by: Herbert Xu

crypto: api - Fix use-after-free and race in crypto_spawn_alg

2020-04-16T06:49:22Z

There are two problems in crypto_spawn_alg. First of all it may return spawn->alg even if spawn->dead is set. This results in a double-free as detected by syzbot. Secondly the setting of the DYING flag is racy because we hold the read-lock instead of the write-lock. We should instead call crypto_shoot_alg in a safe manner by gaining a refcount, dropping the lock, and then releasing the refcount. This patch fixes both problems. Reported-by: syzbot+fc0674cde00b66844470@syzkaller.appspotmail.com Fixes: 4f87ee118d16 ("crypto: api - Do not zap spawn->alg") Fixes: 73669cc55646 ("crypto: api - Fix race condition in...") Cc: Signed-off-by: Herbert Xu

crypto: algapi - Avoid spurious modprobe on LOADED

2020-04-16T06:49:22Z

Currently after any algorithm is registered and tested, there's an unnecessary request_module("cryptomgr") even if it's already loaded. Also, CRYPTO_MSG_ALG_LOADED is sent twice, and thus if the algorithm is "crct10dif", lib/crc-t10dif.c replaces the tfm twice rather than once. This occurs because CRYPTO_MSG_ALG_LOADED is sent using crypto_probing_notify(), which tries to load "cryptomgr" if the notification is not handled (NOTIFY_DONE). This doesn't make sense because "cryptomgr" doesn't handle this notification. Fix this by using crypto_notify() instead of crypto_probing_notify(). Fixes: dd8b083f9a5e ("crypto: api - Introduce notifier for new crypto algorithms") Cc: # v4.20+ Cc: Martin K. Petersen Signed-off-by: Eric Biggers Reviewed-by: Martin K. Petersen Signed-off-by: Herbert Xu

crypto: algapi - remove crypto_template::{alloc,free}()

2020-01-09T03:30:58Z

Now that all templates provide a ->create() method which creates an instance, installs a strongly-typed ->free() method directly to it, and registers it, the older ->alloc() and ->free() methods in 'struct crypto_template' are no longer used. Remove them. Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu