1. 07 1月, 2009 3 次提交
    • M
      eCryptfs: Fix data types (int/size_t) · a8f12864
      Michael Halcrow 提交于
      Correct several format string data type specifiers.  Correct filename size
      data types; they should be size_t rather than int when passed as
      parameters to some other functions (although note that the filenames will
      never be larger than int).
      Signed-off-by: NMichael Halcrow <mhalcrow@us.ibm.com>
      Cc: Dustin Kirkland <dustin.kirkland@gmail.com>
      Cc: Eric Sandeen <sandeen@redhat.com>
      Cc: Tyler Hicks <tchicks@us.ibm.com>
      Cc: David Kleikamp <shaggy@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a8f12864
    • M
      eCryptfs: Replace %Z with %z · df261c52
      Michael Halcrow 提交于
      %Z is a gcc-ism. Using %z instead.
      Signed-off-by: NMichael Halcrow <mhalcrow@us.ibm.com>
      Cc: Dustin Kirkland <dustin.kirkland@gmail.com>
      Cc: Eric Sandeen <sandeen@redhat.com>
      Cc: Tyler Hicks <tchicks@us.ibm.com>
      Cc: David Kleikamp <shaggy@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      df261c52
    • M
      eCryptfs: Filename Encryption: Tag 70 packets · 9c79f34f
      Michael Halcrow 提交于
      This patchset implements filename encryption via a passphrase-derived
      mount-wide Filename Encryption Key (FNEK) specified as a mount parameter.
      Each encrypted filename has a fixed prefix indicating that eCryptfs should
      try to decrypt the filename.  When eCryptfs encounters this prefix, it
      decodes the filename into a tag 70 packet and then decrypts the packet
      contents using the FNEK, setting the filename to the decrypted filename.
      Both unencrypted and encrypted filenames can reside in the same lower
      filesystem.
      
      Because filename encryption expands the length of the filename during the
      encoding stage, eCryptfs will not properly handle filenames that are
      already near the maximum filename length.
      
      In the present implementation, eCryptfs must be able to produce a match
      against the lower encrypted and encoded filename representation when given
      a plaintext filename.  Therefore, two files having the same plaintext name
      will encrypt and encode into the same lower filename if they are both
      encrypted using the same FNEK.  This can be changed by finding a way to
      replace the prepended bytes in the blocked-aligned filename with random
      characters; they are hashes of the FNEK right now, so that it is possible
      to deterministically map from a plaintext filename to an encrypted and
      encoded filename in the lower filesystem.  An implementation using random
      characters will have to decode and decrypt every single directory entry in
      any given directory any time an event occurs wherein the VFS needs to
      determine whether a particular file exists in the lower directory and the
      decrypted and decoded filenames have not yet been extracted for that
      directory.
      
      Thanks to Tyler Hicks and David Kleikamp for assistance in the development
      of this patchset.
      
      This patch:
      
      A tag 70 packet contains a filename encrypted with a Filename Encryption
      Key (FNEK).  This patch implements functions for writing and parsing tag
      70 packets.  This patch also adds definitions and extends structures to
      support filename encryption.
      Signed-off-by: NMichael Halcrow <mhalcrow@us.ibm.com>
      Cc: Dustin Kirkland <dustin.kirkland@gmail.com>
      Cc: Eric Sandeen <sandeen@redhat.com>
      Cc: Tyler Hicks <tchicks@us.ibm.com>
      Cc: David Kleikamp <shaggy@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9c79f34f
  2. 20 11月, 2008 1 次提交
    • M
      eCryptfs: Allocate up to two scatterlists for crypto ops on keys · ac97b9f9
      Michael Halcrow 提交于
      I have received some reports of out-of-memory errors on some older AMD
      architectures.  These errors are what I would expect to see if
      crypt_stat->key were split between two separate pages.  eCryptfs should
      not assume that any of the memory sent through virt_to_scatterlist() is
      all contained in a single page, and so this patch allocates two
      scatterlist structs instead of one when processing keys.  I have received
      confirmation from one person affected by this bug that this patch resolves
      the issue for him, and so I am submitting it for inclusion in a future
      stable release.
      
      Note that virt_to_scatterlist() runs sg_init_table() on the scatterlist
      structs passed to it, so the calls to sg_init_table() in
      decrypt_passphrase_encrypted_session_key() are redundant.
      Signed-off-by: NMichael Halcrow <mhalcrow@us.ibm.com>
      Reported-by: NPaulo J. S. Silva <pjssilva@ime.usp.br>
      Cc: "Leon Woestenberg" <leon.woestenberg@gmail.com>
      Cc: Tim Gardner <tim.gardner@canonical.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ac97b9f9
  3. 17 10月, 2008 1 次提交
  4. 25 7月, 2008 1 次提交
  5. 29 4月, 2008 1 次提交
  6. 07 2月, 2008 1 次提交
  7. 18 12月, 2007 1 次提交
  8. 23 10月, 2007 1 次提交
  9. 17 10月, 2007 11 次提交
  10. 17 2月, 2007 1 次提交
  11. 15 2月, 2007 1 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      Tim Schmielau 提交于
      After Al Viro (finally) succeeded in removing the sched.h #include in module.h
      recently, it makes sense again to remove other superfluous sched.h includes.
      There are quite a lot of files which include it but don't actually need
      anything defined in there.  Presumably these includes were once needed for
      macros that used to live in sched.h, but moved to other header files in the
      course of cleaning it up.
      
      To ease the pain, this time I did not fiddle with any header files and only
      removed #includes from .c-files, which tend to cause less trouble.
      
      Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
      arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
      allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
      configs in arch/arm/configs on arm.  I also checked that no new warnings were
      introduced by the patch (actually, some warnings are removed that were emitted
      by unnecessarily included header files).
      Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a
  12. 13 2月, 2007 2 次提交
  13. 12 2月, 2007 1 次提交
  14. 08 12月, 2006 1 次提交
  15. 01 11月, 2006 2 次提交
  16. 04 10月, 2006 1 次提交