1. 14 Feb, 2020 1 commit
  2. 20 Aug, 2019 1 commit
  3. 05 Jun, 2019 1 commit
  4. 06 Nov, 2017 2 commits
  5. 03 Jul, 2014 1 commit
  6. 08 Jun, 2013 1 commit
  7. 28 Feb, 2013 1 commit
    • Sasha Levin's avatar
      hlist: drop the node parameter from iterators · b67bfe0d
      Sasha Levin authored
      I'm not sure why, but the hlist for each entry iterators were conceived
              list_for_each_entry(pos, head, member)
      The hlist ones were greedy and wanted an extra parameter:
              hlist_for_each_entry(tpos, pos, head, member)
      Why did they need an extra pos parameter? I'm not quite sure. Not only
      they don't really need it, it also prevents the iterator from looking
      exactly like the list iterator, which is unfortunate.
      Besides the semantic patch, there was some manual work required:
       - Fix up the actual hlist iterators in linux/list.h
       - Fix up the declaration of other iterators based on the hlist ones.
       - A very small amount of places were using the 'node' parameter, this
       was modified to use 'obj->member' instead.
       - Coccinelle didn't handle the hlist_for_each_entry_safe iterator
       properly, so those had to be fixed up manually.
      The semantic patch which is mostly the work of Peter Senna Tschudin is here:
      iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;
      type T;
      expression a,c,d,e;
      identifier b;
      statement S;
      -T b;
          <+... when != b
      - b,
      c, d) S
      - b,
      c) S
      - b,
      c) S
      - b,
      c, d) S
      - b,
      c, d) S
      - b,
      c) S
      for_each_busy_worker(a, c,
      - b,
      d) S
      - b,
      c) S
      - b,
      c) S
      - b,
      c) S
      - b,
      c) S
      - b,
      c) S
      - b,
      c) S
      -(a, b)
      + sk_for_each_from(a) S
      - b,
      c, d) S
      - b,
      c) S
      - b,
      c, d, e) S
      - b,
      c) S
      - b,
      c) S
      - b,
      c, d) S
      - b,
      c) S
      - b,
      c, d) S
      - for_each_gfn_sp(a, c, d, b) S
      + for_each_gfn_sp(a, c, d) S
      - for_each_gfn_indirect_valid_sp(a, c, d, b) S
      + for_each_gfn_indirect_valid_sp(a, c, d) S
      - b,
      c) S
      - b,
      c, d) S
      - b,
      c, d) S
      [akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
      [akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
      [akpm@linux-foundation.org: checkpatch fixes]
      [akpm@linux-foundation.org: fix warnings]
      [akpm@linux-foudnation.org: redo intrusive kvm changes]
      Tested-by: default avatarPeter Senna Tschudin <peter.senna@gmail.com>
      Acked-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Cc: Wu Fengguang <fengguang.wu@intel.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Gleb Natapov <gleb@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  8. 27 Feb, 2013 1 commit
  9. 12 Feb, 2013 1 commit
  10. 21 Sep, 2012 1 commit
  11. 08 Jul, 2012 2 commits
    • Tyler Hicks's avatar
      eCryptfs: Make all miscdev functions use daemon ptr in file private_data · 2ecaf55d
      Tyler Hicks authored
      Now that a pointer to a valid struct ecryptfs_daemon is stored in the
      private_data of an opened /dev/ecryptfs file, the remaining miscdev
      functions can utilize the pointer rather than looking up the
      ecryptfs_daemon at the beginning of each operation.
      The security model of /dev/ecryptfs is simplified a little bit with this
      patch. Upon opening /dev/ecryptfs, a per-user ecryptfs_daemon is
      registered. Another daemon cannot be registered for that user until the
      last file reference is released. During the lifetime of the
      ecryptfs_daemon, access checks are not performed on the /dev/ecryptfs
      operations because it is assumed that the application securely handles
      the opened file descriptor and does not unintentionally leak it to
      processes that are not trusted.
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Cc: Sasha Levin <levinsasha928@gmail.com>
    • Tyler Hicks's avatar
      eCryptfs: Remove unused messaging declarations and function · 56696886
      Tyler Hicks authored
      These are no longer needed.
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Cc: Sasha Levin <levinsasha928@gmail.com>
  12. 07 Apr, 2012 1 commit
  13. 27 Aug, 2010 1 commit
  14. 09 Aug, 2010 1 commit
  15. 29 Jul, 2010 1 commit
  16. 30 Mar, 2010 1 commit
    • Tejun Heo's avatar
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo authored
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      The script does the followings.
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
      The conversion was done in the following steps.
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
      6. percpu.h was updated not to include slab.h.
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Guess-its-ok-by: default avatarChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
  17. 22 Apr, 2009 1 commit
    • Tyler Hicks's avatar
      eCryptfs: NULL pointer dereference in ecryptfs_send_miscdev() · 57ea34d1
      Tyler Hicks authored
      If data is NULL, msg_ctx->msg is set to NULL and then dereferenced
      afterwards.  ecryptfs_send_raw_message() is the only place that
      ecryptfs_send_miscdev() is called with data being NULL, but the only
      caller of that function (ecryptfs_process_helo()) is never called.  In
      short, there is currently no way to trigger the NULL pointer
      This patch removes the two unused functions and modifies
      ecryptfs_send_miscdev() to remove the NULL dereferences.
      Signed-off-by: default avatarTyler Hicks <tyhicks@linux.vnet.ibm.com>
  18. 01 Apr, 2009 1 commit
  19. 06 Jan, 2009 1 commit
  20. 24 Nov, 2008 1 commit
    • Serge Hallyn's avatar
      User namespaces: set of cleanups (v2) · 18b6e041
      Serge Hallyn authored
      The user_ns is moved from nsproxy to user_struct, so that a struct
      cred by itself is sufficient to determine access (which it otherwise
      would not be).  Corresponding ecryptfs fixes (by David Howells) are
      here as well.
      Fix refcounting.  The following rules now apply:
              1. The task pins the user struct.
              2. The user struct pins its user namespace.
              3. The user namespace pins the struct user which created it.
      User namespaces are cloned during copy_creds().  Unsharing a new user_ns
      is no longer possible.  (We could re-add that, but it'll cause code
      duplication and doesn't seem useful if PAM doesn't need to clone user
      When a user namespace is created, its first user (uid 0) gets empty
      keyrings and a clean group_info.
      This incorporates a previous patch by David Howells.  Here
      is his original patch description:
      >I suggest adding the attached incremental patch.  It makes the following
      > (1) Provides a current_user_ns() macro to wrap accesses to current's user
      >     namespace.
      > (2) Fixes eCryptFS.
      > (3) Renames create_new_userns() to create_user_ns() to be more consistent
      >     with the other associated functions and because the 'new' in the name is
      >     superfluous.
      > (4) Moves the argument and permission checks made for CLONE_NEWUSER to the
      >     beginning of do_fork() so that they're done prior to making any attempts
      >     at allocation.
      > (5) Calls create_user_ns() after prepare_creds(), and gives it the new creds
      >     to fill in rather than have it return the new root user.  I don't imagine
      >     the new root user being used for anything other than filling in a cred
      >     struct.
      >     This also permits me to get rid of a get_uid() and a free_uid(), as the
      >     reference the creds were holding on the old user_struct can just be
      >     transferred to the new namespace's creator pointer.
      > (6) Makes create_user_ns() reset the UIDs and GIDs of the creds under
      >     preparation rather than doing it in copy_creds().
      >Signed-off-by: David Howells <dhowells@redhat.com>
      	Oct 20: integrate dhowells comments
      		1. leave thread_keyring alone
      		2. use current_user_ns() in set_user()
      Signed-off-by: default avatarSerge Hallyn <serue@us.ibm.com>
  21. 13 Nov, 2008 1 commit
  22. 16 Oct, 2008 1 commit
  23. 29 Apr, 2008 2 commits
  24. 23 Dec, 2007 1 commit
  25. 16 Oct, 2007 1 commit
  26. 21 May, 2007 1 commit
    • Alexey Dobriyan's avatar
      Detach sched.h from mm.h · e8edc6e0
      Alexey Dobriyan authored
      First thing mm.h does is including sched.h solely for can_do_mlock() inline
      function which has "current" dereference inside. By dealing with can_do_mlock()
      mm.h can be detached from sched.h which is good. See below, why.
      This patch
      a) removes unconditional inclusion of sched.h from mm.h
      b) makes can_do_mlock() normal function in mm/mlock.c
      c) exports can_do_mlock() to not break compilation
      d) adds sched.h inclusions back to files that were getting it indirectly.
      e) adds less bloated headers to some files (asm/signal.h, jiffies.h) that were
         getting them indirectly
      Net result is:
      a) mm.h users would get less code to open, read, preprocess, parse, ... if
         they don't need sched.h
      b) sched.h stops being dependency for significant number of files:
         on x86_64 allmodconfig touching sched.h results in recompile of 4083 files,
         after patch it's only 3744 (-8.3%).
      Cross-compile tested on
      	all arm defconfigs, all mips defconfigs, all powerpc defconfigs,
      	alpha alpha-up
      	i386 i386-up i386-defconfig i386-allnoconfig
      	ia64 ia64-up
      	parisc parisc-up
      	powerpc powerpc-up
      	s390 s390-up
      	sparc sparc-up
      	sparc64 sparc64-up
      	x86_64 x86_64-up x86_64-defconfig x86_64-allnoconfig
      as well as my two usual configs.
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  27. 16 Feb, 2007 1 commit
  28. 12 Feb, 2007 3 commits
    • Michael Halcrow's avatar
      [PATCH] eCryptfs: Generalize metadata read/write · dd2a3b7a
      Michael Halcrow authored
      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: default avatarMichael Halcrow <mhalcrow@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Michael Halcrow's avatar
      [PATCH] eCryptfs: Public key; packet management · dddfa461
      Michael Halcrow authored
      Public key support code.  This reads and writes packets in the header that
      contain public key encrypted file keys.  It calls the messaging code in the
      previous patch to send and receive encryption and decryption request
      packets from the userspace daemon.
      [akpm@osdl.org: cleab fix]
      Signed-off-by: default avatarMichael Halcrow <mhalcrow@us.ibm.com>
      Cc: David Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Michael Halcrow's avatar
      [PATCH] eCryptfs: Public key transport mechanism · 88b4a07e
      Michael Halcrow authored
      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
      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
      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
      Signed-off-by: default avatarMichael Halcrow <mhalcrow@us.ibm.com>
      Cc: David Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>