- 09 Sep, 2019 19 commits
-
-
Andrey Smirnov authored
Use devres to unmap memory and drop explicit de-initialization code. NOTE: There's no corresponding unmapping code in caam_jr_remove which seems like a resource leak. Signed-off-by:
Andrey Smirnov <andrew.smirnov@gmail.com> Cc: Chris Healy <cphealy@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Horia Geantă <horia.geanta@nxp.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Iuliana Prodan <iuliana.prodan@nxp.com> Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Reviewed-by:
Horia Geantă <horia.geanta@nxp.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Andrey Smirnov authored
In order to access IP block's registers we need to enable appropriate clocks first, otherwise we are risking hanging the CPU. The problem becomes very apparent when trying to use CAAM driver built as a kernel module. In that case caam_probe() gets called after clk_disable_unused() which means all of the necessary clocks are guaranteed to be disabled. Coincidentally, this change also fixes iomap leak introduced by early return (instead of "goto iounmap_ctrl") in commit 41fc54afae70 ("crypto: caam - simplfy clock initialization") Tested on ZII i.MX6Q+ RDU2 Fixes: 176435ad ("crypto: caam - defer probing until QMan is available") Fixes: 41fc54afae70 ("crypto: caam - simplfy clock initialization") Signed-off-by: -
Ard Biesheuvel authored
Instead of relying on the CTS template to wrap the accelerated CBC skcipher, implement the ciphertext stealing part directly. Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
-
Ard Biesheuvel authored
Update the AES-XTS implementation based on NEON instructions so that it can deal with inputs whose size is not a multiple of the cipher block size. This is part of the original XTS specification, but was never implemented before in the Linux kernel. Signed-off-by:
-
Ard Biesheuvel authored
Update the AES-XTS implementation based on AES instructions so that it can deal with inputs whose size is not a multiple of the cipher block size. This is part of the original XTS specification, but was never implemented before in the Linux kernel. Signed-off-by:
-
Ard Biesheuvel authored
Update the AES-XTS implementation based on NEON instructions so that it can deal with inputs whose size is not a multiple of the cipher block size. This is part of the original XTS specification, but was never implemented before in the Linux kernel. Since the bit slicing driver is only faster if it can operate on at least 7 blocks of input at the same time, let's reuse the alternate path we are adding for CTS to process any data tail whose size is not a multiple of 128 bytes. Signed-off-by:
-
Ard Biesheuvel authored
Add the missing support for ciphertext stealing in the implementation of AES-XTS, which is part of the XTS specification but was omitted up until now due to lack of a need for it. The asm helpers are updated so they can deal with any input size, as long as the last full block and the final partial block are presented at the same time. The glue code is updated so that the common case of operating on a sector or page is mostly as before. When CTS is needed, the walk is split up into two pieces, unless the entire input is covered by a single step. Signed-off-by:
-
Ard Biesheuvel authored
Since the CTS-CBC code completes synchronously, there is no point in keeping part of the scratch data it uses in the request context, so move it to the stack instead. Signed-off-by:
-
Ard Biesheuvel authored
Optimize away one of the tbl instructions in the decryption path, which turns out to be unnecessary. Signed-off-by:
-
Ard Biesheuvel authored
After starting a skcipher walk, the only way to ensure that all resources it has tied up are released is to complete it. In some cases, it will be useful to be able to abort a walk cleanly after it has started, so add this ability to the skcipher walk API. Signed-off-by:
-
Ard Biesheuvel authored
The pure NEON AES implementation predates the bit-slicing one, and is generally slower, unless the algorithm in question can only execute sequentially. So advertising the skciphers that the bit-slicing driver implements as well serves no real purpose, and we can just disable them. Note that the bit-slicing driver also has a link time dependency on the pure NEON driver, for CBC encryption and for XTS tweak calculation, so we still need both drivers on systems that do not implement the Crypto Extensions. At the same time, expose those modaliases for the AES instruction based driver. This is necessary since otherwise, we may end up loading the wrong driver when any of the skciphers are instantiated before the CPU capability based module loading has completed. Finally, add the missing modalias for cts(cbc(aes)) so requests for this algorithm will autoload the correct module. Signed-off-by:
-
Ard Biesheuvel authored
Replace the vector load from memory sequence with a simple instruction sequence to compose the tweak vector directly. Signed-off-by:
-
Ard Biesheuvel authored
Replace the vector load from memory sequence with a simple instruction sequence to compose the tweak vector directly. Signed-off-by:
-
Ard Biesheuvel authored
Replace the vector load from memory sequence with a simple instruction sequence to compose the tweak vector directly. Signed-off-by:
-
Ard Biesheuvel authored
When the ARM AES instruction based crypto driver was introduced, there were no known implementations that could benefit from a 4-way interleave, and so a 3-way interleave was used instead. Since we have sufficient space in the SIMD register file, let's switch to a 4-way interleave to align with the 64-bit driver, and to ensure that we can reach optimum performance when running under emulation on high end 64-bit cores. Signed-off-by:
-
Ard Biesheuvel authored
Reduce the scope of the kernel_neon_begin/end regions so that the SIMD unit is released (and thus preemption re-enabled) if the crypto operation cannot be completed in a single scatterwalk step. This avoids scheduling blackouts due to preemption being enabled for unbounded periods, resulting in a more responsive system. After this change, we can also permit the cipher_walk infrastructure to sleep, so set the 'atomic' parameter to skcipher_walk_virt() to false as well. Signed-off-by:
-
Ard Biesheuvel authored
The AES round keys are arrays of u32s in native endianness now, so update the function prototypes accordingly. Signed-off-by:
-
Herbert Xu authored
skcipher_walk_done may be called with an error by internal or external callers. For those internal callers we shouldn't unmap pages but for external callers we must unmap any pages that are in use. This patch distinguishes between the two cases by checking whether walk->nbytes is zero or not. For internal callers, we now set walk->nbytes to zero prior to the call. For external callers, walk->nbytes has always been non-zero (as zero is used to indicate the termination of a walk). Reported-by:
-
zhong jiang authored
PTR_ERR_OR_ZERO contains if(IS_ERR(...)) + PTR_ERR. It is better to use it directly. hence just replace it. Signed-off-by:
zhong jiang <zhongjiang@huawei.com> Acked-by:
Will Deacon <will@kernel.org> Signed-off-by:
-
- 05 Sep, 2019 21 commits
-
-
Hans de Goede authored
lib/crypto/sha256.c and include/crypto/sha256_base.h define 99% identical functions to init a sha256_state struct for sha224 or sha256 use. This commit moves the functions from lib/crypto/sha256.c to include/crypto/sha.h (making them static inline) and makes the sha224/256_base_init static inline functions from include/crypto/sha256_base.h wrappers around the now also static inline include/crypto/sha.h functions. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Hans de Goede authored
The generic sha256 implementation from lib/crypto/sha256.c uses data structs defined in crypto/sha.h, so lets move the function prototypes there too. Signed-off-by:
-
Hans de Goede authored
Rename the sha*_init arrays to n2_sha*_init so that they do not conflict with the functions declared in crypto/sha256.h. Also rename md5_init to n2_md5_init for consistency. This is a preparation patch for folding crypto/sha256.h into crypto/sha.h. Signed-off-by:
-
Hans de Goede authored
Rename the sha*_init arrays to chcr_sha*_init so that they do not conflict with the functions declared in crypto/sha256.h. This is a preparation patch for folding crypto/sha256.h into crypto/sha.h. Signed-off-by:
-
Hans de Goede authored
Rename the algo_init arrays to cc_algo_init so that they do not conflict with the functions declared in crypto/sha256.h. This is a preparation patch for folding crypto/sha256.h into crypto/sha.h. Signed-off-by:
Gilad Ben-Yossef <gilad@benyossef.com> Signed-off-by:
-
Hans de Goede authored
Rename static / file-local functions so that they do not conflict with the functions declared in crypto/sha256.h. This is a preparation patch for folding crypto/sha256.h into crypto/sha.h. Signed-off-by:
-
Hans de Goede authored
Rename static / file-local functions so that they do not conflict with the functions declared in crypto/sha256.h. This is a preparation patch for folding crypto/sha256.h into crypto/sha.h. Signed-off-by:
-
Hans de Goede authored
Rename static / file-local functions so that they do not conflict with the functions declared in crypto/sha256.h. This is a preparation patch for folding crypto/sha256.h into crypto/sha.h. Signed-off-by:
-
Hans de Goede authored
Rename static / file-local functions so that they do not conflict with the functions declared in crypto/sha256.h. This is a preparation patch for folding crypto/sha256.h into crypto/sha.h. Signed-off-by:
-
Daniel Mack authored
The timeriomem_rng driver only accesses the first 4 bytes of the given memory area and currently, it also forces that memory resource to be exactly 4 bytes in size. This, however, is problematic when used with device-trees that are generated from things like FPGA toolchains, where the minimum size of an exposed memory block may be something like 4k. Hence, let's only check for what's needed for the driver to operate properly; namely that we have enough memory available to read the random data from. Signed-off-by:
Daniel Mack <daniel@zonque.org> Signed-off-by:
-
Pascal van Leeuwen authored
This patch adds support for the basic AES-CCM AEAD cipher suite. Signed-off-by:
Pascal van Leeuwen <pvanleeuwen@verimatrix.com> Signed-off-by:
-
Pascal van Leeuwen authored
This patch adds support for AES in output feedback mode (AES-OFB). Signed-off-by:
-
Pascal van Leeuwen authored
This patch adds support for AES in 128 bit cipher feedback mode (AES-CFB). Signed-off-by:
-
Pascal van Leeuwen authored
This patch adds support for the basic AES-GCM AEAD cipher suite. Signed-off-by:
-
Pascal van Leeuwen authored
Some minor cleanup changing e.g. "if (!x) A else B" to "if (x) B else A", merging some back-to-back if's with the same condition, collapsing some back-to-back assignments to the same variable and replacing some weird assignments with proper symbolics. Signed-off-by:
-
Pascal van Leeuwen authored
Moved counter mode handling code in front as it doesn't depend on the rest of the code to be executed, it can just do its thing and exit. Signed-off-by:
-
Pascal van Leeuwen authored
Instead of having a fixed value (of 300) all over the place, the value for for .cra_priority is now made into a define (SAFEXCEL_CRA_PRIORITY). This makes it easier to play with, e.g. during development. Signed-off-by:
-
Pascal van Leeuwen authored
This patch probes the supported algorithms from the hardware and only registers the ones that the hardware actually supports. This is necessary because this is a generic driver supposed to run on a wide variety of engines, which may or may not implement certain algorithms. Signed-off-by:
-
Pascal van Leeuwen authored
This patch adds support for the AES-XTS skcipher algorithm. Signed-off-by:
-
Pascal van Leeuwen authored
ctx->alg and ctx->mode were set from safexcel_send_req through the various safexcel_encrypt and _decrypt routines, but this makes little sense as these are static per ciphersuite. So moved to _init instead, in preparation of adding more ciphersuites. Signed-off-by:
-
Vic Wu authored
Record crypto key to context during setkey and set the key to transform state buffer in encrypt/decrypt process. Signed-off-by:
Vic Wu <vic.wu@mediatek.com> Tested-by:
John Crispin <john@phrozen.og> Signed-off-by:
-
