1. 22 Apr, 2015 2 commits
  2. 09 Mar, 2015 1 commit
  3. 13 Jan, 2015 1 commit
    • Mathias Krause's avatar
      crypto: add missing crypto module aliases · 3e14dcf7
      Mathias Krause authored
      Commit 5d26a105 ("crypto: prefix module autoloading with "crypto-"")
      changed the automatic module loading when requesting crypto algorithms
      to prefix all module requests with "crypto-". This requires all crypto
      modules to have a crypto specific module alias even if their file name
      would otherwise match the requested crypto algorithm.
      
      Even though commit 5d26a105 added those aliases for a vast amount of
      modules, it was missing a few. Add the required MODULE_ALIAS_CRYPTO
      annotations to those files to make them get loaded automatically, again.
      This fixes, e.g., requesting 'ecb(blowfish-generic)', which used to work
      with kernels v3.18 and below.
      
      Also change MODULE_ALIAS() lines to MODULE_ALIAS_CRYPTO(). The former
      won't work for crypto modules any more.
      
      Fixes: 5d26a105 ("crypto: prefix module autoloading with "crypto-"")
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: 's avatarMathias Krause <minipli@googlemail.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      3e14dcf7
  4. 24 Nov, 2014 1 commit
  5. 23 Sep, 2013 1 commit
    • Neil Horman's avatar
      crypto: ansi_cprng - Fix off by one error in non-block size request · 714b33d1
      Neil Horman authored
      Stephan Mueller reported to me recently a error in random number generation in
      the ansi cprng. If several small requests are made that are less than the
      instances block size, the remainder for loop code doesn't increment
      rand_data_valid in the last iteration, meaning that the last bytes in the
      rand_data buffer gets reused on the subsequent smaller-than-a-block request for
      random data.
      
      The fix is pretty easy, just re-code the for loop to make sure that
      rand_data_valid gets incremented appropriately
      Signed-off-by: 's avatarNeil Horman <nhorman@tuxdriver.com>
      Reported-by: 's avatarStephan Mueller <stephan.mueller@atsec.com>
      CC: Stephan Mueller <stephan.mueller@atsec.com>
      CC: Petr Matousek <pmatouse@redhat.com>
      CC: Herbert Xu <herbert@gondor.apana.org.au>
      CC: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      714b33d1
  6. 01 Aug, 2012 1 commit
  7. 09 Nov, 2011 1 commit
    • Jarod Wilson's avatar
      crypto: ansi_cprng - enforce key != seed in fips mode · 505172e1
      Jarod Wilson authored
      Apparently, NIST is tightening up its requirements for FIPS validation
      with respect to RNGs. Its always been required that in fips mode, the
      ansi cprng not be fed key and seed material that was identical, but
      they're now interpreting FIPS 140-2, section AS07.09 as requiring that
      the implementation itself must enforce the requirement. Easy fix, we
      just do a memcmp of key and seed in fips_cprng_reset and call it a day.
      
      v2: Per Neil's advice, ensure slen is sufficiently long before we
      compare key and seed to avoid looking at potentially unallocated mem.
      
      CC: Stephan Mueller <smueller@atsec.com>
      CC: Steve Grubb <sgrubb@redhat.com>
      Signed-off-by: 's avatarJarod Wilson <jarod@redhat.com>
      Acked-by: 's avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      505172e1
  8. 31 Mar, 2011 1 commit
  9. 23 Nov, 2009 1 commit
  10. 27 Oct, 2009 1 commit
  11. 19 Oct, 2009 1 commit
  12. 29 Aug, 2009 1 commit
  13. 03 Jul, 2009 2 commits
    • Sebastian Andrzej Siewior's avatar
      crypto: ansi_prng - alloc cipher just in init · fd09d7fa
      Sebastian Andrzej Siewior authored
      As reported by Eric Sesterhenn the re-allocation of the cipher in reset leads
      to:
      |BUG: sleeping function called from invalid context at kernel/rwsem.c:21
      |in_atomic(): 1, irqs_disabled(): 0, pid: 4926, name: modprobe
      |INFO: lockdep is turned off.
      |Pid: 4926, comm: modprobe Tainted: G   M 2.6.31-rc1-22297-g52989765 #24
      |Call Trace:
      | [<c011dd93>] __might_sleep+0xf9/0x101
      | [<c0777aa0>] down_read+0x16/0x68
      | [<c048bf04>] crypto_alg_lookup+0x16/0x34
      | [<c048bf52>] crypto_larval_lookup+0x30/0xf9
      | [<c048c038>] crypto_alg_mod_lookup+0x1d/0x62
      | [<c048c13e>] crypto_alloc_base+0x1e/0x64
      | [<c04bf991>] reset_prng_context+0xab/0x13f
      | [<c04e5cfc>] ? __spin_lock_init+0x27/0x51
      | [<c04bfce1>] cprng_init+0x2a/0x42
      | [<c048bb4c>] __crypto_alloc_tfm+0xfa/0x128
      | [<c048c153>] crypto_alloc_base+0x33/0x64
      | [<c04933c9>] alg_test_cprng+0x30/0x1f4
      | [<c0493329>] alg_test+0x12f/0x19f
      | [<c0177f1f>] ? __alloc_pages_nodemask+0x14d/0x481
      | [<d09219e2>] do_test+0xf9d/0x163f [tcrypt]
      | [<d0920de6>] do_test+0x3a1/0x163f [tcrypt]
      | [<d0926035>] tcrypt_mod_init+0x35/0x7c [tcrypt]
      | [<c010113c>] _stext+0x54/0x12c
      | [<d0926000>] ? tcrypt_mod_init+0x0/0x7c [tcrypt]
      | [<c01398a3>] ? up_read+0x16/0x2b
      | [<c0139fc4>] ? __blocking_notifier_call_chain+0x40/0x4c
      | [<c014ee8d>] sys_init_module+0xa9/0x1bf
      | [<c010292b>] sysenter_do_call+0x12/0x32
      
      because a spin lock is held and crypto_alloc_base() may sleep.
      There is no reason to re-allocate the cipher, the state is resetted in
      ->setkey(). This patches makes the cipher allocation a one time thing and
      moves it to init.
      Reported-by: 's avatarEric Sesterhenn <eric.sesterhenn@lsexperts.de>
      Signed-off-by: 's avatarSebastian Andrzej Siewior <sebastian@breakpoint.cc>
      Acked-by: 's avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      fd09d7fa
    • Sebastian Andrzej Siewior's avatar
      crypto: ansi_prng - Use just a BH lock · ed940700
      Sebastian Andrzej Siewior authored
      The current code uses a mix of sping_lock() & spin_lock_irqsave(). This can
      lead to deadlock with the correct timming & cprng_get_random() + cprng_reset()
      sequence.
      I've converted them to bottom half locks since all three user grab just a BH
      lock so this runs probably in softirq :)
      Signed-off-by: 's avatarSebastian Andrzej Siewior <sebastian@breakpoint.cc>
      Acked-by: 's avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      ed940700
  14. 18 Feb, 2009 2 commits
    • Neil Horman's avatar
      crypto: ansi_cprng - Panic on CPRNG test failure when in FIPS mode · c5b1e545
      Neil Horman authored
      FIPS 140-2 specifies that all access to various cryptographic modules be
      prevented in the event that any of the provided self tests fail on the various
      implemented algorithms.  We already panic when any of the test in testmgr.c
      fail when we are operating in fips mode.  The continuous test in the cprng here
      was missed when that was implmented.  This code simply checks for the
      fips_enabled flag if the test fails, and warns us via syslog or panics the box
      accordingly.
      Signed-off-by: 's avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      c5b1e545
    • Neil Horman's avatar
      crypto: ansi_cprng - Force reset on allocation · d7992f42
      Neil Horman authored
      Pseudo RNGs provide predictable outputs based on input parateters {key, V, DT},
      the idea behind them is that only the user should know what the inputs are.
      While its nice to have default known values for testing purposes, it seems
      dangerous to allow the use of those default values without some sort of safety
      measure in place, lest an attacker easily guess the output of the cprng.  This
      patch forces the NEED_RESET flag on when allocating a cprng context, so that any
      user is forced to reseed it before use.  The defaults can still be used for
      testing, but this will prevent their inadvertent use, and be more secure.
      Signed-off-by: 's avatarNeil Horman <nhorman@redhat.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      d7992f42
  15. 25 Dec, 2008 3 commits
    • Jarod Wilson's avatar
      crypto: ansi_cprng - fix inverted DT increment routine · 09fbf7c0
      Jarod Wilson authored
      The ANSI X9.31 PRNG docs aren't particularly clear on how to increment DT,
      but empirical testing shows we're incrementing from the wrong end. A 10,000
      iteration Monte Carlo RNG test currently winds up not getting the expected
      result.
      
      From http://csrc.nist.gov/groups/STM/cavp/documents/rng/RNGVS.pdf :
      
      # CAVS 4.3
      # ANSI931 MCT
      [X9.31]
      [AES 128-Key]
      
      COUNT = 0
      Key = 9f5b51200bf334b5d82be8c37255c848
      DT = 6376bbe52902ba3b67c925fa701f11ac
      V = 572c8e76872647977e74fbddc49501d1
      R = 48e9bd0d06ee18fbe45790d5c3fc9b73
      
      Currently, we get 0dd08496c4f7178bfa70a2161a79459a after 10000 loops.
      
      Inverting the DT increment routine results in us obtaining the expected result
      of 48e9bd0d06ee18fbe45790d5c3fc9b73. Verified on both x86_64 and ppc64.
      Signed-off-by: 's avatarJarod Wilson <jarod@redhat.com>
      Acked-by: 's avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      09fbf7c0
    • Jarod Wilson's avatar
      crypto: ansi_cprng - Avoid incorrect extra call to _get_more_prng_bytes · aa1a85db
      Jarod Wilson authored
      While working with some FIPS RNGVS test vectors yesterday, I discovered a
      little bug in the way the ansi_cprng code works right now.
      
      For example, the following test vector (complete with expected result)
      from http://csrc.nist.gov/groups/STM/cavp/documents/rng/RNGVS.pdf ...
      
      Key = f3b1666d13607242ed061cabb8d46202
      DT = e6b3be782a23fa62d71d4afbb0e922fc
      V = f0000000000000000000000000000000
      R = 88dda456302423e5f69da57e7b95c73a
      
      ...when run through ansi_cprng, yields an incorrect R value
      of e2afe0d794120103d6e86a2b503bdfaa.
      
      If I load up ansi_cprng w/dbg=1 though, it was fairly obvious what was
      going wrong:
      
      ----8<----
      getting 16 random bytes for context ffff810033fb2b10
      Calling _get_more_prng_bytes for context ffff810033fb2b10
      Input DT: 00000000: e6 b3 be 78 2a 23 fa 62 d7 1d 4a fb b0 e9 22 fc 
      Input I: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
      Input V: 00000000: f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
      tmp stage 0: 00000000: e6 b3 be 78 2a 23 fa 62 d7 1d 4a fb b0 e9 22 fc 
      tmp stage 1: 00000000: f4 8e cb 25 94 3e 8c 31 d6 14 cd 8a 23 f1 3f 84 
      tmp stage 2: 00000000: 8c 53 6f 73 a4 1a af d4 20 89 68 f4 58 64 f8 be 
      Returning new block for context ffff810033fb2b10
      Output DT: 00000000: e7 b3 be 78 2a 23 fa 62 d7 1d 4a fb b0 e9 22 fc 
      Output I: 00000000: 04 8e cb 25 94 3e 8c 31 d6 14 cd 8a 23 f1 3f 84 
      Output V: 00000000: 48 89 3b 71 bc e4 00 b6 5e 21 ba 37 8a 0a d5 70 
      New Random Data: 00000000: 88 dd a4 56 30 24 23 e5 f6 9d a5 7e 7b 95 c7 3a 
      Calling _get_more_prng_bytes for context ffff810033fb2b10
      Input DT: 00000000: e7 b3 be 78 2a 23 fa 62 d7 1d 4a fb b0 e9 22 fc 
      Input I: 00000000: 04 8e cb 25 94 3e 8c 31 d6 14 cd 8a 23 f1 3f 84 
      Input V: 00000000: 48 89 3b 71 bc e4 00 b6 5e 21 ba 37 8a 0a d5 70 
      tmp stage 0: 00000000: e7 b3 be 78 2a 23 fa 62 d7 1d 4a fb b0 e9 22 fc 
      tmp stage 1: 00000000: 80 6b 3a 8c 23 ae 8f 53 be 71 4c 16 fc 13 b2 ea 
      tmp stage 2: 00000000: 2a 4d e1 2a 0b 58 8e e6 36 b8 9c 0a 26 22 b8 30 
      Returning new block for context ffff810033fb2b10
      Output DT: 00000000: e8 b3 be 78 2a 23 fa 62 d7 1d 4a fb b0 e9 22 fc 
      Output I: 00000000: c8 e2 01 fd 9f 4a 8f e5 e0 50 f6 21 76 19 67 9a 
      Output V: 00000000: ba 98 e3 75 c0 1b 81 8d 03 d6 f8 e2 0c c6 54 4b 
      New Random Data: 00000000: e2 af e0 d7 94 12 01 03 d6 e8 6a 2b 50 3b df aa 
      returning 16 from get_prng_bytes in context ffff810033fb2b10
      ----8<----
      
      The expected result is there, in the first "New Random Data", but we're
      incorrectly making a second call to _get_more_prng_bytes, due to some checks
      that are slightly off, which resulted in our original bytes never being
      returned anywhere.
      
      One approach to fixing this would be to alter some byte_count checks in
      get_prng_bytes, but it would mean the last DEFAULT_BLK_SZ bytes would be
      copied a byte at a time, rather than in a single memcpy, so a slightly more
      involved, equally functional, and ultimately more efficient way of fixing this
      was suggested to me by Neil, which I'm submitting here. All of the RNGVS ANSI
      X9.31 AES128 VST test vectors I've passed through ansi_cprng are now returning
      the expected results with this change.
      Signed-off-by: 's avatarJarod Wilson <jarod@redhat.com>
      Acked-by: 's avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      aa1a85db
    • Neil Horman's avatar
      crypto: ansi_cprng - Allow resetting of DT value · 2566578a
      Neil Horman authored
      	This is a patch that was sent to me by Jarod Wilson, marking off my
      outstanding todo to allow the ansi cprng to set/reset the DT counter value in a
      cprng instance.  Currently crytpo_rng_reset accepts a seed byte array which is
      interpreted by the ansi_cprng as a {V key} tuple.  This patch extends that tuple
      to now be {V key DT}, with DT an optional value during reset.  This patch also
      fixes  a bug we noticed in which the offset of the key area of the seed is
      started at DEFAULT_PRNG_KSZ rather than DEFAULT_BLK_SZ as it should be.
      Signed-off-by: 's avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: 's avatarJarod Wilson <jarod@redhat.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      2566578a
  16. 29 Aug, 2008 1 commit