1. 09 Aug, 2017 4 commits
    • Arnd Bergmann's avatar
      crypto: ccp - avoid uninitialized variable warning · d634baea
      Arnd Bergmann authored
      The added support for version 5 CCPs introduced a false-positive
      warning in the RSA implementation:
      
      drivers/crypto/ccp/ccp-ops.c: In function 'ccp_run_rsa_cmd':
      drivers/crypto/ccp/ccp-ops.c:1856:3: error: 'sb_count' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      This changes the code in a way that should make it easier for
      the compiler to track the state of the sb_count variable, and
      avoid the warning.
      
      Fixes: 6ba46c7d ("crypto: ccp - Fix base RSA function for version 5 CCPs")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarGary R Hook <gary.hook@amd.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      d634baea
    • Arnd Bergmann's avatar
      crypto: serpent - improve __serpent_setkey with UBSAN · c871c10e
      Arnd Bergmann authored
      When UBSAN is enabled, we get a very large stack frame for
      __serpent_setkey, when the register allocator ends up using more registers
      than it has, and has to spill temporary values to the stack. The code
      was originally optimized for in-order x86-32 CPU implementations using
      older compilers, but it now runs into a highly suboptimal case on all
      CPU architectures, as seen by this warning:
      
      crypto/serpent_generic.c: In function '__serpent_setkey':
      crypto/serpent_generic.c:436:1: error: the frame size of 2720 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
      
      Disabling -fsanitize=alignment would avoid that warning, presumably the
      option turns off a optimization step that is required for getting the
      register allocation right, but there is no easy way to do that on gcc-7
      (gcc-8 introduces a function attribute for this).
      
      I tried to figure out a way to modify the source code instead, and noticed
      that the two stages of the setkey() function (keyiter and sbox) each are
      fine by themselves, but not when combined into one function. Splitting
      out the entire sbox into a separate function also happens to work fine
      with all compilers I tried (arm, arm64 and x86).
      
      The setkey function uses a strange way to handle offsets into the key
      array, using both negative and positive index values, as well as adjusting
      the array pointer back and forth. I have checked that this actually
      makes no difference to modern compilers, but I left that untouched
      to make the patch easier to review and to keep the code closer to
      the reference implementation.
      
      Link: https://patchwork.kernel.org/patch/9189575/Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      c871c10e
    • Stephan Mueller's avatar
      crypto: algif_aead - copy AAD from src to dst · 72548b09
      Stephan Mueller authored
      Use the NULL cipher to copy the AAD and PT/CT from the TX SGL
      to the RX SGL. This allows an in-place crypto operation on the
      RX SGL for encryption, because the TX data is always smaller or
      equal to the RX data (the RX data will hold the tag).
      
      For decryption, a per-request TX SGL is created which will only hold
      the tag value. As the RX SGL will have no space for the tag value and
      an in-place operation will not write the tag buffer, the TX SGL with the
      tag value is chained to the RX SGL. This now allows an in-place
      crypto operation.
      
      For example:
      
      * without the patch:
      kcapi -x 2 -e -c "gcm(aes)" -p 89154d0d4129d322e4487bafaa4f6b46 -k c0ece3e63198af382b5603331cc23fa8 -i 7e489b83622e7228314d878d -a afcd7202d621e06ca53b70c2bdff7fb2 -l 16 -u -s
      00000000000000000000000000000000f4a3eacfbdadd3b1a17117b1d67ffc1f1e21efbbc6d83724a8c296e3bb8cda0c
      
      * with the patch:
      kcapi -x 2 -e -c "gcm(aes)" -p 89154d0d4129d322e4487bafaa4f6b46 -k c0ece3e63198af382b5603331cc23fa8 -i 7e489b83622e7228314d878d -a afcd7202d621e06ca53b70c2bdff7fb2 -l 16 -u -s
      afcd7202d621e06ca53b70c2bdff7fb2f4a3eacfbdadd3b1a17117b1d67ffc1f1e21efbbc6d83724a8c296e3bb8cda0c
      
      Tests covering this functionality have been added to libkcapi.
      Signed-off-by: default avatarStephan Mueller <smueller@chronox.de>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      72548b09
    • Stephan Mueller's avatar
      crypto: algif - return error code when no data was processed · 5703c826
      Stephan Mueller authored
      If no data has been processed during recvmsg, return the error code.
      This covers all errors received during non-AIO operations.
      
      If any error occurs during a synchronous operation in addition to
      -EIOCBQUEUED or -EBADMSG (like -ENOMEM), it should be relayed to the
      caller.
      Signed-off-by: default avatarStephan Mueller <smueller@chronox.de>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      5703c826
  2. 04 Aug, 2017 22 commits
  3. 03 Aug, 2017 14 commits