- 02 Mar, 2022 20 commits
-
-
Nicolai Stange authored
Current work on NVME in-band authentication support ([1]) needs to invoke DH with the FFDHE safe-prime group parameters specified in RFC 7919. Introduce a new CRYPTO_DH_RFC7919_GROUPS Kconfig option. If enabled, make dh_generic register a couple of ffdheXYZ(dh) templates, one for each group: ffdhe2048(dh), ffdhe3072(dh), ffdhe4096(dh), ffdhe6144(dh) and ffdhe8192(dh). Their respective ->set_secret() expects a (serialized) struct dh, just like the underlying "dh" implementation does, but with the P and G values unset so that the safe-prime constants for the given group can be filled in by the wrapping template. Internally, a struct dh_safe_prime instance is being defined for each of the ffdheXYZ(dh) templates as appropriate. In order to prepare for future key generation, fill in the maximum security strength values as specified by SP800-56Arev3 on the go, even though they're not needed at this point yet. Implement the respective ffdheXYZ(dh) crypto_template's ->create() by simply forwarding any calls to the __dh_safe_prime_create() helper introduced with the previous commit, passing the associated dh_safe_prime in addition to the received ->create() arguments. [1] https://lore.kernel.org/r/20211202152358.60116-1-hare@suse.deSigned-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
Recent work on NVME in-band authentication support ([1]) needs to invoke the "dh" KPP with the FFDHE safe-prime group parameters as specified in RFC 7919 and generate ephemeral keys suitable for the respective group. By coincidence, the requirements from NIST SP800-56Arev3, sec. 5.5.2 ("Assurance of Domain-Parameter Validity") basically boil down to disallowing any group parameters not among the approved safe-prime groups specified in either RFC 7919 or RFC 3526 in FIPS mode. Furthermore, SP800-56Arev3 specifies the respective security strength for each of the approved safe-prime groups, which has a direct impact on the minimum key lengths. In this light, it's desirable to introduce built-in support for the RFC 7919 safe-prime groups to the kernel's DH implementation, provide a SP800-56Arev3 conforming key generation primitive for those and render non-approved group parameters unusable in FIPS mode on the way. As suggested ([2]) in the course of discussion to previous iterations of this patchset, the built-in support for ffdhe groups would be best made available in the form of templates wrapping the existing "dh" implementation, one for each group specified by RFC 7919: ffdhe2048(dh), ffdhe3072(dh), ffdhe4096(dh), ffdhe6144(dh) and ffdhe8192(dh). As these templates differ only in the safe-prime constants they'd configure the inner "dh" transforms with, they can share almost all of their "dh"-wrapping template implementation code. Introduce this common code to dh_generic. The actual dump of the RFC 7919 safe-prime constants will be deferred to the next patch in order to facilitate review. The ephemeral key generation primitive mentioned above likewise deserves a patch on its own, as does the mechanism by which unapproved groups are rendered unusable in FIPS mode. Define a struct dh_safe_prime container for specifying the individual templates' associated safe-prime group constants. All ffdheXYZ(dh) template instances will store a pointer to such a dh_safe_prime in their context areas each. Implement the common __dh_safe_prime_create() template instantiation helper. The intention is that the individual ffdheXYZ(dh) crypto_templates' ->create() implementations will simply forward any calls to __dh_safe_prime_create(), passing a suitable dh_safe_prime in addition to the received ->create() arguments. __dh_safe_prime_create() would then create and register a kpp_instance as appropriate, storing the given dh_safe_prime pointer alongside a crypto_kpp_spawn for the inner "dh" kpp_alg in the context area. As the ffdheXYZ(dh) kpp_instances are supposed to act as proxies to the inner "dh" kpp_alg, make each of their associated crypto_kpp transforms to in turn own an inner "dh" transform, a pointer to which gets stored in the context area. Setup and teardown are getting handled from the outer ->init_tfm() and ->exit_tfm() respectively. In order to achieve the overall goal and let the ffdheXYZ(dh) kpp_instances configure the inner "dh" transforms with the respective group parameters, make their common ->set_secret(), the new dh_safe_prime_set_secret(), fill in the P and G values before forwarding the call to the inner "dh"'s ->set_secret(). Note that the outer ->set_secret() can obtain the P value associated with the given ffdheXYZ(dh) kpp_instance by means of the dh_safe_prime referenced from the latter's context. The value of G OTOH always equals constant 2 for the safe-prime groups. Finally, make the remaining two kpp_alg primitives both operating on kpp_requests, i.e. ->generate_public_key() and ->compute_shared_secret(), to merely forward any request to the inner "dh" implementation. However, a kpp_request instance received from the outside cannot get simply passed on as-is, because its associated transform (crypto_kpp_reqtfm()) will have been set to the outer ffdheXYZ(dh) one. In order to handle this, reserve some space in the outer ffdheXYZ(dh) kpp_requests' context areas for in turn storing an inner kpp_request suitable for "dh" each. Make the outer ->generate_public_key() and ->compute_shared_secret() respectively to setup this inner kpp_request by means of the new dh_safe_prime_prepare_dh_req() helper before handing it over to the "dh" implementation for further processing. dh_safe_prime_prepare_dh_req() basically copies the outer kpp_request received from the outside over to the inner one, but installs the inner transform and its own ->complete() proxy callback therein. This completion callback, the new dh_safe_prime_complete_req(), doesn't do anything beyond completing the outer request. Note that there exist some examples in crypto/, which would simply install the completion handler from the outer request at the inner one in similar setups, e.g. seqiv. However, this would mean that the user-provided completion handler won't get called with the address of the outer kpp_request initially submitted and the handler might not be prepared for this. Users could certainly work around this by setting the callback ->data properly, but IMO it's cleaner this way. Furthermore, it might make sense to extend dh_safe_prime_complete_req() in the future and move e.g. those post-computation FIPS checks from the generic "dh" implementation to the ffdheXYZ(dh) templates. [1] https://lore.kernel.org/r/20211202152358.60116-1-hare@suse.de [2] https://lore.kernel.org/r/20211217055227.GA20698@gondor.apana.org.auSigned-off-by: -
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 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 15 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:
-
