1. 05 9月, 2014 1 次提交
  2. 03 9月, 2014 2 次提交
    • D
      PEFILE: Relax the check on the length of the PKCS#7 cert · 0aa04094
      David Howells 提交于
      Relax the check on the length of the PKCS#7 cert as it appears that the PE
      file wrapper size gets rounded up to the nearest 8.
      
      The debugging output looks like this:
      
      	PEFILE: ==> verify_pefile_signature()
      	PEFILE: ==> pefile_parse_binary()
      	PEFILE: checksum @ 110
      	PEFILE: header size = 200
      	PEFILE: cert = 968 @547be0 [68 09 00 00 00 02 02 00 30 82 09 56 ]
      	PEFILE: sig wrapper = { 968, 200, 2 }
      	PEFILE: Signature data not PKCS#7
      
      The wrapper is the first 8 bytes of the hex dump inside [].  This indicates a
      length of 0x968 bytes, including the wrapper header - so 0x960 bytes of
      payload.
      
      The ASN.1 wrapper begins [ ... 30 82 09 56 ].  That indicates an object of size
      0x956 - a four byte discrepency, presumably just padding for alignment
      purposes.
      
      So we just check that the ASN.1 container is no bigger than the payload and
      reduce the recorded size appropriately.
      
      Whilst we're at it, allow shorter PKCS#7 objects that manage to squeeze within
      127 or 255 bytes.  It's just about conceivable if no X.509 certs are included
      in the PKCS#7 message.
      Reported-by: NVivek Goyal <vgoyal@redhat.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Acked-by: NVivek Goyal <vgoyal@redhat.com>
      Acked-by: NPeter Jones <pjones@redhat.com>
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      0aa04094
    • D
      KEYS: Fix public_key asymmetric key subtype name · 876c6e3e
      David Howells 提交于
      The length of the name of an asymmetric key subtype must be stored in struct
      asymmetric_key_subtype::name_len so that it can be matched by a search for
      "<subkey_name>:<partial_fingerprint>".  Fix the public_key subtype to have
      name_len set.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      876c6e3e
  3. 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
  4. 03 8月, 2014 1 次提交
  5. 02 8月, 2014 2 次提交
  6. 01 8月, 2014 4 次提交
  7. 31 7月, 2014 2 次提交
  8. 29 7月, 2014 1 次提交
  9. 28 7月, 2014 2 次提交
  10. 25 7月, 2014 1 次提交
  11. 23 7月, 2014 2 次提交
  12. 19 7月, 2014 1 次提交
  13. 18 7月, 2014 1 次提交
  14. 17 7月, 2014 4 次提交
  15. 10 7月, 2014 1 次提交
  16. 09 7月, 2014 8 次提交
  17. 08 7月, 2014 6 次提交