14 Dec, 2020

3 commits

  • This is a temporary workround for the case when:
    -SWIOTLB is used for DMA bounce buffering AND
    -data to be DMA-ed is mapped DMA_FROM_DEVICE and device only partially
    overwrites the "original" data AND
    -it's expected that the "original" data that was not overwritten
    by the device to be untouched

    As discussed in upstream, the proper fix should be:
    -either an extension of the DMA API OR
    -a workaround in the device driver (considering these cases are rarely
    met in practice)

    Since both alternatives are not trivial (to say the least),
    add a workaround for the few cases matching the error conditions
    listed above.

    Link: https://lore.kernel.org/lkml/VI1PR0402MB348537CB86926B3E6D1DBE0A98070@VI1PR0402MB3485.eurprd04.prod.outlook.com/
    Link: https://lore.kernel.org/lkml/20190522072018.10660-1-horia.geanta@nxp.com/
    Signed-off-by: Horia Geantă
    Reviewed-by: Valentin Ciocoi Radulescu

    Horia Geantă
     
  • Signed-off-by: Radu Alexe
    Signed-off-by: Tudor Ambarus

    Radu Alexe
     
  • This patch adds kernel support for encryption/decryption of TLS 1.0
    records using block ciphers. Implementation is similar to authenc in the
    sense that the base algorithms (AES, SHA1) are combined in a template to
    produce TLS encapsulation frames. The composite algorithm will be called
    "tls10(hmac(),cbc())". The cipher and hmac keys are
    wrapped in the same format used by authenc.c.

    Signed-off-by: Radu Alexe
    Signed-off-by: Cristian Stoica
    Signed-off-by: Horia Geantă

    Merged LF commit (rebase-20200703/crypto/core):
    856fb52acc28 ("crypto: tls - fix logical-not-parentheses compile warning")

    Merged LF commit (next-nxp-20200811):
    0f90a0618247 ("crypto: tls: fix build issue")

    Signed-off-by: Horia Geantă

    Radu Alexe
     

13 Oct, 2020

1 commit

  • Pull crypto updates from Herbert Xu:
    "API:
    - Allow DRBG testing through user-space af_alg
    - Add tcrypt speed testing support for keyed hashes
    - Add type-safe init/exit hooks for ahash

    Algorithms:
    - Mark arc4 as obsolete and pending for future removal
    - Mark anubis, khazad, sead and tea as obsolete
    - Improve boot-time xor benchmark
    - Add OSCCA SM2 asymmetric cipher algorithm and use it for integrity

    Drivers:
    - Fixes and enhancement for XTS in caam
    - Add support for XIP8001B hwrng in xiphera-trng
    - Add RNG and hash support in sun8i-ce/sun8i-ss
    - Allow imx-rngc to be used by kernel entropy pool
    - Use crypto engine in omap-sham
    - Add support for Ingenic X1830 with ingenic"

    * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (205 commits)
    X.509: Fix modular build of public_key_sm2
    crypto: xor - Remove unused variable count in do_xor_speed
    X.509: fix error return value on the failed path
    crypto: bcm - Verify GCM/CCM key length in setkey
    crypto: qat - drop input parameter from adf_enable_aer()
    crypto: qat - fix function parameters descriptions
    crypto: atmel-tdes - use semicolons rather than commas to separate statements
    crypto: drivers - use semicolons rather than commas to separate statements
    hwrng: mxc-rnga - use semicolons rather than commas to separate statements
    hwrng: iproc-rng200 - use semicolons rather than commas to separate statements
    hwrng: stm32 - use semicolons rather than commas to separate statements
    crypto: xor - use ktime for template benchmarking
    crypto: xor - defer load time benchmark to a later time
    crypto: hisilicon/zip - fix the uninitalized 'curr_qm_qp_num'
    crypto: hisilicon/zip - fix the return value when device is busy
    crypto: hisilicon/zip - fix zero length input in GZIP decompress
    crypto: hisilicon/zip - fix the uncleared debug registers
    lib/mpi: Fix unused variable warnings
    crypto: x86/poly1305 - Remove assignments with no effect
    hwrng: npcm - modify readl to readb
    ...

    Linus Torvalds
     

24 Aug, 2020

1 commit

  • Replace the existing /* fall through */ comments and its variants with
    the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
    fall-through markings when it is the case.

    [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through

    Signed-off-by: Gustavo A. R. Silva

    Gustavo A. R. Silva
     

21 Aug, 2020

2 commits


13 Feb, 2020

1 commit

  • When running tcrypt skcipher speed tests, logs contain things like:
    testing speed of async ecb(des3_ede) (ecb(des3_ede-generic)) encryption
    or:
    testing speed of async ecb(aes) (ecb(aes-ce)) encryption

    The algorithm implementations are sync, not async.
    Fix this inaccuracy.

    Fixes: 7166e589da5b6 ("crypto: tcrypt - Use skcipher")
    Signed-off-by: Horia Geantă
    Signed-off-by: Herbert Xu

    Horia Geantă
     

17 Nov, 2019

1 commit


30 Aug, 2019

1 commit


26 Jul, 2019

1 commit


31 May, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

    has been chosen to replace the boilerplate/reference in 3029 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

18 Apr, 2019

1 commit

  • Use subsys_initcall for registration of all templates and generic
    algorithm implementations, rather than module_init. Then change
    cryptomgr to use arch_initcall, to place it before the subsys_initcalls.

    This is needed so that when both a generic and optimized implementation
    of an algorithm are built into the kernel (not loadable modules), the
    generic implementation is registered before the optimized one.
    Otherwise, the self-tests for the optimized implementation are unable to
    allocate the generic implementation for the new comparison fuzz tests.

    Note that on arm, a side effect of this change is that self-tests for
    generic implementations may run before the unaligned access handler has
    been installed. So, unaligned accesses will crash the kernel. This is
    arguably a good thing as it makes it easier to detect that type of bug.

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

    Eric Biggers
     

08 Mar, 2019

1 commit

  • To prevent any issues with persistent data, separate lzo-rle from lzo so
    that it is treated as a separate algorithm, and lzo is still available.

    Link: http://lkml.kernel.org/r/20190205155944.16007-3-dave.rodgman@arm.com
    Signed-off-by: Dave Rodgman
    Cc: David S. Miller
    Cc: Greg Kroah-Hartman
    Cc: Herbert Xu
    Cc: Markus F.X.J. Oberhumer
    Cc: Matt Sealey
    Cc: Minchan Kim
    Cc: Nitin Gupta
    Cc: Richard Purdie
    Cc: Sergey Senozhatsky
    Cc: Sonny Rao
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dave Rodgman
     

13 Dec, 2018

1 commit


20 Nov, 2018

1 commit

  • Add support for the Adiantum encryption mode. Adiantum was designed by
    Paul Crowley and is specified by our paper:

    Adiantum: length-preserving encryption for entry-level processors
    (https://eprint.iacr.org/2018/720.pdf)

    See our paper for full details; this patch only provides an overview.

    Adiantum is a tweakable, length-preserving encryption mode designed for
    fast and secure disk encryption, especially on CPUs without dedicated
    crypto instructions. Adiantum encrypts each sector using the XChaCha12
    stream cipher, two passes of an ε-almost-∆-universal (εA∆U) hash
    function, and an invocation of the AES-256 block cipher on a single
    16-byte block. On CPUs without AES instructions, Adiantum is much
    faster than AES-XTS; for example, on ARM Cortex-A7, on 4096-byte sectors
    Adiantum encryption is about 4 times faster than AES-256-XTS encryption,
    and decryption about 5 times faster.

    Adiantum is a specialization of the more general HBSH construction. Our
    earlier proposal, HPolyC, was also a HBSH specialization, but it used a
    different εA∆U hash function, one based on Poly1305 only. Adiantum's
    εA∆U hash function, which is based primarily on the "NH" hash function
    like that used in UMAC (RFC4418), is about twice as fast as HPolyC's;
    consequently, Adiantum is about 20% faster than HPolyC.

    This speed comes with no loss of security: Adiantum is provably just as
    secure as HPolyC, in fact slightly *more* secure. Like HPolyC,
    Adiantum's security is reducible to that of XChaCha12 and AES-256,
    subject to a security bound. XChaCha12 itself has a security reduction
    to ChaCha12. Therefore, one need not "trust" Adiantum; one need only
    trust ChaCha12 and AES-256. Note that the εA∆U hash function is only
    used for its proven combinatorical properties so cannot be "broken".

    Adiantum is also a true wide-block encryption mode, so flipping any
    plaintext bit in the sector scrambles the entire ciphertext, and vice
    versa. No other such mode is available in the kernel currently; doing
    the same with XTS scrambles only 16 bytes. Adiantum also supports
    arbitrary-length tweaks and naturally supports any length input >= 16
    bytes without needing "ciphertext stealing".

    For the stream cipher, Adiantum uses XChaCha12 rather than XChaCha20 in
    order to make encryption feasible on the widest range of devices.
    Although the 20-round variant is quite popular, the best known attacks
    on ChaCha are on only 7 rounds, so ChaCha12 still has a substantial
    security margin; in fact, larger than AES-256's. 12-round Salsa20 is
    also the eSTREAM recommendation. For the block cipher, Adiantum uses
    AES-256, despite it having a lower security margin than XChaCha12 and
    needing table lookups, due to AES's extensive adoption and analysis
    making it the obvious first choice. Nevertheless, for flexibility this
    patch also permits the "adiantum" template to be instantiated with
    XChaCha20 and/or with an alternate block cipher.

    We need Adiantum support in the kernel for use in dm-crypt and fscrypt,
    where currently the only other suitable options are block cipher modes
    such as AES-XTS. A big problem with this is that many low-end mobile
    devices (e.g. Android Go phones sold primarily in developing countries,
    as well as some smartwatches) still have CPUs that lack AES
    instructions, e.g. ARM Cortex-A7. Sadly, AES-XTS encryption is much too
    slow to be viable on these devices. We did find that some "lightweight"
    block ciphers are fast enough, but these suffer from problems such as
    not having much cryptanalysis or being too controversial.

    The ChaCha stream cipher has excellent performance but is insecure to
    use directly for disk encryption, since each sector's IV is reused each
    time it is overwritten. Even restricting the threat model to offline
    attacks only isn't enough, since modern flash storage devices don't
    guarantee that "overwrites" are really overwrites, due to wear-leveling.
    Adiantum avoids this problem by constructing a
    "tweakable super-pseudorandom permutation"; this is the strongest
    possible security model for length-preserving encryption.

    Of course, storing random nonces along with the ciphertext would be the
    ideal solution. But doing that with existing hardware and filesystems
    runs into major practical problems; in most cases it would require data
    journaling (like dm-integrity) which severely degrades performance.
    Thus, for now length-preserving encryption is still needed.

    Signed-off-by: Eric Biggers
    Reviewed-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Eric Biggers
     

16 Nov, 2018

1 commit

  • Add testmgr and tcrypt tests and vectors for Streebog hash function
    from RFC 6986 and GOST R 34.11-2012, for HMAC-Streebog vectors are
    from RFC 7836 and R 50.1.113-2016.

    Cc: linux-integrity@vger.kernel.org
    Signed-off-by: Vitaly Chikunov
    Acked-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Vitaly Chikunov
     

09 Nov, 2018

1 commit


28 Sep, 2018

3 commits


21 Sep, 2018

1 commit

  • 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

    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