18 Apr, 2019

1 commit


10 Jan, 2019

1 commit

  • commit 7da66670775d201f633577f5b15a4bbeebaaa2b0 upstream.

    Add AES128/192/256-CFB testvectors from NIST SP800-38A.

    Signed-off-by: Dmitry Eremin-Solenikov
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Eremin-Solenikov
    Signed-off-by: Herbert Xu
    Signed-off-by: Greg Kroah-Hartman

    Dmitry Eremin-Solenikov
     

14 Nov, 2018

1 commit

  • commit 331351f89c36bf7d03561a28b6f64fa10a9f6f3a upstream.

    ghash is a keyed hash algorithm, thus setkey needs to be called.
    Otherwise the following error occurs:
    $ modprobe tcrypt mode=318 sec=1
    testing speed of async ghash-generic (ghash-generic)
    tcrypt: test 0 ( 16 byte blocks, 16 bytes per update, 1 updates):
    tcrypt: hashing failed ret=-126

    Cc: # 4.6+
    Fixes: 0660511c0bee ("crypto: tcrypt - Use ahash")
    Tested-by: Franck Lenormand
    Signed-off-by: Horia Geantă
    Acked-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu
    Signed-off-by: Greg Kroah-Hartman

    Horia Geantă
     

03 Aug, 2018

1 commit


01 Jul, 2018

1 commit

  • Remove the original version of the VMAC template that had the nonce
    hardcoded to 0 and produced a digest with the wrong endianness. I'm
    unsure whether this had users or not (there are no explicit in-kernel
    references to it), but given that the hardcoded nonce made it wildly
    insecure unless a unique key was used for each message, let's try
    removing it and see if anyone complains.

    Leave the new "vmac64" template that requires the nonce to be explicitly
    specified as the first 16 bytes of data and uses the correct endianness
    for the digest.

    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     

27 May, 2018

1 commit

  • The Blackfin CRC driver was removed by commit 9678a8dc53c1 ("crypto:
    bfin_crc - remove blackfin CRC driver"), but it was forgotten to remove
    the corresponding "hmac(crc32)" test vectors. I see no point in keeping
    them since nothing else appears to implement or use "hmac(crc32)", which
    isn't an algorithm that makes sense anyway because HMAC is meant to be
    used with a cryptographically secure hash function, which CRC's are not.

    Thus, remove the unneeded test vectors.

    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     

05 May, 2018

1 commit

  • In the quest to remove all stack VLA usage from the kernel[1], this
    allocates the return code buffers before starting jiffie timers, rather
    than using stack space for the array. Additionally cleans up some exit
    paths and make sure that the num_mb module_param() is used only once
    per execution to avoid possible races in the value changing.

    [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com

    Signed-off-by: Kees Cook
    Signed-off-by: Herbert Xu

    Kees Cook
     

16 Mar, 2018

1 commit


12 Jan, 2018

2 commits


28 Dec, 2017

6 commits

  • The performance of some aead tfm providers is affected by
    the amount of parallelism possible with the processing.

    Introduce an async aead concurrent multiple buffer
    processing speed test to be able to test performance of such
    tfm providers.

    Signed-off-by: Gilad Ben-Yossef
    Signed-off-by: Herbert Xu

    Gilad Ben-Yossef
     
  • The performance of some skcipher tfm providers is affected by
    the amount of parallelism possible with the processing.

    Introduce an async skcipher concurrent multiple buffer
    processing speed test to be able to test performance of such
    tfm providers.

    Signed-off-by: Gilad Ben-Yossef
    Signed-off-by: Herbert Xu

    Gilad Ben-Yossef
     
  • The multi buffer concurrent requests ahash speed test only
    supported the cycles mode. Add support for the so called
    jiffies mode that test performance of bytes/sec.

    We only add support for digest mode at the moment.

    Signed-off-by: Gilad Ben-Yossef
    Signed-off-by: Herbert Xu

    Gilad Ben-Yossef
     
  • For multiple buffers speed tests, the number of buffers, or
    requests, used actually sets the level of parallelism a tfm
    provider may utilize to hide latency. The existing number
    (of 8) is good for some software based providers but not
    enough for many HW providers with deep FIFOs.

    Add a module parameter that allows setting the number of
    multiple buffers/requests used, leaving the default at 8.

    Signed-off-by: Gilad Ben-Yossef
    Signed-off-by: Herbert Xu

    Gilad Ben-Yossef
     
  • The AEAD speed test pretended to support decryption, however that support
    was broken as decryption requires a valid auth field which the test did
    not provide.

    Fix this by running the encryption path once with inout/output sgls
    switched to calculate the auth field prior to performing decryption
    speed tests.

    Signed-off-by: Gilad Ben-Yossef
    Signed-off-by: Herbert Xu

    Gilad Ben-Yossef
     
  • The multi buffer ahash speed test was allocating multiple
    buffers for use with the multiple outstanding requests
    it was starting but never actually using them (except
    to free them), instead using a different single statically
    allocated buffer for all requests.

    Fix this by actually using the allocated buffers for the test.

    It is noted that it may seem tempting to instead remove the
    allocation and free of the multiple buffers and leave things as
    they are since this is a hash test where the input is read
    only. However, after consideration I believe that multiple
    buffers better reflect real life scenario with regard
    to data cache and TLB behaviours etc.

    Signed-off-by: Gilad Ben-Yossef
    Signed-off-by: Herbert Xu

    Gilad Ben-Yossef
     

29 Nov, 2017

2 commits


03 Nov, 2017

3 commits


22 Sep, 2017

2 commits

  • Fix checkpatch.pl warnings:

    WARNING: void function return statements are not generally useful
    FILE: crypto/rmd128.c:218:
    FILE: crypto/rmd160.c:261:
    FILE: crypto/rmd256.c:233:
    FILE: crypto/rmd320.c:280:
    FILE: crypto/tcrypt.c:385:
    FILE: drivers/crypto/ixp4xx_crypto.c:538:
    FILE: drivers/crypto/marvell/cesa.c:81:
    FILE: drivers/crypto/ux500/cryp/cryp_core.c:1755:

    Signed-off-by: Geliang Tang
    Signed-off-by: Herbert Xu

    Geliang Tang
     
  • Add testmgr and tcrypt tests and vectors for SM3 secure hash.

    Signed-off-by: Gilad Ben-Yossef
    Signed-off-by: Herbert Xu

    Gilad Ben-Yossef
     

03 Aug, 2017

1 commit

  • Remove xts(aes) speed tests with 2 x 192-bit keys, since implementations
    adhering strictly to IEEE 1619-2007 standard cannot cope with key sizes
    other than 2 x 128, 2 x 256 bits - i.e. AES-XTS-{128,256}:
    [...]
    tcrypt: test 5 (384 bit key, 16 byte blocks):
    caam_jr 8020000.jr: key size mismatch
    tcrypt: setkey() failed flags=200000
    [...]

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

    Horia Geantă
     

18 May, 2017

1 commit

  • The tcrypt AEAD cycles speed tests disables irqs during the test, which is
    broken at the very least since commit
    '1425d2d17f7309c6 ("crypto: tcrypt - Fix AEAD speed tests")'
    adds a wait for completion as part of the test and probably since
    switching to the new AEAD API.

    While the result of taking a cycle count diff may not mean much on SMP
    systems if the task migrates, it's good enough for tcrypt being the quick
    & dirty dev tool it is. It's also what all the other (i.e. hash) cycle
    speed tests do.

    Signed-off-by: Gilad Ben-Yossef
    Reported-by: Ofir Drang
    Reviewed-by: Horia Geantă
    Signed-off-by: Herbert Xu

    Gilad Ben-Yossef
     

23 Jan, 2017

1 commit

  • 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
    Signed-off-by: Herbert Xu

    Rabin Vincent
     

01 Jul, 2016

4 commits


29 Jun, 2016

1 commit

  • This patch resolves a number of issues with the mb speed test
    function:

    * The tfm is never freed.
    * Memory is allocated even when we're not using mb.
    * When an error occurs we don't wait for completion for other requests.
    * When an error occurs during allocation we may leak memory.
    * The test function ignores plen but still runs for plen != blen.
    * The backlog flag is incorrectly used (may crash).

    This patch tries to resolve all these issues as well as making
    the code consistent with the existing hash speed testing function.

    Signed-off-by: Herbert Xu
    Tested-by: Krzysztof Kozlowski

    Herbert Xu
     

28 Jun, 2016

3 commits


27 Jun, 2016

1 commit

  • The existing test suite to calculate the speed of the SHA algorithms
    assumes serial (single buffer)) computation of data. With the SHA
    multibuffer algorithms, we work on 8 lanes of data in parallel. Hence,
    the need to introduce a new test suite to calculate the speed for these
    algorithms.

    Signed-off-by: Megha Dey
    Signed-off-by: Herbert Xu

    Megha Dey
     

20 Jun, 2016

1 commit


06 Feb, 2016

1 commit

  • This patch removes the last user of the obsolete crypto_hash
    interface, tcrypt, by simply switching it over to ahash. In
    fact it already has all the code there so it's just a matter
    of calling the ahash speed test code with the right mask.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

23 Nov, 2015

1 commit


21 Sep, 2015

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?
     

17 Aug, 2015

1 commit