1. 03 Aug, 2018 1 commit
    • Eric Biggers's avatar
      fscrypt: use unbound workqueue for decryption · 63c7e58d
      Eric Biggers authored
      [ Upstream commit 36dd26e0 ]
      Improve fscrypt read performance by switching the decryption workqueue
      from bound to unbound.  With the bound workqueue, when multiple bios
      completed on the same CPU, they were decrypted on that same CPU.  But
      with the unbound queue, they are now decrypted in parallel on any CPU.
      Although fscrypt read performance can be tough to measure due to the
      many sources of variation, this change is most beneficial when
      decryption is slow, e.g. on CPUs without AES instructions.  For example,
      I timed tarring up encrypted directories on f2fs.  On x86 with AES-NI
      instructions disabled, the unbound workqueue improved performance by
      about 25-35%, using 1 to NUM_CPUs jobs with 4 or 8 CPUs available.  But
      with AES-NI enabled, performance was unchanged to within ~2%.
      I also did the same test on a quad-core ARM CPU using xts-speck128-neon
      encryption.  There performance was usually about 10% better with the
      unbound workqueue, bringing it closer to the unencrypted speed.
      The unbound workqueue may be worse in some cases due to worse locality,
      but I think it's still the better default.  dm-crypt uses an unbound
      workqueue by default too, so this change makes fscrypt match.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  2. 30 Nov, 2017 1 commit
    • Eric Biggers's avatar
      fscrypt: lock mutex before checking for bounce page pool · ddf1264e
      Eric Biggers authored
      commit a0b3bc85 upstream.
      fscrypt_initialize(), which allocates the global bounce page pool when
      an encrypted file is first accessed, uses "double-checked locking" to
      try to avoid locking fscrypt_init_mutex.  However, it doesn't use any
      memory barriers, so it's theoretically possible for a thread to observe
      a bounce page pool which has not been fully initialized.  This is a
      classic bug with "double-checked locking".
      While "only a theoretical issue" in the latest kernel, in pre-4.8
      kernels the pointer that was checked was not even the last to be
      initialized, so it was easily possible for a crash (NULL pointer
      dereference) to happen.  This was changed only incidentally by the large
      refactor to use fs/crypto/.
      Solve both problems in a trivial way that can easily be backported: just
      always take the mutex.  It's theoretically less efficient, but it
      shouldn't be noticeable in practice as the mutex is only acquired very
      briefly once per encrypted file.
      Later I'd like to make this use a helper macro like DO_ONCE().  However,
      DO_ONCE() runs in atomic context, so we'd need to add a new macro that
      allows blocking.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  3. 02 Nov, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      How this work was done:
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
      All documentation files were explicitly excluded.
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
         For non */uapi/* files that summary was:
         SPDX license identifier                            # files
         GPL-2.0                                              11139
         and resulted in the first patch in this series.
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
         SPDX license identifier                            # files
         GPL-2.0 WITH Linux-syscall-note                        930
         and resulted in the second patch in this series.
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
         SPDX license identifier                            # files
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
         and that resulted in the third patch in this series.
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: default avatarKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: default avatarPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  4. 12 Oct, 2017 1 commit
  5. 23 Aug, 2017 1 commit
    • Christoph Hellwig's avatar
      block: replace bi_bdev with a gendisk pointer and partitions index · 74d46992
      Christoph Hellwig authored
      This way we don't need a block_device structure to submit I/O.  The
      block_device has different life time rules from the gendisk and
      request_queue and is usually only available when the block device node
      is open.  Other callers need to explicitly create one (e.g. the lightnvm
      passthrough code, or the new nvme multipathing code).
      For the actual I/O path all that we need is the gendisk, which exists
      once per block device.  But given that the block layer also does
      partition remapping we additionally need a partition index, which is
      used for said remapping in generic_make_request.
      Note that all the block drivers generally want request_queue or
      sometimes the gendisk, so this removes a layer of indirection all
      over the stack.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
  6. 06 Jul, 2017 1 commit
    • Tahsin Erdogan's avatar
      ext4: fix __ext4_new_inode() journal credits calculation · af65207c
      Tahsin Erdogan authored
      ea_inode feature allows creating extended attributes that are up to
      64k in size. Update __ext4_new_inode() to pick increased credit limits.
      To avoid overallocating too many journal credits, update
      __ext4_xattr_set_credits() to make a distinction between xattr create
      vs update. This helps __ext4_new_inode() because all attributes are
      known to be new, so we can save credits that are normally needed to
      delete old values.
      Also, have fscrypt specify its maximum context size so that we don't
      end up allocating credits for 64k size.
      Signed-off-by: default avatarTahsin Erdogan <tahsin@google.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
  7. 24 Jun, 2017 1 commit
    • Daniel Walter's avatar
      fscrypt: add support for AES-128-CBC · b7e7cf7a
      Daniel Walter authored
      fscrypt provides facilities to use different encryption algorithms which
      are selectable by userspace when setting the encryption policy. Currently,
      only AES-256-XTS for file contents and AES-256-CBC-CTS for file names are
      implemented. This is a clear case of kernel offers the mechanism and
      userspace selects a policy. Similar to what dm-crypt and ecryptfs have.
      This patch adds support for using AES-128-CBC for file contents and
      AES-128-CBC-CTS for file name encryption. To mitigate watermarking
      attacks, IVs are generated using the ESSIV algorithm. While AES-CBC is
      actually slightly less secure than AES-XTS from a security point of view,
      there is more widespread hardware support. Using AES-CBC gives us the
      acceptable performance while still providing a moderate level of security
      for persistent storage.
      Especially low-powered embedded devices with crypto accelerators such as
      CAAM or CESA often only support AES-CBC. Since using AES-CBC over AES-XTS
      is basically thought of a last resort, we use AES-128-CBC over AES-256-CBC
      since it has less encryption rounds and yields noticeable better
      performance starting from a file size of just a few kB.
      Signed-off-by: default avatarDaniel Walter <dwalter@sigma-star.at>
      [david@sigma-star.at: addressed review comments]
      Signed-off-by: David Gstir's avatarDavid Gstir <david@sigma-star.at>
      Reviewed-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
  8. 23 Jun, 2017 1 commit
  9. 09 Jun, 2017 1 commit
  10. 04 May, 2017 3 commits
    • Eric Biggers's avatar
      fscrypt: introduce helper function for filename matching · 17159420
      Eric Biggers authored
      Introduce a helper function fscrypt_match_name() which tests whether a
      fscrypt_name matches a directory entry.  Also clean up the magic numbers
      and document things properly.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
    • Eric Biggers's avatar
      fscrypt: avoid collisions when presenting long encrypted filenames · 6b06cdee
      Eric Biggers authored
      When accessing an encrypted directory without the key, userspace must
      operate on filenames derived from the ciphertext names, which contain
      arbitrary bytes.  Since we must support filenames as long as NAME_MAX,
      we can't always just base64-encode the ciphertext, since that may make
      it too long.  Currently, this is solved by presenting long names in an
      abbreviated form containing any needed filesystem-specific hashes (e.g.
      to identify a directory block), then the last 16 bytes of ciphertext.
      This needs to be sufficient to identify the actual name on lookup.
      However, there is a bug.  It seems to have been assumed that due to the
      use of a CBC (ciphertext block chaining)-based encryption mode, the last
      16 bytes (i.e. the AES block size) of ciphertext would depend on the
      full plaintext, preventing collisions.  However, we actually use CBC
      with ciphertext stealing (CTS), which handles the last two blocks
      specially, causing them to appear "flipped".  Thus, it's actually the
      second-to-last block which depends on the full plaintext.
      This caused long filenames that differ only near the end of their
      plaintexts to, when observed without the key, point to the wrong inode
      and be undeletable.  For example, with ext4:
          # echo pass | e4crypt add_key -p 16 edir/
          # seq -f "edir/abcdefghijklmnopqrstuvwxyz012345%.0f" 100000 | xargs touch
          # find edir/ -type f | xargs stat -c %i | sort | uniq | wc -l
          # sync
          # echo 3 > /proc/sys/vm/drop_caches
          # keyctl new_session
          # find edir/ -type f | xargs stat -c %i | sort | uniq | wc -l
          # rm -rf edir/
          rm: cannot remove 'edir/_A7nNFi3rhkEQlJ6P,hdzluhODKOeWx5V': Structure needs cleaning
      To fix this, when presenting long encrypted filenames, encode the
      second-to-last block of ciphertext rather than the last 16 bytes.
      Although it would be nice to solve this without depending on a specific
      encryption mode, that would mean doing a cryptographic hash like SHA-256
      which would be much less efficient.  This way is sufficient for now, and
      it's still compatible with encryption modes like HEH which are strong
      pseudorandom permutations.  Also, changing the presented names is still
      allowed at any time because they are only provided to allow applications
      to do things like delete encrypted directories.  They're not designed to
      be used to persistently identify files --- which would be hard to do
      anyway, given that they're encrypted after all.
      For ease of backports, this patch only makes the minimal fix to both
      ext4 and f2fs.  It leaves ubifs as-is, since ubifs doesn't compare the
      ciphertext block yet.  Follow-on patches will clean things up properly
      and make the filesystems use a shared helper function.
      Fixes: 5de0b4d0 ("ext4 crypto: simplify and speed up filename encryption")
      Reported-by: default avatarGwendal Grignou <gwendal@chromium.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
    • Eric Biggers's avatar
      fscrypt: fix context consistency check when key(s) unavailable · 272f98f6
      Eric Biggers authored
      To mitigate some types of offline attacks, filesystem encryption is
      designed to enforce that all files in an encrypted directory tree use
      the same encryption policy (i.e. the same encryption context excluding
      the nonce).  However, the fscrypt_has_permitted_context() function which
      enforces this relies on comparing struct fscrypt_info's, which are only
      available when we have the encryption keys.  This can cause two
      incorrect behaviors:
      1. If we have the parent directory's key but not the child's key, or
         vice versa, then fscrypt_has_permitted_context() returned false,
         causing applications to see EPERM or ENOKEY.  This is incorrect if
         the encryption contexts are in fact consistent.  Although we'd
         normally have either both keys or neither key in that case since the
         master_key_descriptors would be the same, this is not guaranteed
         because keys can be added or removed from keyrings at any time.
      2. If we have neither the parent's key nor the child's key, then
         fscrypt_has_permitted_context() returned true, causing applications
         to see no error (or else an error for some other reason).  This is
         incorrect if the encryption contexts are in fact inconsistent, since
         in that case we should deny access.
      To fix this, retrieve and compare the fscrypt_contexts if we are unable
      to set up both fscrypt_infos.
      While this slightly hurts performance when accessing an encrypted
      directory tree without the key, this isn't a case we really need to be
      optimizing for; access *with* the key is much more important.
      Furthermore, the performance hit is barely noticeable given that we are
      already retrieving the fscrypt_context and doing two keyring searches in
      fscrypt_get_encryption_info().  If we ever actually wanted to optimize
      this case we might start by caching the fscrypt_contexts.
      Cc: stable@vger.kernel.org # 4.0+
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
  11. 30 Apr, 2017 2 commits
    • Joe Richey's avatar
      fscrypt: Move key structure and constants to uapi · 9c8268de
      Joe Richey authored
      This commit exposes the necessary constants and structures for a
      userspace program to pass filesystem encryption keys into the keyring.
      The fscrypt_key structure was already part of the kernel ABI, this
      change just makes it so programs no longer have to redeclare these
      structures (like e4crypt in e2fsprogs currently does).
      Note that we do not expose the other FS_*_KEY_SIZE constants as they are
      not necessary. Only XTS is supported for contents_encryption_mode, so
      currently FS_MAX_KEY_SIZE bytes of key material must always be passed to
      the kernel.
      This commit also removes __packed from fscrypt_key as it does not
      contain any implicit padding and does not refer to an on-disk structure.
      Signed-off-by: default avatarJoe Richey <joerichey@google.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
    • Eric Biggers's avatar
      fscrypt: remove unnecessary checks for NULL operations · cd39e4ba
      Eric Biggers authored
      The functions in fs/crypto/*.c are only called by filesystems configured
      with encryption support.  Since the ->get_context(), ->set_context(),
      and ->empty_dir() operations are always provided in that case (and must
      be, otherwise there would be no way to get/set encryption policies, or
      in the case of ->get_context() even access encrypted files at all),
      there is no need to check for these operations being NULL and we can
      remove these unneeded checks.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Reviewed-by: Richard Weinberger's avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
  12. 15 Mar, 2017 2 commits
    • Eric Biggers's avatar
      fscrypt: eliminate ->prepare_context() operation · 94840e3c
      Eric Biggers authored
      The only use of the ->prepare_context() fscrypt operation was to allow
      ext4 to evict inline data from the inode before ->set_context().
      However, there is no reason why this cannot be done as simply the first
      step in ->set_context(), and in fact it makes more sense to do it that
      way because then the policy modes and flags get validated before any
      real work is done.  Therefore, merge ext4_prepare_context() into
      ext4_set_context(), and remove ->prepare_context().
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
    • Eric Biggers's avatar
      fscrypt: remove broken support for detecting keyring key revocation · 1b53cf98
      Eric Biggers authored
      Filesystem encryption ostensibly supported revoking a keyring key that
      had been used to "unlock" encrypted files, causing those files to become
      "locked" again.  This was, however, buggy for several reasons, the most
      severe of which was that when key revocation happened to be detected for
      an inode, its fscrypt_info was immediately freed, even while other
      threads could be using it for encryption or decryption concurrently.
      This could be exploited to crash the kernel or worse.
      This patch fixes the use-after-free by removing the code which detects
      the keyring key having been revoked, invalidated, or expired.  Instead,
      an encrypted inode that is "unlocked" now simply remains unlocked until
      it is evicted from memory.  Note that this is no worse than the case for
      block device-level encryption, e.g. dm-crypt, and it still remains
      possible for a privileged user to evict unused pages, inodes, and
      dentries by running 'sync; echo 3 > /proc/sys/vm/drop_caches', or by
      simply unmounting the filesystem.  In fact, one of those actions was
      already needed anyway for key revocation to work even somewhat sanely.
      This change is not expected to break any applications.
      In the future I'd like to implement a real API for fscrypt key
      revocation that interacts sanely with ongoing filesystem operations ---
      waiting for existing operations to complete and blocking new operations,
      and invalidating and sanitizing key material and plaintext from the VFS
      caches.  But this is a hard problem, and for now this bug must be fixed.
      This bug affected almost all versions of ext4, f2fs, and ubifs
      encryption, and it was potentially reachable in any kernel configured
      with encryption support (CONFIG_EXT4_ENCRYPTION=y,
      CONFIG_UBIFS_FS_ENCRYPTION=y).  Note that older kernels did not use the
      shared fs/crypto/ code, but due to the potential security implications
      of this bug, it may still be worthwhile to backport this fix to them.
      Fixes: b7236e21 ("ext4 crypto: reorganize how we store keys in the inode")
      Cc: stable@vger.kernel.org # v4.2+
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Acked-by: default avatarMichael Halcrow <mhalcrow@google.com>
  13. 01 Mar, 2017 1 commit
    • David Howells's avatar
      KEYS: Differentiate uses of rcu_dereference_key() and user_key_payload() · 0837e49a
      David Howells authored
      rcu_dereference_key() and user_key_payload() are currently being used in
      two different, incompatible ways:
       (1) As a wrapper to rcu_dereference() - when only the RCU read lock used
           to protect the key.
       (2) As a wrapper to rcu_dereference_protected() - when the key semaphor is
           used to protect the key and the may be being modified.
      Fix this by splitting both of the key wrappers to produce:
       (1) RCU accessors for keys when caller has the key semaphore locked:
       (2) RCU accessors for keys when caller holds the RCU read lock:
      This should fix following warning in the NFS idmapper
        [ INFO: suspicious RCU usage. ]
        4.10.0 #1 Tainted: G        W
        ./include/keys/user-type.h:53 suspicious rcu_dereference_protected() usage!
        other info that might help us debug this:
        rcu_scheduler_active = 2, debug_locks = 0
        1 lock held by mount.nfs/5987:
          #0:  (rcu_read_lock){......}, at: [<d000000002527abc>] nfs_idmap_get_key+0x15c/0x420 [nfsv4]
        stack backtrace:
        CPU: 1 PID: 5987 Comm: mount.nfs Tainted: G        W       4.10.0 #1
        Call Trace:
          dump_stack+0xe8/0x154 (unreliable)
          nfs_idmap_get_key+0x380/0x420 [nfsv4]
          nfs_map_name_to_uid+0x2a0/0x3b0 [nfsv4]
          decode_getfattr_attrs+0xfac/0x16b0 [nfsv4]
          decode_getfattr_generic.constprop.106+0xbc/0x150 [nfsv4]
          nfs4_xdr_dec_lookup_root+0xac/0xb0 [nfsv4]
          rpcauth_unwrap_resp+0xe8/0x140 [sunrpc]
          call_decode+0x29c/0x910 [sunrpc]
          __rpc_execute+0x140/0x8f0 [sunrpc]
          rpc_run_task+0x170/0x200 [sunrpc]
          nfs4_call_sync_sequence+0x68/0xa0 [nfsv4]
          _nfs4_lookup_root.isra.44+0xd0/0xf0 [nfsv4]
          nfs4_lookup_root+0xe0/0x350 [nfsv4]
          nfs4_lookup_root_sec+0x70/0xa0 [nfsv4]
          nfs4_find_root_sec+0xc4/0x100 [nfsv4]
          nfs4_proc_get_rootfh+0x5c/0xf0 [nfsv4]
          nfs4_get_rootfh+0x6c/0x190 [nfsv4]
          nfs4_server_common_setup+0xc4/0x260 [nfsv4]
          nfs4_create_server+0x278/0x3c0 [nfsv4]
          nfs4_remote_mount+0x50/0xb0 [nfsv4]
          nfs_do_root_mount+0xb0/0x140 [nfsv4]
          nfs4_try_mount+0x60/0x100 [nfsv4]
          nfs_fs_mount+0x5ec/0xda0 [nfs]
      Reported-by: default avatarJan Stancek <jstancek@redhat.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Tested-by: default avatarJan Stancek <jstancek@redhat.com>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
  14. 07 Feb, 2017 3 commits
  15. 08 Jan, 2017 1 commit
  16. 02 Jan, 2017 1 commit
    • Theodore Ts'o's avatar
      fscrypt: make test_dummy_encryption require a keyring key · 5bbdcbbb
      Theodore Ts'o authored
      Currently, the test_dummy_encryption ext4 mount option, which exists
      only to test encrypted I/O paths with xfstests, overrides all
      per-inode encryption keys with a fixed key.
      This change minimizes test_dummy_encryption-specific code path changes
      by supplying a fake context for directories which are not encrypted
      for use when creating new directories, files, or symlinks.  This
      allows us to properly exercise the keyring lookup, derivation, and
      context inheritance code paths.
      Before mounting a file system using test_dummy_encryption, userspace
      must execute the following shell commands:
          raw="$(printf ""\\\\x%02x"" $(seq 0 63))"
          if lscpu | grep "Byte Order" | grep -q Little ; then
          keyctl new_session
          echo -n -e "${key}" | keyctl padd logon fscrypt:4242424242424242 @s
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
  17. 01 Jan, 2017 1 commit
  18. 31 Dec, 2016 6 commits
    • Eric Biggers's avatar
      fscrypt: pass up error codes from ->get_context() · efee590e
      Eric Biggers authored
      It was possible for the ->get_context() operation to fail with a
      specific error code, which was then not returned to the caller of
      to pass through these error codes.  Also reorganize the code so that
      ->get_context() only needs to be called one time when setting an
      encryption policy, and handle contexts of unrecognized sizes more
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
    • Eric Biggers's avatar
      fscrypt: remove user-triggerable warning messages · 868e1bc6
      Eric Biggers authored
      Several warning messages were not rate limited and were user-triggerable
      from FS_IOC_SET_ENCRYPTION_POLICY.  These shouldn't really have been
      there in the first place, but either way they aren't as useful now that
      the error codes have been improved.  So just remove them.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
    • Eric Biggers's avatar
      fscrypt: use EEXIST when file already uses different policy · 8488cd96
      Eric Biggers authored
      As part of an effort to clean up fscrypt-related error codes, make
      FS_IOC_SET_ENCRYPTION_POLICY fail with EEXIST when the file already uses
      a different encryption policy.  This is more descriptive than EINVAL,
      which was ambiguous with some of the other error cases.
      I am not aware of any users who might be relying on the previous error
      code of EINVAL, which was never documented anywhere.
      This failure case will be exercised by an xfstest.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
    • Eric Biggers's avatar
      fscrypt: use ENOTDIR when setting encryption policy on nondirectory · dffd0cfa
      Eric Biggers authored
      As part of an effort to clean up fscrypt-related error codes, make
      FS_IOC_SET_ENCRYPTION_POLICY fail with ENOTDIR when the file descriptor
      does not refer to a directory.  This is more descriptive than EINVAL,
      which was ambiguous with some of the other error cases.
      I am not aware of any users who might be relying on the previous error
      code of EINVAL, which was never documented anywhere, and in some buggy
      kernels did not exist at all as the S_ISDIR() check was missing.
      This failure case will be exercised by an xfstest.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
    • Eric Biggers's avatar
      fscrypt: use ENOKEY when file cannot be created w/o key · 54475f53
      Eric Biggers authored
      As part of an effort to clean up fscrypt-related error codes, make
      attempting to create a file in an encrypted directory that hasn't been
      "unlocked" fail with ENOKEY.  Previously, several error codes were used
      for this case, including ENOENT, EACCES, and EPERM, and they were not
      consistent between and within filesystems.  ENOKEY is a better choice
      because it expresses that the failure is due to lacking the encryption
      key.  It also matches the error code returned when trying to open an
      encrypted regular file without the key.
      I am not aware of any users who might be relying on the previous
      inconsistent error codes, which were never documented anywhere.
      This failure case will be exercised by an xfstest.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
    • Eric Biggers's avatar
      fscrypt: fix renaming and linking special files · 42d97eb0
      Eric Biggers authored
      Attempting to link a device node, named pipe, or socket file into an
      encrypted directory through rename(2) or link(2) always failed with
      EPERM.  This happened because fscrypt_has_permitted_context() saw that
      the file was unencrypted and forbid creating the link.  This behavior
      was unexpected because such files are never encrypted; only regular
      files, directories, and symlinks can be encrypted.
      To fix this, make fscrypt_has_permitted_context() always return true on
      special files.
      This will be covered by a test in my encryption xfstests patchset.
      Fixes: 9bd8212f ("ext4 crypto: add encryption policy and password salt support")
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Reviewed-by: Richard Weinberger's avatarRichard Weinberger <richard@nod.at>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
  19. 28 Dec, 2016 1 commit
    • Theodore Ts'o's avatar
      fscrypt: fix the test_dummy_encryption mount option · fe4f6c80
      Theodore Ts'o authored
      Commit f1c131b4: "crypto: xts - Convert to skcipher" now fails
      the setkey operation if the AES key is the same as the tweak key.
      Previously this check was only done if FIPS mode is enabled.  Now this
      check is also done if weak key checking was requested.  This is
      reasonable, but since we were using the dummy key which was a constant
      series of 0x42 bytes, it now caused dummy encrpyption test mode to
      Fix this by using 0x42... and 0x24... for the two keys, so they are
      Fixes: f1c131b4
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
  20. 11 Dec, 2016 10 commits