25 Oct, 2016

17 commits


21 Oct, 2016

23 commits

  • The lsb field uses a value of -1 to indicate that it
    is unassigned. Therefore type must be a signed int.

    Signed-off-by: Gary R Hook
    Signed-off-by: Herbert Xu

    Gary R Hook
     
  • The AES key schedule generation is mostly endian agnostic, with the
    exception of the rotation and the incorporation of the round constant
    at the start of each round. So implement a big endian specific version
    of that part to make the whole routine big endian compatible.

    Fixes: 86464859cc77 ("crypto: arm - AES in ECB/CBC/CTR/XTS modes using ARMv8 Crypto Extensions")
    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Ard Biesheuvel
     
  • Emit the XTS tweak literal constants in the appropriate order for a
    single 128-bit scalar literal load.

    Fixes: 49788fe2a128 ("arm64/crypto: AES-ECB/CBC/CTR/XTS using ARMv8 NEON and Crypto Extensions")
    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Ard Biesheuvel
     
  • The AES implementation using pure NEON instructions relies on the generic
    AES key schedule generation routines, which store the round keys as arrays
    of 32-bit quantities stored in memory using native endianness. This means
    we should refer to these round keys using 4x4 loads rather than 16x1 loads.
    In addition, the ShiftRows tables are loading using a single scalar load,
    which is also affected by endianness, so emit these tables in the correct
    order depending on whether we are building for big endian or not.

    Fixes: 49788fe2a128 ("arm64/crypto: AES-ECB/CBC/CTR/XTS using ARMv8 NEON and Crypto Extensions")
    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Ard Biesheuvel
     
  • The AES-CCM implementation that uses ARMv8 Crypto Extensions instructions
    refers to the AES round keys as pairs of 64-bit quantities, which causes
    failures when building the code for big endian. In addition, it byte swaps
    the input counter unconditionally, while this is only required for little
    endian builds. So fix both issues.

    Fixes: 12ac3efe74f8 ("arm64/crypto: use crypto instructions to generate AES key schedule")
    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Ard Biesheuvel
     
  • The SHA256 digest is an array of 8 32-bit quantities, so we should refer
    to them as such in order for this code to work correctly when built for
    big endian. So replace 16 byte scalar loads and stores with 4x32 vector
    ones where appropriate.

    Fixes: 6ba6c74dfc6b ("arm64/crypto: SHA-224/SHA-256 using ARMv8 Crypto Extensions")
    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Ard Biesheuvel
     
  • The SHA1 digest is an array of 5 32-bit quantities, so we should refer
    to them as such in order for this code to work correctly when built for
    big endian. So replace 16 byte scalar loads and stores with 4x4 vector
    ones where appropriate.

    Fixes: 2c98833a42cd ("arm64/crypto: SHA-1 using ARMv8 Crypto Extensions")
    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Ard Biesheuvel
     
  • The GHASH key and digest are both pairs of 64-bit quantities, but the
    GHASH code does not always refer to them as such, causing failures when
    built for big endian. So replace the 16x1 loads and stores with 2x8 ones.

    Fixes: b913a6404ce2 ("arm64/crypto: improve performance of GHASH algorithm")
    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Ard Biesheuvel
     
  • The core AES cipher implementation that uses ARMv8 Crypto Extensions
    instructions erroneously loads the round keys as 64-bit quantities,
    which causes the algorithm to fail when built for big endian. In
    addition, the key schedule generation routine fails to take endianness
    into account as well, when loading the combining the input key with
    the round constants. So fix both issues.

    Fixes: 12ac3efe74f8 ("arm64/crypto: use crypto instructions to generate AES key schedule")
    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Ard Biesheuvel
     
  • The per-transform 'consts' array is accessed as __be64 in
    crypto_cmac_digest_setkey() but was only guaranteed to be aligned to
    __alignof__(long). Fix this by aligning it to __alignof__(__be64).

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

    Eric Biggers
     
  • cmac_create() previously returned 0 if a cipher with a block size other
    than 8 or 16 bytes was specified. It should return -EINVAL instead.
    Granted, this doesn't actually change any behavior because cryptomgr
    currently ignores any return value other than -EAGAIN from template
    ->create() functions.

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

    Eric Biggers
     
  • crypto_exit_cipher_ops() and crypto_exit_compress_ops() are no-ops and
    have been for a long time, so remove them.

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

    Eric Biggers
     
  • The definition of crypto_lookup_skcipher() was already removed in
    commit 3a01d0ee2b99 ("crypto: skcipher - Remove top-level givcipher
    interface"). So the declaration should be removed too.

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

    Eric Biggers
     
  • The size used in 'dma_free_coherent()' looks un-initialized here.
    ctx->sa_len is set a few lines below and is apparently not set by the
    caller.
    So use 'size' as in the corresponding 'dma_alloc_coherent()' a few lines
    above.

    This has been spotted with coccinelle, using the following script:
    ////////////////////
    @r@
    expression x0, x1, y0, y1, z0, z1, t0, t1, ret;
    @@

    * ret = dma_alloc_coherent(x0, y0, z0, t0);
    ...
    * dma_free_coherent(x1, y1, ret, t1);

    @script:python@
    y0 << r.y0;
    y1 << r.y1;

    @@
    if y1.find(y0) == -1:
    print "WARNING: sizes look different: '%s' vs '%s'" % (y0, y1)
    ////////////////////

    Signed-off-by: Christophe JAILLET
    Signed-off-by: Herbert Xu

    Christophe Jaillet
     
  • Currently, the driver breaks chain for all kind of hash requests in order to
    don't override intermediate states of partial ahash updates. However, some final
    ahash requests can be directly processed by the engine, and so without
    intermediate state. This is typically the case for most for the HMAC requests
    processed via IPSec.

    This commits adds a TDMA descriptor to copy context for these of requests
    into the "op" dma pool, then it allow to chain these requests at the DMA level.
    The 'complete' operation is also updated to retrieve the MAC digest from the
    right location.

    Signed-off-by: Romain Perier
    Acked-by: Boris Brezillon
    Signed-off-by: Herbert Xu

    Romain Perier
     
  • So far, we used a dedicated dma pool to copy the result of outer IV for
    cipher requests. Instead of using a dma pool per outer data, we prefer
    use the op dma pool that contains all part of the request from the SRAM.
    Then, the outer data that is likely to be used by the 'complete'
    operation, is copied later. In this way, any type of result can be
    retrieved by DMA for cipher or ahash requests.

    Signed-off-by: Romain Perier
    Acked-by: Boris Brezillon
    Signed-off-by: Herbert Xu

    Romain Perier
     
  • Currently FIPS depends on MODULE_SIG, even if MODULES is disabled.
    This change allows the enabling of FIPS without support for modules.

    If module loading support is enabled, only then does
    FIPS require MODULE_SIG.

    Signed-off-by: Alec Ari
    Signed-off-by: Herbert Xu

    Alec Ari
     
  • This patch adds the xts(aes) algorithm, which is supported from
    hardware version 0x500 and above (sama5d2x).

    Signed-off-by: Cyrille Pitchen
    Signed-off-by: Herbert Xu

    Cyrille Pitchen
     
  • This patch fixes a compiler error when VERBOSE_DEBUG is defined. Indeed,
    in atmel_aes_write(), the 3rd argument of atmel_aes_reg_name() was
    missing.

    Signed-off-by: Cyrille Pitchen
    Reported-by: Levent Demir
    Signed-off-by: Herbert Xu

    Cyrille Pitchen
     
  • This commits adds the devicetree description of the SafeXcel IP-76 TRNG
    found in the two Armada CP110.

    Signed-off-by: Romain Perier
    Signed-off-by: Herbert Xu

    Romain Perier
     
  • This commits adds a device variant for Safexcel,EIP76 found in Marvell
    Armada 8k. It defines registers mapping with the good offset and add a
    specific initialization function.

    Signed-off-by: Romain Perier
    Signed-off-by: Herbert Xu

    Romain Perier
     
  • So far, this driver was only used for OMAP SoCs. However, if a device
    variant is added for an IP block that has nothing to do with the OMAP
    platform, the message "OMAP Random Number Generator Ver" is displayed
    anyway. Instead of hardcoding "OMAP" into this message, we decide to
    only display "Random Number Generator". As dev_info is already
    pre-pending the message with the name of the device, we have enough
    informations.

    Signed-off-by: Romain Perier
    Signed-off-by: Herbert Xu

    Romain Perier
     
  • So far, this driver only supports up to 64 bits of output data generated
    by an RNG. Some IP blocks, like the SafeXcel IP-76 supports up to 128
    bits of output data. This commits renames registers descriptions
    OUTPUT_L_REG and OUTPUT_H_REG to OUTPUT_0_REG and OUPUT_1_REG,
    respectively. It also adds two new values to the enumeration of existing
    registers: OUTPUT_2_REG and OUTPUT_3_REG.

    Signed-off-by: Romain Perier
    Signed-off-by: Herbert Xu

    Romain Perier