26 Jan, 2016

1 commit

  • The output buffer in test_ahash_speed will point to an address located
    within the tcrypt module image.
    This causes problems when trying to DMA map the buffer.
    For e.g. on ARM-based LS1021A, a page fault occurs within the
    DMA API when trying to access the struct page returned by
    virt_to_page(output):

    insmod tcrypt.ko mode=403

    testing speed of async sha1 (sha1-caam)
    test 0 ( 16 byte blocks, 16 bytes per update, 1 updates):
    Unable to handle kernel paging request at virtual address f07e9080
    pgd = e58d0e00
    [f07e9080] *pgd=80000080007003, *pmd=00000000
    Internal error: Oops: 206 [#1] SMP THUMB2
    Modules linked in: tcrypt(+)
    CPU: 1 PID: 1119 Comm: insmod Not tainted 4.2.0-rc1-256134-gbf433416e675 #1
    Hardware name: Freescale LS1021A
    task: ea063900 ti: e5a34000 task.ti: e5a34000
    PC is at dma_cache_maint_page+0x38/0xd0
    LR is at __dma_page_cpu_to_dev+0x15/0x64
    pc : [] lr : [] psr: 000f0033
    sp : e5a35ca0 ip : 8063df00 fp : f07e9080
    r10: 00000cd0 r9 : 8063df00 r8 : 805a2f04
    r7 : 0017f804 r6 : 00000002 r5 : ee7f9000 r4 : 00000014
    r3 : 80612d40 r2 : 01ff0080 r1 : 00000380 r0 : ee7f9000
    Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment user
    Control: 70c5387d Table: e58d0e00 DAC: 9b7ede70
    Process insmod (pid: 1119, stack limit = 0xe5a34210)
    Stack: (0xe5a35ca0 to 0xe5a36000)
    [...]
    [] (dma_cache_maint_page) from [] (__dma_page_cpu_to_dev+0x15/0x64)
    [] (__dma_page_cpu_to_dev) from [] (arm_dma_map_page+0x1f/0x44)
    [] (arm_dma_map_page) from [] (ahash_digest+0x35f/0x510)
    [] (ahash_digest) from [] (test_ahash_speed.constprop.6+0x24a/0x4e4 [tcrypt])
    [] (test_ahash_speed.constprop.6 [tcrypt]) from [] (do_test+0x1898/0x2058 [tcrypt])
    [] (do_test [tcrypt]) from [] (tcrypt_mod_init+0x2e/0x63 [tcrypt])
    [] (tcrypt_mod_init [tcrypt]) from [] (do_one_initcall+0xb3/0x134)
    [] (do_one_initcall) from [] (do_init_module+0x3b/0x13c)
    [] (do_init_module) from [] (load_module+0x97b/0x9dc)
    [] (load_module) from [] (SyS_finit_module+0x35/0x3e)
    [] (SyS_finit_module) from [] (ret_fast_syscall+0x1/0x4c)
    Code: 1aba 0152 eb00 0b02 (5882) 0f92

    addr2line -f -i -e vmlinux 800155a0
    page_zonenum
    include/linux/mm.h:728
    page_zone
    include/linux/mm.h:881
    dma_cache_maint_page
    arch/arm/mm/dma-mapping.c:822

    Signed-off-by: Horia Geant?
    Signed-off-by: Herbert Xu

    Horia Geant?
     

11 Mar, 2015

1 commit

  • Commit 5be4d4c94b1f ("crypto: replace scatterwalk_sg_next with sg_next")
    did not consider the fact that scatterwalk_sg_next() was looking at
    sg entry length, while sg_next() looks at the "chained" sg bit.

    This should have no effect in theory. However in practice, there are
    cases where the sg table is initialized to a number of entries and
    some of them are not properly configured. While scatterwalk_sg_next()
    would have returned NULL (since sg length = 0 and sg page_link = 0),
    sg_next() happily returns the next unconfigured sg entry.

    insmod tcrypt.ko mode=500 sec=1

    testing speed of async cbc(aes) (cbc-aes-talitos) encryption
    test 0 (128 bit key, 16 byte blocks):
    Unable to handle kernel paging request for data at address 0x00000000
    Faulting instruction address: 0xc00d79e4
    Oops: Kernel access of bad area, sig: 11 [#1]
    SMP NR_CPUS=8 P1022 DS
    Modules linked in: tcrypt(+) talitos
    CPU: 0 PID: 2670 Comm: insmod Not tainted 4.0.0-rc1-QorIQ-SDK-V1.6+g904f1ca82209 #1
    task: e8de3200 ti: e70bc000 task.ti: e70bc000
    NIP: c00d79e4 LR: f92d223c CTR: c00d79c8
    REGS: e70bda00 TRAP: 0300 Not tainted (4.0.0-rc1-QorIQ-SDK-V1.6+g904f1ca82209)
    MSR: 00029000 CR: 84428f22 XER: 00000000
    DEAR: 00000000 ESR: 00000000
    GPR00: f92d223c e70bdab0 e8de3200 00000000 e70bdbb8 00000001 00000000 00000000
    GPR08: 00000000 00000000 c08b0380 27282010 c00d79c8 1003a634 00000000 e70bdf1c
    GPR16: e70bdef0 00000020 00000000 c08c0000 00000010 00000000 e70bdbb8 00000010
    GPR24: e976d3a8 00000010 00000000 e70bdbd8 e8961010 00000001 c086e560 00000000
    NIP [c00d79e4] page_address+0x1c/0x110
    LR [f92d223c] talitos_map_sg+0x130/0x184 [talitos]
    Call Trace:
    [e70bdab0] [00000010] 0x10 (unreliable)
    [e70bdad0] [f92d223c] talitos_map_sg+0x130/0x184 [talitos]
    [e70bdb00] [f92d30d8] common_nonsnoop.constprop.13+0xc0/0x304 [talitos]
    [e70bdb30] [f933fd90] test_acipher_speed+0x434/0x7dc [tcrypt]
    [e70bdcc0] [f934318c] do_test+0x2478/0x306c [tcrypt]
    [e70bdd80] [f11fe058] tcrypt_mod_init+0x58/0x100 [tcrypt]
    [e70bdda0] [c0002354] do_one_initcall+0x90/0x1f4
    [e70bde10] [c061fe00] do_init_module+0x60/0x1ac
    [e70bde30] [c00a79f0] load_module+0x185c/0x1f88
    [e70bdee0] [c00a82b0] SyS_finit_module+0x7c/0x98
    [e70bdf40] [c000e8b0] ret_from_syscall+0x0/0x3c

    Signed-off-by: Herbert Xu

    Horia Geant?
     

04 Feb, 2015

2 commits


13 Jan, 2015

1 commit

  • tcrypt/testmgr uses wait_for_completion_interruptible() everywhere when
    it waits for a request to be completed. If it's interrupted, then the
    test is aborted and the request is freed.

    However, if any of these calls actually do get interrupted, the result
    will likely be a kernel crash, when the driver handles the now-freed
    request. Use wait_for_completion() instead.

    Signed-off-by: Rabin Vincent
    Signed-off-by: Herbert Xu

    Rabin Vincent
     

05 Dec, 2014

1 commit


01 Aug, 2014

1 commit


03 Jul, 2014

1 commit


20 Jun, 2014

1 commit


22 May, 2014

1 commit

  • Test vectors were taken from existing test for
    CBC(DES3_EDE). Associated data has been added to test vectors.
    HMAC computed with Crypto++ has been used. Following algos have
    been covered.

    (a) "authenc(hmac(sha1),cbc(des))"
    (b) "authenc(hmac(sha1),cbc(des3_ede))"
    (c) "authenc(hmac(sha224),cbc(des))"
    (d) "authenc(hmac(sha224),cbc(des3_ede))"
    (e) "authenc(hmac(sha256),cbc(des))"
    (f) "authenc(hmac(sha256),cbc(des3_ede))"
    (g) "authenc(hmac(sha384),cbc(des))"
    (h) "authenc(hmac(sha384),cbc(des3_ede))"
    (i) "authenc(hmac(sha512),cbc(des))"
    (j) "authenc(hmac(sha512),cbc(des3_ede))"

    Signed-off-by: Vakul Garg
    [NiteshNarayanLal@freescale.com: added hooks for the missing algorithms test and tested the patch]
    Signed-off-by: Nitesh Lal
    Signed-off-by: Herbert Xu

    Nitesh Lal
     

28 Apr, 2014

3 commits


21 Mar, 2014

1 commit


20 Dec, 2013

1 commit


28 Nov, 2013

1 commit

  • For aead case when source and destination buffers are different,
    there is an incorrect assumption that the source length includes the ICV
    length. Fix this, since it leads to an oops when using sg_count() to
    find the number of nents in the scatterlist:

    Unable to handle kernel paging request for data at address 0x00000004
    Faulting instruction address: 0xf91f7634
    Oops: Kernel access of bad area, sig: 11 [#1]
    SMP NR_CPUS=8 P4080 DS
    Modules linked in: caamalg(+) caam_jr caam
    CPU: 1 PID: 1053 Comm: cryptomgr_test Not tainted 3.11.0 #16
    task: eeb24ab0 ti: eeafa000 task.ti: eeafa000
    NIP: f91f7634 LR: f91f7f24 CTR: f91f7ef0
    REGS: eeafbbc0 TRAP: 0300 Not tainted (3.11.0)
    MSR: 00029002 CR: 44044044 XER: 00000000
    DEAR: 00000004, ESR: 00000000

    GPR00: f91f7f24 eeafbc70 eeb24ab0 00000002 ee8e0900 ee8e0800 00000024 c45c4462
    GPR08: 00000010 00000000 00000014 0c0e4000 24044044 00000000 00000000 c0691590
    GPR16: eeab0000 eeb23000 00000000 00000000 00000000 00000001 00000001 eeafbcc8
    GPR24: 000000d1 00000010 ee2d5000 ee49ea10 ee49ea10 ee46f640 ee46f640 c0691590
    NIP [f91f7634] aead_edesc_alloc.constprop.14+0x144/0x780 [caamalg]
    LR [f91f7f24] aead_encrypt+0x34/0x288 [caamalg]
    Call Trace:
    [eeafbc70] [a1004000] 0xa1004000 (unreliable)
    [eeafbcc0] [f91f7f24] aead_encrypt+0x34/0x288 [caamalg]
    [eeafbcf0] [c020d77c] __test_aead+0x3ec/0xe20
    [eeafbe20] [c020f35c] test_aead+0x6c/0xe0
    [eeafbe40] [c020f420] alg_test_aead+0x50/0xd0
    [eeafbe60] [c020e5e4] alg_test+0x114/0x2e0
    [eeafbee0] [c020bd1c] cryptomgr_test+0x4c/0x60
    [eeafbef0] [c0047058] kthread+0xa8/0xb0
    [eeafbf40] [c000eb0c] ret_from_kernel_thread+0x5c/0x64
    Instruction dump:
    69084321 7d080034 5508d97e 69080001 0f080000 81290024 552807fe 0f080000
    3a600001 5529003a 2f8a0000 40dd0028 3ab50001 8109000c 70e30002
    ---[ end trace b3c3e23925c7484e ]---

    While here, add a tcrypt mode for making it easy to test authenc
    (needed for triggering case above).

    Signed-off-by: Horia Geanta
    Signed-off-by: Herbert Xu

    Horia Geanta
     

15 Nov, 2013

1 commit


07 Sep, 2013

1 commit


24 Jul, 2013

1 commit

  • This reverts commits
    67822649d7305caf3dd50ed46c27b99c94eff996
    39761214eefc6b070f29402aa1165f24d789b3f7
    0b95a7f85718adcbba36407ef88bba0a7379ed03
    31d939625a9a20b1badd2d4e6bf6fd39fa523405
    2d31e518a42828df7877bca23a958627d60408bc

    Unfortunately this change broke boot on some systems that used an
    initrd which does not include the newly created crct10dif modules.
    As these modules are required by sd_mod under certain configurations
    this is a serious problem.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

24 May, 2013

1 commit

  • These are simple tests to do sanity check of CRC T10 DIF hash. The
    correctness of the transform can be checked with the command
    modprobe tcrypt mode=47
    The speed of the transform can be evaluated with the command
    modprobe tcrypt mode=320

    Set the cpu frequency to constant and turn turbo off when running the
    speed test so the frequency governor will not tweak the frequency and
    affects the measurements.

    Signed-off-by: Tim Chen
    Signed-off-by: Herbert Xu

    Tim Chen
     

25 Apr, 2013

3 commits


08 Jan, 2013

1 commit

  • Some hardware crypto drivers register asynchronous ctr(aes), which is left
    unused in IPSEC because rfc3686 template only supports synchronous block
    ciphers. Some other drivers register rfc3686(ctr(aes)) to workaround this
    limitation but not all.

    This patch changes rfc3686 to use asynchronous block ciphers, to allow async
    ctr(aes) algorithms to be utilized automatically by IPSEC.

    Signed-off-by: Jussi Kivilinna
    Acked-by: Herbert Xu
    Signed-off-by: Steffen Klassert

    Jussi Kivilinna
     

09 Nov, 2012

1 commit


24 Oct, 2012

2 commits


15 Oct, 2012

1 commit


27 Sep, 2012

2 commits

  • Add missing tests for ctr(camellia), lrw(camellia), xts(camellia) and ghash,
    as these have test vectors available.

    Signed-off-by: Jussi Kivilinna
    Acked-by: David S. Miller
    Signed-off-by: Herbert Xu

    Jussi Kivilinna
     
  • Ran into this while looking at some new crypto code using FPU
    hitting a WARN_ON_ONCE(!irq_fpu_usable()) in the kernel_fpu_begin()
    on a x86 kernel that uses the new eagerfpu model. In short, current eagerfpu
    changes return 0 for interrupted_kernel_fpu_idle() and the in_interrupt()
    thinks it is in the interrupt context because of the local_bh_disable().
    Thus resulting in the WARN_ON().

    Remove the local_bh_disable/enable() calls around the existing
    local_irq_disable/enable() calls. local_irq_disable/enable() already
    disables the BH.

    [ If there are any other legitimate users calling kernel_fpu_begin() from
    the process context but with BH disabled, then we can look into fixing the
    irq_fpu_usable() in future. ]

    Signed-off-by: Suresh Siddha
    Cc: Tim Chen
    Signed-off-by: Herbert Xu

    Suresh Siddha
     

01 Aug, 2012

2 commits


11 Jul, 2012

1 commit


14 Jun, 2012

1 commit


12 Jun, 2012

2 commits

  • This patch adds a x86_64/avx assembler implementation of the Twofish block
    cipher. The implementation processes eight blocks in parallel (two 4 block
    chunk AVX operations). The table-lookups are done in general-purpose registers.
    For small blocksizes the 3way-parallel functions from the twofish-x86_64-3way
    module are called. A good performance increase is provided for blocksizes
    greater or equal to 128B.

    Patch has been tested with tcrypt and automated filesystem tests.

    Tcrypt benchmark results:

    Intel Core i5-2500 CPU (fam:6, model:42, step:7)

    twofish-avx-x86_64 vs. twofish-x86_64-3way
    128bit key: (lrw:256bit) (xts:256bit)
    size ecb-enc ecb-dec cbc-enc cbc-dec ctr-enc ctr-dec lrw-enc lrw-dec xts-enc xts-dec
    16B 0.96x 0.97x 1.00x 0.95x 0.97x 0.97x 0.96x 0.95x 0.95x 0.98x
    64B 0.99x 0.99x 1.00x 0.99x 0.98x 0.98x 0.99x 0.98x 0.99x 0.98x
    256B 1.20x 1.21x 1.00x 1.19x 1.15x 1.14x 1.19x 1.20x 1.18x 1.19x
    1024B 1.29x 1.30x 1.00x 1.28x 1.23x 1.24x 1.26x 1.28x 1.26x 1.27x
    8192B 1.31x 1.32x 1.00x 1.31x 1.25x 1.25x 1.28x 1.29x 1.28x 1.30x

    256bit key: (lrw:384bit) (xts:512bit)
    size ecb-enc ecb-dec cbc-enc cbc-dec ctr-enc ctr-dec lrw-enc lrw-dec xts-enc xts-dec
    16B 0.96x 0.96x 1.00x 0.96x 0.97x 0.98x 0.95x 0.95x 0.95x 0.96x
    64B 1.00x 0.99x 1.00x 0.98x 0.98x 1.01x 0.98x 0.98x 0.98x 0.98x
    256B 1.20x 1.21x 1.00x 1.21x 1.15x 1.15x 1.19x 1.20x 1.18x 1.19x
    1024B 1.29x 1.30x 1.00x 1.28x 1.23x 1.23x 1.26x 1.27x 1.26x 1.27x
    8192B 1.31x 1.33x 1.00x 1.31x 1.26x 1.26x 1.29x 1.29x 1.28x 1.30x

    twofish-avx-x86_64 vs aes-asm (8kB block):
    128bit 256bit
    ecb-enc 1.19x 1.63x
    ecb-dec 1.18x 1.62x
    cbc-enc 0.75x 1.03x
    cbc-dec 1.23x 1.67x
    ctr-enc 1.24x 1.65x
    ctr-dec 1.24x 1.65x
    lrw-enc 1.15x 1.53x
    lrw-dec 1.14x 1.52x
    xts-enc 1.16x 1.56x
    xts-dec 1.16x 1.56x

    Signed-off-by: Johannes Goetzfried
    Signed-off-by: Herbert Xu

    Johannes Goetzfried
     
  • Signed-off-by: Sonic Zhang
    Acked-by: Mike Frysinger
    Signed-off-by: Herbert Xu

    Sonic Zhang
     

14 Mar, 2012

1 commit


09 Nov, 2011

3 commits