Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 23 12月, 2018 3 次提交
  3. 08 10月, 2018 1 次提交
  5. 05 10月, 2018 1 次提交
  7. 14 9月, 2018 1 次提交
  9. 22 2月, 2018 3 次提交
  11. 25 1月, 2018 1 次提交
    • S
      crypto: aesni - handle zero length dst buffer · 9c674e1e
      由 Stephan Mueller 提交于 
      GCM can be invoked with a zero destination buffer. This is possible if
the AAD and the ciphertext have zero lengths and only the tag exists in
the source buffer (i.e. a source buffer cannot be zero). In this case,
the GCM cipher only performs the authentication and no decryption
operation.

When the destination buffer has zero length, it is possible that no page
is mapped to the SG pointing to the destination. In this case,
sg_page(req->dst) is an invalid access. Therefore, page accesses should
only be allowed if the req->dst->length is non-zero which is the
indicator that a page must exist.

This fixes a crash that can be triggered by user space via AF_ALG.

CC: <stable@vger.kernel.org>
Signed-off-by: NStephan Mueller <smueller@chronox.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      9c674e1e
  13. 22 12月, 2017 2 次提交
  15. 22 9月, 2017 2 次提交
  17. 04 8月, 2017 1 次提交
    • A
      crypto: algapi - make crypto_xor() take separate dst and src arguments · 45fe93df
      由 Ard Biesheuvel 提交于 
      There are quite a number of occurrences in the kernel of the pattern

  if (dst != src)
          memcpy(dst, src, walk.total % AES_BLOCK_SIZE);
  crypto_xor(dst, final, walk.total % AES_BLOCK_SIZE);

or

  crypto_xor(keystream, src, nbytes);
  memcpy(dst, keystream, nbytes);

where crypto_xor() is preceded or followed by a memcpy() invocation
that is only there because crypto_xor() uses its output parameter as
one of the inputs. To avoid having to add new instances of this pattern
in the arm64 code, which will be refactored to implement non-SIMD
fallbacks, add an alternative implementation called crypto_xor_cpy(),
taking separate input and output arguments. This removes the need for
the separate memcpy().
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      45fe93df
  19. 18 5月, 2017 1 次提交
  21. 03 2月, 2017 1 次提交
  23. 30 12月, 2016 1 次提交
  25. 27 12月, 2016 1 次提交
  27. 28 11月, 2016 1 次提交
  29. 12 11月, 2016 1 次提交
    • A
      crypto: aesni: shut up -Wmaybe-uninitialized warning · beae2c9e
      由 Arnd Bergmann 提交于 
      The rfc4106 encrypy/decrypt helper functions cause an annoying
false-positive warning in allmodconfig if we turn on
-Wmaybe-uninitialized warnings again:

  arch/x86/crypto/aesni-intel_glue.c: In function ‘helper_rfc4106_decrypt’:
  include/linux/scatterlist.h:67:31: warning: ‘dst_sg_walk.sg’ may be used uninitialized in this function [-Wmaybe-uninitialized]

The problem seems to be that the compiler doesn't track the state of the
'one_entry_in_sg' variable across the kernel_fpu_begin/kernel_fpu_end
section.

This takes the easy way out by adding a bogus initialization, which
should be harmless enough to get the patch into v4.9 so we can turn on
this warning again by default without producing useless output.  A
follow-up patch for v4.10 rearranges the code to make the warning go
away.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      beae2c9e
  31. 01 7月, 2016 1 次提交
    • H
      crypto: aesni - Use crypto_cipher to derive rfc4106 subkey · 02fa472a
      由 Herbert Xu 提交于 
      Currently aesni uses an async ctr(aes) to derive the rfc4106
subkey, which was presumably copied over from the generic rfc4106
code.  Over there it's done that way because we already have a
ctr(aes) spawn.  But it is simply overkill for aesni since we
have to go get a ctr(aes) from scratch anyway.

This patch simplifies the subkey derivation by using a straight
aes cipher instead.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      02fa472a
  33. 23 6月, 2016 1 次提交
  35. 13 4月, 2016 1 次提交
  37. 17 2月, 2016 1 次提交
    • S
      crypto: xts - consolidate sanity check for keys · 28856a9e
      由 Stephan Mueller 提交于 
      The patch centralizes the XTS key check logic into the service function
xts_check_key which is invoked from the different XTS implementations.
With this, the XTS implementations in ARM, ARM64, PPC and S390 have now
a sanity check for the XTS keys similar to the other arches.

In addition, this service function received a check to ensure that the
key != the tweak key which is mandated by FIPS 140-2 IG A.9. As the
check is not present in the standards defining XTS, it is only enforced
in FIPS mode of the kernel.
Signed-off-by: NStephan Mueller <smueller@chronox.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      28856a9e
  39. 17 8月, 2015 1 次提交
  41. 14 7月, 2015 1 次提交
  43. 29 6月, 2015 1 次提交
  45. 03 6月, 2015 2 次提交
  47. 19 5月, 2015 1 次提交
    • I
      x86/fpu: Rename i387.h to fpu/api.h · df6b35f4
      由 Ingo Molnar 提交于 
      We already have fpu/types.h, move i387.h to fpu/api.h.

The file name has become a misnomer anyway: it offers generic FPU APIs,
but is not limited to i387 functionality.
Reviewed-by: NBorislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: NIngo Molnar <mingo@kernel.org>
      df6b35f4
  49. 13 5月, 2015 1 次提交
  51. 31 3月, 2015 1 次提交
  53. 13 3月, 2015 1 次提交
    • S
      crypto: aesni - fix memory usage in GCM decryption · ccfe8c3f
      由 Stephan Mueller 提交于 
      The kernel crypto API logic requires the caller to provide the
length of (ciphertext || authentication tag) as cryptlen for the
AEAD decryption operation. Thus, the cipher implementation must
calculate the size of the plaintext output itself and cannot simply use
cryptlen.

The RFC4106 GCM decryption operation tries to overwrite cryptlen memory
in req->dst. As the destination buffer for decryption only needs to hold
the plaintext memory but cryptlen references the input buffer holding
(ciphertext || authentication tag), the assumption of the destination
buffer length in RFC4106 GCM operation leads to a too large size. This
patch simply uses the already calculated plaintext size.

In addition, this patch fixes the offset calculation of the AAD buffer
pointer: as mentioned before, cryptlen already includes the size of the
tag. Thus, the tag does not need to be added. With the addition, the AAD
will be written beyond the already allocated buffer.

Note, this fixes a kernel crash that can be triggered from user space
via AF_ALG(aead) -- simply use the libkcapi test application
from [1] and update it to use rfc4106-gcm-aes.

Using [1], the changes were tested using CAVS vectors to demonstrate
that the crypto operation still delivers the right results.

[1] http://www.chronox.de/libkcapi.html

CC: Tadeusz Struk <tadeusz.struk@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NStephan Mueller <smueller@chronox.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      ccfe8c3f
  55. 28 2月, 2015 1 次提交
  57. 14 1月, 2015 1 次提交
    • T
      crypto: aesni - Add support for 192 & 256 bit keys to AESNI RFC4106 · e31ac32d
      由 Timothy McCaffrey 提交于 
      These patches fix the RFC4106 implementation in the aesni-intel
module so it supports 192 & 256 bit keys.

Since the AVX support that was added to this module also only
supports 128 bit keys, and this patch only affects the SSE
implementation, changes were also made to use the SSE version
if key sizes other than 128 are specified.

RFC4106 specifies that 192 & 256 bit keys must be supported (section
8.4).

Also, this should fix Strongswan issue 341 where the aesni module
needs to be unloaded if 256 bit keys are used:

http://wiki.strongswan.org/issues/341

This patch has been tested with Sandy Bridge and Haswell processors.
With 128 bit keys and input buffers > 512 bytes a slight performance
degradation was noticed (~1%).  For input buffers of less than 512
bytes there was no performance impact.  Compared to 128 bit keys,
256 bit key size performance is approx. .5 cycles per byte slower
on Sandy Bridge, and .37 cycles per byte slower on Haswell (vs.
SSE code).

This patch has also been tested with StrongSwan IPSec connections
where it worked correctly.

I created this diff from a git clone of crypto-2.6.git.

Any questions, please feel free to contact me.
Signed-off-by: NTimothy McCaffrey <timothy.mccaffrey@unisys.com>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      e31ac32d
  59. 24 11月, 2014 1 次提交
  61. 06 11月, 2014 1 次提交
    • V
      crypto: aesni - remove unnecessary #define · 304576a7
      由 Valentin Rothberg 提交于 
      The CPP identifier 'HAS_PCBC' is defined when the Kconfig
option CRYPTO_PCBC is set as 'y' or 'm', and is further
used in two ifdef blocks to conditionally compile source
code. This indirection hides the actual Kconfig dependency
and complicates readability. Moreover, it's inconsistent
with the rest of the ifdef blocks in the file, which
directly reference Kconfig options.

This patch removes 'HAS_PCBC' and replaces its occurrences
with the actual dependency on 'CRYPTO_PCBC' being set as
'y' or 'm'.
Signed-off-by: NValentin Rothberg <valentinrothberg@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      304576a7
  63. 02 10月, 2014 1 次提交
  65. 24 9月, 2014 1 次提交