Skip to content

L
linux
Switch branch/tag
  1. 13 Aug, 2019 12 commits
    • Eric Biggers's avatar
      fscrypt: refactor key setup code in preparation for v2 policies · 3ec4f2a6
      Eric Biggers authored 
      Do some more refactoring of the key setup code, in preparation for
introducing a filesystem-level keyring and v2 encryption policies:

- Now that ci_inode exists, don't pass around the inode unnecessarily.

- Define a function setup_file_encryption_key() which handles the crypto
  key setup given an under-construction fscrypt_info.  Don't pass the
  fscrypt_context, since everything is in the fscrypt_info.
  [This will be extended for v2 policies and the fs-level keyring.]

- Define a function fscrypt_set_derived_key() which sets the per-file
  key, without depending on anything specific to v1 policies.
  [This will also be used for v2 policies.]

- Define a function fscrypt_setup_v1_file_key() which takes the raw
  master key, thus separating finding the key from using it.
  [This will also be used if the key is found in the fs-level keyring.]
Reviewed-by: default avatarTheodore Ts'o <tytso@mit.edu>
Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      3ec4f2a6
    • Eric Biggers's avatar
      fscrypt: rename fscrypt_master_key to fscrypt_direct_key · a828daab
      Eric Biggers authored 
      In preparation for introducing a filesystem-level keyring which will
contain fscrypt master keys, rename the existing 'struct
fscrypt_master_key' to 'struct fscrypt_direct_key'.  This is the
structure in the existing table of master keys that's maintained to
deduplicate the crypto transforms for v1 DIRECT_KEY policies.

I've chosen to keep this table as-is rather than make it automagically
add/remove the keys to/from the filesystem-level keyring, since that
would add a lot of extra complexity to the filesystem-level keyring.
Reviewed-by: default avatarTheodore Ts'o <tytso@mit.edu>
Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      a828daab
    • 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 17 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7