1. 28 11月, 2007 1 次提交
  2. 03 11月, 2007 1 次提交
    • J
      [CIFS] implement upcalls for SPNEGO blob via keyctl API · 09fe7ba7
      Jeff Layton 提交于
      Add routines to handle upcalls to userspace via keyctl for the purpose
      of getting a SPNEGO blob for a particular uid and server combination.
      
      Clean up the Makefile a bit and set it up to only compile cifs_spnego
      if CONFIG_CIFS_UPCALL is set. Also change CONFIG_CIFS_UPCALL to depend
      on CONFIG_KEYS rather than CONFIG_CONNECTOR.
      
      cifs_spnego.h defines the communications between kernel and userspace
      and is intended to be shared with userspace programs.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      09fe7ba7
  3. 31 10月, 2007 1 次提交
  4. 20 10月, 2007 1 次提交
  5. 18 10月, 2007 1 次提交
    • A
      Ext4: Uninitialized Block Groups · 717d50e4
      Andreas Dilger 提交于
      In pass1 of e2fsck, every inode table in the fileystem is scanned and checked,
      regardless of whether it is in use.  This is this the most time consuming part
      of the filesystem check.  The unintialized block group feature can greatly
      reduce e2fsck time by eliminating checking of uninitialized inodes.
      
      With this feature, there is a a high water mark of used inodes for each block
      group.  Block and inode bitmaps can be uninitialized on disk via a flag in the
      group descriptor to avoid reading or scanning them at e2fsck time.  A checksum
      of each group descriptor is used to ensure that corruption in the group
      descriptor's bit flags does not cause incorrect operation.
      
      The feature is enabled through a mkfs option
      
      	mke2fs /dev/ -O uninit_groups
      
      A patch adding support for uninitialized block groups to e2fsprogs tools has
      been posted to the linux-ext4 mailing list.
      
      The patches have been stress tested with fsstress and fsx.  In performance
      tests testing e2fsck time, we have seen that e2fsck time on ext3 grows
      linearly with the total number of inodes in the filesytem.  In ext4 with the
      uninitialized block groups feature, the e2fsck time is constant, based
      solely on the number of used inodes rather than the total inode count.
      Since typical ext4 filesystems only use 1-10% of their inodes, this feature can
      greatly reduce e2fsck time for users.  With performance improvement of 2-20
      times, depending on how full the filesystem is.
      
      The attached graph shows the major improvements in e2fsck times in filesystems
      with a large total inode count, but few inodes in use.
      
      In each group descriptor if we have
      
      EXT4_BG_INODE_UNINIT set in bg_flags:
              Inode table is not initialized/used in this group. So we can skip
              the consistency check during fsck.
      EXT4_BG_BLOCK_UNINIT set in bg_flags:
              No block in the group is used. So we can skip the block bitmap
              verification for this group.
      
      We also add two new fields to group descriptor as a part of
      uninitialized group patch.
      
              __le16  bg_itable_unused;       /* Unused inodes count */
              __le16  bg_checksum;            /* crc16(sb_uuid+group+desc) */
      
      bg_itable_unused:
      
      If we have EXT4_BG_INODE_UNINIT not set in bg_flags
      then bg_itable_unused will give the offset within
      the inode table till the inodes are used. This can be
      used by fsck to skip list of inodes that are marked unused.
      
      bg_checksum:
      Now that we depend on bg_flags and bg_itable_unused to determine
      the block and inode usage, we need to make sure group descriptor
      is not corrupt. We add checksum to group descriptor to
      detect corruption. If the descriptor is found to be corrupt, we
      mark all the blocks and inodes in the group used.
      Signed-off-by: NAvantika Mathur <mathur@us.ibm.com>
      Signed-off-by: NAndreas Dilger <adilger@clusterfs.com>
      Signed-off-by: NMingming Cao <cmm@us.ibm.com>
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      717d50e4
  6. 17 10月, 2007 4 次提交
  7. 10 10月, 2007 2 次提交
  8. 12 9月, 2007 1 次提交
  9. 02 8月, 2007 1 次提交
  10. 20 7月, 2007 1 次提交
  11. 18 7月, 2007 2 次提交
  12. 15 7月, 2007 1 次提交
  13. 11 7月, 2007 3 次提交
  14. 10 7月, 2007 1 次提交
  15. 11 6月, 2007 1 次提交
  16. 09 5月, 2007 2 次提交
    • A
      Remove obsolete fat_cvf help text · 148e423f
      Alexander E. Patrakov 提交于
      The text removed by the following patch refers to functionality that never
      worked, to non-existing documentation file, and to mount options marked as
      obsolete in the module.
      Signed-off-by: NAlexander E. Patrakov <patrakov@ums.usu.ru>
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
      148e423f
    • R
      reiserfs: proc support requires PROC_FS · 880ebdc5
      Randy Dunlap 提交于
      REISER_FS /proc option needs to depend on PROC_FS.
      
      fs/reiserfs/procfs.c: In function 'show_super':
      fs/reiserfs/procfs.c:134: error: 'reiserfs_proc_info_data_t' has no member named 'max_hash_collisions'
      fs/reiserfs/procfs.c:134: error: 'reiserfs_proc_info_data_t' has no member named 'breads'
      fs/reiserfs/procfs.c:135: error: 'reiserfs_proc_info_data_t' has no member named 'bread_miss'
      fs/reiserfs/procfs.c:135: error: 'reiserfs_proc_info_data_t' has no member named 'search_by_key'
      fs/reiserfs/procfs.c:136: error: 'reiserfs_proc_info_data_t' has no member named 'search_by_key_fs_changed'
      fs/reiserfs/procfs.c:136: error: 'reiserfs_proc_info_data_t' has no member named 'search_by_key_restarted'
      fs/reiserfs/procfs.c:137: error: 'reiserfs_proc_info_data_t' has no member named 'insert_item_restarted'
      fs/reiserfs/procfs.c:137: error: 'reiserfs_proc_info_data_t' has no member named 'paste_into_item_restarted'
      fs/reiserfs/procfs.c:138: error: 'reiserfs_proc_info_data_t' has no member named 'cut_from_item_restarted'
      fs/reiserfs/procfs.c:139: error: 'reiserfs_proc_info_data_t' has no member named 'delete_solid_item_restarted'
      fs/reiserfs/procfs.c:139: error: 'reiserfs_proc_info_data_t' has no member named 'delete_item_restarted'
      fs/reiserfs/procfs.c:140: error: 'reiserfs_proc_info_data_t' has no member named 'leaked_oid'
      fs/reiserfs/procfs.c:140: error: 'reiserfs_proc_info_data_t' has no member named 'leaves_removable'
      fs/reiserfs/procfs.c: In function 'show_per_level':
      fs/reiserfs/procfs.c:184: error: 'reiserfs_proc_info_data_t' has no member named 'balance_at'
      fs/reiserfs/procfs.c:185: error: 'reiserfs_proc_info_data_t' has no member named 'sbk_read_at'
      fs/reiserfs/procfs.c:186: error: 'reiserfs_proc_info_data_t' has no member named 'sbk_fs_changed'
      fs/reiserfs/procfs.c:187: error: 'reiserfs_proc_info_data_t' has no member named 'sbk_restarted'
      fs/reiserfs/procfs.c:188: error: 'reiserfs_proc_info_data_t' has no member named 'free_at'
      fs/reiserfs/procfs.c:189: error: 'reiserfs_proc_info_data_t' has no member named 'items_at'
      fs/reiserfs/procfs.c:190: error: 'reiserfs_proc_info_data_t' has no member named 'can_node_be_removed'
      fs/reiserfs/procfs.c:191: error: 'reiserfs_proc_info_data_t' has no member named 'lnum'
      fs/reiserfs/procfs.c:192: error: 'reiserfs_proc_info_data_t' has no member named 'rnum'
      fs/reiserfs/procfs.c:193: error: 'reiserfs_proc_info_data_t' has no member named 'lbytes'
      fs/reiserfs/procfs.c:194: error: 'reiserfs_proc_info_data_t' has no member named 'rbytes'
      fs/reiserfs/procfs.c:195: error: 'reiserfs_proc_info_data_t' has no member named 'get_neighbors'
      fs/reiserfs/procfs.c:196: error: 'reiserfs_proc_info_data_t' has no member named 'get_neighbors_restart'
      fs/reiserfs/procfs.c:197: error: 'reiserfs_proc_info_data_t' has no member named 'need_l_neighbor'
      fs/reiserfs/procfs.c:197: error: 'reiserfs_proc_info_data_t' has no member named 'need_r_neighbor'
      fs/reiserfs/procfs.c: In function 'show_bitmap':
      fs/reiserfs/procfs.c:224: error: 'reiserfs_proc_info_data_t' has no member named 'free_block'
      fs/reiserfs/procfs.c:225: error: 'reiserfs_proc_info_data_t' has no member named 'scan_bitmap'
      fs/reiserfs/procfs.c:226: error: 'reiserfs_proc_info_data_t' has no member named 'scan_bitmap'
      fs/reiserfs/procfs.c:227: error: 'reiserfs_proc_info_data_t' has no member named 'scan_bitmap'
      fs/reiserfs/procfs.c:228: error: 'reiserfs_proc_info_data_t' has no member named 'scan_bitmap'
      fs/reiserfs/procfs.c:229: error: 'reiserfs_proc_info_data_t' has no member named 'scan_bitmap'
      fs/reiserfs/procfs.c:230: error: 'reiserfs_proc_info_data_t' has no member named 'scan_bitmap'
      fs/reiserfs/procfs.c:230: error: 'reiserfs_proc_info_data_t' has no member named 'scan_bitmap'
      fs/reiserfs/procfs.c: In function 'show_journal':
      fs/reiserfs/procfs.c:384: error: 'reiserfs_proc_info_data_t' has no member named 'journal'
      fs/reiserfs/procfs.c:385: error: 'reiserfs_proc_info_data_t' has no member named 'journal'
      fs/reiserfs/procfs.c:386: error: 'reiserfs_proc_info_data_t' has no member named 'journal'
      fs/reiserfs/procfs.c:387: error: 'reiserfs_proc_info_data_t' has no member named 'journal'
      fs/reiserfs/procfs.c:388: error: 'reiserfs_proc_info_data_t' has no member named 'journal'
      fs/reiserfs/procfs.c:389: error: 'reiserfs_proc_info_data_t' has no member named 'journal'
      fs/reiserfs/procfs.c:390: error: 'reiserfs_proc_info_data_t' has no member named 'journal'
      fs/reiserfs/procfs.c:391: error: 'reiserfs_proc_info_data_t' has no member named 'journal'
      fs/reiserfs/procfs.c:392: error: 'reiserfs_proc_info_data_t' has no member named 'journal'
      fs/reiserfs/procfs.c:393: error: 'reiserfs_proc_info_data_t' has no member named 'journal'
      fs/reiserfs/procfs.c:394: error: 'reiserfs_proc_info_data_t' has no member named 'journal'
      fs/reiserfs/procfs.c:395: error: 'reiserfs_proc_info_data_t' has no member named 'journal'
      fs/reiserfs/procfs.c:395: error: 'reiserfs_proc_info_data_t' has no member named 'journal'
      fs/reiserfs/procfs.c:395: error: 'reiserfs_proc_info_data_t' has no member named 'journal'
      fs/reiserfs/procfs.c: In function 'reiserfs_proc_info_init':
      fs/reiserfs/procfs.c:504: warning: implicit declaration of function '__PINFO'
      fs/reiserfs/procfs.c:504: error: request for member 'lock' in something not a structure or union
      fs/reiserfs/procfs.c: In function 'reiserfs_proc_info_done':
      fs/reiserfs/procfs.c:544: error: request for member 'lock' in something not a structure or union
      fs/reiserfs/procfs.c:545: error: request for member 'exiting' in something not a structure or union
      fs/reiserfs/procfs.c:546: error: request for member 'lock' in something not a structure or union
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      880ebdc5
  17. 03 5月, 2007 1 次提交
    • D
      [AFS/AF_RXRPC]: Miscellaneous fixes. · 80c72fe4
      David Howells 提交于
      Make miscellaneous fixes to AFS and AF_RXRPC:
      
       (*) Make AF_RXRPC select KEYS rather than RXKAD or AFS_FS in Kconfig.
      
       (*) Don't use FS_BINARY_MOUNTDATA.
      
       (*) Remove a done 'TODO' item in a comemnt on afs_get_sb().
      
       (*) Don't pass a void * as the page pointer argument of kmap_atomic() as this
           breaks on m68k.  Patch from Geert Uytterhoeven <geert@linux-m68k.org>.
      
       (*) Use match_*() functions rather than doing my own parsing.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      80c72fe4
  18. 01 5月, 2007 1 次提交
  19. 28 4月, 2007 1 次提交
  20. 27 4月, 2007 2 次提交
  21. 18 2月, 2007 1 次提交
  22. 14 2月, 2007 1 次提交
  23. 13 2月, 2007 1 次提交
    • M
      [PATCH] eCryptfs: Public key transport mechanism · 88b4a07e
      Michael Halcrow 提交于
      This is the transport code for public key functionality in eCryptfs.  It
      manages encryption/decryption request queues with a transport mechanism.
      Currently, netlink is the only implemented transport.
      
      Each inode has a unique File Encryption Key (FEK).  Under passphrase, a File
      Encryption Key Encryption Key (FEKEK) is generated from a salt/passphrase
      combo on mount.  This FEKEK encrypts each FEK and writes it into the header of
      each file using the packet format specified in RFC 2440.  This is all
      symmetric key encryption, so it can all be done via the kernel crypto API.
      
      These new patches introduce public key encryption of the FEK.  There is no
      asymmetric key encryption support in the kernel crypto API, so eCryptfs pushes
      the FEK encryption and decryption out to a userspace daemon.  After
      considering our requirements and determining the complexity of using various
      transport mechanisms, we settled on netlink for this communication.
      
      eCryptfs stores authentication tokens into the kernel keyring.  These tokens
      correlate with individual keys.  For passphrase mode of operation, the
      authentication token contains the symmetric FEKEK.  For public key, the
      authentication token contains a PKI type and an opaque data blob managed by
      individual PKI modules in userspace.
      
      Each user who opens a file under an eCryptfs partition mounted in public key
      mode must be running a daemon.  That daemon has the user's credentials and has
      access to all of the keys to which the user should have access.  The daemon,
      when started, initializes the pluggable PKI modules available on the system
      and registers itself with the eCryptfs kernel module.  Userspace utilities
      register public key authentication tokens into the user session keyring.
      These authentication tokens correlate key signatures with PKI modules and PKI
      blobs.  The PKI blobs contain PKI-specific information necessary for the PKI
      module to carry out asymmetric key encryption and decryption.
      
      When the eCryptfs module parses the header of an existing file and finds a Tag
      1 (Public Key) packet (see RFC 2440), it reads in the public key identifier
      (signature).  The asymmetrically encrypted FEK is in the Tag 1 packet;
      eCryptfs puts together a decrypt request packet containing the signature and
      the encrypted FEK, then it passes it to the daemon registered for the
      current->euid via a netlink unicast to the PID of the daemon, which was
      registered at the time the daemon was started by the user.
      
      The daemon actually just makes calls to libecryptfs, which implements request
      packet parsing and manages PKI modules.  libecryptfs grabs the public key
      authentication token for the given signature from the user session keyring.
      This auth tok tells libecryptfs which PKI module should receive the request.
      libecryptfs then makes a decrypt() call to the PKI module, and it passes along
      the PKI block from the auth tok.  The PKI uses the blob to figure out how it
      should decrypt the data passed to it; it performs the decryption and passes
      the decrypted data back to libecryptfs.  libecryptfs then puts together a
      reply packet with the decrypted FEK and passes that back to the eCryptfs
      module.
      
      The eCryptfs module manages these request callouts to userspace code via
      message context structs.  The module maintains an array of message context
      structs and places the elements of the array on two lists: a free and an
      allocated list.  When eCryptfs wants to make a request, it moves a msg ctx
      from the free list to the allocated list, sets its state to pending, and fires
      off the message to the user's registered daemon.
      
      When eCryptfs receives a netlink message (via the callback), it correlates the
      msg ctx struct in the alloc list with the data in the message itself.  The
      msg->index contains the offset of the array of msg ctx structs.  It verifies
      that the registered daemon PID is the same as the PID of the process that sent
      the message.  It also validates a sequence number between the received packet
      and the msg ctx.  Then, it copies the contents of the message (the reply
      packet) into the msg ctx struct, sets the state in the msg ctx to done, and
      wakes up the process that was sleeping while waiting for the reply.
      
      The sleeping process was whatever was performing the sys_open().  This process
      originally called ecryptfs_send_message(); it is now in
      ecryptfs_wait_for_response().  When it wakes up and sees that the msg ctx
      state was set to done, it returns a pointer to the message contents (the reply
      packet) and returns.  If all went well, this packet contains the decrypted
      FEK, which is then copied into the crypt_stat struct, and life continues as
      normal.
      
      The case for creation of a new file is very similar, only instead of a decrypt
      request, eCryptfs sends out an encrypt request.
      
      > - We have a great clod of key mangement code in-kernel.  Why is that
      >   not suitable (or growable) for public key management?
      
      eCryptfs uses Howells' keyring to store persistent key data and PKI state
      information.  It defers public key cryptographic transformations to userspace
      code.  The userspace data manipulation request really is orthogonal to key
      management in and of itself.  What eCryptfs basically needs is a secure way to
      communicate with a particular daemon for a particular task doing a syscall,
      based on the UID.  Nothing running under another UID should be able to access
      that channel of communication.
      
      > - Is it appropriate that new infrastructure for public key
      > management be private to a particular fs?
      
      The messaging.c file contains a lot of code that, perhaps, could be extracted
      into a separate kernel service.  In essence, this would be a sort of
      request/reply mechanism that would involve a userspace daemon.  I am not aware
      of anything that does quite what eCryptfs does, so I was not aware of any
      existing tools to do just what we wanted.
      
      >   What happens if one of these daemons exits without sending a quit
      >   message?
      
      There is a stale uid<->pid association in the hash table for that user.  When
      the user registers a new daemon, eCryptfs cleans up the old association and
      generates a new one.  See ecryptfs_process_helo().
      
      > - _why_ does it use netlink?
      
      Netlink provides the transport mechanism that would minimize the complexity of
      the implementation, given that we can have multiple daemons (one per user).  I
      explored the possibility of using relayfs, but that would involve having to
      introduce control channels and a protocol for creating and tearing down
      channels for the daemons.  We do not have to worry about any of that with
      netlink.
      Signed-off-by: NMichael Halcrow <mhalcrow@us.ibm.com>
      Cc: David Howells <dhowells@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      88b4a07e
  24. 12 2月, 2007 1 次提交
  25. 08 2月, 2007 1 次提交
  26. 23 12月, 2006 1 次提交
  27. 13 12月, 2006 2 次提交
  28. 30 11月, 2006 2 次提交
  29. 17 11月, 2006 1 次提交