- 02 Mar, 2022 18 commits
-
-
Nicolai Stange authored
A subsequent commit will introduce "dh" wrapping templates of the form "ffdhe2048(dh)", "ffdhe3072(dh)" and so on in order to provide built-in support for the well-known safe-prime ffdhe group parameters specified in RFC 7919. Those templates' ->set_secret() will wrap the inner "dh" implementation's ->set_secret() and set the ->p and ->g group parameters as appropriate on the way inwards. More specifically, - A ffdheXYZ(dh) user would call crypto_dh_encode() on a struct dh instance having ->p == ->g == NULL as well as ->p_size == ->g_size == 0 and pass the resulting buffer to the outer ->set_secret(). - This outer ->set_secret() would then decode the struct dh via crypto_dh_decode_key(), set ->p, ->g, ->p_size as well as ->g_size as appropriate for the group in question and encode the struct dh again before passing it further down to the inner "dh"'s ->set_secret(). The problem is that crypto_dh_decode_key() implements some basic checks which would reject parameter sets with ->p_size == 0 and thus, the ffdheXYZ templates' ->set_secret() cannot use it as-is for decoding the passed buffer. As the inner "dh"'s ->set_secret() will eventually conduct said checks on the final parameter set anyway, the outer ->set_secret() really only needs the decoding functionality. Split out the pure struct dh decoding part from crypto_dh_decode_key() into the new __crypto_dh_decode_key(). __crypto_dh_decode_key() gets defined in crypto/dh_helper.c, but will have to get called from crypto/dh.c and thus, its declaration must be somehow made available to the latter. Strictly speaking, __crypto_dh_decode_key() is internal to the dh_generic module, yet it would be a bit over the top to introduce a new header like e.g. include/crypto/internal/dh.h containing just a single prototype. Add the __crypto_dh_decode_key() declaration to include/crypto/dh.h instead. Provide a proper kernel-doc annotation, even though __crypto_dh_decode_key() is purposedly not on the function list specified in Documentation/crypto/api-kpp.rst. Signed-off-by:
Nicolai Stange <nstange@suse.de> Reviewed-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Nicolai Stange authored
struct dh contains several pointer members corresponding to DH parameters: ->key, ->p and ->g. A subsequent commit will introduce "dh" wrapping templates of the form "ffdhe2048(dh)", "ffdhe3072(dh)" and so on in order to provide built-in support for the well-known safe-prime ffdhe group parameters specified in RFC 7919. These templates will need to set the group parameter related members of the (serialized) struct dh instance passed to the inner "dh" kpp_alg instance, i.e. ->p and ->g, to some constant, static storage arrays. Turn the struct dh pointer members' types into "pointer to const" in preparation for this. Signed-off-by:
-
Nicolai Stange authored
The only current user of the DH KPP algorithm, the keyctl(KEYCTL_DH_COMPUTE) syscall, doesn't set the domain parameter ->q in struct dh. Remove it and any associated (de)serialization code in crypto_dh_encode_key() and crypto_dh_decode_key. Adjust the encoded ->secret values in testmgr's DH test vectors accordingly. Note that the dh-generic implementation would have initialized its struct dh_ctx's ->q from the decoded struct dh's ->q, if present. If this struct dh_ctx's ->q would ever have been non-NULL, it would have enabled a full key validation as specified in NIST SP800-56A in dh_is_pubkey_valid(). However, as outlined above, ->q is always NULL in practice and the full key validation code is effectively dead. A later patch will make dh_is_pubkey_valid() to calculate Q from P on the fly, if possible, so don't remove struct dh_ctx's ->q now, but leave it there until that has happened. Signed-off-by:
-
Nicolai Stange authored
The upcoming support for the RFC 7919 ffdhe group parameters will be made available in the form of templates like "ffdhe2048(dh)", "ffdhe3072(dh)" and so on. Template instantiations thereof would wrap the inner "dh" kpp_alg and also provide kpp_alg services to the outside again. The primitves needed for providing kpp_alg services from template instances have been introduced with the previous patch. Continue this work now and implement everything needed for enabling template instances to make use of inner KPP algorithms like "dh". More specifically, define a struct crypto_kpp_spawn in close analogy to crypto_skcipher_spawn, crypto_shash_spawn and alike. Implement a crypto_grab_kpp() and crypto_drop_kpp() pair for binding such a spawn to some inner kpp_alg and for releasing it respectively. Template implementations can instantiate transforms from the underlying kpp_alg by means of the new crypto_spawn_kpp(). Finally, provide the crypto_spawn_kpp_alg() helper for accessing a spawn's underlying kpp_alg during template instantiation. Annotate everything with proper kernel-doc comments, even though include/crypto/internal/kpp.h is not considered for the generated docs. Signed-off-by:
-
Nicolai Stange authored
The upcoming support for the RFC 7919 ffdhe group parameters will be made available in the form of templates like "ffdhe2048(dh)", "ffdhe3072(dh)" and so on. Template instantiations thereof would wrap the inner "dh" kpp_alg and also provide kpp_alg services to the outside again. Furthermore, it might be perhaps be desirable to provide KDF templates in the future, which would similarly wrap an inner kpp_alg and present themselves to the outside as another kpp_alg, transforming the shared secret on its way out. Introduce the bits needed for supporting KPP template instances. Everything related to inner kpp_alg spawns potentially being held by such template instances will be deferred to a subsequent patch in order to facilitate review. Define struct struct kpp_instance in close analogy to the already existing skcipher_instance, shash_instance and alike, but wrapping a struct kpp_alg. Implement the new kpp_register_instance() template instance registration primitive. Provide some helper functions for - going back and forth between a generic struct crypto_instance and the new struct kpp_instance, - obtaining the instantiating kpp_instance from a crypto_kpp transform and - for accessing a given kpp_instance's implementation specific context data. Annotate everything with proper kernel-doc comments, even though include/crypto/internal/kpp.h is not considered for the generated docs. Signed-off-by:
-
Corentin Labbe authored
When doing iperf over ipsec with crypto hardware sun8i-ce, I hit some spinlock recursion bug. This is due to completion function called with enabled BH. Add check a to detect this. Fixes: 735d37b5 ("crypto: engine - Introduce the block request crypto engine framework") Signed-off-by:
Corentin Labbe <clabbe@baylibre.com> Signed-off-by:
-
Corentin Labbe authored
Doing ipsec produces a spinlock recursion warning. This is due to not disabling BH during crypto completion function. Fixes: 46c5338d ("crypto: sl3516 - Add sl3516 crypto engine") Signed-off-by:
-
Corentin Labbe authored
Doing ipsec produces a spinlock recursion warning. This is due to not disabling BH during crypto completion function. Fixes: 48fe583f ("crypto: amlogic - Add crypto accelerator for amlogic GXL") Signed-off-by:
-
Corentin Labbe authored
Doing ipsec produces a spinlock recursion warning. This is due to not disabling BH during crypto completion function. Fixes: 06f751b6 ("crypto: allwinner - Add sun8i-ce Crypto Engine") Signed-off-by:
-
Corentin Labbe authored
Doing ipsec produces a spinlock recursion warning. This is due to not disabling BH during crypto completion function. Fixes: f08fcced ("crypto: allwinner - Add sun8i-ss cryptographic offloader") Signed-off-by:
-
Corentin Labbe authored
On my renesas salavator-X, I saw some cavium driver failing crypto self-tests. But salvator does not have such hardware. This is due to cavium/zip driver registering algorithms even if hardware is not present. The solution is to move algorithm registration in the probe function. This permits also to simplify module init/exit by using module_pci_driver. Signed-off-by:
-
Claudiu Beznea authored
Remove extra line. Signed-off-by:
Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by:
-
Claudiu Beznea authored
Add runtime PM support. Signed-off-by:
-
Claudiu Beznea authored
Use __maybe_unused and pm_ptr() for pm ops. Signed-off-by:
-
Claudiu Beznea authored
Move set of TRNG_HALFR in atmel_trng_init() as this function is also called on resume path. In case of SAMA7G5 where backup and self-refresh PM mode is available most of the SoC parts are powered of (including TRNG) when entering suspend. In that case on resuming path TRNG_HALFR should also be re-configured. Signed-off-by:
-
Claudiu Beznea authored
s/atmel_trng_disable/atmel_trng_cleanup/g and s/atmel_trng_enable/atmel_trng_init/g to cope with struct hwrng::{init, cleanup} members. Signed-off-by: -
Claudiu Beznea authored
Call atmel_trng_disable() on failure path of probe. Fixes: a1fa98d8 ("hwrng: atmel - disable TRNG during suspend") Signed-off-by:
-
Claudiu Beznea authored
Add wait for ready support on read. Signed-off-by:
-
- 23 Feb, 2022 5 commits
-
-
Kai Ye authored
Due to the subreq pointer misuse the private context memory. The aead soft crypto occasionally casues the OS panic as setting the 64K page. Here is fix it. Fixes: 6c46a329 ("crypto: hisilicon/sec - add fallback tfm...") Signed-off-by:
Kai Ye <yekai13@huawei.com> Signed-off-by:
-
Gilad Ben-Yossef authored
Refuse to try mapping zero bytes as this may cause a fault on some configurations / platforms and it seems the prev. attempt is not enough and we need to be more explicit. Signed-off-by:
Gilad Ben-Yossef <gilad@benyossef.com> Reported-by:
Corentin Labbe <clabbe.montjoie@gmail.com> Fixes: ce0fc6db ("crypto: ccree - protect against empty or NULL scatterlists") Tested-by:
-
YueHaibing authored
This is unused after commit 768db5fe ("crypto: x86/des - drop CTR mode implementation") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
YueHaibing authored
This is unused after commit c0a64926 ("crypto: x86/blowfish - drop CTR mode implementation") Signed-off-by:
-
Harman Kalra authored
Since there are two workqueues implemented in CPTPF driver - one for handling mailbox requests from VFs and another for handling FLR. In both cases PF driver will forward the request to AF driver by writing to mailbox memory. A race condition may arise if two simultaneous requests are written to mailbox memory. Introducing locking mechanism to maintain synchronization between multiple mailbox accesses. Signed-off-by:
Harman Kalra <hkalra@marvell.com> Signed-off-by:
-
- 18 Feb, 2022 17 commits
-
-
Dominik Brodowski authored
The rng_quality sysfs attribute returns the quality setting for the currently active hw_random device, in entropy bits per 1024 bits of input. Storing a value between 0 and 1024 to this file updates this estimate accordingly. Based on the updates to the quality setting, the rngd kernel thread may be stopped (if no hw_random device is trusted to return entropy), may be started (if the quality setting is increased from zero), or may use a different hw_random source (if that has higher quality output). Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by:
-
Dominik Brodowski authored
The current_quality variable exposed as a module parameter is fundamentally broken: If it is set at boot time, it is overwritten once the first hw rng device is loaded; if it is set at runtime, it is without effect if the hw rng device had its quality value set to 0 (and no default_quality was set); and if a new rng is selected, it gets overwritten. Therefore, mark it as obsolete, and replace it by the per-rng quality setting. Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
-
Dominik Brodowski authored
Extract the start/stop logic for the in-kernel rngd thread to a separate function. Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
-
Dominik Brodowski authored
There is no real reason why this list needs to be kept ordered by the driver-provided quality value -- a value which is set only by a handful of hw_random devices anyway. Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
-
Corentin Labbe authored
When loading rockchip crypto module, testmgr complains that ivsize of ecb-des3-ede-rk is not the same than generic implementation. In fact ECB does not use an IV. Fixes: ce0183cb ("crypto: rockchip - switch to skcipher API") Signed-off-by:
-
Kai Ye authored
It is not need to enable sm4 extra mode in at HW V3. Here is fix it. Signed-off-by:
-
Kai Ye authored
Added the register configuration of the SVA mode for HW V3. Signed-off-by:
-
Julia Lawall authored
Platform_driver probe functions aren't called with locks held and thus don't need GFP_ATOMIC. Use GFP_KERNEL instead. Problem found with Coccinelle. Signed-off-by:
Julia Lawall <Julia.Lawall@inria.fr> Signed-off-by:
-
Rikard Falkeborn authored
The only usage of these is to pass their address to sysfs_{create,remove}_group(), which takes pointers to const struct attribute_group. Make them const to allow the compiler to put them in read-only memory. Signed-off-by:Rikard Falkeborn <rikard.falkeborn@gmail.com> Reviewed-by:
Daniel Axtens <dja@axtens.net> Signed-off-by:
-
Rikard Falkeborn authored
The only usage of omap_sham_attr_group is to pass its address to sysfs_{create,remove}_group(), which takes pointers to const struct attribute_group. Make it const to allow the compiler to put it in read-only memory. Signed-off-by: -
Rikard Falkeborn authored
The only usage of omap_aes_attr_group is to pass its address to sysfs_{create,remove}_group(), which takes pointers to const struct attribute_group. Make it const to allow the compiler to put it in read-only memory. Signed-off-by: -
Wojciech Ziemba authored
Add support for HW QAT Power Management (PM) feature. This feature is enabled at init time (1) by sending an admin message to the firmware, targeting the admin AE, that sets the idle time before the device changes state and (2) by unmasking the PM source of interrupt in ERRMSK2. The interrupt handler is extended to handle a PM interrupt which is triggered by HW when a PM transition occurs. In this case, the driver responds acknowledging the transaction using the HOST_MSG mailbox. Signed-off-by:
Wojciech Ziemba <wojciech.ziemba@intel.com> Co-developed-by:
Marcinx Malinowski <marcinx.malinowski@intel.com> Signed-off-by:
Giovanni Cabiddu <giovanni.cabiddu@intel.com> Reviewed-by:
Marco Chiappero <marco.chiappero@intel.com> Signed-off-by:
-
Wojciech Ziemba authored
Move error source related CSRs from 4xxx to the wider GEN4 header file. Signed-off-by:
-
Wojciech Ziemba authored
In an effort to reduce the amount of workqueues, scattered across the QAT driver, introduce the misc workqueue. This queue will be used to handle bottom halves, Power Management and more in the future. The function adf_misc_wq_queue_work() has been added to simplify the enqueuing of jobs. Signed-off-by:
-
Herbert Xu authored
The lrw template relies on ecb to work. So we need to declare a Kconfig dependency as well as a module softdep on it. Signed-off-by: -
Herbert Xu authored
The xts module needs ecb to be present as it's meant to work on top of ecb. This patch adds a softdep so ecb can be included automatically into the initramfs. Reported-by:
rftc <rftc@gmx.de> Signed-off-by:
-
Andy Shevchenko authored
While in this particular case it would not be a (critical) issue, the pattern itself is bad and error prone in case the location of the parameter is changed. Don't cast parameter to unsigned long pointer in the bit operations. Instead copy to a local variable on stack of a proper type and use. Fixes: b4b7e67c ("crypto: qat - Intel(R) QAT ucode part of fw loader") Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
-
