1. 25 Nov, 2022 20 commits
  2. 22 Nov, 2022 1 commit
  3. 18 Nov, 2022 13 commits
  4. 14 Nov, 2022 1 commit
  5. 11 Nov, 2022 5 commits
    • Shashank Gupta's avatar
      crypto: qat - remove ADF_STATUS_PF_RUNNING flag from probe · 557ffd5a
      Shashank Gupta authored
      The ADF_STATUS_PF_RUNNING bit is set after the successful initialization
      of the communication between VF to PF in adf_vf2pf_notify_init().
      So, it is not required to be set after the execution of the function
      adf_dev_init().
      Signed-off-by: default avatarShashank Gupta <shashank.gupta@intel.com>
      Reviewed-by: default avatarGiovanni Cabiddu <giovanni.cabiddu@intel.com>
      Reviewed-by: default avatarWojciech Ziemba <wojciech.ziemba@intel.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      557ffd5a
    • Yang Li's avatar
      crypto: rockchip - Remove surplus dev_err() when using platform_get_irq() · fb11cddf
      Yang Li authored
      There is no need to call the dev_err() function directly to print a
      custom message when handling an error from either the platform_get_irq()
      or platform_get_irq_byname() functions as both are going to display an
      appropriate error message in case of a failure.
      
      ./drivers/crypto/rockchip/rk3288_crypto.c:351:2-9: line 351 is
      redundant because platform_get_irq() already prints an error
      
      Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2677Reported-by: default avatarAbaci Robot <abaci@linux.alibaba.com>
      Signed-off-by: default avatarYang Li <yang.lee@linux.alibaba.com>
      Acked-by: default avatarCorentin Labbe <clabbe@baylibre.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      fb11cddf
    • Ard Biesheuvel's avatar
      crypto: lib/aesgcm - Provide minimal library implementation · 520af5da
      Ard Biesheuvel authored
      Implement a minimal library version of AES-GCM based on the existing
      library implementations of AES and multiplication in GF(2^128). Using
      these primitives, GCM can be implemented in a straight-forward manner.
      
      GCM has a couple of sharp edges, i.e., the amount of input data
      processed with the same initialization vector (IV) should be capped to
      protect the counter from 32-bit rollover (or carry), and the size of the
      authentication tag should be fixed for a given key. [0]
      
      The former concern is addressed trivially, given that the function call
      API uses 32-bit signed types for the input lengths. It is still up to
      the caller to avoid IV reuse in general, but this is not something we
      can police at the implementation level.
      
      As for the latter concern, let's make the authentication tag size part
      of the key schedule, and only permit it to be configured as part of the
      key expansion routine.
      
      Note that table based AES implementations are susceptible to known
      plaintext timing attacks on the encryption key. The AES library already
      attempts to mitigate this to some extent, but given that the counter
      mode encryption used by GCM operates exclusively on known plaintext by
      construction (the IV and therefore the initial counter value are known
      to an attacker), let's take some extra care to mitigate this, by calling
      the AES library with interrupts disabled.
      
      [0] https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38d.pdf
      
      Link: https://lore.kernel.org/all/c6fb9b25-a4b6-2e4a-2dd1-63adda055a49@amd.com/Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
      Tested-by: default avatarNikunj A Dadhania <nikunj@amd.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      520af5da
    • Ard Biesheuvel's avatar
      crypto: lib/gf128mul - make gf128mul_lle time invariant · b67ce439
      Ard Biesheuvel authored
      The gf128mul library has different variants with different
      memory/performance tradeoffs, where the faster ones use 4k or 64k lookup
      tables precomputed at runtime, which are based on one of the
      multiplication factors, which is commonly the key for keyed hash
      algorithms such as GHASH.
      
      The slowest variant is gf128_mul_lle() [and its bbe/ble counterparts],
      which does not use precomputed lookup tables, but it still relies on a
      single u16[256] lookup table which is input independent. The use of such
      a table may cause the execution time of gf128_mul_lle() to correlate
      with the value of the inputs, which is generally something that must be
      avoided for cryptographic algorithms. On top of that, the function uses
      a sequence of if () statements that conditionally invoke be128_xor()
      based on which bits are set in the second argument of the function,
      which is usually a pointer to the multiplication factor that represents
      the key.
      
      In order to remove the correlation between the execution time of
      gf128_mul_lle() and the value of its inputs, let's address the
      identified shortcomings:
      - add a time invariant version of gf128mul_x8_lle() that replaces the
        table lookup with the expression that is used at compile time to
        populate the lookup table;
      - make the invocations of be128_xor() unconditional, but pass a zero
        vector as the third argument if the associated bit in the key is
        cleared.
      
      The resulting code is likely to be significantly slower. However, given
      that this is the slowest version already, making it even slower in order
      to make it more secure is assumed to be justified.
      
      The bbe and ble counterparts could receive the same treatment, but the
      former is never used anywhere in the kernel, and the latter is only
      used in the driver for a asynchronous crypto h/w accelerator (Chelsio),
      where timing variances are unlikely to matter.
      Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      b67ce439
    • Ard Biesheuvel's avatar
      crypto: move gf128mul library into lib/crypto · 61c581a4
      Ard Biesheuvel authored
      The gf128mul library does not depend on the crypto API at all, so it can
      be moved into lib/crypto. This will allow us to use it in other library
      code in a subsequent patch without having to depend on CONFIG_CRYPTO.
      
      While at it, change the Kconfig symbol name to align with other crypto
      library implementations. However, the source file name is retained, as
      it is reflected in the module .ko filename, and changing this might
      break things for users.
      Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      61c581a4