- 04 Oct, 2019 40 commits
-
-
Pascal van Leeuwen authored
The current driver assumes one dedicated ring interrupt controller per ring. However, some existing EIP(1)97 HW has less ring AIC's than rings. This patch allows the driver to work with such HW by detecting how many ring AIC's are present and restricting the number of rings it *uses* by the number of ring AIC's present. This allows it to at least function. (optimization for the future: add ring dispatch functionality in the interrupt service routine such that multiple rings can be supported from one ring AIC, allowing all rings to be used) Signed-off-by:
Pascal van Leeuwen <pvanleeuwen@verimatrix.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Pascal van Leeuwen authored
This patch adds support for large EIP197's with a 256 bit wide internal bus, which affects the format of the result descriptor due to internal alignment requirements. Signed-off-by:
-
Pascal van Leeuwen authored
This patch adds support for rfc4309(ccm(aes)) for use with IPsec ESP Signed-off-by:
-
Pascal van Leeuwen authored
This patch adds support for rfc4543(gcm(aes)) - i.e. AES-GMAC - for use with IPsec ESP Signed-off-by:
-
Pascal van Leeuwen authored
This patch adds support for rfc4106(gcm(aes)) for use with IPsec ESP Signed-off-by:
-
Pascal van Leeuwen authored
This patch fixed a corner case admin RAM probing issue witnessed on the Xilinx VCU118 FPGA development board with an EIP197 configuration with 4096 words of admin RAM, of which only 2050 were recognised. Signed-off-by:
-
Pascal van Leeuwen authored
This patch corrects an error in the Transform Record Cache initialization code that was causing intermittent stability problems on the Macchiatobin board. Unfortunately, due to HW platform specifics, the problem could not happen on the main development platform, being the VCU118 Xilinx development board. And since it was a problem with hash table access, it was very dependent on the actual physical context record DMA buffers being used, i.e. with some (bad) luck it could seemingly work quit stable for a while. Signed-off-by:
-
Nagadheeraj Rottela authored
Self test failures are due to wrong output IV. This patch fixes this issue by copying back output IV into skcipher request. Signed-off-by:
Nagadheeraj Rottela <rnagadheeraj@marvell.com> Reviewed-by:
Srikanth Jampala <jsrikanth@marvell.com> Signed-off-by:
-
Nagadheeraj Rottela authored
Check if device supports assoclen to solve hung task timeout error when extra tests are enabled. Return -EINVAL if assoclen is not supported. Check authsize to return -EINVAL if authentication tag size is invalid. Change blocksize to 1 to match with generic implementation. Signed-off-by:
Mallesham Jatharakonda <mallesham.jatharakonda@oneconvergence.com> Suggested-by:
-
Tony Lindgren authored
This allows us to simplify things more for probe and exit. Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Adam Ford <aford173@gmail.com> Cc: Pali Rohár <pali.rohar@gmail.com> Cc: Sebastian Reichel <sre@kernel.org> Cc: Tero Kristo <t-kristo@ti.com> Suggested-by:
Sebastian Reichel <sre@kernel.org> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Tony Lindgren authored
Nowadays we have runtime PM, and we can use it with autosuspend_timeout to idle things automatically. This allows us to get rid of the custom PM implementation. We enable clocks and init RNG in runtime_resume, and reset RNG and disable clocks in runtime_suspend. And then omap3_rom_rng_read() becomes very simple and we don't need the old functions for omap3_rom_rng_idle() and omap3_rom_rng_get_random(). We can now also get rid of pr_fmt as we're using dev_err instead. Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Adam Ford <aford173@gmail.com> Cc: Pali Rohár <pali.rohar@gmail.com> Cc: Sebastian Reichel <sre@kernel.org> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by:
-
Tony Lindgren authored
Let's update omap3-rom-rng to use standard driver data to make it easier to add runtime PM support in the following patch. Just use it for the rng ops and clock for now. Let's still keep also old rng_clk still around, we will remove delayed work and rng_clk with runtime PM in the next patch. Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Adam Ford <aford173@gmail.com> Cc: Pali Rohár <pali.rohar@gmail.com> Cc: Sebastian Reichel <sre@kernel.org> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by:
-
Tony Lindgren authored
Similar to commit 62f95ae8 ("hwrng: omap - Set default quality") we need to initialize the default quality for the RNG to be used. The symptoms of this problem is that doing hd /dev/random does not produce much data at all. Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Adam Ford <aford173@gmail.com> Cc: Pali Rohár <pali.rohar@gmail.com> Cc: Sebastian Reichel <sre@kernel.org> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by:
-
Tony Lindgren authored
When unloading omap3-rom-rng, we'll get the following: WARNING: CPU: 0 PID: 100 at drivers/clk/clk.c:948 clk_core_disable This is because the clock may be already disabled by omap3_rom_rng_idle(). Let's fix the issue by checking for rng_idle on exit. Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Adam Ford <aford173@gmail.com> Cc: Pali Rohár <pali.rohar@gmail.com> Cc: Sebastian Reichel <sre@kernel.org> Cc: Tero Kristo <t-kristo@ti.com> Fixes: 1c6b7c21 ("hwrng: OMAP3 ROM Random Number Generator support") Signed-off-by:
-
Tony Lindgren authored
Commit 0ed266d7 ("clk: ti: omap3: cleanup unnecessary clock aliases") removed old omap3 clock framework aliases but caused omap3-rom-rng to stop working with clock not found error. Based on discussions on the mailing list it was requested by Tero Kristo that it would be best to fix this issue by probing omap3-rom-rng using device tree to provide a proper clk property. The other option would be to add back the missing clock alias, but that does not help moving things forward with removing old legacy platform_data. Let's also add a proper device tree binding and keep it together with the fix. Cc: devicetree@vger.kernel.org Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Adam Ford <aford173@gmail.com> Cc: Pali Rohár <pali.rohar@gmail.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Sebastian Reichel <sre@kernel.org> Cc: Tero Kristo <t-kristo@ti.com> Fixes: 0ed266d7 ("clk: ti: omap3: cleanup unnecessary clock aliases") Reported-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Tony Lindgren authored
In general we should check for GP device instead of HS device unless the other options such as EMU are also checked. Otherwise omap3-rom-rng won't probe on few of the old n900 macro boards still in service in automated build and boot test systems. Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Adam Ford <aford173@gmail.com> Cc: Pali Rohár <pali.rohar@gmail.com> Cc: Sebastian Reichel <sre@kernel.org> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by:
-
Pascal van Leeuwen authored
This patch adds support for the authenc(hmac(sha224),cbc(des)), authenc(hmac(sha256),cbc(des)), authenc(hmac(sha384),cbc(des)) and authenc(hmac(sha512),cbc(des)) aead's changes since v1: - nothing Signed-off-by:
-
Pascal van Leeuwen authored
This patch adds support for the authenc(hmac(sha224),cbc(des3_ede)), authenc(hmac(sha256),cbc(des3_ede)), authenc(hmac(sha384),cbc(des3_ede)) and authenc(hmac(sha512),cbc(des3_ede)) aead's changes since v1: - nothing Signed-off-by:
-
Pascal van Leeuwen authored
This patch adds support for the authenc(hmac(sha1),cbc(des)) aead changes since v1: - rebased on top of DES changes made to cryptodev/master Signed-off-by:
-
Pascal van Leeuwen authored
Due to the addition of SHA3 and HMAC-SHA3 support to the inside-secure driver, it now depends on CRYPTO_SHA3. Added reference. changes since v1: - added missing dependency to crypto/Kconfig Signed-off-by:
-
Pascal van Leeuwen authored
This patch adds support for hmac(sha3-224), hmac(sha3-256), hmac(sha3-384) and hmac(sha3-512) authentication algorithms. The patch has been tested with the eip197c_iewxkbc configuration on the Xilinx VCU118 development board, including the testmgr extra tests. changes since v1: - nothing Signed-off-by:
-
Pascal van Leeuwen authored
This patch adds support for sha3-224, sha3-256, sha3-384 and sha3-512 basic hashes. The patch has been tested with the eip197c_iewxkbc configuration on the Xilinx VCU118 development board, including the testmgr extra tests. changes since v1: - nothing Signed-off-by:
-
Pascal van Leeuwen authored
This patch adds support for the authenc(hmac(sha1),cbc(sm4)), authenc(hmac(sm3),cbc(sm4)), authenc(hmac(sha1),rfc3686(ctr(sm4))), and authenc(hmac(sm3),rfc3686(ctr(sm4))) aead ciphersuites. These are necessary to support IPsec according to the Chinese standard GM/T 022-1014 - IPsec VPN specification. Note that there are no testvectors present in testmgr for these ciphersuites. However, considering all building blocks have already been verified elsewhere, it is fair to assume the generic implementation to be correct-by-construction. The hardware implementation has been fuzzed against this generic implementation by means of a locally modified testmgr. The intention is to upstream these testmgr changes but this is pending other testmgr changes being made by Eric Biggers. The patch has been tested with the eip197c_iewxkbc configuration on the Xilinx VCU118 development board, using the abovementioned modified testmgr This patch applies on top of "Add support for SM4 ciphers" and needs to be applied before "Add (HMAC) SHA3 support". Signed-off-by:
-
Ard Biesheuvel authored
The next version of Clang will start policing compiler command line options, and will reject combinations of -march and -mfpu that it thinks are incompatible. This results in errors like clang-10: warning: ignoring extension 'crypto' because the 'armv7-a' architecture does not support it [-Winvalid-command-line-argument] /tmp/aegis128-neon-inner-5ee428.s: Assembler messages: /tmp/aegis128-neon-inner-5ee428.s:73: Error: selected processor does not support `aese.8 q2,q14' in ARM mode when buiding the SIMD aegis128 code for 32-bit ARM, given that the 'armv7-a' -march argument is considered to be compatible with the ARM crypto extensions. Instead, we should use armv8-a, which does allow the crypto extensions to be enabled. Signed-off-by:Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
-
Pascal van Leeuwen authored
Added testvectors for the rfc3686(ctr(sm4)) skcipher algorithm changes since v1: - nothing Signed-off-by:
-
Pascal van Leeuwen authored
This patch adds support for SM4 in (32 bit) CTR mode, i.e. skcipher rfc3686(ctr(sm4)). changes since v1: - nothing Signed-off-by:
-
Pascal van Leeuwen authored
This patch adds support for SM4 in CFB mode, i.e. skcipher cfb(sm4). changes since v1: - nothing Signed-off-by:
-
Pascal van Leeuwen authored
Added testvectors for the ofb(sm4) and cfb(sm4) skcipher algorithms changes since v1: - nothing Signed-off-by:
-
Pascal van Leeuwen authored
This patch adds support for SM4 in OFB mode, i.e. skcipher ofb(sm4). changes since v1: - nothing Signed-off-by:
-
Pascal van Leeuwen authored
This patch adds support for SM4 in CBC mode, i.e. skcipher cbc(sm4). changes since v1: - nothing Signed-off-by:
-
Pascal van Leeuwen authored
This patch adds support for SM4 in ECB mode, i.e. skcipher ecb(sm4). changes since v1: - make SAFEXCEL_SM4 case entry explit, using the proper SM4_BLOCK_SIZE instead of "borrowing" the AES code which "coincidentally" works Signed-off-by:
-
Pascal van Leeuwen authored
Added testvectors for the hmac(sm3) ahash authentication algorithm changes since v1 & v2: -nothing Signed-off-by:
-
Pascal van Leeuwen authored
Added support for the hmac(sm3) ahash authentication algorithm changes since v1: - added Acked-by tag below, no changes to the source changes since v2: - nothing Acked-by:
Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by:
-
Pascal van Leeuwen authored
Added support for the SM3 ahash algorithm changes since v1: - moved definition of CONTEXT_CONTROL_CRYPTO_ALG_SM3 (0x7) up above 0xf changes since v2: - allow compilation if CONFIG_CRYPTO_SM3 is not set Acked-by:
-
Pascal van Leeuwen authored
Due to the addition of Chacha20-Poly1305 support to the inside-secure driver, it now depends on CRYPTO_CHACHA20POLY1305. Added reference. changes since v1: - added missing dependency to crypto/Kconfig changes since v2: - nothing changes since v3: - nothing Signed-off-by:
-
Pascal van Leeuwen authored
This patch adds support for the Chacha20-Poly1305 cipher suite. It adds both the basic rfc7539(chacha20,poly1305) as well as the rfc7539esp(chacha20,poly1305) variant for IPsec ESP acceleration. changes since v1: - rebased on top of DES library changes done on cryptodev/master - fixed crypto/Kconfig so that generic fallback is compiled as well changes since v2: - nothing changes since v3: - Fixed a problem where the tcrypt performance test would run fully on the fallback cipher instead of the HW due to using an AAD length of 8 for rfc7539esp. While this is not actually legal ESP (which includes SPI and sequence number in the AAD as well), it is both inconvenient and not necessary to run these vectors on the fallback cipher. - Due to above, also realised that for plain (non-ESP) rfc7539, you probably want to be able to run vectors with less than 8 bytes of AAD on the HW, and this is actually possible as long as cryptlen is large enough, so made that possible as well. Signed-off-by:
-
Pascal van Leeuwen authored
Added support for the CHACHA20 skcipher algorithm. Tested on an eip197c-iesb configuration in the Xilinx VCU118 devboard, passes all testmgr vectors plus the extra fuzzing tests. changes since v1: - rebased on top of DES library changes done on cryptodev/master - fixed crypto/Kconfig so that generic fallback is compiled as well changes since v2: - made switch entry SAFEXCEL_AES explit and added empty default, as requested by Antoine Tenart. Also needed to make SM4 patches apply. changes since v3: - nothing Signed-off-by:
-
Tomer Maimon authored
Add Nuvoton NPCM BMC Random Number Generator(RNG) driver. Signed-off-by:
Tomer Maimon <tmaimon77@gmail.com> Reviewed-by:
Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by:
-
Tomer Maimon authored
Added device tree binding documentation for Nuvoton BMC NPCM Random Number Generator (RNG). Signed-off-by:
-
Ard Biesheuvel authored
To improve performance on cores with deep pipelines such as ThunderX2, reimplement gcm(aes) using a 4-way interleave rather than the 2-way interleave we use currently. This comes down to a complete rewrite of the GCM part of the combined GCM/GHASH driver, and instead of interleaving two invocations of AES with the GHASH handling at the instruction level, the new version uses a more coarse grained approach where each chunk of 64 bytes is encrypted first and then ghashed (or ghashed and then decrypted in the converse case). The core NEON routine is now able to consume inputs of any size, and tail blocks of less than 64 bytes are handled using overlapping loads and stores, and processed by the same 4-way encryption and hashing routines. This gets rid of most of the branches, and avoids having to return to the C code to handle the tail block using a stack buffer. The table below compares the performance of the old driver and the new one on various micro-architectures and running in various modes. | AES-128 | AES-192 | AES-256 | #bytes | 512 | 1500 | 4k | 512 | 1500 | 4k | 512 | 1500 | 4k | -------+-----+------+-----+-----+------+-----+-----+------+-----+ TX2 | 35% | 23% | 11% | 34% | 20% | 9% | 38% | 25% | 16% | EMAG | 11% | 6% | 3% | 12% | 4% | 2% | 11% | 4% | 2% | A72 | 8% | 5% | -4% | 9% | 4% | -5% | 7% | 4% | -5% | A53 | 11% | 6% | -1% | 10% | 8% | -1% | 10% | 8% | -2% | Signed-off-by:
-
