07 Oct, 2016

1 commit


28 May, 2016

1 commit

  • smack ->d_instantiate() uses ->setxattr(), so to be able to call it before
    we'd hashed the new dentry and attached it to inode, we need ->setxattr()
    instances getting the inode as an explicit argument rather than obtaining
    it from dentry.

    Similar change for ->getxattr() had been done in commit ce23e64. Unlike
    ->getxattr() (which is used by both selinux and smack instances of
    ->d_instantiate()) ->setxattr() is used only by smack one and unfortunately
    it got missed back then.

    Reported-by: Seung-Woo Kim
    Tested-by: Casey Schaufler
    Signed-off-by: Al Viro

    Al Viro
     

18 May, 2016

1 commit

  • Pull parallel filesystem directory handling update from Al Viro.

    This is the main parallel directory work by Al that makes the vfs layer
    able to do lookup and readdir in parallel within a single directory.
    That's a big change, since this used to be all protected by the
    directory inode mutex.

    The inode mutex is replaced by an rwsem, and serialization of lookups of
    a single name is done by a "in-progress" dentry marker.

    The series begins with xattr cleanups, and then ends with switching
    filesystems over to actually doing the readdir in parallel (switching to
    the "iterate_shared()" that only takes the read lock).

    A more detailed explanation of the process from Al Viro:
    "The xattr work starts with some acl fixes, then switches ->getxattr to
    passing inode and dentry separately. This is the point where the
    things start to get tricky - that got merged into the very beginning
    of the -rc3-based #work.lookups, to allow untangling the
    security_d_instantiate() mess. The xattr work itself proceeds to
    switch a lot of filesystems to generic_...xattr(); no complications
    there.

    After that initial xattr work, the series then does the following:

    - untangle security_d_instantiate()

    - convert a bunch of open-coded lookup_one_len_unlocked() to calls of
    that thing; one such place (in overlayfs) actually yields a trivial
    conflict with overlayfs fixes later in the cycle - overlayfs ended
    up switching to a variant of lookup_one_len_unlocked() sans the
    permission checks. I would've dropped that commit (it gets
    overridden on merge from #ovl-fixes in #for-next; proper resolution
    is to use the variant in mainline fs/overlayfs/super.c), but I
    didn't want to rebase the damn thing - it was fairly late in the
    cycle...

    - some filesystems had managed to depend on lookup/lookup exclusion
    for *fs-internal* data structures in a way that would break if we
    relaxed the VFS exclusion. Fixing hadn't been hard, fortunately.

    - core of that series - parallel lookup machinery, replacing
    ->i_mutex with rwsem, making lookup_slow() take it only shared. At
    that point lookups happen in parallel; lookups on the same name
    wait for the in-progress one to be done with that dentry.

    Surprisingly little code, at that - almost all of it is in
    fs/dcache.c, with fs/namei.c changes limited to lookup_slow() -
    making it use the new primitive and actually switching to locking
    shared.

    - parallel readdir stuff - first of all, we provide the exclusion on
    per-struct file basis, same as we do for read() vs lseek() for
    regular files. That takes care of most of the needed exclusion in
    readdir/readdir; however, these guys are trickier than lookups, so
    I went for switching them one-by-one. To do that, a new method
    '->iterate_shared()' is added and filesystems are switched to it
    as they are either confirmed to be OK with shared lock on directory
    or fixed to be OK with that. I hope to kill the original method
    come next cycle (almost all in-tree filesystems are switched
    already), but it's still not quite finished.

    - several filesystems get switched to parallel readdir. The
    interesting part here is dealing with dcache preseeding by readdir;
    that needs minor adjustment to be safe with directory locked only
    shared.

    Most of the filesystems doing that got switched to in those
    commits. Important exception: NFS. Turns out that NFS folks, with
    their, er, insistence on VFS getting the fuck out of the way of the
    Smart Filesystem Code That Knows How And What To Lock(tm) have
    grown the locking of their own. They had their own homegrown
    rwsem, with lookup/readdir/atomic_open being *writers* (sillyunlink
    is the reader there). Of course, with VFS getting the fuck out of
    the way, as requested, the actual smarts of the smart filesystem
    code etc. had become exposed...

    - do_last/lookup_open/atomic_open cleanups. As the result, open()
    without O_CREAT locks the directory only shared. Including the
    ->atomic_open() case. Backmerge from #for-linus in the middle of
    that - atomic_open() fix got brought in.

    - then comes NFS switch to saner (VFS-based ;-) locking, killing the
    homegrown "lookup and readdir are writers" kinda-sorta rwsem. All
    exclusion for sillyunlink/lookup is done by the parallel lookups
    mechanism. Exclusion between sillyunlink and rmdir is a real rwsem
    now - rmdir being the writer.

    Result: NFS lookups/readdirs/O_CREAT-less opens happen in parallel
    now.

    - the rest of the series consists of switching a lot of filesystems
    to parallel readdir; in a lot of cases ->llseek() gets simplified
    as well. One backmerge in there (again, #for-linus - rockridge
    fix)"

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (74 commits)
    ext4: switch to ->iterate_shared()
    hfs: switch to ->iterate_shared()
    hfsplus: switch to ->iterate_shared()
    hostfs: switch to ->iterate_shared()
    hpfs: switch to ->iterate_shared()
    hpfs: handle allocation failures in hpfs_add_pos()
    gfs2: switch to ->iterate_shared()
    f2fs: switch to ->iterate_shared()
    afs: switch to ->iterate_shared()
    befs: switch to ->iterate_shared()
    befs: constify stuff a bit
    isofs: switch to ->iterate_shared()
    get_acorn_filename(): deobfuscate a bit
    btrfs: switch to ->iterate_shared()
    logfs: no need to lock directory in lseek
    switch ecryptfs to ->iterate_shared
    9p: switch to ->iterate_shared()
    fat: switch to ->iterate_shared()
    romfs, squashfs: switch to ->iterate_shared()
    more trivial ->iterate_shared conversions
    ...

    Linus Torvalds
     

20 Apr, 2016

1 commit

  • You cannot allocate crypto tfm objects in NORECLAIM or NOFS contexts.
    The ecryptfs code currently does exactly that for the MD5 tfm.

    This patch fixes it by preallocating the MD5 tfm in a safe context.

    The MD5 tfm is also reentrant so this patch removes the superfluous
    cs_hash_tfm_mutex.

    Reported-by: Nicolas Boichat
    Signed-off-by: Herbert Xu

    Herbert Xu
     

11 Apr, 2016

1 commit


20 Mar, 2016

1 commit

  • Pull vfs updates from Al Viro:

    - Preparations of parallel lookups (the remaining main obstacle is the
    need to move security_d_instantiate(); once that becomes safe, the
    rest will be a matter of rather short series local to fs/*.c

    - preadv2/pwritev2 series from Christoph

    - assorted fixes

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (32 commits)
    splice: handle zero nr_pages in splice_to_pipe()
    vfs: show_vfsstat: do not ignore errors from show_devname method
    dcache.c: new helper: __d_add()
    don't bother with __d_instantiate(dentry, NULL)
    untangle fsnotify_d_instantiate() a bit
    uninline d_add()
    replace d_add_unique() with saner primitive
    quota: use lookup_one_len_unlocked()
    cifs_get_root(): use lookup_one_len_unlocked()
    nfs_lookup: don't bother with d_instantiate(dentry, NULL)
    kill dentry_unhash()
    ceph_fill_trace(): don't bother with d_instantiate(dn, NULL)
    autofs4: don't bother with d_instantiate(dentry, NULL) in ->lookup()
    configfs: move d_rehash() into configfs_create() for regular files
    ceph: don't bother with d_rehash() in splice_dentry()
    namei: teach lookup_slow() to skip revalidate
    namei: massage lookup_slow() to be usable by lookup_one_len_unlocked()
    lookup_one_len_unlocked(): use lookup_dcache()
    namei: simplify invalidation logics in lookup_dcache()
    namei: change calling conventions for lookup_{fast,slow} and follow_managed()
    ...

    Linus Torvalds
     

23 Feb, 2016

1 commit


27 Jan, 2016

1 commit


21 Oct, 2015

1 commit

  • Merge the type-specific data with the payload data into one four-word chunk
    as it seems pointless to keep them separate.

    Use user_key_payload() for accessing the payloads of overloaded
    user-defined keys.

    Signed-off-by: David Howells
    cc: linux-cifs@vger.kernel.org
    cc: ecryptfs@vger.kernel.org
    cc: linux-ext4@vger.kernel.org
    cc: linux-f2fs-devel@lists.sourceforge.net
    cc: linux-nfs@vger.kernel.org
    cc: ceph-devel@vger.kernel.org
    cc: linux-ima-devel@lists.sourceforge.net

    David Howells
     

25 Feb, 2015

1 commit

  • The patch 237fead61998: "[PATCH] ecryptfs: fs/Makefile and
    fs/Kconfig" from Oct 4, 2006, leads to the following static checker
    warning:

    fs/ecryptfs/crypto.c:846 ecryptfs_new_file_context()
    error: off-by-one overflow 'crypt_stat->cipher' size 32. rl = '0-32'

    There is a mismatch between the size of ecryptfs_crypt_stat.cipher
    and ecryptfs_mount_crypt_stat.global_default_cipher_name causing the
    copy of the cipher name to cause a off-by-one string copy error. This
    fix ensures the space reserved for this string is the same size including
    the trailing zero at the end throughout ecryptfs.

    This fix avoids increasing the size of ecryptfs_crypt_stat.cipher
    and also ecryptfs_parse_tag_70_packet_silly_stack.cipher_string and instead
    reduces the of ECRYPTFS_MAX_CIPHER_NAME_SIZE to 31 and includes the + 1 for
    the end of string terminator.

    NOTE: An overflow is not possible in practice since the value copied
    into global_default_cipher_name is validated by
    ecryptfs_code_for_cipher_string() at mount time. None of the allowed
    cipher strings are long enough to cause the potential buffer overflow
    fixed by this patch.

    Signed-off-by: Colin Ian King
    Reported-by: Dan Carpenter
    [tyhicks: Added the NOTE about the overflow not being triggerable]
    Signed-off-by: Tyler Hicks

    Colin Ian King
     

25 Oct, 2013

2 commits


29 Jun, 2013

1 commit


10 May, 2013

1 commit

  • Make the switch from the blkcipher kernel crypto interface to the
    ablkcipher interface.

    encrypt_scatterlist() and decrypt_scatterlist() now use the ablkcipher
    interface but, from the eCryptfs standpoint, still treat the crypto
    operation as a synchronous operation. They submit the async request and
    then wait until the operation is finished before they return. Most of
    the changes are contained inside those two functions.

    Despite waiting for the completion of the crypto operation, the
    ablkcipher interface provides performance increases in most cases when
    used on AES-NI capable hardware.

    Signed-off-by: Tyler Hicks
    Acked-by: Colin King
    Reviewed-by: Zeev Zilberman
    Cc: Dustin Kirkland
    Cc: Tim Chen
    Cc: Ying Huang
    Cc: Thieu Le
    Cc: Li Wang
    Cc: Jarkko Sakkinen

    Tyler Hicks
     

08 Mar, 2013

1 commit

  • Pull ecryptfs fixes from Tyler Hicks:
    "Minor code cleanups and new Kconfig option to disable /dev/ecryptfs

    The code cleanups fix up W=1 compiler warnings and some unnecessary
    checks. The new Kconfig option, defaulting to N, allows the rarely
    used eCryptfs kernel to userspace communication channel to be compiled
    out. This may be the first step in it being eventually removed."

    Hmm. I'm not sure whether these should be called "fixes", and it
    probably should have gone in the merge window. But I'll let it slide.

    * tag 'ecryptfs-3.9-rc2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs:
    eCryptfs: allow userspace messaging to be disabled
    eCryptfs: Fix redundant error check on ecryptfs_find_daemon_by_euid()
    ecryptfs: ecryptfs_msg_ctx_alloc_to_free(): remove kfree() redundant null check
    eCryptfs: decrypt_pki_encrypted_session_key(): remove kfree() redundant null check
    eCryptfs: remove unneeded checks in virt_to_scatterlist()
    eCryptfs: Fix -Wmissing-prototypes warnings
    eCryptfs: Fix -Wunused-but-set-variable warnings
    eCryptfs: initialize payload_len in keystore.c

    Linus Torvalds
     

04 Mar, 2013

1 commit

  • When the userspace messaging (for the less common case of userspace key
    wrap/unwrap via ecryptfsd) is not needed, allow eCryptfs to build with
    it removed. This saves on kernel code size and reduces potential attack
    surface by removing the /dev/ecryptfs node.

    Signed-off-by: Kees Cook
    Signed-off-by: Tyler Hicks

    Kees Cook
     

26 Feb, 2013

1 commit


03 Aug, 2012

1 commit

  • Pull ecryptfs fixes from Tyler Hicks:
    - Fixes a bug when the lower filesystem mount options include 'acl',
    but the eCryptfs mount options do not
    - Cleanups in the messaging code
    - Better handling of empty files in the lower filesystem to improve
    usability. Failed file creations are now cleaned up and empty lower
    files are converted into eCryptfs during open().
    - The write-through cache changes are being reverted due to bugs that
    are not easy to fix. Stability outweighs the performance
    enhancements here.
    - Improvement to the mount code to catch unsupported ciphers specified
    in the mount options

    * tag 'ecryptfs-3.6-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs:
    eCryptfs: check for eCryptfs cipher support at mount
    eCryptfs: Revert to a writethrough cache model
    eCryptfs: Initialize empty lower files when opening them
    eCryptfs: Unlink lower inode when ecryptfs_create() fails
    eCryptfs: Make all miscdev functions use daemon ptr in file private_data
    eCryptfs: Remove unused messaging declarations and function
    eCryptfs: Copy up POSIX ACL and read-only flags from lower mount

    Linus Torvalds
     

23 Jul, 2012

1 commit


09 Jul, 2012

3 commits

  • Historically, eCryptfs has only initialized lower files in the
    ecryptfs_create() path. Lower file initialization is the act of writing
    the cryptographic metadata from the inode's crypt_stat to the header of
    the file. The ecryptfs_open() path already expects that metadata to be
    in the header of the file.

    A number of users have reported empty lower files in beneath their
    eCryptfs mounts. Most of the causes for those empty files being left
    around have been addressed, but the presence of empty files causes
    problems due to the lack of proper cryptographic metadata.

    To transparently solve this problem, this patch initializes empty lower
    files in the ecryptfs_open() error path. If the metadata is unreadable
    due to the lower inode size being 0, plaintext passthrough support is
    not in use, and the metadata is stored in the header of the file (as
    opposed to the user.ecryptfs extended attribute), the lower file will be
    initialized.

    The number of nested conditionals in ecryptfs_open() was getting out of
    hand, so a helper function was created. To avoid the same nested
    conditional problem, the conditional logic was reversed inside of the
    helper function.

    https://launchpad.net/bugs/911507

    Signed-off-by: Tyler Hicks
    Cc: John Johansen
    Cc: Colin Ian King

    Tyler Hicks
     
  • 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: Tyler Hicks
    Cc: Sasha Levin

    Tyler Hicks
     
  • These are no longer needed.

    Signed-off-by: Tyler Hicks
    Cc: Sasha Levin

    Tyler Hicks
     

17 Feb, 2012

1 commit

  • statfs() calls on eCryptfs files returned the wrong filesystem type and,
    when using filename encryption, the wrong maximum filename length.

    If mount-wide filename encryption is enabled, the cipher block size and
    the lower filesystem's max filename length will determine the max
    eCryptfs filename length. Pre-tested, known good lengths are used when
    the lower filesystem's namelen is 255 and a cipher with 8 or 16 byte
    block sizes is used. In other, less common cases, we fall back to a safe
    rounded-down estimate when determining the eCryptfs namelen.

    https://launchpad.net/bugs/885744

    Signed-off-by: Tyler Hicks
    Reported-by: Kees Cook
    Reviewed-by: Kees Cook
    Reviewed-by: John Johansen

    Tyler Hicks
     

26 Jan, 2012

1 commit


24 Nov, 2011

1 commit

  • The file creation path prematurely called d_instantiate() and
    unlock_new_inode() before the eCryptfs inode info was fully
    allocated and initialized and before the eCryptfs metadata was written
    to the lower file.

    This could result in race conditions in subsequent file and inode
    operations leading to unexpected error conditions or a null pointer
    dereference while attempting to use the unallocated memory.

    https://launchpad.net/bugs/813146

    Signed-off-by: Tyler Hicks
    Cc: stable@kernel.org

    Tyler Hicks
     

01 Nov, 2011

1 commit

  • Standardize the style for compiler based printf format verification.
    Standardized the location of __printf too.

    Done via script and a little typing.

    $ grep -rPl --include=*.[ch] -w "__attribute__" * | \
    grep -vP "^(tools|scripts|include/linux/compiler-gcc.h)" | \
    xargs perl -n -i -e 'local $/; while (<>) { s/\b__attribute__\s*\(\s*\(\s*format\s*\(\s*printf\s*,\s*(.+)\s*,\s*(.+)\s*\)\s*\)\s*\)/__printf($1, $2)/g ; print; }'

    [akpm@linux-foundation.org: revert arch bits]
    Signed-off-by: Joe Perches
    Cc: "Kirill A. Shutemov"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Joe Perches
     

27 Jun, 2011

2 commits


30 May, 2011

5 commits

  • Now that ecryptfs_lookup_interpose() is no longer using
    ecryptfs_header_cache_2 to read in metadata, the kmem_cache can be
    removed and the ecryptfs_header_cache_1 kmem_cache can be renamed to
    ecryptfs_header_cache.

    Signed-off-by: Tyler Hicks

    Tyler Hicks
     
  • ecryptfs_lookup_interpose() has turned into spaghetti code over the
    years. This is an effort to clean it up.

    - Shorten overly descriptive variable names such as ecryptfs_dentry
    - Simplify gotos and error paths
    - Create helper function for reading plaintext i_size from metadata

    It also includes an optimization when reading i_size from the metadata.
    A complete page-sized kmem_cache_alloc() was being done to read in 16
    bytes of metadata. The buffer for that is now statically declared.

    Signed-off-by: Tyler Hicks

    Tyler Hicks
     
  • Only unlock and d_add() new inodes after the plaintext inode size has
    been read from the lower filesystem. This fixes a race condition that
    was sometimes seen during a multi-job kernel build in an eCryptfs mount.

    https://bugzilla.kernel.org/show_bug.cgi?id=36002

    Signed-off-by: Tyler Hicks
    Reported-by: David
    Tested-by: David

    Tyler Hicks
     
  • The eCryptfs inode get, initialization, and dentry interposition code
    has two separate paths. One is for when dentry interposition is needed
    after doing things like a mkdir in the lower filesystem and the other
    is needed after a lookup. Unlocking new inodes and doing a d_add() needs
    to happen at different times, depending on which type of dentry
    interposing is being done.

    This patch cleans up the inode get and initialization code paths and
    splits them up so that the locking and d_add() differences mentioned
    above can be handled appropriately in a later patch.

    Signed-off-by: Tyler Hicks
    Tested-by: David

    Tyler Hicks
     
  • These functions should live in inode.c since their focus is on inodes
    and they're primarily used by functions in inode.c.

    Also does a simple cleanup of ecryptfs_inode_test() and rolls
    ecryptfs_init_inode() into ecryptfs_inode_set().

    Signed-off-by: Tyler Hicks
    Tested-by: David

    Tyler Hicks
     

26 Apr, 2011

2 commits

  • When failing to read the lower file's crypto metadata during a lookup,
    eCryptfs must continue on without throwing an error. For example, there
    may be a plaintext file in the lower mount point that the user wants to
    delete through the eCryptfs mount.

    If an error is encountered while reading the metadata in lookup(), the
    eCryptfs inode's size could be incorrect. We must be sure to reread the
    plaintext inode size from the metadata when performing an open() or
    setattr(). The metadata is already being read in those paths, so this
    adds minimal performance overhead.

    This patch introduces a flag which will track whether or not the
    plaintext inode size has been read so that an incorrect i_size can be
    fixed in the open() or setattr() paths.

    https://bugs.launchpad.net/bugs/509180

    Cc:
    Signed-off-by: Tyler Hicks

    Tyler Hicks
     
  • For any given lower inode, eCryptfs keeps only one lower file open and
    multiplexes all eCryptfs file operations through that lower file. The
    lower file was considered "persistent" and stayed open from the first
    lookup through the lifetime of the inode.

    This patch keeps the notion of a single, per-inode lower file, but adds
    reference counting around the lower file so that it is closed when not
    currently in use. If the reference count is at 0 when an operation (such
    as open, create, etc.) needs to use the lower file, a new lower file is
    opened. Since the file is no longer persistent, all references to the
    term persistent file are changed to lower file.

    Locking is added around the sections of code that opens the lower file
    and assign the pointer in the inode info, as well as the code the fputs
    the lower file when all eCryptfs users are done with it.

    This patch is needed to fix issues, when mounted on top of the NFSv3
    client, where the lower file is left silly renamed until the eCryptfs
    inode is destroyed.

    Signed-off-by: Tyler Hicks

    Tyler Hicks
     

28 Mar, 2011

5 commits

  • Authentication tokens content may change if another requestor calls the
    update() method of the corresponding key. The new function
    ecryptfs_verify_auth_tok_from_key() retrieves the authentication token from
    the provided key and verifies if it is still valid before being used to
    encrypt or decrypt an eCryptfs file.

    Signed-off-by: Roberto Sassu
    [tyhicks: Minor formatting changes]
    Signed-off-by: Tyler Hicks

    Roberto Sassu
     
  • The size of the 'keysig' array is incremented of one byte in order to make
    room for the NULL character. The 'keysig' variable is used, in the function
    ecryptfs_generate_key_packet_set(), to find an authentication token with
    the given signature and is printed a debug message if it cannot be
    retrieved.

    Signed-off-by: Roberto Sassu
    Signed-off-by: Tyler Hicks

    Roberto Sassu
     
  • This patch removes the 'num_global_auth_toks' field of the
    ecryptfs_mount_crypt_stat structure, used to count the number of items in
    the 'global_auth_tok_list' list. This variable is not needed because there
    are no checks based upon it.

    Signed-off-by: Roberto Sassu
    Signed-off-by: Tyler Hicks

    Roberto Sassu
     
  • Change the write path to encrypt the data only when the page is written to
    disk in ecryptfs_writepage. Previously, ecryptfs encrypts the page in
    ecryptfs_write_end which means that if there are multiple write requests to
    the same page, ecryptfs ends up re-encrypting that page over and over again.
    This patch minimizes the number of encryptions needed.

    Signed-off-by: Thieu Le
    [tyhicks: Changed NULL .drop_inode sop pointer to generic_drop_inode]
    Signed-off-by: Tyler Hicks

    Thieu Le
     
  • Now that grow_file() is not called in the ecryptfs_create() path, the
    ECRYPTFS_NEW_FILE flag is no longer needed. It helped
    ecryptfs_readpage() know not to decrypt zeroes that were read from the
    lower file in the grow_file() path.

    Signed-off-by: Tyler Hicks

    Tyler Hicks