BUG: Seems un-initialed dst pointer received from algif_aead when outlen is zero
Hi, For tag only AEAD decrypt operation(Zero length Payload). The dst sg list pointer panic with general protection fault. I think it should be NULL when output buffer is supposed to be empty. Kcapi command to re-produce the issue ./kcapi -x 2 -c "gcm(aes)" -i 0d92aa861746b324f20ee6b7 -k f4a6a5e5f2066f6dd9ec6fc5169c29043560ef595c9e81e76f42d29212cc581c -a "" -t "5f24c68cbe6f32c29652442bf5d483ad" -q "" Its decrypt operation. Expected result should be EBADMSG. Regards Harsh Jain
Re: [PATCH] crypto: testmgr - mark ctr(des3_ede) as fips_allowed
Am Montag, 20. März 2017, 21:28:05 CET schrieb Marcelo Henrique Cerri: Hi Marcelo, > 3DES is missing the fips_allowed flag for CTR mode. > > Signed-off-by: Marcelo Henrique Cerri Acked-by: Stephan Mueller Ciao Stephan
[PATCH] crypto: testmgr - mark ctr(des3_ede) as fips_allowed
3DES is missing the fips_allowed flag for CTR mode. Signed-off-by: Marcelo Henrique Cerri --- crypto/testmgr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/crypto/testmgr.c b/crypto/testmgr.c index 89f1dd1f4b13..cd075c7d8ee1 100644 --- a/crypto/testmgr.c +++ b/crypto/testmgr.c @@ -2645,6 +2645,7 @@ static const struct alg_test_desc alg_test_descs[] = { }, { .alg = "ctr(des3_ede)", .test = alg_test_skcipher, + .fips_allowed = 1, .suite = { .cipher = { .enc = __VECS(des3_ede_ctr_enc_tv_template), -- 2.7.4
Re: Question - seeding the hw pseudo random number generator
On Mon, Mar 20, 2017 at 09:28:58PM +0800, Herbert Xu wrote: > On Mon, Mar 20, 2017 at 12:19:32PM +0530, PrasannaKumar Muralidharan wrote: > > > > AF_ALG interface for rng does have seeding support. I think hw_random > > does not provide seeding support intentionally as I understand that > > True RNG need not require seeding (please correct me if I am wrong). > > Yes. We should be converting PRNGs in hwrng over to algif_rng. The actual hardware block can be seeded from true RNG (taking data from thermal noise) so the solutions (if I understand correctly) for exynos-rng might be: 1. Seed from internal TRNG making it a proper hwrandom device, 2. Convert to AF_ALG and seed with data from user-space through that interface. Thanks for explanation, I'll queue it to my tasks list. Best regards, Krzysztof
Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt
On 6 March 2017 at 20:08, Gilad Ben-Yossef wrote: > > I gave it a spin on a x86_64 with 8 CPUs with AES-NI using cryptd and > on Arm using CryptoCell hardware accelerator. > > There was no difference in performance between 512 and 4096 bytes > cluster size on the x86_64 (800 MB loop file system) > > There was an improvement in latency of 3.2% between 512 and 4096 bytes > cluster size on the Arm. I expect the performance benefits for this > test for Binoy's patch to be the same. > > In both cases the very naive test was a simple dd with block size of > 4096 bytes or the raw block device. > > I do not know what effect having a bigger cluster size would have on > have on other more complex file system operations. > Is there any specific benchmark worth testing with? The multiple instances issue in /proc/crypto is fixed. It was because of the IV code itself modifying the algorithm name inadvertently in the global crypto algorithm lookup table when it was splitting up "plain(cbc(aes))" into "plain" and "cbc(aes)" so as to invoke the child algorithm. I ran a few tests with dd, bonnie and FIO under Qemu - x86 using the automated script [1] that I wrote to make the testing easy. The tests were done on software implementations of the algorithms as the real hardware was not available with me. According to the test, I found that the sequential reads and writes have a good improvement (5.7 %) in the data rate with the proposed solution while the random reads shows a very little improvement. When tested with FIO, the random writes also shows a small improvement (2.2%) but the random reads show a little deterioration in performance (4 %). When tested in arm hardware, only the sequential writes with bonnie shows improvement (5.6%). All other tests shows degraded performance in the absence of crypto hardware. [1] https://github.com/binoyjayan/utilities/blob/master/utils/dmtest Dependencies: dd [Full version], bonnie, fio Thanks, Binoy
Re: [PATCH] crypto: zip - Memory corruption in zip_clear_stats()
On Sat, Mar 18, 2017 at 4:29 PM, Dan Carpenter wrote: > On Sat, Mar 18, 2017 at 11:24:34AM +0100, walter harms wrote: >> >> >> Am 17.03.2017 21:46, schrieb Dan Carpenter: >> > There is a typo here. It should be "stats" instead of "state". The >> > impact is that we clear 224 bytes instead of 80 and we zero out memory >> > that we shouldn't. Thank you Dan for identifying the issue. Yes there is a typo and it needs a fix. >> > Fixes: 09ae5d37e093 ("crypto: zip - Add Compression/Decompression >> > statistics") >> > Signed-off-by: Dan Carpenter >> > >> > diff --git a/drivers/crypto/cavium/zip/zip_main.c >> > b/drivers/crypto/cavium/zip/zip_main.c >> > index 0951e20b395b..6ff13d80d82e 100644 >> > --- a/drivers/crypto/cavium/zip/zip_main.c >> > +++ b/drivers/crypto/cavium/zip/zip_main.c >> > @@ -530,7 +530,7 @@ static int zip_clear_stats(struct seq_file *s, void >> > *unused) >> > for (index = 0; index < MAX_ZIP_DEVICES; index++) { >> > if (zip_dev[index]) { >> > memset(&zip_dev[index]->stats, 0, >> > - sizeof(struct zip_state)); >> > + sizeof(struct zip_stats)); Yes this resolves the issue. Thanks for this fix. Mahipal >> >> as future FIXME some show find a name that differ in more than just the last >> char. >> NTL maybe >> sizeof(zip_dev[index]->stats) >> can be used here ? > > That's sort of unweildy. I don't fear that change because I'm confident > I would catch it with static analysis. > > regards, > dan carpenter >
Re: Question - seeding the hw pseudo random number generator
Am Montag, 20. März 2017, 14:28:58 CET schrieb Herbert Xu: Hi Herbert, > On Mon, Mar 20, 2017 at 12:19:32PM +0530, PrasannaKumar Muralidharan wrote: > > AF_ALG interface for rng does have seeding support. I think hw_random > > does not provide seeding support intentionally as I understand that > > True RNG need not require seeding (please correct me if I am wrong). > > Yes. We should be converting PRNGs in hwrng over to algif_rng. IMHO this not only applies to the PRNGs in drivers/crypto (which should simply register with crypto_register_rngs) but also to ~/hacking/sources/linux/arch/ s390/crypto/prng.c which exports a /dev/prandom file. For the seeding, it may make sense to follow the example given with crypto/ drbg.c using the add_random_ready_callback function. Ciao Stephan
Re: Question - seeding the hw pseudo random number generator
On Mon, Mar 20, 2017 at 12:19:32PM +0530, PrasannaKumar Muralidharan wrote: > > AF_ALG interface for rng does have seeding support. I think hw_random > does not provide seeding support intentionally as I understand that > True RNG need not require seeding (please correct me if I am wrong). Yes. We should be converting PRNGs in hwrng over to algif_rng. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH] crypto: zip - add a cast for printing atomic64_t values
kernelci.org reports a build-time regression on linux-next, with a harmless warning in x86 allmodconfig: drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 7 has type 'long long int' [-Wformat=] drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 6 has type 'long long int' [-Wformat=] drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 5 has type 'long long int' [-Wformat=] The return type for atomic64_read() unfortunately differs between architectures, with some defining it as atomic_long_read() and others returning a 64-bit type explicitly. Fixing this in general would be nice, but also require changing other users of these functions, so the simpler workaround is to add a cast here that avoids the warnings on the default build. Fixes: 09ae5d37e093 ("crypto: zip - Add Compression/Decompression statistics") Signed-off-by: Arnd Bergmann --- drivers/crypto/cavium/zip/zip_main.c | 40 ++-- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/drivers/crypto/cavium/zip/zip_main.c b/drivers/crypto/cavium/zip/zip_main.c index 0951e20b395b..49f50c0e0308 100644 --- a/drivers/crypto/cavium/zip/zip_main.c +++ b/drivers/crypto/cavium/zip/zip_main.c @@ -488,32 +488,32 @@ static int zip_show_stats(struct seq_file *s, void *unused) atomic64_read(&st->comp_out_bytes)); seq_printf(s, "ZIP Device %d Stats\n" "---\n" - "Comp Req Submitted: \t%ld\n" - "Comp Req Completed: \t%ld\n" - "Compress In Bytes : \t%ld\n" - "Compressed Out Bytes : \t%ld\n" + "Comp Req Submitted: \t%lld\n" + "Comp Req Completed: \t%lld\n" + "Compress In Bytes : \t%lld\n" + "Compressed Out Bytes : \t%lld\n" "Average Chunk size: \t%llu\n" "Average Compression ratio : \t%llu\n" - "Decomp Req Submitted : \t%ld\n" - "Decomp Req Completed : \t%ld\n" - "Decompress In Bytes : \t%ld\n" - "Decompressed Out Bytes: \t%ld\n" - "Decompress Bad requests : \t%ld\n" - "Pending Req : \t%ld\n" + "Decomp Req Submitted : \t%lld\n" + "Decomp Req Completed : \t%lld\n" + "Decompress In Bytes : \t%lld\n" + "Decompressed Out Bytes: \t%lld\n" + "Decompress Bad requests : \t%lld\n" + "Pending Req : \t%lld\n" "-\n", index, - atomic64_read(&st->comp_req_submit), - atomic64_read(&st->comp_req_complete), - atomic64_read(&st->comp_in_bytes), - atomic64_read(&st->comp_out_bytes), + (u64)atomic64_read(&st->comp_req_submit), + (u64)atomic64_read(&st->comp_req_complete), + (u64)atomic64_read(&st->comp_in_bytes), + (u64)atomic64_read(&st->comp_out_bytes), avg_chunk, avg_cr, - atomic64_read(&st->decomp_req_submit), - atomic64_read(&st->decomp_req_complete), - atomic64_read(&st->decomp_in_bytes), - atomic64_read(&st->decomp_out_bytes), - atomic64_read(&st->decomp_bad_reqs), - atomic64_read(&st->pending_req)); + (u64)atomic64_read(&st->decomp_req_submit), + (u64)atomic64_read(&st->decomp_req_complete), + (u64)atomic64_read(&st->decomp_in_bytes), + (u64)atomi
[PATCH v2 06/10] x86: crypto, annotate local functions
Use the newly added SYM_FUNC_START_LOCAL to annotate starts of all functions which do not have ".globl" annotation, but their ends are annotated by ENDPROC. This is needed to balance ENDPROC for tools that are about to generate debuginfo. Signed-off-by: Jiri Slaby Cc: Herbert Xu Cc: "David S. Miller" Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Cc: --- arch/x86/crypto/aesni-intel_asm.S| 29 ++-- arch/x86/crypto/camellia-aesni-avx-asm_64.S | 10 +- arch/x86/crypto/camellia-aesni-avx2-asm_64.S | 10 +- arch/x86/crypto/cast5-avx-x86_64-asm_64.S| 4 ++-- arch/x86/crypto/cast6-avx-x86_64-asm_64.S| 4 ++-- arch/x86/crypto/ghash-clmulni-intel_asm.S| 2 +- arch/x86/crypto/serpent-avx-x86_64-asm_64.S | 4 ++-- arch/x86/crypto/serpent-avx2-asm_64.S| 4 ++-- arch/x86/crypto/twofish-avx-x86_64-asm_64.S | 4 ++-- 9 files changed, 31 insertions(+), 40 deletions(-) diff --git a/arch/x86/crypto/aesni-intel_asm.S b/arch/x86/crypto/aesni-intel_asm.S index 3c465184ff8a..8913ea70323c 100644 --- a/arch/x86/crypto/aesni-intel_asm.S +++ b/arch/x86/crypto/aesni-intel_asm.S @@ -1746,7 +1746,7 @@ ENDPROC(aesni_gcm_enc) .align 4 _key_expansion_128: -_key_expansion_256a: +SYM_FUNC_START_LOCAL(_key_expansion_256a) pshufd $0b, %xmm1, %xmm1 shufps $0b0001, %xmm0, %xmm4 pxor %xmm4, %xmm0 @@ -1759,8 +1759,7 @@ _key_expansion_256a: ENDPROC(_key_expansion_128) ENDPROC(_key_expansion_256a) -.align 4 -_key_expansion_192a: +SYM_FUNC_START_LOCAL(_key_expansion_192a) pshufd $0b01010101, %xmm1, %xmm1 shufps $0b0001, %xmm0, %xmm4 pxor %xmm4, %xmm0 @@ -1784,8 +1783,7 @@ _key_expansion_192a: ret ENDPROC(_key_expansion_192a) -.align 4 -_key_expansion_192b: +SYM_FUNC_START_LOCAL(_key_expansion_192b) pshufd $0b01010101, %xmm1, %xmm1 shufps $0b0001, %xmm0, %xmm4 pxor %xmm4, %xmm0 @@ -1804,8 +1802,7 @@ _key_expansion_192b: ret ENDPROC(_key_expansion_192b) -.align 4 -_key_expansion_256b: +SYM_FUNC_START_LOCAL(_key_expansion_256b) pshufd $0b10101010, %xmm1, %xmm1 shufps $0b0001, %xmm2, %xmm4 pxor %xmm4, %xmm2 @@ -1968,8 +1965,7 @@ ENDPROC(aesni_enc) * KEY * TKEYP (T1) */ -.align 4 -_aesni_enc1: +SYM_FUNC_START_LOCAL(_aesni_enc1) movaps (KEYP), KEY # key mov KEYP, TKEYP pxor KEY, STATE # round 0 @@ -2032,8 +2028,7 @@ ENDPROC(_aesni_enc1) * KEY * TKEYP (T1) */ -.align 4 -_aesni_enc4: +SYM_FUNC_START_LOCAL(_aesni_enc4) movaps (KEYP), KEY # key mov KEYP, TKEYP pxor KEY, STATE1# round 0 @@ -2160,8 +2155,7 @@ ENDPROC(aesni_dec) * KEY * TKEYP (T1) */ -.align 4 -_aesni_dec1: +SYM_FUNC_START_LOCAL(_aesni_dec1) movaps (KEYP), KEY # key mov KEYP, TKEYP pxor KEY, STATE # round 0 @@ -2224,8 +2218,7 @@ ENDPROC(_aesni_dec1) * KEY * TKEYP (T1) */ -.align 4 -_aesni_dec4: +SYM_FUNC_START_LOCAL(_aesni_dec4) movaps (KEYP), KEY # key mov KEYP, TKEYP pxor KEY, STATE1# round 0 @@ -2591,8 +2584,7 @@ ENDPROC(aesni_cbc_dec) * INC:== 1, in little endian * BSWAP_MASK == endian swapping mask */ -.align 4 -_aesni_inc_init: +SYM_FUNC_START_LOCAL(_aesni_inc_init) movaps .Lbswap_mask, BSWAP_MASK movaps IV, CTR PSHUFB_XMM BSWAP_MASK CTR @@ -2617,8 +2609,7 @@ ENDPROC(_aesni_inc_init) * CTR:== output IV, in little endian * TCTR_LOW: == lower qword of CTR */ -.align 4 -_aesni_inc: +SYM_FUNC_START_LOCAL(_aesni_inc) paddq INC, CTR add $1, TCTR_LOW jnc .Linc_low diff --git a/arch/x86/crypto/camellia-aesni-avx-asm_64.S b/arch/x86/crypto/camellia-aesni-avx-asm_64.S index f7c495e2863c..5964d98c4448 100644 --- a/arch/x86/crypto/camellia-aesni-avx-asm_64.S +++ b/arch/x86/crypto/camellia-aesni-avx-asm_64.S @@ -188,7 +188,7 @@ * larger and would only be 0.5% faster (on sandy-bridge). */ .align 8 -roundsm16_x0_x1_x2_x3_x4_x5_x6_x7_y0_y1_y2_y3_y4_y5_y6_y7_cd: +SYM_FUNC_START_LOCAL(roundsm16_x0_x1_x2_x3_x4_x5_x6_x7_y0_y1_y2_y3_y4_y5_y6_y7_cd) roundsm16(%xmm0, %xmm1, %xmm2, %xmm3, %xmm4, %xmm5, %xmm6, %xmm7, %xmm8, %xmm9, %xmm10, %xmm11, %xmm12, %xmm13, %xmm14, %xmm15, %rcx, (%r9)); @@ -196,7 +196,7 @@ roundsm16_x0_x1_x2_x3_x4_x5_x6_x7_y0_y1_y2_y3_y4_y5_y6_y7_cd: ENDPROC(roundsm16_x0_x1_x2_x3_x4_x5_x6_x7_y0_y1_y2_y3_y4_y5_y6_y7_cd) .align 8 -roundsm16_x4_x5_x6_x7_x0_x1_x2_x3_y4_y5_y6_y7_y0_y1_y2_y3_ab: +SYM_FUNC_START_LOCAL(roundsm16_x4_x5_x6_x7_x0_x1_x2_x3_y4_y5_y6_y7_y0_y1_y2_y3_ab) roundsm16(%xmm4, %xmm5, %xmm6, %xmm7, %xmm0, %xmm1, %xmm2, %xmm3, %xmm12, %xmm13, %xmm14, %xmm15, %xmm8, %xmm9, %xmm10, %xmm11, %rax, (%r9)); @
[PATCH v2 07/10] x86: assembly, annotate aliases
_key_expansion_128 is an alias to _key_expansion_256a, __memcpy to memcpy, xen_syscall32_target to xen_sysenter_target, and so on. Annotate them all using the new SYM_FUNC_START_ALIAS, SYM_FUNC_START_LOCAL_ALIAS, and SYM_FUNC_END_ALIAS. This will make the tools generating the debuginfo happy. Signed-off-by: Jiri Slaby Cc: Herbert Xu Cc: "David S. Miller" Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Cc: Boris Ostrovsky Cc: Juergen Gross Reviewed-by: Juergen Gross [xen parts] Cc: Cc: --- arch/x86/crypto/aesni-intel_asm.S | 5 ++--- arch/x86/lib/memcpy_64.S | 4 ++-- arch/x86/lib/memmove_64.S | 4 ++-- arch/x86/lib/memset_64.S | 4 ++-- arch/x86/xen/xen-asm_64.S | 4 ++-- 5 files changed, 10 insertions(+), 11 deletions(-) diff --git a/arch/x86/crypto/aesni-intel_asm.S b/arch/x86/crypto/aesni-intel_asm.S index 8913ea70323c..ea247bfed89d 100644 --- a/arch/x86/crypto/aesni-intel_asm.S +++ b/arch/x86/crypto/aesni-intel_asm.S @@ -1744,8 +1744,7 @@ ENDPROC(aesni_gcm_enc) #endif -.align 4 -_key_expansion_128: +SYM_FUNC_START_LOCAL_ALIAS(_key_expansion_128) SYM_FUNC_START_LOCAL(_key_expansion_256a) pshufd $0b, %xmm1, %xmm1 shufps $0b0001, %xmm0, %xmm4 @@ -1756,8 +1755,8 @@ SYM_FUNC_START_LOCAL(_key_expansion_256a) movaps %xmm0, (TKEYP) add $0x10, TKEYP ret -ENDPROC(_key_expansion_128) ENDPROC(_key_expansion_256a) +SYM_FUNC_END_ALIAS(_key_expansion_128) SYM_FUNC_START_LOCAL(_key_expansion_192a) pshufd $0b01010101, %xmm1, %xmm1 diff --git a/arch/x86/lib/memcpy_64.S b/arch/x86/lib/memcpy_64.S index 779782f58324..2d6518b4dbd6 100644 --- a/arch/x86/lib/memcpy_64.S +++ b/arch/x86/lib/memcpy_64.S @@ -26,7 +26,7 @@ * Output: * rax original destination */ -ENTRY(__memcpy) +SYM_FUNC_START_ALIAS(__memcpy) ENTRY(memcpy) ALTERNATIVE_2 "jmp memcpy_orig", "", X86_FEATURE_REP_GOOD, \ "jmp memcpy_erms", X86_FEATURE_ERMS @@ -40,7 +40,7 @@ ENTRY(memcpy) rep movsb ret ENDPROC(memcpy) -ENDPROC(__memcpy) +SYM_FUNC_END_ALIAS(__memcpy) EXPORT_SYMBOL(memcpy) EXPORT_SYMBOL(__memcpy) diff --git a/arch/x86/lib/memmove_64.S b/arch/x86/lib/memmove_64.S index 15de86cd15b0..d22af97e5b27 100644 --- a/arch/x86/lib/memmove_64.S +++ b/arch/x86/lib/memmove_64.S @@ -25,7 +25,7 @@ */ .weak memmove -ENTRY(memmove) +SYM_FUNC_START_ALIAS(memmove) ENTRY(__memmove) /* Handle more 32 bytes in loop */ @@ -207,6 +207,6 @@ ENTRY(__memmove) 13: retq ENDPROC(__memmove) -ENDPROC(memmove) +SYM_FUNC_END_ALIAS(memmove) EXPORT_SYMBOL(__memmove) EXPORT_SYMBOL(memmove) diff --git a/arch/x86/lib/memset_64.S b/arch/x86/lib/memset_64.S index 55b95db30a61..0d3a1d341e60 100644 --- a/arch/x86/lib/memset_64.S +++ b/arch/x86/lib/memset_64.S @@ -18,7 +18,7 @@ * * rax original destination */ -ENTRY(memset) +SYM_FUNC_START_ALIAS(memset) ENTRY(__memset) /* * Some CPUs support enhanced REP MOVSB/STOSB feature. It is recommended @@ -42,8 +42,8 @@ ENTRY(__memset) rep stosb movq %r9,%rax ret -ENDPROC(memset) ENDPROC(__memset) +SYM_FUNC_END_ALIAS(memset) EXPORT_SYMBOL(memset) EXPORT_SYMBOL(__memset) diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S index 2a968c087269..b3bf662a4f6a 100644 --- a/arch/x86/xen/xen-asm_64.S +++ b/arch/x86/xen/xen-asm_64.S @@ -117,13 +117,13 @@ ENDPROC(xen_sysenter_target) #else /* !CONFIG_IA32_EMULATION */ -ENTRY(xen_syscall32_target) +SYM_FUNC_START_ALIAS(xen_syscall32_target) ENTRY(xen_sysenter_target) lea 16(%rsp), %rsp /* strip %rcx, %r11 */ mov $-ENOSYS, %rax pushq $0 jmp hypercall_iret -ENDPROC(xen_syscall32_target) ENDPROC(xen_sysenter_target) +SYM_FUNC_END_ALIAS(xen_syscall32_target) #endif /* CONFIG_IA32_EMULATION */ -- 2.12.0