1. 19 10月, 2017 1 次提交
  2. 24 6月, 2017 1 次提交
    • D
      fscrypt: add support for AES-128-CBC · b7e7cf7a
      Daniel Walter 提交于
      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: NDaniel Walter <dwalter@sigma-star.at>
      [david@sigma-star.at: addressed review comments]
      Signed-off-by: NDavid Gstir <david@sigma-star.at>
      Reviewed-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      b7e7cf7a
  3. 16 3月, 2017 1 次提交
    • E
      fscrypt: remove broken support for detecting keyring key revocation · 1b53cf98
      Eric Biggers 提交于
      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_EXT4_FS_ENCRYPTION=y, CONFIG_F2FS_FS_ENCRYPTION=y, or
      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: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Acked-by: NMichael Halcrow <mhalcrow@google.com>
      1b53cf98
  4. 02 1月, 2017 1 次提交
  5. 12 12月, 2016 8 次提交
  6. 14 11月, 2016 5 次提交
  7. 13 10月, 2016 1 次提交
    • E
      fscrypto: make XTS tweak initialization endian-independent · fb445437
      Eric Biggers 提交于
      The XTS tweak (or IV) was initialized differently on little endian and
      big endian systems.  Because the ciphertext depends on the XTS tweak, it
      was not possible to use an encrypted filesystem created by a little
      endian system on a big endian system and vice versa, even if they shared
      the same PAGE_SIZE.  Fix this by always using little endian.
      
      This will break hypothetical big endian users of ext4 or f2fs
      encryption.  However, all users we are aware of are little endian, and
      it's believed that "real" big endian users are unlikely to exist yet.
      So this might as well be fixed now before it's too late.
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      fb445437
  8. 16 9月, 2016 2 次提交
  9. 08 6月, 2016 2 次提交
  10. 13 4月, 2016 3 次提交
  11. 05 4月, 2016 1 次提交
    • K
      mm, fs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros · 09cbfeaf
      Kirill A. Shutemov 提交于
      PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} macros were introduced *long* time
      ago with promise that one day it will be possible to implement page
      cache with bigger chunks than PAGE_SIZE.
      
      This promise never materialized.  And unlikely will.
      
      We have many places where PAGE_CACHE_SIZE assumed to be equal to
      PAGE_SIZE.  And it's constant source of confusion on whether
      PAGE_CACHE_* or PAGE_* constant should be used in a particular case,
      especially on the border between fs and mm.
      
      Global switching to PAGE_CACHE_SIZE != PAGE_SIZE would cause to much
      breakage to be doable.
      
      Let's stop pretending that pages in page cache are special.  They are
      not.
      
      The changes are pretty straight-forward:
      
       - <foo> << (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;
      
       - <foo> >> (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;
      
       - PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} -> PAGE_{SIZE,SHIFT,MASK,ALIGN};
      
       - page_cache_get() -> get_page();
      
       - page_cache_release() -> put_page();
      
      This patch contains automated changes generated with coccinelle using
      script below.  For some reason, coccinelle doesn't patch header files.
      I've called spatch for them manually.
      
      The only adjustment after coccinelle is revert of changes to
      PAGE_CAHCE_ALIGN definition: we are going to drop it later.
      
      There are few places in the code where coccinelle didn't reach.  I'll
      fix them manually in a separate patch.  Comments and documentation also
      will be addressed with the separate patch.
      
      virtual patch
      
      @@
      expression E;
      @@
      - E << (PAGE_CACHE_SHIFT - PAGE_SHIFT)
      + E
      
      @@
      expression E;
      @@
      - E >> (PAGE_CACHE_SHIFT - PAGE_SHIFT)
      + E
      
      @@
      @@
      - PAGE_CACHE_SHIFT
      + PAGE_SHIFT
      
      @@
      @@
      - PAGE_CACHE_SIZE
      + PAGE_SIZE
      
      @@
      @@
      - PAGE_CACHE_MASK
      + PAGE_MASK
      
      @@
      expression E;
      @@
      - PAGE_CACHE_ALIGN(E)
      + PAGE_ALIGN(E)
      
      @@
      expression E;
      @@
      - page_cache_get(E)
      + get_page(E)
      
      @@
      expression E;
      @@
      - page_cache_release(E)
      + put_page(E)
      Signed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      09cbfeaf
  12. 27 3月, 2016 1 次提交
    • L
      f2fs/crypto: fix xts_tweak initialization · 02fc59a0
      Linus Torvalds 提交于
      Commit 0b81d077 ("fs crypto: move per-file encryption from f2fs
      tree to fs/crypto") moved the f2fs crypto files to fs/crypto/ and
      renamed the symbol prefixes from "f2fs_" to "fscrypt_" (and from "F2FS_"
      to just "FS" for preprocessor symbols).
      
      Because of the symbol renaming, it's a bit hard to see it as a file
      move: use
      
          git show -M30 0b81d077
      
      to lower the rename detection to just 30% similarity and make git show
      the files as renamed (the header file won't be shown as a rename even
      then - since all it contains is symbol definitions, it looks almost
      completely different).
      
      Even with the renames showing as renames, the diffs are not all that
      easy to read, since so much is just the renames.  But Eric Biggers
      noticed that it's not just all renames: the initialization of the
      xts_tweak had been broken too, using the inode number rather than the
      page offset.
      
      That's not right - it makes the xfs_tweak the same for all pages of each
      inode.  It _might_ make sense to make the xfs_tweak contain both the
      offset _and_ the inode number, but not just the inode number.
      Reported-by: NEric Biggers <ebiggers3@gmail.com>
      Cc: Jaegeuk Kim <jaegeuk@kernel.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      02fc59a0
  13. 18 3月, 2016 1 次提交
    • J
      fs crypto: move per-file encryption from f2fs tree to fs/crypto · 0b81d077
      Jaegeuk Kim 提交于
      This patch adds the renamed functions moved from the f2fs crypto files.
      
      1. definitions for per-file encryption used by ext4 and f2fs.
      
      2. crypto.c for encrypt/decrypt functions
       a. IO preparation:
        - fscrypt_get_ctx / fscrypt_release_ctx
       b. before IOs:
        - fscrypt_encrypt_page
        - fscrypt_decrypt_page
        - fscrypt_zeroout_range
       c. after IOs:
        - fscrypt_decrypt_bio_pages
        - fscrypt_pullback_bio_page
        - fscrypt_restore_control_page
      
      3. policy.c supporting context management.
       a. For ioctls:
        - fscrypt_process_policy
        - fscrypt_get_policy
       b. For context permission
        - fscrypt_has_permitted_context
        - fscrypt_inherit_context
      
      4. keyinfo.c to handle permissions
        - fscrypt_get_encryption_info
        - fscrypt_free_encryption_info
      
      5. fname.c to support filename encryption
       a. general wrapper functions
        - fscrypt_fname_disk_to_usr
        - fscrypt_fname_usr_to_disk
        - fscrypt_setup_filename
        - fscrypt_free_filename
      
       b. specific filename handling functions
        - fscrypt_fname_alloc_buffer
        - fscrypt_fname_free_buffer
      
      6. Makefile and Kconfig
      
      Cc: Al Viro <viro@ftp.linux.org.uk>
      Signed-off-by: NMichael Halcrow <mhalcrow@google.com>
      Signed-off-by: NIldar Muslukhov <ildarm@google.com>
      Signed-off-by: NUday Savagaonkar <savagaon@google.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      0b81d077