1. 08 Feb, 2017 1 commit
  2. 07 Feb, 2017 3 commits
  3. 08 Jan, 2017 3 commits
  4. 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:
      
          mode='\x00\x00\x00\x00'
          raw="$(printf ""\\\\x%02x"" $(seq 0 63))"
          if lscpu | grep "Byte Order" | grep -q Little ; then
              size='\x40\x00\x00\x00'
          else
              size='\x00\x00\x00\x40'
          fi
          key="${mode}${raw}${size}"
          keyctl new_session
          echo -n -e "${key}" | keyctl padd logon fscrypt:4242424242424242 @s
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      5bbdcbbb
  5. 01 Jan, 2017 1 commit
  6. 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
      FS_IOC_SET_ENCRYPTION_POLICY or FS_IOC_GET_ENCRYPTION_POLICY.  Make sure
      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
      appropriately.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      efee590e
    • 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>
      868e1bc6
    • 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>
      8488cd96
    • 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>
      dffd0cfa
    • 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>
      54475f53
    • 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: default avatarRichard Weinberger <richard@nod.at>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      42d97eb0
  7. 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
      fail.
      
      Fix this by using 0x42... and 0x24... for the two keys, so they are
      different.
      
      Fixes: f1c131b4
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      fe4f6c80
  8. 26 Dec, 2016 2 commits
    • Linus Torvalds's avatar
      Linux 4.10-rc1 · 7ce7d89f
      Linus Torvalds authored
      7ce7d89f
    • Larry Finger's avatar
      powerpc: Fix build warning on 32-bit PPC · 8ae679c4
      Larry Finger authored
      I am getting the following warning when I build kernel 4.9-git on my
      PowerBook G4 with a 32-bit PPC processor:
      
          AS      arch/powerpc/kernel/misc_32.o
        arch/powerpc/kernel/misc_32.S:299:7: warning: "CONFIG_FSL_BOOKE" is not defined [-Wundef]
      
      This problem is evident after commit 989cea5c ("kbuild: prevent
      lib-ksyms.o rebuilds"); however, this change in kbuild only exposes an
      error that has been in the code since 2005 when this source file was
      created.  That was with commit 9994a338 ("powerpc: Introduce
      entry_{32,64}.S, misc_{32,64}.S, systbl.S").
      
      The offending line does not make a lot of sense.  This error does not
      seem to cause any errors in the executable, thus I am not recommending
      that it be applied to any stable versions.
      
      Thanks to Nicholas Piggin for suggesting this solution.
      
      Fixes: 9994a338 ("powerpc: Introduce entry_{32,64}.S, misc_{32,64}.S, systbl.S")
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8ae679c4
  9. 25 Dec, 2016 22 commits