Re: [PATCHv3] arm: crypto: Add optimized SHA-256/224
On Mon, Mar 30, 2015 at 09:37:27AM +0100, Sami Tolvanen wrote: Add Andy Polyakov's optimized assembly and NEON implementations for SHA-256/224. The sha256-armv4.pl script for generating the assembly code is from OpenSSL commit 51f8d095562f36cdaa6893597b5c609e943b0565. Compared to sha256-generic these implementations have the following tcrypt speed improvements on Motorola Nexus 6 (Snapdragon 805): I cannot merge this because none of your emails are making it to the mailing list so nobody except those on the cc list can see the patch. Please refer to section 7 in Documentation/SubmittingPatches. Thanks, -- Email: Herbert Xu herb...@gondor.apana.org.au 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: [linux-sunxi] Re: AW: problem with testing a CTR block cipher mode which is partially working
On 04/01/15 04:06, kevin.z.m...@gmail.com wrote: Dear All, About the SS module, there is some detail information. There is some issues on the SS hardware module, the issues make the some AES/DES/3DS algorithm be not available. 1. The byte order of the counter is wrong, make the result error, so, the CTR mode is not available. 2. Hardware don't support the continuous subcontracting, make the CTS mode is not available. 3. Another issue need be taken attention is that hardware will modify the key register when do AES encrypt, so, it need software to restore the key register when doing every frame. These issues are presented on the A10, A13, A20, A31 and A33. The issues of SS module have been fixed on the A83T platform, so, I suggest to take more attention to the A83T platform if any interest in the SS module. If any problem, please don't hesitate to contact me(ke...@allwinnertech.com) or Shuge(sh...@allwinnertech.com). Thanks for your answer, I have loose hours on that problem. Perhaps you could update all datasheet/user manual about this known issue ? Regards -- 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: [PATCHv3] arm: crypto: Add optimized SHA-256/224
On Wed, Apr 01, 2015 at 08:43:25PM +0800, Herbert Xu wrote: I cannot merge this because none of your emails are making it to the mailing list so nobody except those on the cc list can see the patch. Please refer to section 7 in Documentation/SubmittingPatches. Please find a hosted version of the patch here: https://raw.githubusercontent.com/samitolvanen/kernelpatches/master/sha256.v3.patch Sami -- 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: omap-sham: Check for HIGHMEM before mapping SG pages
On Tue, Mar 31, 2015 at 09:52:23AM +0530, Lokesh Vutla wrote:
Commit 26a05489ee0e (crypto: omap-sham - Map SG pages if they are HIGHMEM
before accessing)
says that HIGHMEM pages may not be mapped so we must
kmap them before accessing, but it doesn't check whether the
corresponding page is in highmem or not. Because of this all
the crypto tests are failing.
: d9 a1 1b 7c aa 90 3b aa 11 ab cb 25 00 b8 ac bf
[2.338169] 0010: c1 39 cd ff 48 d0 a8 e2 2b fa 33 a1
[2.344008] alg: hash: Chunking test 1 failed for omap-sha256
So Checking for HIGHMEM before mapping SG pages.
Fixes: 26a05489ee0 (crypto: omap-sham - Map SG pages if they are HIGHMEM
before accessing)
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/crypto/omap-sham.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 3c76696..ace5852 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -639,13 +639,17 @@ static size_t omap_sham_append_sg(struct
omap_sham_reqctx *ctx)
const u8 *vaddr;
while (ctx-sg) {
- vaddr = kmap_atomic(sg_page(ctx-sg));
+ if (PageHighMem(sg_page(ctx-sg)))
+ vaddr = kmap_atomic(sg_page(ctx-sg));
+ else
+ vaddr = sg_virt(ctx-sg);
This is completely bogus. kmap_atomic should be identical to
sg_virt(sg_page()) for the lowmem case.
So either your architecture is broken (because the same problem
would obviously affect the core crypto code which does exactly
the same thing), or there is some other bug causing the selftest
to fail.
Cheers,
--
Email: Herbert Xu herb...@gondor.apana.org.au
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: omap-aes: Fix support for unequal lengths
On Tue, Mar 31, 2015 at 09:52:25AM +0530, Lokesh Vutla wrote: For cases where total length of an input SGs is not same as length of the input data for encryption, omap-aes driver crashes. This happens in the case when IPsec is trying to use omap-aes driver. To avoid this, we copy all the pages from the input SG list into a contiguous buffer and prepare a single element SG list for this buffer with length as the total bytes to crypt, which is similar thing that is done in case of unaligned lengths. Fixes: 6242332ff2f3 (crypto: omap-aes - Add support for cases of unaligned lengths) Signed-off-by: Lokesh Vutla lokeshvu...@ti.com Applied. -- Email: Herbert Xu herb...@gondor.apana.org.au 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: qat - fix typo
Bruce Allan bruce.w.al...@intel.com wrote: adt_ctl_drv should be adf_ctl_drv Signed-off-by: Bruce Allan bruce.w.al...@intel.com All seven patches applied. -- Email: Herbert Xu herb...@gondor.apana.org.au 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 v2 net-next] crypto: algif - explicitly mark end of data
From: Tadeusz Struk tadeusz.st...@intel.com Date: Wed, 01 Apr 2015 13:53:06 -0700 After the TX sgl is expanded we need to explicitly mark end of data at the last buffer that contains data. Changes in v2 - use type 'bool' and true/false for 'mark'. Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com Applied. -- 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
AES Crypto driver in CTS mode
Hi All, I tried to get the reference drivers for AES in CTS mode in open source(driver/crypto) ,but looks like there is no reference driver implementation is available for any of the Crypto Hardware.But it seems support for software implementation for CTS mode is available.Please can some one help me with this if there are any reference driver implementation in CTS mode? BR, Srisowj -- 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 net-next] crypto: af_alg - make exports consistant
From: Tadeusz Struk tadeusz.st...@intel.com Date: Mon, 30 Mar 2015 14:25:43 -0700 Use EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL. Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com Applied. -- 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 net-next] crypto: algif - use kmalloc instead of kzalloc
From: Tadeusz Struk tadeusz.st...@intel.com Date: Mon, 30 Mar 2015 14:25:44 -0700 No need to use kzalloc to allocate sgls as the structure is initialized anyway. Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com Applied. -- 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 net-next] crypto: algif - explicitly mark end of data
From: Tadeusz Struk tadeusz.st...@intel.com Date: Mon, 30 Mar 2015 14:25:43 -0700 + int mark = 0, err = -ENOMEM; lock_sock(sk); req = kmalloc(reqlen, GFP_KERNEL); ... @@ -573,10 +572,11 @@ static int skcipher_recvmsg_async(struct socket *sock, struct msghdr *msg, kfree(sreq-tsg); sreq-tsg = tmp; tx_nents *= 2; + mark = 1; ... @@ -604,6 +604,9 @@ static int skcipher_recvmsg_async(struct socket *sock, struct msghdr *msg, iov_iter_advance(msg-msg_iter, used); } + if (mark) + sg_mark_end(sreq-tsg + txbufs - 1); Please use type 'bool' and true/false for 'mark'. -- 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 net-next] crypto: algif - explicitly mark end of data
After the TX sgl is expanded we need to explicitly mark end of data
at the last buffer that contains data.
Changes in v2
- use type 'bool' and true/false for 'mark'.
Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com
---
crypto/algif_skcipher.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index 8276f21..5eff93f 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -509,11 +509,11 @@ static int skcipher_recvmsg_async(struct socket *sock,
struct msghdr *msg,
struct skcipher_async_req *sreq;
struct ablkcipher_request *req;
struct skcipher_async_rsgl *last_rsgl = NULL;
- unsigned int len = 0, tx_nents = skcipher_all_sg_nents(ctx);
+ unsigned int txbufs = 0, len = 0, tx_nents = skcipher_all_sg_nents(ctx);
unsigned int reqlen = sizeof(struct skcipher_async_req) +
GET_REQ_SIZE(ctx) + GET_IV_SIZE(ctx);
- int i = 0;
int err = -ENOMEM;
+ bool mark = false;
lock_sock(sk);
req = kmalloc(reqlen, GFP_KERNEL);
@@ -555,7 +555,7 @@ static int skcipher_recvmsg_async(struct socket *sock,
struct msghdr *msg,
iov_iter_count(msg-msg_iter));
used = min_t(unsigned long, used, sg-length);
- if (i == tx_nents) {
+ if (txbufs == tx_nents) {
struct scatterlist *tmp;
int x;
/* Ran out of tx slots in async request
@@ -573,10 +573,11 @@ static int skcipher_recvmsg_async(struct socket *sock,
struct msghdr *msg,
kfree(sreq-tsg);
sreq-tsg = tmp;
tx_nents *= 2;
+ mark = true;
}
/* Need to take over the tx sgl from ctx
* to the asynch req - these sgls will be freed later */
- sg_set_page(sreq-tsg + i++, sg_page(sg), sg-length,
+ sg_set_page(sreq-tsg + txbufs++, sg_page(sg), sg-length,
sg-offset);
if (list_empty(sreq-list)) {
@@ -604,6 +605,9 @@ static int skcipher_recvmsg_async(struct socket *sock,
struct msghdr *msg,
iov_iter_advance(msg-msg_iter, used);
}
+ if (mark)
+ sg_mark_end(sreq-tsg + txbufs - 1);
+
ablkcipher_request_set_crypt(req, sreq-tsg, sreq-first_sgl.sgl.sg,
len, sreq-iv);
err = ctx-enc ? crypto_ablkcipher_encrypt(req) :
--
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
