[PATCH v2 0/2 ] Bug Fixes for 4.10
This patch series includes critical bug fixes Atul Gupta (2): crypto:chcr- Fix panic on dma_unmap_sg crypto:chcr- Check device is allocated before use drivers/crypto/chelsio/chcr_algo.c | 49 +++- drivers/crypto/chelsio/chcr_core.c | 18 ++--- drivers/crypto/chelsio/chcr_crypto.h | 3 +++ 3 files changed, 37 insertions(+), 33 deletions(-) -- 1.8.2.3 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] crypto:chcr- Check device is allocated before use
Ensure dev is allocated for crypto uld context before using the device
for crypto operations.
Signed-off-by: Atul Gupta
---
drivers/crypto/chelsio/chcr_core.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/crypto/chelsio/chcr_core.c
b/drivers/crypto/chelsio/chcr_core.c
index 918da8e..1c65f07 100644
--- a/drivers/crypto/chelsio/chcr_core.c
+++ b/drivers/crypto/chelsio/chcr_core.c
@@ -52,6 +52,7 @@
int assign_chcr_device(struct chcr_dev **dev)
{
struct uld_ctx *u_ctx;
+ int ret = -ENXIO;
/*
* Which device to use if multiple devices are available TODO
@@ -59,15 +60,14 @@ int assign_chcr_device(struct chcr_dev **dev)
* must go to the same device to maintain the ordering.
*/
mutex_lock(&dev_mutex); /* TODO ? */
- u_ctx = list_first_entry(&uld_ctx_list, struct uld_ctx, entry);
- if (!u_ctx) {
- mutex_unlock(&dev_mutex);
- return -ENXIO;
+ list_for_each_entry(u_ctx, &uld_ctx_list, entry)
+ if (u_ctx && u_ctx->dev) {
+ *dev = u_ctx->dev;
+ ret = 0;
+ break;
}
-
- *dev = u_ctx->dev;
mutex_unlock(&dev_mutex);
- return 0;
+ return ret;
}
static int chcr_dev_add(struct uld_ctx *u_ctx)
@@ -202,10 +202,8 @@ static int chcr_uld_state_change(void *handle, enum
cxgb4_state state)
static int __init chcr_crypto_init(void)
{
- if (cxgb4_register_uld(CXGB4_ULD_CRYPTO, &chcr_uld_info)) {
+ if (cxgb4_register_uld(CXGB4_ULD_CRYPTO, &chcr_uld_info))
pr_err("ULD register fail: No chcr crypto support in cxgb4");
- return -1;
- }
return 0;
}
--
1.8.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] crypto:chcr- Fix panic on dma_unmap_sg
Save DMA mapped sg list addresses to request context buffer.
Signed-off-by: Atul Gupta
---
drivers/crypto/chelsio/chcr_algo.c | 49 +++-
drivers/crypto/chelsio/chcr_crypto.h | 3 +++
2 files changed, 29 insertions(+), 23 deletions(-)
diff --git a/drivers/crypto/chelsio/chcr_algo.c
b/drivers/crypto/chelsio/chcr_algo.c
index 2ed1e24..d29c2b4 100644
--- a/drivers/crypto/chelsio/chcr_algo.c
+++ b/drivers/crypto/chelsio/chcr_algo.c
@@ -158,7 +158,7 @@ int chcr_handle_resp(struct crypto_async_request *req,
unsigned char *input,
case CRYPTO_ALG_TYPE_AEAD:
ctx_req.req.aead_req = (struct aead_request *)req;
ctx_req.ctx.reqctx = aead_request_ctx(ctx_req.req.aead_req);
- dma_unmap_sg(&u_ctx->lldi.pdev->dev, ctx_req.req.aead_req->dst,
+ dma_unmap_sg(&u_ctx->lldi.pdev->dev, ctx_req.ctx.reqctx->dst,
ctx_req.ctx.reqctx->dst_nents, DMA_FROM_DEVICE);
if (ctx_req.ctx.reqctx->skb) {
kfree_skb(ctx_req.ctx.reqctx->skb);
@@ -1362,8 +1362,7 @@ static struct sk_buff *create_authenc_wr(struct
aead_request *req,
struct chcr_wr *chcr_req;
struct cpl_rx_phys_dsgl *phys_cpl;
struct phys_sge_parm sg_param;
- struct scatterlist *src, *dst;
- struct scatterlist src_sg[2], dst_sg[2];
+ struct scatterlist *src;
unsigned int frags = 0, transhdr_len;
unsigned int ivsize = crypto_aead_ivsize(tfm), dst_size = 0;
unsigned int kctx_len = 0;
@@ -1383,19 +1382,21 @@ static struct sk_buff *create_authenc_wr(struct
aead_request *req,
if (sg_nents_for_len(req->src, req->assoclen + req->cryptlen) < 0)
goto err;
- src = scatterwalk_ffwd(src_sg, req->src, req->assoclen);
- dst = src;
+ src = scatterwalk_ffwd(reqctx->srcffwd, req->src, req->assoclen);
+ reqctx->dst = src;
+
if (req->src != req->dst) {
err = chcr_copy_assoc(req, aeadctx);
if (err)
return ERR_PTR(err);
- dst = scatterwalk_ffwd(dst_sg, req->dst, req->assoclen);
+ reqctx->dst = scatterwalk_ffwd(reqctx->dstffwd, req->dst,
+ req->assoclen);
}
if (get_aead_subtype(tfm) == CRYPTO_ALG_SUB_TYPE_AEAD_NULL) {
null = 1;
assoclen = 0;
}
- reqctx->dst_nents = sg_nents_for_len(dst, req->cryptlen +
+ reqctx->dst_nents = sg_nents_for_len(reqctx->dst, req->cryptlen +
(op_type ? -authsize : authsize));
if (reqctx->dst_nents <= 0) {
pr_err("AUTHENC:Invalid Destination sg entries\n");
@@ -1460,7 +1461,7 @@ static struct sk_buff *create_authenc_wr(struct
aead_request *req,
sg_param.obsize = req->cryptlen + (op_type ? -authsize : authsize);
sg_param.qid = qid;
sg_param.align = 0;
- if (map_writesg_phys_cpl(&u_ctx->lldi.pdev->dev, phys_cpl, dst,
+ if (map_writesg_phys_cpl(&u_ctx->lldi.pdev->dev, phys_cpl, reqctx->dst,
&sg_param))
goto dstmap_fail;
@@ -1711,8 +1712,7 @@ static struct sk_buff *create_aead_ccm_wr(struct
aead_request *req,
struct chcr_wr *chcr_req;
struct cpl_rx_phys_dsgl *phys_cpl;
struct phys_sge_parm sg_param;
- struct scatterlist *src, *dst;
- struct scatterlist src_sg[2], dst_sg[2];
+ struct scatterlist *src;
unsigned int frags = 0, transhdr_len, ivsize = AES_BLOCK_SIZE;
unsigned int dst_size = 0, kctx_len;
unsigned int sub_type;
@@ -1728,17 +1728,19 @@ static struct sk_buff *create_aead_ccm_wr(struct
aead_request *req,
if (sg_nents_for_len(req->src, req->assoclen + req->cryptlen) < 0)
goto err;
sub_type = get_aead_subtype(tfm);
- src = scatterwalk_ffwd(src_sg, req->src, req->assoclen);
- dst = src;
+ src = scatterwalk_ffwd(reqctx->srcffwd, req->src, req->assoclen);
+ reqctx->dst = src;
+
if (req->src != req->dst) {
err = chcr_copy_assoc(req, aeadctx);
if (err) {
pr_err("AAD copy to destination buffer fails\n");
return ERR_PTR(err);
}
- dst = scatterwalk_ffwd(dst_sg, req->dst, req->assoclen);
+ reqctx->dst = scatterwalk_ffwd(reqctx->dstffwd, req->dst,
+ req->assoclen);
}
- reqctx->dst_nents = sg_nents_for_len(dst, req->cryptlen +
+ reqctx->dst_nents = sg_nents_for_len(reqctx->dst, req->cryptlen +
(op_type ? -authsize : authsize));
if (reqctx->dst_nents <= 0) {
pr_err("CCM:Invalid Destination sg entries\n");
@@ -1777,7 +1779,7 @@ static struct sk_buff *create_aead_
Re: [PATCH v4 1/4] lib: Update LZ4 compressor module
On Sun, 22 Jan 2017 20:35:14 +0100 Sven Schmidt
<4ssch...@informatik.uni-hamburg.de> wrote:
> This patch updates LZ4 kernel module to LZ4 v1.7.3 by Yann Collet.
> The kernel module is inspired by the previous work by Chanho Min.
> The updated LZ4 module will not break existing code since there were alias
> methods added to ensure backwards compatibility.
>
> API changes:
>
> New method LZ4_compress_fast which differs from the variant available
> in kernel by the new acceleration parameter,
> allowing to trade compression ratio for more compression speed
> and vice versa.
>
> LZ4_decompress_fast is the respective decompression method, featuring a very
> fast decoder (multiple GB/s per core), able to reach RAM speed in multi-core
> systems. The decompressor allows to decompress data compressed with
> LZ4 fast as well as the LZ4 HC (high compression) algorithm.
>
> Also the useful functions LZ4_decompress_safe_partial
> LZ4_compress_destsize were added. The latter reverses the logic by trying to
> compress as much data as possible from source to dest while the former aims
> to decompress partial blocks of data.
>
> A bunch of streaming functions were also added
> which allow compressig/decompressing data in multiple steps
> (so called "streaming mode").
>
> The methods lz4_compress and lz4_decompress_unknownoutputsize
> are now known as LZ4_compress_default respectivley LZ4_decompress_safe.
> The old methods are still available for providing backwards compatibility.
>
> ...
>
> +/*
> + * For backward compatibility
> + */
> +static inline int lz4_compressbound(size_t isize)
> {
Do we actually need the back-compat wrappers? After your other three
patches we have no callers, correct? If so, we should go ahead and
eliminate such back-compatibility interfaces.
> - return isize + (isize / 255) + 16;
> + return LZ4_COMPRESSBOUND(isize);
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] crypto: api - Clear CRYPTO_ALG_DEAD bit before registering an alg
Hi Herbert, > -Original Message- > From: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto- > ow...@vger.kernel.org] On Behalf Of Herbert Xu > Sent: Monday, January 23, 2017 2:58 PM > To: Benedetto, Salvatore > Cc: linux-crypto@vger.kernel.org > Subject: Re: [PATCH] crypto: api - Clear CRYPTO_ALG_DEAD bit before > registering an alg > > On Fri, Jan 13, 2017 at 11:54:08AM +, Salvatore Benedetto wrote: > > Make sure CRYPTO_ALG_DEAD bit is cleared before proceeding with the > > algorithm registration. This fixes qat-dh registration when driver is > > restarted > > > > Signed-off-by: Salvatore Benedetto > > Patch applied. Thanks. I forgot to add CC stable to it. This error was introduced in 4.8 and so I think it should go into stable 4.8 and 4.9. Should I resend or can you add that? Regards, Salvatore > -- > Email: Herbert Xu Home Page: > http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt > -- > To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the > body of a message to majord...@vger.kernel.org More majordomo info at > http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: vmx -- disable preemption to enable vsx in aes_ctr.c
On Fri, 20 Jan 2017 16:35:33 +0800
Li Zhong wrote:
> Some preemptible check warnings were reported from
> enable_kernel_vsx(). This patch disables preemption in aes_ctr.c
> before enabling vsx, and they are now consistent with other files in
> the same directory.
>
> Signed-off-by: Li Zhong
> ---
> drivers/crypto/vmx/aes_ctr.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/crypto/vmx/aes_ctr.c
> b/drivers/crypto/vmx/aes_ctr.c index 38ed10d..7cf6d31 100644
> --- a/drivers/crypto/vmx/aes_ctr.c
> +++ b/drivers/crypto/vmx/aes_ctr.c
> @@ -80,11 +80,13 @@ static int p8_aes_ctr_setkey(struct crypto_tfm
> *tfm, const u8 *key, int ret;
> struct p8_aes_ctr_ctx *ctx = crypto_tfm_ctx(tfm);
>
> + preempt_disable();
> pagefault_disable();
> enable_kernel_vsx();
> ret = aes_p8_set_encrypt_key(key, keylen * 8, &ctx->enc_key);
> disable_kernel_vsx();
> pagefault_enable();
> + preempt_enable();
>
> ret += crypto_blkcipher_setkey(ctx->fallback, key, keylen);
> return ret;
> @@ -99,11 +101,13 @@ static void p8_aes_ctr_final(struct
> p8_aes_ctr_ctx *ctx, u8 *dst = walk->dst.virt.addr;
> unsigned int nbytes = walk->nbytes;
>
> + preempt_disable();
> pagefault_disable();
> enable_kernel_vsx();
> aes_p8_encrypt(ctrblk, keystream, &ctx->enc_key);
> disable_kernel_vsx();
> pagefault_enable();
> + preempt_enable();
>
> crypto_xor(keystream, src, nbytes);
> memcpy(dst, keystream, nbytes);
> @@ -132,6 +136,7 @@ static int p8_aes_ctr_crypt(struct blkcipher_desc
> *desc, blkcipher_walk_init(&walk, dst, src, nbytes);
> ret = blkcipher_walk_virt_block(desc, &walk,
> AES_BLOCK_SIZE); while ((nbytes = walk.nbytes) >= AES_BLOCK_SIZE) {
> + preempt_disable();
> pagefault_disable();
> enable_kernel_vsx();
> aes_p8_ctr32_encrypt_blocks(walk.src.virt.addr,
> @@ -143,6 +148,7 @@ static int p8_aes_ctr_crypt(struct blkcipher_desc
> *desc, walk.iv);
> disable_kernel_vsx();
> pagefault_enable();
> + preempt_enable();
>
> /* We need to update IV mostly for last
> bytes/round */ inc = (nbytes & AES_BLOCK_MASK) / AES_BLOCK_SIZE;
>
>
Well observed, Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] x86/crypto: make constants readonly, allow linker to merge them
On 01/20/2017 12:09 AM, Thomas Gleixner wrote: On Thu, 19 Jan 2017, Denys Vlasenko wrote: A lot of asm-optimized routines in arch/x86/crypto/ keep its constants in .data. This is wrong, they should be on .rodata. Mnay of these constants are the same in different modules. For example, 128-bit shuffle mask 0x000102030405060708090A0B0C0D0E0F exists in at least half a dozen places. There is a way to let linker merge them and use just one copy. The rules are as follows: mergeable objects of different sizes should not share sections. You can't put them all in one .rodata section, they will lose "mergeability". GCC puts its mergeable constants in ".rodata.cstSIZE" sections, or ".rodata.cstSIZE." if -fdata-sections is used. This patch does the same: .section .rodata.cst16.SHUF_MASK, "aM", @progbits, 16 It is important that all data in such section consists of 16-byte elements, not larger ones, and there are no implicit use of one element from another. When this is not the case, use non-mergeable section: .section .rodata[.VAR_NAME], "a", @progbits This reduces .data by ~15 kbytes: textdata bss dec hex filename 11097415 2705840 2630712 16433967 fac32f vmlinux-prev.o 2095 2690672 2630712 16433479 fac147 vmlinux.o And at the same time it increases text size by ~15k. The overall change in total size is 488 byte reduction. Weird. Of course: the constants do need to go somewhere. They migrate to .rodata.blabla sections, which eventually got appended to read-only .text Without merging, if I would just move constants to .rodata, there would be no net size win at all. I did not look deepper why the overall change is smaller than expected. It may be affected by changed padding. The linker is not too clever about it, and also IIRC we don't actually giving it the best options to sort sections during link time to pack them better. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: tcrypt - Add mode to test specified algs
On Mon, Jan 23, 2017 at 10:14:03PM +0800, Herbert Xu wrote:
> On Wed, Jan 18, 2017 at 05:25:00PM +0100, Rabin Vincent wrote:
> > From: Rabin Vincent
> > tcrypt offers a bunch of mode= values to test various (groups of)
> > algorithms, but there is no way provided to test a subset of the
> > algorithms. This adds a new mode=2000 which interprets alg= as a
> > colon-separated list of algorithms to test with alg_test(). Colon is
> > used since the names may contain commas.
> >
> > This is useful during driver development and also for regression testing
> > to avoid the errors that are otherwise generated when attempting to test
> > non-enabled algorithms.
> >
> > # insmod tcrypt.ko dyndbg mode=2000
> > alg="cbc(aes):ecb(aes):hmac(sha256):sha256:xts(aes)"
> > [ 649.418569] tcrypt: testing cbc(aes)
> > [ 649.420809] tcrypt: testing ecb(aes)
> > [ 649.422627] tcrypt: testing hmac(sha256)
> > [ 649.424861] tcrypt: testing sha256
> > [ 649.426368] tcrypt: testing xts(aes)
> > [ 649.430014] tcrypt: all tests passed
> >
> > Signed-off-by: Rabin Vincent
>
> You can already do this with the existing mode=0 setting, no?
That's what I thought so too, but that doesn't seem to be the case. The
mode=0 handling is this:
switch (m) {
case 0:
if (alg) {
if (!crypto_has_alg(alg, type,
mask ?: CRYPTO_ALG_TYPE_MASK))
ret = -ENOENT;
break;
}
for (i = 1; i < 200; i++)
ret += do_test(NULL, 0, 0, i);
break;
So, if alg= is specified, after first checking if the specified alg is
present, it just goes ahead and runs all the tests. I'm not sure what
mode=0 alg=foo is meant to be used for.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: vmx -- disable preemption to enable vsx in aes_ctr.c
Li Zhong wrote: > Some preemptible check warnings were reported from enable_kernel_vsx(). This > patch disables preemption in aes_ctr.c before enabling vsx, and they are now > consistent with other files in the same directory. > > Signed-off-by: Li Zhong Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] x86/crypto: fix %progbits -> @progbits
On Thu, Jan 19, 2017 at 10:28:05PM +0100, Denys Vlasenko wrote: > %progbits form is used on ARM (where @ is a comment char). > > x86 consistently uses @progbits everywhere else. > > Signed-off-by: Denys Vlasenko Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] update mediatek crypto driver
On Fri, Jan 20, 2017 at 01:41:07PM +0800, Ryder Lee wrote: > Hi, > > This series of patches is a global rework of the mtk driver. > Fix bug - incomplete DMA data transfer when SG buffer dst.len != src.len > > It also updates some part of the code to make them more generic. For > instance the crypto request queue management supports both async block > cipher and AEAD requests, which allows us to add support the the GCM mode. > GMAC mode is not supported yet. > > Current implementation was validated using the tcrypt > module running modes: > - 10: ecb(aes), cbc(aes), ctr(aes), rfc3686(ctr(aes)) > - 35: gcm(aes) > - 2,6,11,12: sha1, sha2 family > > tcrypt speed test was run with modes: > - 211: rfc4106(gcm(aes)), gcm(aes) > - 500: ecb(aes), cbc(aes), ctr(aes), rfc3686(ctr(aes)) > - 403 ~ 406: sha1, sha2 family > > IxChariot multiple pairs throughput 24 hours test: > - IPSec VPN > - MACSec > > Ryder Lee (8): > crypto: mediatek - move HW control data to transformation context > crypto: mediatek - fix incorrect data transfer result > crypto: mediatek - make crypto request queue management more generic > crypto: mediatek - rework crypto request completion > crypto: mediatek - regroup functions by usage > crypto: mediatek - fix typo and indentation > crypto: mediatek - add support to CTR mode > crypto: mediatek - add support to GCM mode All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] x86/crypto: make constants readonly, allow linker to merge them
On Thu, Jan 19, 2017 at 10:33:04PM +0100, Denys Vlasenko wrote: > A lot of asm-optimized routines in arch/x86/crypto/ keep its > constants in .data. This is wrong, they should be on .rodata. > > Mnay of these constants are the same in different modules. > For example, 128-bit shuffle mask 0x000102030405060708090A0B0C0D0E0F > exists in at least half a dozen places. > > There is a way to let linker merge them and use just one copy. > The rules are as follows: mergeable objects of different sizes > should not share sections. You can't put them all in one .rodata > section, they will lose "mergeability". > > GCC puts its mergeable constants in ".rodata.cstSIZE" sections, > or ".rodata.cstSIZE." if -fdata-sections is used. > This patch does the same: > > .section .rodata.cst16.SHUF_MASK, "aM", @progbits, 16 > > It is important that all data in such section consists of > 16-byte elements, not larger ones, and there are no implicit > use of one element from another. > > When this is not the case, use non-mergeable section: > > .section .rodata[.VAR_NAME], "a", @progbits > > This reduces .data by ~15 kbytes: > > textdata bss dec hex filename > 11097415 2705840 2630712 16433967 fac32f vmlinux-prev.o > 2095 2690672 2630712 16433479 fac147 vmlinux.o > > Merged objects are visible in System.map: > > 81a28810 r POLY > 81a28810 r POLY > 81a28820 r TWOONE > 81a28820 r TWOONE > 81a28830 r PSHUFFLE_BYTE_FLIP_MASK <- merged regardless of > 81a28830 r SHUF_MASK <- the name difference > 81a28830 r SHUF_MASK > 81a28830 r SHUF_MASK > .. > 81a28d00 r K512 <- merged three identical 640-byte tables > 81a28d00 r K512 > 81a28d00 r K512 > > Use of object names in section name suffixes is not strictly necessary, > but might help if someday link stage will use garbage collection > to eliminate unused sections (ld --gc-sections). > > Signed-off-by: Denys Vlasenko Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: tcrypt - Add mode to test specified algs
On Wed, Jan 18, 2017 at 05:25:00PM +0100, Rabin Vincent wrote: > From: Rabin Vincent > > tcrypt offers a bunch of mode= values to test various (groups of) > algorithms, but there is no way provided to test a subset of the > algorithms. This adds a new mode=2000 which interprets alg= as a > colon-separated list of algorithms to test with alg_test(). Colon is > used since the names may contain commas. > > This is useful during driver development and also for regression testing > to avoid the errors that are otherwise generated when attempting to test > non-enabled algorithms. > > # insmod tcrypt.ko dyndbg mode=2000 > alg="cbc(aes):ecb(aes):hmac(sha256):sha256:xts(aes)" > [ 649.418569] tcrypt: testing cbc(aes) > [ 649.420809] tcrypt: testing ecb(aes) > [ 649.422627] tcrypt: testing hmac(sha256) > [ 649.424861] tcrypt: testing sha256 > [ 649.426368] tcrypt: testing xts(aes) > [ 649.430014] tcrypt: all tests passed > > Signed-off-by: Rabin Vincent You can already do this with the existing mode=0 setting, no? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: arm/aes-neonbs - fix issue with v2.22 and older assembler
On Thu, Jan 19, 2017 at 12:23:32PM +, Ard Biesheuvel wrote: > The GNU assembler for ARM version 2.22 or older fails to infer the > element size from the vmov instructions, and aborts the build in > the following way; > > .../aes-neonbs-core.S: Assembler messages: > .../aes-neonbs-core.S:817: Error: bad type for scalar -- `vmov q1h[1],r10' > .../aes-neonbs-core.S:817: Error: bad type for scalar -- `vmov q1h[0],r9' > .../aes-neonbs-core.S:817: Error: bad type for scalar -- `vmov q1l[1],r8' > .../aes-neonbs-core.S:817: Error: bad type for scalar -- `vmov q1l[0],r7' > .../aes-neonbs-core.S:818: Error: bad type for scalar -- `vmov q2h[1],r10' > .../aes-neonbs-core.S:818: Error: bad type for scalar -- `vmov q2h[0],r9' > .../aes-neonbs-core.S:818: Error: bad type for scalar -- `vmov q2l[1],r8' > .../aes-neonbs-core.S:818: Error: bad type for scalar -- `vmov q2l[0],r7' > > Fix this by setting the element size explicitly, by replacing vmov with > vmov.32. > > Signed-off-by: Ard Biesheuvel Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: tcrypt - Add debug prints
On Wed, Jan 18, 2017 at 02:54:05PM +0100, Rabin Vincent wrote: > From: Rabin Vincent > > tcrypt is very tight-lipped when it succeeds, but a bit more feedback > would be useful when developing or debugging crypto drivers, especially > since even a successful run ends with the module failing to insert. Add > a couple of debug prints, which can be enabled with dynamic debug: > > Before: > > # insmod tcrypt.ko mode=10 > insmod: can't insert 'tcrypt.ko': Resource temporarily unavailable > > After: > > # insmod tcrypt.ko mode=10 dyndbg > tcrypt: testing ecb(aes) > tcrypt: testing cbc(aes) > tcrypt: testing lrw(aes) > tcrypt: testing xts(aes) > tcrypt: testing ctr(aes) > tcrypt: testing rfc3686(ctr(aes)) > tcrypt: all tests passed > insmod: can't insert 'tcrypt.ko': Resource temporarily unavailable > > Signed-off-by: Rabin Vincent Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: arm64/aes-blk - honour iv_out requirement in CBC and CTR modes
On Tue, Jan 17, 2017 at 01:46:29PM +, Ard Biesheuvel wrote: > Update the ARMv8 Crypto Extensions and the plain NEON AES implementations > in CBC and CTR modes to return the next IV back to the skcipher API client. > This is necessary for chaining to work correctly. > > Note that for CTR, this is only done if the request is a round multiple of > the block size, since otherwise, chaining is impossible anyway. > > Cc: # v3.16+ > Signed-off-by: Ard Biesheuvel Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] crypto: img-hash - use dma_data_direction when calling dma_map_sg
On Sun, Jan 15, 2017 at 01:37:50PM +0100, Nicolas Iooss wrote: > The fourth argument of dma_map_sg() and dma_unmap_sg() is an item of > dma_data_direction enum. Function img_hash_xmit_dma() wrongly used > DMA_MEM_TO_DEV, which is an item of dma_transfer_direction enum. > > Replace DMA_MEM_TO_DEV (which value is 1) with DMA_TO_DEVICE (which > value is fortunately also 1) when calling dma_map_sg() and > dma_unmap_sg(). > > Signed-off-by: Nicolas Iooss Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: api - Clear CRYPTO_ALG_DEAD bit before registering an alg
On Fri, Jan 13, 2017 at 11:54:08AM +, Salvatore Benedetto wrote: > Make sure CRYPTO_ALG_DEAD bit is cleared before proceeding with > the algorithm registration. This fixes qat-dh registration when > driver is restarted > > Signed-off-by: Salvatore Benedetto Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] Add support for ECDSA algorithm
On Fri, Jan 20, 2017 at 05:05:55PM +0530, Nitin Kumbhar wrote: > Hello, > > This patch series adds support for Elliptic Curve Digital Signature > Algorithm (ECDSA). To reuse existing ECC functionality, which is > added as part of ECDH, it separates out ECC and ECDH so that > only ECC functionality is available for ECDSA even when ECDH is in > a disabled state. > > Patch #1 restructures ECC and ECDH code such that ECC is not > dependent on ECDH config. > > Patches #2 & #3 add vli and ecc functions which are required > for other Elliptic curve algorithms like ECDSA and ECIES. > > Patch #4 adds support for ECDSA. This has been validated for P192 > and P256 elliptic curves. > > Patches #5 and #6 add ECDSA tests to validate ECDSA functionality > and measure ECDSA performance. Who is going to use this in the kernel? Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Urgent Please,,
Good Day Dear, My name is Ms. Joyes Dadi, I am glad you are reading this letter and I hope we will start our communication and I know that this message will look strange, surprising and probably unbelievable to you, but it is the reality. I want to make a donation of money to you. I contact you by the will of God. I am a firm German woman specialized in mining gold and diamonds in Africa. But now, I'm very sick of a cancer. My husband died in an accident two years ago with our two children and now I have cancer of the esophagus that damaged almost all the cells in my system/agencies and I'll die soon according to my doctor. My most concern now is, we grew up in the orphanage and were married in orphanage. If I die this deposited fund will soon be left alone in the hand of the bank, and I do want to it that way. Please, if you can be reliable and sincere to accept my humble proposal; I have (10.5Millions Euro) in a fixed deposit account; I will order the Bank to transfer the money into your account in your country immediately, and then you will take the fund to your country and invest it to the orphanage homes Please, answer as quickly as possible. God bless you. Ms. Joyes Dadi Email: joyesdadi...@citromail.hu -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 02/10] crypto: arm/aes-ce - remove cra_alignmask
Remove the unnecessary alignmask: it is much more efficient to deal with
the misalignment in the core algorithm than relying on the crypto API to
copy the data to a suitably aligned buffer.
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/aes-ce-core.S | 84 ++--
arch/arm/crypto/aes-ce-glue.c | 15 ++--
2 files changed, 47 insertions(+), 52 deletions(-)
diff --git a/arch/arm/crypto/aes-ce-core.S b/arch/arm/crypto/aes-ce-core.S
index 987aa632c9f0..ba8e6a32fdc9 100644
--- a/arch/arm/crypto/aes-ce-core.S
+++ b/arch/arm/crypto/aes-ce-core.S
@@ -169,19 +169,19 @@ ENTRY(ce_aes_ecb_encrypt)
.Lecbencloop3x:
subsr4, r4, #3
bmi .Lecbenc1x
- vld1.8 {q0-q1}, [r1, :64]!
- vld1.8 {q2}, [r1, :64]!
+ vld1.8 {q0-q1}, [r1]!
+ vld1.8 {q2}, [r1]!
bl aes_encrypt_3x
- vst1.8 {q0-q1}, [r0, :64]!
- vst1.8 {q2}, [r0, :64]!
+ vst1.8 {q0-q1}, [r0]!
+ vst1.8 {q2}, [r0]!
b .Lecbencloop3x
.Lecbenc1x:
addsr4, r4, #3
beq .Lecbencout
.Lecbencloop:
- vld1.8 {q0}, [r1, :64]!
+ vld1.8 {q0}, [r1]!
bl aes_encrypt
- vst1.8 {q0}, [r0, :64]!
+ vst1.8 {q0}, [r0]!
subsr4, r4, #1
bne .Lecbencloop
.Lecbencout:
@@ -195,19 +195,19 @@ ENTRY(ce_aes_ecb_decrypt)
.Lecbdecloop3x:
subsr4, r4, #3
bmi .Lecbdec1x
- vld1.8 {q0-q1}, [r1, :64]!
- vld1.8 {q2}, [r1, :64]!
+ vld1.8 {q0-q1}, [r1]!
+ vld1.8 {q2}, [r1]!
bl aes_decrypt_3x
- vst1.8 {q0-q1}, [r0, :64]!
- vst1.8 {q2}, [r0, :64]!
+ vst1.8 {q0-q1}, [r0]!
+ vst1.8 {q2}, [r0]!
b .Lecbdecloop3x
.Lecbdec1x:
addsr4, r4, #3
beq .Lecbdecout
.Lecbdecloop:
- vld1.8 {q0}, [r1, :64]!
+ vld1.8 {q0}, [r1]!
bl aes_decrypt
- vst1.8 {q0}, [r0, :64]!
+ vst1.8 {q0}, [r0]!
subsr4, r4, #1
bne .Lecbdecloop
.Lecbdecout:
@@ -226,10 +226,10 @@ ENTRY(ce_aes_cbc_encrypt)
vld1.8 {q0}, [r5]
prepare_key r2, r3
.Lcbcencloop:
- vld1.8 {q1}, [r1, :64]!@ get next pt block
+ vld1.8 {q1}, [r1]! @ get next pt block
veorq0, q0, q1 @ ..and xor with iv
bl aes_encrypt
- vst1.8 {q0}, [r0, :64]!
+ vst1.8 {q0}, [r0]!
subsr4, r4, #1
bne .Lcbcencloop
vst1.8 {q0}, [r5]
@@ -244,8 +244,8 @@ ENTRY(ce_aes_cbc_decrypt)
.Lcbcdecloop3x:
subsr4, r4, #3
bmi .Lcbcdec1x
- vld1.8 {q0-q1}, [r1, :64]!
- vld1.8 {q2}, [r1, :64]!
+ vld1.8 {q0-q1}, [r1]!
+ vld1.8 {q2}, [r1]!
vmovq3, q0
vmovq4, q1
vmovq5, q2
@@ -254,19 +254,19 @@ ENTRY(ce_aes_cbc_decrypt)
veorq1, q1, q3
veorq2, q2, q4
vmovq6, q5
- vst1.8 {q0-q1}, [r0, :64]!
- vst1.8 {q2}, [r0, :64]!
+ vst1.8 {q0-q1}, [r0]!
+ vst1.8 {q2}, [r0]!
b .Lcbcdecloop3x
.Lcbcdec1x:
addsr4, r4, #3
beq .Lcbcdecout
vmovq15, q14@ preserve last round key
.Lcbcdecloop:
- vld1.8 {q0}, [r1, :64]!@ get next ct block
+ vld1.8 {q0}, [r1]! @ get next ct block
veorq14, q15, q6@ combine prev ct with last key
vmovq6, q0
bl aes_decrypt
- vst1.8 {q0}, [r0, :64]!
+ vst1.8 {q0}, [r0]!
subsr4, r4, #1
bne .Lcbcdecloop
.Lcbcdecout:
@@ -300,15 +300,15 @@ ENTRY(ce_aes_ctr_encrypt)
rev ip, r6
add r6, r6, #1
vmovs11, ip
- vld1.8 {q3-q4}, [r1, :64]!
- vld1.8 {q5}, [r1, :64]!
+ vld1.8 {q3-q4}, [r1]!
+ vld1.8 {q5}, [r1]!
bl aes_encrypt_3x
veorq0, q0, q3
veorq1, q1, q4
veorq2, q2, q5
rev ip, r6
- vst1.8 {q0-q1}, [r0, :64]!
- vst1.8 {q2}, [r0, :64]!
+ vst1.8 {q0-q1}, [r0]!
+ vst1.8 {q2}, [r0]!
vmovs27, ip
b .Lctrloop3x
.Lc
[PATCH v2 06/10] crypto: arm64/chacha20 - remove cra_alignmask
Remove the unnecessary alignmask: it is much more efficient to deal with
the misalignment in the core algorithm than relying on the crypto API to
copy the data to a suitably aligned buffer.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/chacha20-neon-glue.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/crypto/chacha20-neon-glue.c
b/arch/arm64/crypto/chacha20-neon-glue.c
index a7f2337d46cf..a7cd575ea223 100644
--- a/arch/arm64/crypto/chacha20-neon-glue.c
+++ b/arch/arm64/crypto/chacha20-neon-glue.c
@@ -93,7 +93,6 @@ static struct skcipher_alg alg = {
.base.cra_priority = 300,
.base.cra_blocksize = 1,
.base.cra_ctxsize = sizeof(struct chacha20_ctx),
- .base.cra_alignmask = 1,
.base.cra_module= THIS_MODULE,
.min_keysize= CHACHA20_KEY_SIZE,
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 07/10] crypto: arm64/aes - avoid literals for cross-module symbol references
Using simple adrp/add pairs to refer to the AES lookup tables exposed by
the generic AES driver (which could be loaded far away from this driver
when KASLR is in effect) was unreliable at module load time before commit
41c066f2c4d4 ("arm64: assembler: make adr_l work in modules under KASLR"),
which is why the AES code used literals instead.
So now we can get rid of the literals, and switch to the adr_l macro.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/aes-cipher-core.S | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/crypto/aes-cipher-core.S
b/arch/arm64/crypto/aes-cipher-core.S
index 37590ab8121a..cd58c61e6677 100644
--- a/arch/arm64/crypto/aes-cipher-core.S
+++ b/arch/arm64/crypto/aes-cipher-core.S
@@ -89,8 +89,8 @@ CPU_BE( rev w8, w8 )
eor w7, w7, w11
eor w8, w8, w12
- ldr tt, =\ttab
- ldr lt, =\ltab
+ adr_l tt, \ttab
+ adr_l lt, \ltab
tbnzrounds, #1, 1f
@@ -111,9 +111,6 @@ CPU_BE( rev w8, w8 )
stp w5, w6, [out]
stp w7, w8, [out, #8]
ret
-
- .align 4
- .ltorg
.endm
.align 5
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 09/10] crypto: arm64/aes-neon-blk - tweak performance for low end cores
The non-bitsliced AES implementation using the NEON is highly sensitive
to micro-architectural details, and, as it turns out, the Cortex-A53 on
the Raspberry Pi 3 is a core that can benefit from this code, given that
its scalar AES performance is abysmal (32.9 cycles per byte).
The new bitsliced AES code manages 19.8 cycles per byte on this core,
but can only operate on 8 blocks at a time, which is not supported by
all chaining modes. With a bit of tweaking, we can get the plain NEON
code to run at 22.0 cycles per byte, making it useful for sequential
modes like CBC encryption. (Like bitsliced NEON, the plain NEON
implementation does not use any lookup tables, which makes it easy on
the D-cache, and invulnerable to cache timing attacks)
So tweak the plain NEON AES code to use tbl instructions rather than
shl/sri pairs, and to avoid the need to reload permutation vectors or
other constants from memory in every round.
To allow the ECB and CBC encrypt routines to be reused by the bitsliced
NEON code in a subsequent patch, export them from the module.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/aes-glue.c | 2 +
arch/arm64/crypto/aes-neon.S | 210
2 files changed, 81 insertions(+), 131 deletions(-)
diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c
index 8ee1fb7aaa4f..055bc3f61138 100644
--- a/arch/arm64/crypto/aes-glue.c
+++ b/arch/arm64/crypto/aes-glue.c
@@ -409,5 +409,7 @@ static int __init aes_init(void)
module_cpu_feature_match(AES, aes_init);
#else
module_init(aes_init);
+EXPORT_SYMBOL(neon_aes_ecb_encrypt);
+EXPORT_SYMBOL(neon_aes_cbc_encrypt);
#endif
module_exit(aes_exit);
diff --git a/arch/arm64/crypto/aes-neon.S b/arch/arm64/crypto/aes-neon.S
index 85f07ead7c5c..0d111a6fc229 100644
--- a/arch/arm64/crypto/aes-neon.S
+++ b/arch/arm64/crypto/aes-neon.S
@@ -1,7 +1,7 @@
/*
* linux/arch/arm64/crypto/aes-neon.S - AES cipher for ARMv8 NEON
*
- * Copyright (C) 2013 Linaro Ltd
+ * Copyright (C) 2013 - 2017 Linaro Ltd.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -25,9 +25,9 @@
/* preload the entire Sbox */
.macro prepare, sbox, shiftrows, temp
adr \temp, \sbox
- moviv12.16b, #0x40
+ moviv12.16b, #0x1b
ldr q13, \shiftrows
- moviv14.16b, #0x1b
+ ldr q14, .Lror32by8
ld1 {v16.16b-v19.16b}, [\temp], #64
ld1 {v20.16b-v23.16b}, [\temp], #64
ld1 {v24.16b-v27.16b}, [\temp], #64
@@ -50,37 +50,32 @@
/* apply SubBytes transformation using the the preloaded Sbox */
.macro sub_bytes, in
- sub v9.16b, \in\().16b, v12.16b
+ sub v9.16b, \in\().16b, v15.16b
tbl \in\().16b, {v16.16b-v19.16b}, \in\().16b
- sub v10.16b, v9.16b, v12.16b
+ sub v10.16b, v9.16b, v15.16b
tbx \in\().16b, {v20.16b-v23.16b}, v9.16b
- sub v11.16b, v10.16b, v12.16b
+ sub v11.16b, v10.16b, v15.16b
tbx \in\().16b, {v24.16b-v27.16b}, v10.16b
tbx \in\().16b, {v28.16b-v31.16b}, v11.16b
.endm
/* apply MixColumns transformation */
- .macro mix_columns, in
- mul_by_xv10.16b, \in\().16b, v9.16b, v14.16b
- rev32 v8.8h, \in\().8h
- eor \in\().16b, v10.16b, \in\().16b
- shl v9.4s, v8.4s, #24
- shl v11.4s, \in\().4s, #24
- sri v9.4s, v8.4s, #8
- sri v11.4s, \in\().4s, #8
- eor v9.16b, v9.16b, v8.16b
- eor v10.16b, v10.16b, v9.16b
- eor \in\().16b, v10.16b, v11.16b
- .endm
-
+ .macro mix_columns, in, enc
+ .if \enc == 0
/* Inverse MixColumns: pre-multiply by { 5, 0, 4, 0 } */
- .macro inv_mix_columns, in
- mul_by_xv11.16b, \in\().16b, v10.16b, v14.16b
- mul_by_xv11.16b, v11.16b, v10.16b, v14.16b
- eor \in\().16b, \in\().16b, v11.16b
- rev32 v11.8h, v11.8h
- eor \in\().16b, \in\().16b, v11.16b
- mix_columns \in
+ mul_by_xv8.16b, \in\().16b, v9.16b, v12.16b
+ mul_by_xv8.16b, v8.16b, v9.16b, v12.16b
+ eor \in\().16b, \in\().16b, v8.16b
+ rev32 v8.8h, v8.8h
+ eor \in\().16b, \in\().16b, v8.16b
+ .endif
+
+ mul_by_xv9.16b, \in\().16b, v8.16b, v12.16b
+ rev32 v8.8h, \in\().8h
+ eor v8.16b, v8.16b, v9.16b
+ eor \in\().16b, \in\().16b, v8.16b
+ tbl \in\().16b, {\in\().16b}, v14.16b
[PATCH v2 10/10] crypto: arm64/aes - replace scalar fallback with plain NEON fallback
The new bitsliced NEON implementation of AES uses a fallback in two
places: CBC encryption (which is strictly sequential, whereas this
driver can only operate efficiently on 8 blocks at a time), and the
XTS tweak generation, which involves encrypting a single AES block
with a different key schedule.
The plain (i.e., non-bitsliced) NEON code is more suitable as a fallback,
given that it is faster than scalar on low end cores (which is what
the NEON implementations target, since high end cores have dedicated
instructions for AES), and shows similar behavior in terms of D-cache
footprint and sensitivity to cache timing attacks. So switch the fallback
handling to the plain NEON driver.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/Kconfig | 2 +-
arch/arm64/crypto/aes-neonbs-glue.c | 38 ++--
2 files changed, 29 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/crypto/Kconfig b/arch/arm64/crypto/Kconfig
index 5de75c3dcbd4..bed7feddfeed 100644
--- a/arch/arm64/crypto/Kconfig
+++ b/arch/arm64/crypto/Kconfig
@@ -86,7 +86,7 @@ config CRYPTO_AES_ARM64_BS
tristate "AES in ECB/CBC/CTR/XTS modes using bit-sliced NEON algorithm"
depends on KERNEL_MODE_NEON
select CRYPTO_BLKCIPHER
- select CRYPTO_AES_ARM64
+ select CRYPTO_AES_ARM64_NEON_BLK
select CRYPTO_SIMD
endif
diff --git a/arch/arm64/crypto/aes-neonbs-glue.c
b/arch/arm64/crypto/aes-neonbs-glue.c
index 323dd76ae5f0..863e436ecf89 100644
--- a/arch/arm64/crypto/aes-neonbs-glue.c
+++ b/arch/arm64/crypto/aes-neonbs-glue.c
@@ -10,7 +10,6 @@
#include
#include
-#include
#include
#include
#include
@@ -42,7 +41,12 @@ asmlinkage void aesbs_xts_encrypt(u8 out[], u8 const in[],
u8 const rk[],
asmlinkage void aesbs_xts_decrypt(u8 out[], u8 const in[], u8 const rk[],
int rounds, int blocks, u8 iv[]);
-asmlinkage void __aes_arm64_encrypt(u32 *rk, u8 *out, const u8 *in, int
rounds);
+/* borrowed from aes-neon-blk.ko */
+asmlinkage void neon_aes_ecb_encrypt(u8 out[], u8 const in[], u32 const rk[],
+int rounds, int blocks, int first);
+asmlinkage void neon_aes_cbc_encrypt(u8 out[], u8 const in[], u32 const rk[],
+int rounds, int blocks, u8 iv[],
+int first);
struct aesbs_ctx {
u8 rk[13 * (8 * AES_BLOCK_SIZE) + 32];
@@ -140,16 +144,28 @@ static int aesbs_cbc_setkey(struct crypto_skcipher *tfm,
const u8 *in_key,
return 0;
}
-static void cbc_encrypt_one(struct crypto_skcipher *tfm, const u8 *src, u8
*dst)
+static int cbc_encrypt(struct skcipher_request *req)
{
+ struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
struct aesbs_cbc_ctx *ctx = crypto_skcipher_ctx(tfm);
+ struct skcipher_walk walk;
+ int err, first = 1;
- __aes_arm64_encrypt(ctx->enc, dst, src, ctx->key.rounds);
-}
+ err = skcipher_walk_virt(&walk, req, true);
-static int cbc_encrypt(struct skcipher_request *req)
-{
- return crypto_cbc_encrypt_walk(req, cbc_encrypt_one);
+ kernel_neon_begin();
+ while (walk.nbytes >= AES_BLOCK_SIZE) {
+ unsigned int blocks = walk.nbytes / AES_BLOCK_SIZE;
+
+ /* fall back to the non-bitsliced NEON implementation */
+ neon_aes_cbc_encrypt(walk.dst.virt.addr, walk.src.virt.addr,
+ctx->enc, ctx->key.rounds, blocks, walk.iv,
+first);
+ err = skcipher_walk_done(&walk, walk.nbytes % AES_BLOCK_SIZE);
+ first = 0;
+ }
+ kernel_neon_end();
+ return err;
}
static int cbc_decrypt(struct skcipher_request *req)
@@ -254,9 +270,11 @@ static int __xts_crypt(struct skcipher_request *req,
err = skcipher_walk_virt(&walk, req, true);
- __aes_arm64_encrypt(ctx->twkey, walk.iv, walk.iv, ctx->key.rounds);
-
kernel_neon_begin();
+
+ neon_aes_ecb_encrypt(walk.iv, walk.iv, ctx->twkey,
+ctx->key.rounds, 1, 1);
+
while (walk.nbytes >= AES_BLOCK_SIZE) {
unsigned int blocks = walk.nbytes / AES_BLOCK_SIZE;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 08/10] crypto: arm64/aes - performance tweak
Shuffle some instructions around in the __hround macro to shave off 0.1 cycles per byte on Cortex-A57. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/aes-cipher-core.S | 52 +++- 1 file changed, 19 insertions(+), 33 deletions(-) diff --git a/arch/arm64/crypto/aes-cipher-core.S b/arch/arm64/crypto/aes-cipher-core.S index cd58c61e6677..f2f9cc519309 100644 --- a/arch/arm64/crypto/aes-cipher-core.S +++ b/arch/arm64/crypto/aes-cipher-core.S @@ -20,46 +20,32 @@ tt .reqx4 lt .reqx2 - .macro __hround, out0, out1, in0, in1, in2, in3, t0, t1, enc - ldp \out0, \out1, [rk], #8 - - ubfxw13, \in0, #0, #8 - ubfxw14, \in1, #8, #8 - ldr w13, [tt, w13, uxtw #2] - ldr w14, [tt, w14, uxtw #2] - + .macro __pair, enc, reg0, reg1, in0, in1e, in1d, shift + ubfx\reg0, \in0, #\shift, #8 .if \enc - ubfxw17, \in1, #0, #8 - ubfxw18, \in2, #8, #8 + ubfx\reg1, \in1e, #\shift, #8 .else - ubfxw17, \in3, #0, #8 - ubfxw18, \in0, #8, #8 + ubfx\reg1, \in1d, #\shift, #8 .endif - ldr w17, [tt, w17, uxtw #2] - ldr w18, [tt, w18, uxtw #2] + ldr \reg0, [tt, \reg0, uxtw #2] + ldr \reg1, [tt, \reg1, uxtw #2] + .endm - ubfxw15, \in2, #16, #8 - ubfxw16, \in3, #24, #8 - ldr w15, [tt, w15, uxtw #2] - ldr w16, [tt, w16, uxtw #2] + .macro __hround, out0, out1, in0, in1, in2, in3, t0, t1, enc + ldp \out0, \out1, [rk], #8 - .if \enc - ubfx\t0, \in3, #16, #8 - ubfx\t1, \in0, #24, #8 - .else - ubfx\t0, \in1, #16, #8 - ubfx\t1, \in2, #24, #8 - .endif - ldr \t0, [tt, \t0, uxtw #2] - ldr \t1, [tt, \t1, uxtw #2] + __pair \enc, w13, w14, \in0, \in1, \in3, 0 + __pair \enc, w15, w16, \in1, \in2, \in0, 8 + __pair \enc, w17, w18, \in2, \in3, \in1, 16 + __pair \enc, \t0, \t1, \in3, \in0, \in2, 24 eor \out0, \out0, w13 - eor \out1, \out1, w17 - eor \out0, \out0, w14, ror #24 - eor \out1, \out1, w18, ror #24 - eor \out0, \out0, w15, ror #16 - eor \out1, \out1, \t0, ror #16 - eor \out0, \out0, w16, ror #8 + eor \out1, \out1, w14 + eor \out0, \out0, w15, ror #24 + eor \out1, \out1, w16, ror #24 + eor \out0, \out0, w17, ror #16 + eor \out1, \out1, w18, ror #16 + eor \out0, \out0, \t0, ror #8 eor \out1, \out1, \t1, ror #8 .endm -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 04/10] crypto: arm64/aes-ce-ccm - remove cra_alignmask
Remove the unnecessary alignmask: it is much more efficient to deal with
the misalignment in the core algorithm than relying on the crypto API to
copy the data to a suitably aligned buffer.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/aes-ce-ccm-glue.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/crypto/aes-ce-ccm-glue.c
b/arch/arm64/crypto/aes-ce-ccm-glue.c
index cc5515dac74a..6a7dbc7c83a6 100644
--- a/arch/arm64/crypto/aes-ce-ccm-glue.c
+++ b/arch/arm64/crypto/aes-ce-ccm-glue.c
@@ -258,7 +258,6 @@ static struct aead_alg ccm_aes_alg = {
.cra_priority = 300,
.cra_blocksize = 1,
.cra_ctxsize= sizeof(struct crypto_aes_ctx),
- .cra_alignmask = 7,
.cra_module = THIS_MODULE,
},
.ivsize = AES_BLOCK_SIZE,
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 05/10] crypto: arm64/aes-blk - remove cra_alignmask
Remove the unnecessary alignmask: it is much more efficient to deal with
the misalignment in the core algorithm than relying on the crypto API to
copy the data to a suitably aligned buffer.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/aes-glue.c | 16 ++--
arch/arm64/crypto/aes-modes.S | 8 +++-
2 files changed, 9 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c
index 5164aaf82c6a..8ee1fb7aaa4f 100644
--- a/arch/arm64/crypto/aes-glue.c
+++ b/arch/arm64/crypto/aes-glue.c
@@ -215,14 +215,15 @@ static int ctr_encrypt(struct skcipher_request *req)
u8 *tsrc = walk.src.virt.addr;
/*
-* Minimum alignment is 8 bytes, so if nbytes is <= 8, we need
-* to tell aes_ctr_encrypt() to only read half a block.
+* Tell aes_ctr_encrypt() to process a tail block.
*/
- blocks = (nbytes <= 8) ? -1 : 1;
+ blocks = -1;
- aes_ctr_encrypt(tail, tsrc, (u8 *)ctx->key_enc, rounds,
+ aes_ctr_encrypt(tail, NULL, (u8 *)ctx->key_enc, rounds,
blocks, walk.iv, first);
- memcpy(tdst, tail, nbytes);
+ if (tdst != tsrc)
+ memcpy(tdst, tsrc, nbytes);
+ crypto_xor(tdst, tail, nbytes);
err = skcipher_walk_done(&walk, 0);
}
kernel_neon_end();
@@ -282,7 +283,6 @@ static struct skcipher_alg aes_algs[] = { {
.cra_flags = CRYPTO_ALG_INTERNAL,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct crypto_aes_ctx),
- .cra_alignmask = 7,
.cra_module = THIS_MODULE,
},
.min_keysize= AES_MIN_KEY_SIZE,
@@ -298,7 +298,6 @@ static struct skcipher_alg aes_algs[] = { {
.cra_flags = CRYPTO_ALG_INTERNAL,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct crypto_aes_ctx),
- .cra_alignmask = 7,
.cra_module = THIS_MODULE,
},
.min_keysize= AES_MIN_KEY_SIZE,
@@ -315,7 +314,6 @@ static struct skcipher_alg aes_algs[] = { {
.cra_flags = CRYPTO_ALG_INTERNAL,
.cra_blocksize = 1,
.cra_ctxsize= sizeof(struct crypto_aes_ctx),
- .cra_alignmask = 7,
.cra_module = THIS_MODULE,
},
.min_keysize= AES_MIN_KEY_SIZE,
@@ -332,7 +330,6 @@ static struct skcipher_alg aes_algs[] = { {
.cra_priority = PRIO - 1,
.cra_blocksize = 1,
.cra_ctxsize= sizeof(struct crypto_aes_ctx),
- .cra_alignmask = 7,
.cra_module = THIS_MODULE,
},
.min_keysize= AES_MIN_KEY_SIZE,
@@ -350,7 +347,6 @@ static struct skcipher_alg aes_algs[] = { {
.cra_flags = CRYPTO_ALG_INTERNAL,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct crypto_aes_xts_ctx),
- .cra_alignmask = 7,
.cra_module = THIS_MODULE,
},
.min_keysize= 2 * AES_MIN_KEY_SIZE,
diff --git a/arch/arm64/crypto/aes-modes.S b/arch/arm64/crypto/aes-modes.S
index 838dad5c209f..92b982a8b112 100644
--- a/arch/arm64/crypto/aes-modes.S
+++ b/arch/arm64/crypto/aes-modes.S
@@ -337,7 +337,7 @@ AES_ENTRY(aes_ctr_encrypt)
.Lctrcarrydone:
subsw4, w4, #1
- bmi .Lctrhalfblock /* blocks < 0 means 1/2 block */
+ bmi .Lctrtailblock /* blocks <0 means tail block */
ld1 {v3.16b}, [x1], #16
eor v3.16b, v0.16b, v3.16b
st1 {v3.16b}, [x0], #16
@@ -348,10 +348,8 @@ AES_ENTRY(aes_ctr_encrypt)
FRAME_POP
ret
-.Lctrhalfblock:
- ld1 {v3.8b}, [x1]
- eor v3.8b, v0.8b, v3.8b
- st1 {v3.8b}, [x0]
+.Lctrtailblock:
+ st1 {v0.16b}, [x0]
FRAME_POP
ret
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 03/10] crypto: arm/chacha20 - remove cra_alignmask
Remove the unnecessary alignmask: it is much more efficient to deal with
the misalignment in the core algorithm than relying on the crypto API to
copy the data to a suitably aligned buffer.
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/chacha20-neon-glue.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/crypto/chacha20-neon-glue.c
b/arch/arm/crypto/chacha20-neon-glue.c
index 592f75ae4fa1..59a7be08e80c 100644
--- a/arch/arm/crypto/chacha20-neon-glue.c
+++ b/arch/arm/crypto/chacha20-neon-glue.c
@@ -94,7 +94,6 @@ static struct skcipher_alg alg = {
.base.cra_priority = 300,
.base.cra_blocksize = 1,
.base.cra_ctxsize = sizeof(struct chacha20_ctx),
- .base.cra_alignmask = 1,
.base.cra_module= THIS_MODULE,
.min_keysize= CHACHA20_KEY_SIZE,
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 00/10] crypto - AES for ARM/arm64 updates for v4.11 (round #2)
Patch #1 is a fix for the CBC chaining issue that was discussed on the mailing list. The driver itself is queued for v4.11, so this fix can go right on top. Patches #2 - #6 clear the cra_alignmasks of various drivers: all NEON capable CPUs can perform unaligned accesses, and the advantage of using the slightly faster aligned accessors (which only exist on ARM not arm64) is certainly outweighed by the cost of copying data to suitably aligned buffers. NOTE: patch #5 won't apply unless 'crypto: arm64/aes-blk - honour iv_out requirement in CBC and CTR modes' is applied first, which was sent out separately as a bugfix for v3.16 - v4.9. If this is a problem, this patch can wait. Patch #7 and #8 are minor tweaks to the new scalar AES code. Patch #9 improves the performance of the plain NEON AES code, to make it more suitable as a fallback for the new bitsliced NEON code, which can only operate on 8 blocks in parallel, and needs another driver to perform CBC encryption or XTS tweak generation. Patch #10 updates the new bitsliced AES NEON code to switch to the plain NEON driver as a fallback. Patches #9 and #10 improve the performance of CBC encryption by ~35% on low end cores such as the Cortex-A53 that can be found in the Raspberry Pi3 Changes since v1: - shave off another few cycles from the sequential AES NEON code (patch #9) Ard Biesheuvel (10): crypto: arm64/aes-neon-bs - honour iv_out requirement in CTR mode crypto: arm/aes-ce - remove cra_alignmask crypto: arm/chacha20 - remove cra_alignmask crypto: arm64/aes-ce-ccm - remove cra_alignmask crypto: arm64/aes-blk - remove cra_alignmask crypto: arm64/chacha20 - remove cra_alignmask crypto: arm64/aes - avoid literals for cross-module symbol references crypto: arm64/aes - performance tweak crypto: arm64/aes-neon-blk - tweak performance for low end cores crypto: arm64/aes - replace scalar fallback with plain NEON fallback arch/arm/crypto/aes-ce-core.S | 84 arch/arm/crypto/aes-ce-glue.c | 15 +- arch/arm/crypto/chacha20-neon-glue.c | 1 - arch/arm64/crypto/Kconfig | 2 +- arch/arm64/crypto/aes-ce-ccm-glue.c| 1 - arch/arm64/crypto/aes-cipher-core.S| 59 ++ arch/arm64/crypto/aes-glue.c | 18 +- arch/arm64/crypto/aes-modes.S | 8 +- arch/arm64/crypto/aes-neon.S | 210 arch/arm64/crypto/aes-neonbs-core.S| 25 ++- arch/arm64/crypto/aes-neonbs-glue.c| 38 +++- arch/arm64/crypto/chacha20-neon-glue.c | 1 - 12 files changed, 203 insertions(+), 259 deletions(-) -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 01/10] crypto: arm64/aes-neon-bs - honour iv_out requirement in CTR mode
Update the new bitsliced NEON AES implementation in CTR mode to return
the next IV back to the skcipher API client. This is necessary for
chaining to work correctly.
Note that this is only done if the request is a round multiple of the
block size, since otherwise, chaining is impossible anyway.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/aes-neonbs-core.S | 25 +---
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/crypto/aes-neonbs-core.S
b/arch/arm64/crypto/aes-neonbs-core.S
index 8d0cdaa2768d..2ada12dd768e 100644
--- a/arch/arm64/crypto/aes-neonbs-core.S
+++ b/arch/arm64/crypto/aes-neonbs-core.S
@@ -874,12 +874,19 @@ CPU_LE( rev x8, x8 )
cselx4, x4, xzr, pl
cselx9, x9, xzr, le
+ tbnzx9, #1, 0f
next_ctrv1
+ tbnzx9, #2, 0f
next_ctrv2
+ tbnzx9, #3, 0f
next_ctrv3
+ tbnzx9, #4, 0f
next_ctrv4
+ tbnzx9, #5, 0f
next_ctrv5
+ tbnzx9, #6, 0f
next_ctrv6
+ tbnzx9, #7, 0f
next_ctrv7
0: mov bskey, x2
@@ -928,11 +935,11 @@ CPU_LE( rev x8, x8 )
eor v5.16b, v5.16b, v15.16b
st1 {v5.16b}, [x0], #16
- next_ctrv0
+8: next_ctrv0
cbnzx4, 99b
0: st1 {v0.16b}, [x5]
-8: ldp x29, x30, [sp], #16
+9: ldp x29, x30, [sp], #16
ret
/*
@@ -941,23 +948,23 @@ CPU_LE( rev x8, x8 )
*/
1: cbz x6, 8b
st1 {v1.16b}, [x5]
- b 8b
+ b 9b
2: cbz x6, 8b
st1 {v4.16b}, [x5]
- b 8b
+ b 9b
3: cbz x6, 8b
st1 {v6.16b}, [x5]
- b 8b
+ b 9b
4: cbz x6, 8b
st1 {v3.16b}, [x5]
- b 8b
+ b 9b
5: cbz x6, 8b
st1 {v7.16b}, [x5]
- b 8b
+ b 9b
6: cbz x6, 8b
st1 {v2.16b}, [x5]
- b 8b
+ b 9b
7: cbz x6, 8b
st1 {v5.16b}, [x5]
- b 8b
+ b 9b
ENDPROC(aesbs_ctr_encrypt)
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: camellia: add missing declarations
On Mon, Jan 16, 2017 at 05:06:51PM +0100, Nicholas Mc Guire wrote: > Add declarations for the camellia substitution box to allow a clean build. > > Signed-off-by: Nicholas Mc Guire > --- > Problem reported by sparse > arch/x86/crypto/camellia_glue.c:65:21: warning: symbol 'camellia_sp1000' > was not declared. Should it be static? > arch/x86/crypto/camellia_glue.c:154:21: warning: symbol 'camellia_sp22000222' > was not declared. Should it be static? > arch/x86/crypto/camellia_glue.c:243:21: warning: symbol 'camellia_sp03303033' > was not declared. Should it be static? > arch/x86/crypto/camellia_glue.c:332:21: warning: symbol 'camellia_sp0004' > was not declared. Should it be static? > arch/x86/crypto/camellia_glue.c:421:21: warning: symbol 'camellia_sp02220222' > was not declared. Should it be static? > arch/x86/crypto/camellia_glue.c:510:21: warning: symbol 'camellia_sp30333033' > was not declared. Should it be static? > arch/x86/crypto/camellia_glue.c:599:21: warning: symbol 'camellia_sp44044404' > was not declared. Should it be static? > arch/x86/crypto/camellia_glue.c:688:21: warning: symbol 'camellia_sp11101110' > was not declared. Should it be static? > > Patch was compile tested with: x86_64_defconfig + > CONFIG_CRYPTO_CAMELLIA_X86_64=m > > Patch is against 4.10-rc3 (localversion-next is next-20170116) This is arguably a sparse bug. These variables are only referenced by assembly code and already carries the __visible tag. So sparse should learn to suppress this warning when __visible is present. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 0/4]crypto:chcr- Bug Fixes for 4.10
On Fri, Jan 13, 2017 at 05:59:19PM +0530, Harsh Jain wrote: > This patch series is based on Herbert's cryptodev-2.6 tree. > It includes several critical bug fixes. > > Atul Gupta (3): > crypto:chcr-Change flow IDs > crypto:chcr- Fix panic on dma_unmap_sg > crypto:chcr- Check device is allocated before use > Julia Lawall (1): > crypto:chcr-fix itnull.cocci warnings Patches 2 and 3 look critical, but the other ones do not. Please don't mix fixes targeted for this cycle with other patches. Please resubmit them as two separate series. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers
On Fri, Jan 20, 2017 at 06:07:04PM +0100, Cyrille Pitchen wrote: > Hi all, > > Le 13/01/2017 à 12:39, Herbert Xu a écrit : > > On Fri, Jan 13, 2017 at 12:36:56PM +0100, Stephan Müller wrote: > >> > >> I thought I understood that you would not want to see it in any > >> implementation. But, ok, if you want to leave it. > > > > If you remove it from authenc then authenc will be broken. > > > > Hence if the copy of the associated data is needed in the crypto/authenc.c > driver, then I should also keep this copy in the drivers/crypto/atmel-aes.c > for authenc(hmac(shaX),cbc-aes) algorithms [1], shouldn't I? > > If so, should I keep the current not optimized implementation of > atmel_aes_authenc_copy_assoc() or try to use the code extracted by Stephan > from crypto/authenc.c using the null cipher as proposed in this thread? > > As said earlier in this thread, copying the associated data is not a so big > deal when compared to the main crypto processing. Please just ignore this for now. We have not decided to require the copying of the AAD in the kernel API. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/6] Add bulk skcipher requests to crypto API and dm-crypt
On Thu, Jan 19, 2017 at 03:21:37PM +0100, Ondrej Mosnáček wrote: > > Hm, I just looked at what the IPsec IV generation is actually doing > and it seems to me that it's basically a crypto template that just > somehow transforms the IV before it is passed to the child cipher... I > thought for a while that you were implying that there already is some > facility in the crypto API that allows submitting multiple messages + > some initial sequence number that is auto-incremented and IVs are > generated from the numbers. However, I could not find anything like > that in the code, so now I think what you meant was just that I should > somehow pull the actual IV generators into the crypto layer so that > the IVs can be generated inside the hardware. IPsec currently only deals with one packet at a time, but the point is that the IV generator handles everything transparently and the IV is actually part of the cipher text for the AEAD op. IOW it would be trivial to extend our current IPsec IV generators to handle multiple packets as the IVs are embedded with the cipher text. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
