1. 25 8月, 2014 6 次提交
  2. 09 8月, 2014 1 次提交
    • Y
      initramfs: support initramfs that is bigger than 2GiB · d97b07c5
      Yinghai Lu 提交于
      Now with 64bit bzImage and kexec tools, we support ramdisk that size is
      bigger than 2g, as we could put it above 4G.
      
      Found compressed initramfs image could not be decompressed properly.  It
      turns out that image length is int during decompress detection, and it
      will become < 0 when length is more than 2G.  Furthermore, during
      decompressing len as int is used for inbuf count, that has problem too.
      
      Change len to long, that should be ok as on 32 bit platform long is
      32bits.
      
      Tested with following compressed initramfs image as root with kexec.
      	gzip, bzip2, xz, lzma, lzop, lz4.
      run time for populate_rootfs():
         size        name       Nehalem-EX  Westmere-EX  Ivybridge-EX
       9034400256 root_img     :   26s           24s          30s
       3561095057 root_img.lz4 :   28s           27s          27s
       3459554629 root_img.lzo :   29s           29s          28s
       3219399480 root_img.gz  :   64s           62s          49s
       2251594592 root_img.xz  :  262s          260s         183s
       2226366598 root_img.lzma:  386s          376s         277s
       2901482513 root_img.bz2 :  635s          599s
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Rashika Kheria <rashika.kheria@gmail.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Kyungsik Lee <kyungsik.lee@lge.com>
      Cc: P J P <ppandit@redhat.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
      Cc: "Daniel M. Weeks" <dan@danweeks.net>
      Cc: Alexandre Courbot <acourbot@nvidia.com>
      Cc: Jan Beulich <JBeulich@suse.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d97b07c5
  3. 03 8月, 2014 1 次提交
  4. 02 8月, 2014 2 次提交
  5. 01 8月, 2014 4 次提交
  6. 31 7月, 2014 2 次提交
  7. 29 7月, 2014 1 次提交
  8. 28 7月, 2014 2 次提交
  9. 25 7月, 2014 1 次提交
  10. 23 7月, 2014 2 次提交
  11. 19 7月, 2014 1 次提交
  12. 18 7月, 2014 1 次提交
  13. 17 7月, 2014 4 次提交
  14. 10 7月, 2014 1 次提交
  15. 09 7月, 2014 8 次提交
  16. 08 7月, 2014 3 次提交
    • S
      crypto: drbg - HMAC-SHA1 DRBG has crypto strength of 128 bits · 5b635e28
      Stephan Mueller 提交于
      The patch corrects the security strength of the HMAC-SHA1 DRBG to 128
      bits. This strength defines the size of the seed required for the DRBG.
      Thus, the patch lowers the seeding requirement from 256 bits to 128 bits
      for HMAC-SHA1.
      Signed-off-by: NStephan Mueller <smueller@chronox.de>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      5b635e28
    • S
      crypto: drbg - Mix a time stamp into DRBG state · 27e4de2b
      Stephan Mueller 提交于
      The current locking approach of the DRBG tries to keep the protected
      code paths very minimal. It is therefore possible that two threads query
      one DRBG instance at the same time. When thread A requests random
      numbers, a shadow copy of the DRBG state is created upon which the
      request for A is processed. After finishing the state for A's request is
      merged back into the DRBG state. If now thread B requests random numbers
      from the same DRBG after the request for thread A is received, but
      before A's shadow state is merged back, the random numbers for B will be
      identical to the ones for A. Please note that the time window is very
      small for this scenario.
      
      To prevent that there is even a theoretical chance for thread A and B
      having the same DRBG state, the current time stamp is provided as
      additional information string for each new request.
      
      The addition of the time stamp as additional information string implies
      that now all generate functions must be capable to process a linked
      list with additional information strings instead of a scalar.
      
      CC: Rafael Aquini <aquini@redhat.com>
      Signed-off-by: NStephan Mueller <smueller@chronox.de>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      27e4de2b
    • S
      crypto: drbg - Select correct DRBG core for stdrng · 4f150718
      Stephan Mueller 提交于
      When the DRBG is initialized, the core is looked up using the DRBG name.
      The name that can be used for the lookup is registered in
      cra_driver_name. The cra_name value contains stdrng.
      
      Thus, the lookup code must use crypto_tfm_alg_driver_name to obtain the
      precise DRBG name and select the correct DRBG.
      Signed-off-by: NStephan Mueller <smueller@chronox.de>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      4f150718