Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 25 5月, 2008 1 次提交
  3. 29 4月, 2008 2 次提交
  5. 07 2月, 2008 6 次提交
  7. 24 12月, 2007 2 次提交
  9. 06 11月, 2007 2 次提交
  11. 27 10月, 2007 1 次提交
  13. 24 10月, 2007 1 次提交
  15. 23 10月, 2007 1 次提交
  17. 17 10月, 2007 16 次提交
  19. 13 2月, 2007 6 次提交
    • M
      [PATCH] eCryptfs: open-code flag checking and manipulation · e2bd99ec
      由 Michael Halcrow 提交于 
      Open-code flag checking and manipulation.
Signed-off-by: NMichael Halcrow <mhalcrow@us.ibm.com>
Signed-off-by: NTrevor Highland <tshighla@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e2bd99ec
    • M
      [PATCH] eCryptfs: convert kmap() to kmap_atomic() · 9d8b8ce5
      由 Michael Halcrow 提交于 
      Replace kmap() with kmap_atomic().  Reduce the amount of time that mappings
are held.
Signed-off-by: NMichael Halcrow <mhalcrow@us.ibm.com>
Signed-off-by: NTrevor Highland <tshighla@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9d8b8ce5
    • M
      [PATCH] eCryptfs: convert f_op->write() to vfs_write() · 70456600
      由 Michael Halcrow 提交于 
      sys_write() takes a local copy of f_pos and writes that back
into the struct file. It does this so that two concurrent write()
callers don't make a mess of f_pos, and of the file contents.

ecryptfs should be calling vfs_write().  That way we also get the fsnotify
notifications, which ecryptfs presently appears to have subverted.

Convert direct calls to f_op->write() into calls to vfs_write().
Signed-off-by: NMichael Halcrow <mhalcrow@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      70456600
    • M
      [PATCH] eCryptfs: Encrypted passthrough · e77a56dd
      由 Michael Halcrow 提交于 
      Provide an option to provide a view of the encrypted files such that the
metadata is always in the header of the files, regardless of whether the
metadata is actually in the header or in the extended attribute.  This mode of
operation is useful for applications like incremental backup utilities that do
not preserve the extended attributes when directly accessing the lower files.

With this option enabled, the files under the eCryptfs mount point will be
read-only.
Signed-off-by: NMichael Halcrow <mhalcrow@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e77a56dd
    • M
      [PATCH] eCryptfs: Generalize metadata read/write · dd2a3b7a
      由 Michael Halcrow 提交于 
      Generalize the metadata reading and writing mechanisms, with two targets for
now: metadata in file header and metadata in the user.ecryptfs xattr of the
lower file.

[akpm@osdl.org: printk warning fix]
[bunk@stusta.de: make some needlessly global code static]
Signed-off-by: NMichael Halcrow <mhalcrow@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dd2a3b7a
    • M
      [PATCH] eCryptfs: xattr flags and mount options · 17398957
      由 Michael Halcrow 提交于 
      This patch set introduces the ability to store cryptographic metadata into an
lower file extended attribute rather than the lower file header region.

This patch set implements two new mount options:

ecryptfs_xattr_metadata
 - When set, newly created files will have their cryptographic
   metadata stored in the extended attribute region of the file rather
   than the header.

   When storing the data in the file header, there is a minimum of 8KB
   reserved for the header information for each file, making each file at
   least 12KB in size.  This can take up a lot of extra disk space if the user
   creates a lot of small files.  By storing the data in the extended
   attribute, each file will only occupy at least of 4KB of space.

   As the eCryptfs metadata set becomes larger with new features such as
   multi-key associations, most popular filesystems will not be able to store
   all of the information in the xattr region in some cases due to space
   constraints.  However, the majority of users will only ever associate one
   key per file, so most users will be okay with storing their data in the
   xattr region.

   This option should be used with caution.  I want to emphasize that the
   xattr must be maintained under all circumstances, or the file will be
   rendered permanently unrecoverable.  The last thing I want is for a user to
   forget to set an xattr flag in a backup utility, only to later discover
   that their backups are worthless.

ecryptfs_encrypted_view
 - When set, this option causes eCryptfs to present applications a
   view of encrypted files as if the cryptographic metadata were
   stored in the file header, whether the metadata is actually stored
   in the header or in the extended attributes.

   No matter what eCryptfs winds up doing in the lower filesystem, I want
   to preserve a baseline format compatibility for the encrypted files.  As of
   right now, the metadata may be in the file header or in an xattr.  There is
   no reason why the metadata could not be put in a separate file in future
   versions.

   Without the compatibility mode, backup utilities would have to know to
   back up the metadata file along with the files.  The semantics of eCryptfs
   have always been that the lower files are self-contained units of encrypted
   data, and the only additional information required to decrypt any given
   eCryptfs file is the key.  That is what has always been emphasized about
   eCryptfs lower files, and that is what users expect.  Providing the
   encrypted view option will provide a way to userspace applications wherein
   they can always get to the same old familiar eCryptfs encrypted files,
   regardless of what eCryptfs winds up doing with the metadata behind the
   scenes.

This patch:

Add extended attribute support to version bit vector, flags to indicate when
xattr or encrypted view modes are enabled, and support for the new mount
options.
Signed-off-by: NMichael Halcrow <mhalcrow@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      17398957
  21. 12 2月, 2007 1 次提交
  23. 07 2月, 2007 1 次提交