- 23 Oct, 2020 1 commit
-
-
Eric Biggers authored
One of the assignments that was removed by commit 4a0c1de6 ("crypto: x86/poly1305 - Remove assignments with no effect") is actually needed, since it affects the return value. This fixes the following crypto self-test failure: alg: shash: poly1305-simd test failed (wrong result) on test vector 2, cfg="init+update+final aligned buffer" Fixes: 4a0c1de6 ("crypto: x86/poly1305 - Remove assignments with no effect") Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 08 Oct, 2020 6 commits
-
-
Herbert Xu authored
The sm2 code was split out of public_key.c in a way that breaks modular builds. This patch moves the code back into the same file as the original motivation was to minimise ifdefs and that has nothing to do with splitting the code out. Fixes: 21552563 ("X.509: support OSCCA SM2-with-SM3...") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Nathan Chancellor authored
Clang warns: crypto/xor.c:101:4: warning: variable 'count' is uninitialized when used here [-Wuninitialized] count++; ^~~~~ crypto/xor.c:86:17: note: initialize the variable 'count' to silence this warning int i, j, count; ^ = 0 1 warning generated. After the refactoring to use ktime that happened in this function, count is only assigned, never read. Just remove the variable to get rid of the warning. Fixes: c055e3ea ("crypto: xor - use ktime for template benchmarking") Link: https://github.com/ClangBuiltLinux/linux/issues/1171Signed-off-by:Nathan Chancellor <natechancellor@gmail.com> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Acked-by:
Ard Biesheuvel <ardb@kernel.org> Signed-off-by:
-
Tianjia Zhang authored
When memory allocation fails, an appropriate return value should be set. Fixes: 21552563 ("X.509: support OSCCA SM2-with-SM3 certificate verification") Signed-off-by:
Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Signed-off-by:
-
Herbert Xu authored
The setkey function for GCM/CCM algorithms didn't verify the key length before copying the key and subtracting the salt length. This patch delays the copying of the key til after the verification has been done. It also adds checks on the key length to ensure that it's at least as long as the salt. Fixes: 9d12ba86 ("crypto: brcm - Add Broadcom SPU driver") Cc: <stable@vger.kernel.org> Reported-by:
kiyin(尹亮) <kiyin@tencent.com> Signed-off-by:
-
Giovanni Cabiddu authored
Remove pointer to struct pci_driver from function adf_enable_aer() as it is possible to get it directly from pdev->driver. Signed-off-by:
Giovanni Cabiddu <giovanni.cabiddu@intel.com> Reviewed-by:
Fiona Trahe <fiona.trahe@intel.com> Reviewed-by:
Wojciech Ziemba <wojciech.ziemba@intel.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by:
-
Giovanni Cabiddu authored
Fix description of function parameters. This is to fix the following warnings when compiling the driver with W=1: drivers/crypto/qat/qat_common/adf_sriov.c:133: warning: Function parameter or member 'numvfs' not described in 'adf_sriov_configure' drivers/crypto/qat/qat_common/adf_dev_mgr.c:296: warning: Function parameter or member 'pci_dev' not described in 'adf_devmgr_pci_to_accel_dev' drivers/crypto/qat/qat_common/adf_dev_mgr.c:296: warning: Excess function parameter 'accel_dev' description in 'adf_devmgr_pci_to_accel_dev' Signed-off-by:
-
- 02 Oct, 2020 29 commits
-
-
Julia Lawall authored
Replace commas with semicolons. What is done is essentially described by the following Coccinelle semantic patch (http://coccinelle.lip6.fr/): // <smpl> @@ expression e1,e2; @@ e1 -, +; e2 ... when any // </smpl> Signed-off-by:
Julia Lawall <Julia.Lawall@inria.fr> Signed-off-by:
-
Julia Lawall authored
Replace commas with semicolons. What is done is essentially described by the following Coccinelle semantic patch (http://coccinelle.lip6.fr/): // <smpl> @@ expression e1,e2; @@ e1 -, +; e2 ... when any // </smpl> Signed-off-by:
-
Julia Lawall authored
Replace commas with semicolons. What is done is essentially described by the following Coccinelle semantic patch (http://coccinelle.lip6.fr/): // <smpl> @@ expression e1,e2; @@ e1 -, +; e2 ... when any // </smpl> Signed-off-by:
-
Julia Lawall authored
Replace commas with semicolons. What is done is essentially described by the following Coccinelle semantic patch (http://coccinelle.lip6.fr/): // <smpl> @@ expression e1,e2; @@ e1 -, +; e2 ... when any // </smpl> Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Julia Lawall authored
Replace commas with semicolons. What is done is essentially described by the following Coccinelle semantic patch (http://coccinelle.lip6.fr/): // <smpl> @@ expression e1,e2; @@ e1 -, +; e2 ... when any // </smpl> Signed-off-by:
-
Ard Biesheuvel authored
Currently, we use the jiffies counter as a time source, by staring at it until a HZ period elapses, and then staring at it again and perform as many XOR operations as we can at the same time until another HZ period elapses, so that we can calculate the throughput. This takes longer than necessary, and depends on HZ, which is undesirable, since HZ is system dependent. Let's use the ktime interface instead, and use it to time a fixed number of XOR operations, which can be done much faster, and makes the time spent depend on the performance level of the system itself, which is much more reasonable. To ensure that we have the resolution we need even on systems with 32 kHz time sources, while not spending too much time in the benchmark on a slow CPU, let's switch to 3 attempts of 800 repetitions each: that way, we will only misidentify algorithms that perform within 10% of each other as the fastest if they are faster than 10 GB/s to begin with, which is not expected to occur on systems with such coarse clocks. On ThunderX2, I get the following results: Before: [72625.956765] xor: measuring software checksum speed [72625.993104] 8regs : 10169.000 MB/sec [72626.033099] 32regs : 12050.000 MB/sec [72626.073095] arm64_neon: 11100.000 MB/sec [72626.073097] xor: using function: 32regs (12050.000 MB/sec) After: [72599.650216] xor: measuring software checksum speed [72599.651188] 8regs : 10491 MB/sec [72599.652006] 32regs : 12345 MB/sec [72599.652871] arm64_neon : 11402 MB/sec [72599.652873] xor: using function: 32regs (12345 MB/sec) Link: https://lore.kernel.org/linux-crypto/20200923182230.22715-3-ardb@kernel.org/Signed-off-by:
-
Ard Biesheuvel authored
Currently, the XOR module performs its boot time benchmark at core initcall time when it is built-in, to ensure that the RAID code can make use of it when it is built-in as well. Let's defer this to a later stage during the boot, to avoid impacting the overall boot time of the system. Instead, just pick an arbitrary implementation from the list, and use that as the preliminary default. Reviewed-by:
-
Sihang Chen authored
The 'qm->curr_qm_qp_num' is not initialized, which will result in failure to write the current_q file. Signed-off-by:
Sihang Chen <chensihang1@hisilicon.com> Signed-off-by:
Yang Shen <shenyang39@huawei.com> Reviewed-by:
Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by:
-
Yang Shen authored
As before, when the ZIP device is too busy to creat a request, it will return '-EBUSY'. But the crypto process think the '-EBUSY' means a successful request and wait for its completion. So replace '-EBUSY' with '-EAGAIN' to show crypto this request is failed. Fixes: 62c455ca("crypto: hisilicon - add HiSilicon ZIP...") Signed-off-by:
-
Zhou Wang authored
The zero length input will cause a call trace when use GZIP decompress like this: Unable to handle kernel paging request at virtual address ... lr : get_gzip_head_size+0x7c/0xd0 [hisi_zip] Judge the input length and return '-EINVAL' when input is invalid. Fixes: 62c455ca("crypto: hisilicon - add HiSilicon ZIP...") Signed-off-by: -
Hao Fang authored
ZIP debug registers aren't cleared even if its driver is removed, so add a clearing operation when remove driver. Signed-off-by:
Hao Fang <fanghao11@huawei.com> Signed-off-by:
-
Herbert Xu authored
This patch removes a number of unused variables and marks others as unused in order to silence compiler warnings about them. Fixes: a8ea8bdd ("lib/mpi: Extend the MPI library") Signed-off-by:
-
Herbert Xu authored
This patch removes a few ineffectual assignments from the function crypto_poly1305_setdctxkey. Reported-by:
-
Tomer Maimon authored
Modify the read size to the correct HW random registers size, 8bit. The incorrect read size caused and faulty HW random value. Signed-off-by:
Tomer Maimon <tmaimon77@gmail.com> Signed-off-by:
-
Peter Ujfalusi authored
Make sure that we call the dma_unmap_sg on the correct scatterlist on completion with the correct sg_nents. Use sg_table to managed the DMA mapping and at the same time add the needed dma_sync calls for the sg_table. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
-
Andrei Botila authored
Newer CAAM versions (Era 9+) support 16B IVs. Since for these devices the HW limitation is no longer present newer version should process the requests containing 16B IVs directly in hardware without using a fallback. Signed-off-by:
Andrei Botila <andrei.botila@nxp.com> Reviewed-by:
Horia Geantă <horia.geanta@nxp.com> Signed-off-by:
-
Andrei Botila authored
Newer CAAM versions (Era 9+) support 16B IVs. Since for these devices the HW limitation is no longer present newer version should process the requests containing 16B IVs directly in hardware without using a fallback. Signed-off-by:
-
Andrei Botila authored
Newer CAAM versions (Era 9+) support 16B IVs. Since for these devices the HW limitation is no longer present newer version should process the requests containing 16B IVs directly in hardware without using a fallback. Signed-off-by:
-
Andrei Botila authored
XTS should not return succes when dealing with block length equal to zero. This is different than the rest of the skcipher algorithms. Fixes: 31bb2f0d ("crypto: caam - check zero-length input") Cc: <stable@vger.kernel.org> # v5.4+ Signed-off-by:
-
Andrei Botila authored
CAAM accelerator only supports XTS-AES-128 and XTS-AES-256 since it adheres strictly to the standard. All the other key lengths are accepted and processed through a fallback as long as they pass the xts_verify_key() checks. Fixes: 226853ac ("crypto: caam/qi2 - add skcipher algorithms") Cc: <stable@vger.kernel.org> # v4.20+ Signed-off-by:
-
Andrei Botila authored
CAAM accelerator only supports XTS-AES-128 and XTS-AES-256 since it adheres strictly to the standard. All the other key lengths are accepted and processed through a fallback as long as they pass the xts_verify_key() checks. Fixes: b189817c ("crypto: caam/qi - add ablkcipher and authenc algorithms") Cc: <stable@vger.kernel.org> # v4.12+ Signed-off-by:
-
Andrei Botila authored
CAAM accelerator only supports XTS-AES-128 and XTS-AES-256 since it adheres strictly to the standard. All the other key lengths are accepted and processed through a fallback as long as they pass the xts_verify_key() checks. Fixes: c6415a60 ("crypto: caam - add support for acipher xts(aes)") Cc: <stable@vger.kernel.org> # v4.4+ Signed-off-by:
-
Andrei Botila authored
A hardware limitation exists for CAAM until Era 9 which restricts the accelerator to IVs with only 8 bytes. When CAAM has a lower era a fallback is necessary to process 16 bytes IV. Fixes: 226853ac ("crypto: caam/qi2 - add skcipher algorithms") Cc: <stable@vger.kernel.org> # v4.20+ Signed-off-by:
-
Andrei Botila authored
A hardware limitation exists for CAAM until Era 9 which restricts the accelerator to IVs with only 8 bytes. When CAAM has a lower era a fallback is necessary to process 16 bytes IV. Fixes: b189817c ("crypto: caam/qi - add ablkcipher and authenc algorithms") Cc: <stable@vger.kernel.org> # v4.12+ Signed-off-by:
-
Andrei Botila authored
A hardware limitation exists for CAAM until Era 9 which restricts the accelerator to IVs with only 8 bytes. When CAAM has a lower era a fallback is necessary to process 16 bytes IV. Fixes: c6415a60 ("crypto: caam - add support for acipher xts(aes)") Cc: <stable@vger.kernel.org> # v4.4+ Signed-off-by:
-
Qinglang Miao authored
Simplify the return expression. Signed-off-by:
Qinglang Miao <miaoqinglang@huawei.com> Signed-off-by:
-
Qinglang Miao authored
Simplify the return expression. Signed-off-by:
-
Pavel Machek authored
Fix resource leak in error handling. Signed-off-by:
Pavel Machek (CIP) <pavel@denx.de> Acked-by:
John Allen <john.allen@amd.com> Signed-off-by:
-
Liu Shixin authored
Simplify the return expression. Signed-off-by:
Liu Shixin <liushixin2@huawei.com> Signed-off-by:
-
- 25 Sep, 2020 4 commits
-
-
Tianjia Zhang authored
Asymmetric digsig supports SM2-with-SM3 algorithm combination, so that IMA can also verify SM2's signature data. Signed-off-by:
Xufeng Zhang <yunbo.xufeng@linux.alibaba.com> Reviewed-by:
Mimi Zohar <zohar@linux.ibm.com> Reviewed-by:
Vitaly Chikunov <vt@altlinux.org> Signed-off-by:
-
Tianjia Zhang authored
The digital certificate format based on SM2 crypto algorithm as specified in GM/T 0015-2012. It was published by State Encryption Management Bureau, China. The method of generating Other User Information is defined as ZA=H256(ENTLA || IDA || a || b || xG || yG || xA || yA), it also specified in https://tools.ietf.org/html/draft-shen-sm2-ecdsa-02. The x509 certificate supports SM2-with-SM3 type certificate verification. Because certificate verification requires ZA in addition to tbs data, ZA also depends on elliptic curve parameters and public key data, so you need to access tbs in sig and calculate ZA. Finally calculate the digest of the signature and complete the verification work. The calculation process of ZA is declared in specifications GM/T 0009-2012 and GM/T 0003.2-2012. Signed-off-by:
Gilad Ben-Yossef <gilad@benyossef.com> Signed-off-by:
-
Tianjia Zhang authored
The digital certificate format based on SM2 crypto algorithm as specified in GM/T 0015-2012. It was published by State Encryption Management Bureau, China. This patch adds the OID object identifier defined by OSCCA. The x509 certificate supports SM2-with-SM3 type certificate parsing. It uses the standard elliptic curve public key, and the sm2 algorithm signs the hash generated by sm3. Signed-off-by:
-
Tianjia Zhang authored
Add testmgr test vectors for SM2 algorithm. These vectors come from `openssl pkeyutl -sign` and libgcrypt. Signed-off-by:
-
