- 11 Sep, 2020 11 commits
-
-
Ard Biesheuvel authored
Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ard Biesheuvel authored
Signed-off-by:
-
Ard Biesheuvel authored
The RC4-HMAC-MD5 KerberosV algorithm is based on RFC 4757 [0], which was specifically issued for interoperability with Windows 2000, but was never intended to receive the same level of support. The RFC says The IETF Kerberos community supports publishing this specification as an informational document in order to describe this widely implemented technology. However, while these encryption types provide the operations necessary to implement the base Kerberos specification [RFC4120], they do not provide all the required operations in the Kerberos cryptography framework [RFC3961]. As a result, it is not generally possible to implement potential extensions to Kerberos using these encryption types. The Kerberos encryption type negotiation mechanism [RFC4537] provides one approach for using such extensions even when a Kerberos infrastructure uses long-term RC4 keys. Because this specification does not implement operations required by RFC 3961 and because of security concerns with the use of RC4 and MD4 discussed in Section 8, this specification is not appropriate for publication on the standards track. The RC4-HMAC encryption types are used to ease upgrade of existing Windows NT environments, provide strong cryptography (128-bit key lengths), and provide exportable (meet United States government export restriction requirements) encryption. This document describes the implementation of those encryption types. Furthermore, this RFC was re-classified as 'historic' by RFC 8429 [1] in 2018, stating that 'none of the encryption types it specifies should be used' Note that other outdated algorithms are left in place (some of which are guarded by CONFIG_SUNRPC_DISABLE_INSECURE_ENCTYPES), so this should only adversely affect interoperability with Windows NT/2000 systems that have not received any updates since 2008 (but are connected to a network nonetheless) [0] https://tools.ietf.org/html/rfc4757 [1] https://tools.ietf.org/html/rfc8429Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Ard Biesheuvel authored
Switch to the ARC4 library interface, to remove the pointless dependency on the skcipher API, from which we will hopefully be able to drop ecb(arc4) skcipher support. Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Ard Biesheuvel authored
Switch to the ARC4 library interface, to remove the pointless dependency on the skcipher API, from which we will hopefully be able to drop ecb(arc4) skcipher support. Signed-off-by:
-
Marco Felsch authored
The RNGB can generate 2^20 words (1 word == 4 byte) of 'random' data after the seed pool was initialized. The pool needs to be reseeded if more words are required. The reseeding is done automatically since commit 3acd9ea9 ("hwrng: imx-rngc - use automatic seeding"). We can't retrieve the TRNG values directly so we need a other way to get the quality level. We know that the PRNG uses 20.000 entropy samples from the TRNG to generate 2^20 words (1MiB) and the quality level is defined as (in bits of entropy per 1024 bits of input). So the quality level can be calculated by: 20.000 * 1024 ------------- = ~ 19.5 2^20 Signed-off-by:
Marco Felsch <m.felsch@pengutronix.de> Signed-off-by:
-
Dominik Przychodni authored
Return -EINVAL for authenc(hmac(sha1),cbc(aes)), authenc(hmac(sha256),cbc(aes)) and authenc(hmac(sha512),cbc(aes)) if the cipher length is not multiple of the AES block. This is to prevent an undefined device behaviour. Fixes: d370cec3 ("crypto: qat - Intel(R) QAT crypto interface") Cc: <stable@vger.kernel.org> Signed-off-by:
Dominik Przychodni <dominik.przychodni@intel.com> [giovanni.cabiddu@intel.com: reworded commit message] Signed-off-by:
Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by:
-
Andy Shevchenko authored
Use traditional error check pattern ret = ...; if (ret) return ret; ... instead of checking error code to be 0. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Iuliana Prodan <iuliana.prodan@nxp.com> Signed-off-by:
-
Uros Bizjak authored
x86_64 zero extends 32bit operations, so for 64bit operands, XORL r32,r32 is functionally equal to XORQ r64,r64, but avoids a REX prefix byte when legacy registers are used. Signed-off-by:
Uros Bizjak <ubizjak@gmail.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Acked-by:
Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
-
Uros Bizjak authored
x86_64 zero extends 32bit operations, so for 64bit operands, XORL r32,r32 is functionally equal to XORL r64,r64, but avoids a REX prefix byte when legacy registers are used. Signed-off-by:
-
Tero Kristo authored
Clang detects a warning for an assignment that doesn't really do anything. Fix this by removing the offending piece of code. Fixes: 7694b6ca ("crypto: sa2ul - Add crypto driver") Reported-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
Tero Kristo <t-kristo@ti.com> Reviewed-by:
-
- 04 Sep, 2020 14 commits
-
-
Herbert Xu authored
The endianness marking on the variable v in meson_cipher is wrong. It is actually in CPU-order, not little-endian. This patch fixes it. Fixes: 3d041588 ("crypto: amlogic - enable working on big...") Signed-off-by:
Corentin Labbe <clabbe@baylibre.com> Tested-by:
-
Daniel Jordan authored
At Steffen's request, I'll help maintain padata for the foreseeable future. While at it, let's have patches go to lkml too since the code is now used outside of crypto. Signed-off-by:
Daniel Jordan <daniel.m.jordan@oracle.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Steffen Klassert <steffen.klassert@secunet.com> Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Acked-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
-
Denis Efremov authored
Remove redundant memzero_explicit() in sun8i_ss_cipher() before calling kfree_sensitive(). kfree_sensitive() will zero the memory with memzero_explicit(). Fixes: 453431a5 ("mm, treewide: rename kzfree() to kfree_sensitive()") Signed-off-by:
Denis Efremov <efremov@linux.com> Signed-off-by:
-
Denis Efremov authored
Use kfree_sensitive() instead of open-coding it. Signed-off-by:
Corentin Labbe <clabbe.montjoie@gmail.com> Tested-by:
-
Denis Efremov authored
Use kfree_sensitive() instead of open-coding it. Signed-off-by:
-
Denis Efremov authored
Use kfree_sensitive() instead of open-coding it. Signed-off-by:
-
Denis Efremov authored
Use kfree_sensitive() instead of open-coding it. Signed-off-by:
Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by:
-
Krzysztof Kozlowski authored
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and also it prints the error value. Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Krzysztof Kozlowski authored
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and also it prints the error value. Signed-off-by:
-
Krzysztof Kozlowski authored
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and also it prints the error value. Signed-off-by:
Hadar Gat <hadar.gat@arm.com> Signed-off-by:
-
Herbert Xu authored
This patch fixes a sparse endianness warning by changing crc32 to __le32 instead of u32: CHECK ../arch/powerpc/crypto/crc-vpmsum_test.c ../arch/powerpc/crypto/crc-vpmsum_test.c:102:39: warning: cast from restricted __le32 Signed-off-by: -
Herbert Xu authored
This patch changes a couple u128's to be128 which is the correct type to use and fixes a few sparse warnings. Signed-off-by:
-
Herbert Xu authored
This patch adds declarations for variables only used by assembly code to silence compiler warnings: CC [M] arch/arm64/crypto/sha1-ce-glue.o AS [M] arch/arm64/crypto/sha1-ce-core.o CC [M] arch/arm64/crypto/sha2-ce-glue.o AS [M] arch/arm64/crypto/sha2-ce-core.o CHECK ../arch/arm64/crypto/sha1-ce-glue.c CHECK ../arch/arm64/crypto/sha2-ce-glue.c ../arch/arm64/crypto/sha1-ce-glue.c:38:11: warning: symbol 'sha1_ce_offsetof_count' was not declared. Should it be static? ../arch/arm64/crypto/sha1-ce-glue.c:39:11: warning: symbol 'sha1_ce_offsetof_finalize' was not declared. Should it be static? ../arch/arm64/crypto/sha2-ce-glue.c:38:11: warning: symbol 'sha256_ce_offsetof_count' was not declared. Should it be static? ../arch/arm64/crypto/sha2-ce-glue.c:40:11: warning: symbol 'sha256_ce_offsetof_finalize' was not declared. Should it be static? Signed-off-by:
-
Herbert Xu authored
This patch adds a prototype for poly1305_blocks_neon to slience a compiler warning: CC [M] arch/arm/crypto/poly1305-glue.o ../arch/arm/crypto/poly1305-glue.c:25:13: warning: no previous prototype for `poly1305_blocks_neon' [-Wmissing-prototypes] void __weak poly1305_blocks_neon(void *state, const u8 *src, u32 len, u32 hibit) ^~~~~~~~~~~~~~~~~~~~ Signed-off-by:
-
- 28 Aug, 2020 9 commits
-
-
Herbert Xu authored
This patch fixes most of the sparse endianness warnings in stm32. The patch itself doesn't change anything apart from markings, but there is some questionable code in stm32_cryp_check_ctr_counter. That function operates on the counters as if they're in CPU order, however, they're then written out as big-endian. This looks like a genuine bug. Therefore I've left that warning alone until someone can confirm that this really does work as intended on little-endian. Signed-off-by: -
dinghao.liu@zju.edu.cn authored
pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. However, users of cc_pm_get(), a direct wrapper of pm_runtime_get_sync(), assume that PM usage counter will not change on error. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Fixes: 8c7849a3 ("crypto: ccree - simplify Runtime PM handling") Signed-off-by:
Dinghao Liu <dinghao.liu@zju.edu.cn> Signed-off-by:
-
Herbert Xu authored
This patch squashes all the sparse warnings in mediatek, some of which appear to be genuine bugs. In particular, previously on BE the keys and IVs all get 32-bit swabbed which can't be right because they don't get swabbed on LE. I presume LE is the one that actually works. Another funky thing is that the GHASH key gets swabbed on LE. This makes no sense but I'm presuming someone actually tested this on LE so I'm preserving the swabbing. Someone needs to test this though as it is entirely possible that GCM is the only thing that worked on BE but not LE. Signed-off-by: -
Herbert Xu authored
As we're already using Kconfig to disable 64-bit builds for this driver, there is no point in doing it again in the source code. Signed-off-by: -
George Acosta authored
Provide an error message for users when pci_request_mem_regions failed. Signed-off-by:
George Acosta <acostag.ubuntu@gmail.com> Signed-off-by:
-
YueHaibing authored
drivers/crypto/sa2ul.c: In function ‘sa_sha_init’: drivers/crypto/sa2ul.c:1486:33: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] crypto_ahash_digestsize(tfm), (u64)rctx); ^ ./include/linux/dev_printk.h:123:47: note: in definition of macro ‘dev_dbg’ dev_printk(KERN_DEBUG, dev, dev_fmt(fmt), ##__VA_ARGS__); \ ^~~~~~~~~~~ Use %p to print rctx pointer. Signed-off-by:YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
Herbert Xu authored
This patch removes AHASH_REQUEST_ON_STACK which is unused. Signed-off-by:
-
Herbert Xu authored
This patch adds the helper ahash_alg_instance which is used to convert a crypto_ahash object into its corresponding ahash_instance. Signed-off-by: -
Herbert Xu authored
This patch adds the type-safe init_tfm/exit_tfm functions to the ahash interface. This is meant to replace the unsafe cra_init and cra_exit interface. Signed-off-by:
-
- 25 Aug, 2020 2 commits
-
-
Fabio Estevam authored
Building ARM allmodconfig leads to the following warnings: arch/arm/crypto/curve25519-glue.c:73:12: error: implicit declaration of function 'sg_copy_to_buffer' [-Werror=implicit-function-declaration] arch/arm/crypto/curve25519-glue.c:74:9: error: implicit declaration of function 'sg_nents_for_len' [-Werror=implicit-function-declaration] arch/arm/crypto/curve25519-glue.c:88:11: error: implicit declaration of function 'sg_copy_from_buffer' [-Werror=implicit-function-declaration] Include <linux/scatterlist.h> to fix such warnings Reported-by:
Olof's autobuilder <build@lixom.net> Fixes: 0c3dc787 ("crypto: algapi - Remove skbuff.h inclusion") Signed-off-by:
Fabio Estevam <festevam@gmail.com> Acked-by:
-
Herbert Xu authored
The stm32 driver was missing a number of includes that we being pulled in by unrelated header files. As the indirect inclusion went away, it now fails to build. This patch adds the missing inclusions. Reported-by:
kernel test robot <lkp@intel.com> Fixes: 0c3dc787 ("crypto: algapi - Remove skbuff.h inclusion") Signed-off-by:
-
- 21 Aug, 2020 4 commits
-
-
Yang Shen authored
When the devices are removed or not existing, the corresponding algorithms which are registered by 'hisi-zip' driver can't be used. Move 'hisi_zip_register_to_crypto' from 'hisi_zip_init' to 'hisi_zip_probe'. The algorithms will be registered to crypto only when there is device bind on the driver. And when the devices are removed, the algorithms will be unregistered. In the previous process, the function 'xxx_register_to_crypto' need a lock and a static variable to judge if the registration is the first time. Move this action into the function 'hisi_qm_alg_register'. Each device will call 'hisi_qm_alg_register' to add itself to qm list in probe process and registering algs when the qm list is empty. Signed-off-by:
Yang Shen <shenyang39@huawei.com> Reviewed-by:
Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by:
-
Weili Qian authored
Call trace will appear in the Hisilicon crypto driver unbinding or disabling SRIOV during task running with TFMs on the corresponding function. The log looks like this: [ 293.908078] Call trace: [ 293.908080] __queue_work+0x494/0x548 [ 293.908081] queue_work_on+0x84/0xd8 [ 293.908092] qm_irq+0x4c/0xd0 [hisi_qm] [ 293.908096] __handle_irq_event_percpu+0x74/0x2a0 [ 293.908098] handle_irq_event_percpu+0x40/0x98 [ 293.908099] handle_irq_event+0x4c/0x80 [ 293.908101] handle_fasteoi_irq+0xb0/0x170 [ 293.908102] generic_handle_irq+0x3c/0x58 [ 293.908103] __handle_domain_irq+0x68/0xc0 [ 293.908104] gic_handle_irq+0xb4/0x298 [ 293.908105] el1_irq+0xcc/0x180 [ 293.908107] arch_cpu_idle+0x38/0x228 [ 293.908110] default_idle_call+0x20/0x40 [ 293.908113] do_idle+0x1cc/0x2b8 [ 293.908114] cpu_startup_entry+0x2c/0x30 [ 293.908115] rest_init+0xdc/0xe8 [ 293.908117] arch_call_rest_init+0x14/0x1c [ 293.908117] start_kernel+0x490/0x4c4 This patch adds a waiting logic as user doing the above two operations to avoid panic. The two operations will hold on in the driver remove function until the tasks release all their relative TFMs. Signed-off-by:
Hui Tang <tanghui20@huawei.com> Signed-off-by:
Weili Qian <qianweili@huawei.com> Signed-off-by:
-
Yang Shen authored
Since the drivers such as HPRE/SEC/ZIP do not implement 'pci_driver.shutdow', a RAS will be triggered at OS rebooting or shutting down as the hardware device is processing request. The log looks like this: NOTICE: [NimbusSecNodeType1]:[2372L]This is sec, Base = 0x141800000 NOTICE: [NimbusSecHandle]:[2319L] SecIntSt = 0x3 NOTICE: [NimbusSecHandle]:[2320L] SecQmIntStatus = 0x2 NOTICE: [PrintSecurityType]:[344L] SecurityType is RECOVERABLE! This patch offers a new API in qm to shutdown devices, and add shutdown callbacks in ACC driver based on this new API. So the running devices will be stopped when the OS reboot or shutdown. Signed-off-by:
-
Shukun Tan authored
When PF FLR, the hardware will actively trigger the VF FLR. Configuration space of VF needs to be saved and restored to ensure that it is available after the PF FLR. Fixes: 7ce396fa("crypto: hisilicon - add FLR support") Signed-off-by:
Shukun Tan <tanshukun1@huawei.com> Signed-off-by:
-
