Skip to content

L
linux
Switch branch/tag
  1. 13 Aug, 2019 10 commits
    • Eric Biggers's avatar
      fscrypt: add ->ci_inode to fscrypt_info · 59dc6a8e
      Eric Biggers authored 
      Add an inode back-pointer to 'struct fscrypt_info', such that
inode->i_crypt_info->ci_inode == inode.

This will be useful for:

1. Evicting the inodes when a fscrypt key is removed, since we'll track
   the inodes using a given key by linking their fscrypt_infos together,
   rather than the inodes directly.  This avoids bloating 'struct inode'
   with a new list_head.

2. Simplifying the per-file key setup, since the inode pointer won't
   have to be passed around everywhere just in case something goes wrong
   and it's needed for fscrypt_warn().
Reviewed-by: default avatarTheodore Ts'o <tytso@mit.edu>
Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      59dc6a8e
    • Eric Biggers's avatar
      fscrypt: use FSCRYPT_* definitions, not FS_* · 3b6df59b
      Eric Biggers authored 
      Update fs/crypto/ to use the new names for the UAPI constants rather
than the old names, then make the old definitions conditional on
!__KERNEL__.
Reviewed-by: default avatarTheodore Ts'o <tytso@mit.edu>
Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      3b6df59b
    • Eric Biggers's avatar
      fscrypt: use FSCRYPT_ prefix for uapi constants · 2336d0de
      Eric Biggers authored 
      Prefix all filesystem encryption UAPI constants except the ioctl numbers
with "FSCRYPT_" rather than with "FS_".  This namespaces the constants
more appropriately and makes it clear that they are related specifically
to the filesystem encryption feature, and to the 'fscrypt_*' structures.
With some of the old names like "FS_POLICY_FLAGS_VALID", it was not
immediately clear that the constant had anything to do with encryption.

This is also useful because we'll be adding more encryption-related
constants, e.g. for the policy version, and we'd otherwise have to
choose whether to use unclear names like FS_POLICY_V1 or inconsistent
names like FS_ENCRYPTION_POLICY_V1.

For source compatibility with existing userspace programs, keep the old
names defined as aliases to the new names.

Finally, as long as new names are being defined anyway, I skipped
defining new names for the fscrypt mode numbers that aren't actually
used: INVALID (0), AES_256_GCM (2), AES_256_CBC (3), SPECK128_256_XTS
(7), and SPECK128_256_CTS (8).
Reviewed-by: default avatarTheodore Ts'o <tytso@mit.edu>
Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      2336d0de
    • Eric Biggers's avatar
      fs, fscrypt: move uapi definitions to new header <linux/fscrypt.h> · 7af0ab0d
      Eric Biggers authored 
      More fscrypt definitions are being added, and we shouldn't use a
disproportionate amount of space in <linux/fs.h> for fscrypt stuff.
So move the fscrypt definitions to a new header <linux/fscrypt.h>.

For source compatibility with existing userspace programs, <linux/fs.h>
still includes the new header.
Reviewed-by: default avatarTheodore Ts'o <tytso@mit.edu>
Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      7af0ab0d
    • Eric Biggers's avatar
      fscrypt: use ENOPKG when crypto API support missing · 29a98c1c
      Eric Biggers authored 
      Return ENOPKG rather than ENOENT when trying to open a file that's
encrypted using algorithms not available in the kernel's crypto API.

This avoids an ambiguity, since ENOENT is also returned when the file
doesn't exist.

Note: this is the same approach I'm taking for fs-verity.
Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      29a98c1c
    • Eric Biggers's avatar
      fscrypt: improve warnings for missing crypto API support · a4d14e91
      Eric Biggers authored 
      Users of fscrypt with non-default algorithms will encounter an error
like the following if they fail to include the needed algorithms into
the crypto API when configuring the kernel (as per the documentation):

    Error allocating 'adiantum(xchacha12,aes)' transform: -2

This requires that the user figure out what the "-2" error means.
Make it more friendly by printing a warning like the following instead:

    Missing crypto API support for Adiantum (API name: "adiantum(xchacha12,aes)")

Also upgrade the log level for *other* errors to KERN_ERR.
Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      a4d14e91
    • Eric Biggers's avatar
      fscrypt: improve warning messages for unsupported encryption contexts · 63f668f0
      Eric Biggers authored 
      When fs/crypto/ encounters an inode with an invalid encryption context,
currently it prints a warning if the pair of encryption modes are
unrecognized, but it's silent if there are other problems such as
unsupported context size, format, or flags.  To help people debug such
situations, add more warning messages.
Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      63f668f0
    • Eric Biggers's avatar
      fscrypt: make fscrypt_msg() take inode instead of super_block · 886da8b3
      Eric Biggers authored 
      Most of the warning and error messages in fs/crypto/ are for situations
related to a specific inode, not merely to a super_block.  So to make
things easier, make fscrypt_msg() take an inode rather than a
super_block, and make it print the inode number.

Note: This is the same approach I'm taking for fsverity_msg().
Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      886da8b3
    • Eric Biggers's avatar
      fscrypt: clean up base64 encoding/decoding · 1c5100a2
      Eric Biggers authored 
      Some minor cleanups for the code that base64 encodes and decodes
encrypted filenames and long name digests:

- Rename "digest_{encode,decode}()" => "base64_{encode,decode}()" since
  they are used for filenames too, not just for long name digests.
- Replace 'while' loops with more conventional 'for' loops.
- Use 'u8' for binary data.  Keep 'char' for string data.
- Fully constify the lookup table (pointer was not const).
- Improve comment.

No actual change in behavior.
Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      1c5100a2
    • Eric Biggers's avatar
      fscrypt: remove loadable module related code · 75798f85
      Eric Biggers authored 
      Since commit 643fa961 ("fscrypt: remove filesystem specific build
config option"), fs/crypto/ can no longer be built as a loadable module.
Thus it no longer needs a module_exit function, nor a MODULE_LICENSE.
So remove them, and change module_init to late_initcall.
Reviewed-by: default avatarChandan Rajendra <chandan@linux.ibm.com>
Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      75798f85
  3. 05 Aug, 2019 1 commit
  5. 04 Aug, 2019 10 commits
  7. 03 Aug, 2019 19 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7