Skip to content

L
linux
Switch branch/tag
  1. 06 Nov, 2019 2 commits
    • Eric Biggers's avatar
      fscrypt: add support for IV_INO_LBLK_64 policies · b103fb76
      Eric Biggers authored 
      Inline encryption hardware compliant with the UFS v2.1 standard or with
the upcoming version of the eMMC standard has the following properties:

(1) Per I/O request, the encryption key is specified by a previously
    loaded keyslot.  There might be only a small number of keyslots.

(2) Per I/O request, the starting IV is specified by a 64-bit "data unit
    number" (DUN).  IV bits 64-127 are assumed to be 0.  The hardware
    automatically increments the DUN for each "data unit" of
    configurable size in the request, e.g. for each filesystem block.

Property (1) makes it inefficient to use the traditional fscrypt
per-file keys.  Property (2) precludes the use of the existing
DIRECT_KEY fscrypt policy flag, which needs at least 192 IV bits.

Therefore, add a new fscrypt policy flag IV_INO_LBLK_64 which causes the
encryption to modified as follows:

- The encryption keys are derived from the master key, encryption mode
  number, and filesystem UUID.

- The IVs are chosen as (inode_number << 32) | file_logical_block_num.
  For filenames encryption, file_logical_block_num is 0.

Since the file nonces aren't used in the key derivation, many files may
share the same encryption key.  This is much more efficient on the
target hardware.  Including the inode number in the IVs and mixing the
filesystem UUID into the keys ensures that data in different files is
nevertheless still encrypted differently.

Additionally, limiting the inode and block numbers to 32 bits and
placing the block number in the low bits maintains compatibility with
the 64-bit DUN convention (property (2) above).

Since this scheme assumes that inode numbers are stable (which may
preclude filesystem shrinking) and that inode and file logical block
numbers are at most 32-bit, IV_INO_LBLK_64 will only be allowed on
filesystems that meet these constraints.  These are acceptable
limitations for the cases where this format would actually be used.

Note that IV_INO_LBLK_64 is an on-disk format, not an implementation.
This patch just adds support for it using the existing filesystem layer
encryption.  A later patch will add support for inline encryption.
Reviewed-by: default avatarPaul Crowley <paulcrowley@google.com>
Co-developed-by: default avatarSatya Tangirala <satyat@google.com>
Signed-off-by: default avatarSatya Tangirala <satyat@google.com>
Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      b103fb76
    • Eric Biggers's avatar
      fscrypt: avoid data race on fscrypt_mode::logged_impl_name · ff73c2c0
      Eric Biggers authored 
      The access to logged_impl_name is technically a data race, which tools
like KCSAN could complain about in the future.  See:
https://github.com/google/ktsan/wiki/READ_ONCE-and-WRITE_ONCE

Fix by using xchg(), which also ensures that only one thread does the
logging.

This also required switching from bool to int, to avoid a build error on
the RISC-V architecture which doesn't implement xchg on bytes.
Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      ff73c2c0
  3. 21 Oct, 2019 4 commits
    • Eric Biggers's avatar
      docs: ioctl-number: document fscrypt ioctl numbers · 065ab4c4
      Eric Biggers authored 
      The 'f' ioctls with numbers 19-26 decimal are currently used for fscrypt
(a.k.a. ext4/f2fs/ubifs encryption), and up to 39 decimal is reserved
for future fscrypt use, as per the comment in fs/ext4/ext4.h.  So the
reserved range is 13-27 hex.

Document this in ioctl-number.rst.
Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      065ab4c4
    • Eric Biggers's avatar
      fscrypt: zeroize fscrypt_info before freeing · 6f99756d
      Eric Biggers authored 
      memset the struct fscrypt_info to zero before freeing.  This isn't
really needed currently, since there's no secret key directly in the
fscrypt_info.  But there's a decent chance that someone will add such a
field in the future, e.g. in order to use an API that takes a raw key
such as siphash().  So it's good to do this as a hardening measure.
Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      6f99756d
    • Eric Biggers's avatar
      fscrypt: remove struct fscrypt_ctx · 1565bdad
      Eric Biggers authored 
      Now that ext4 and f2fs implement their own post-read workflow that
supports both fscrypt and fsverity, the fscrypt-only workflow based
around struct fscrypt_ctx is no longer used.  So remove the unused code.

This is based on a patch from Chandan Rajendra's "Consolidate FS read
I/O callbacks code" patchset, but rebased onto the latest kernel, folded
__fscrypt_decrypt_bio() into fscrypt_decrypt_bio(), cleaned up
fscrypt_initialize(), and updated the commit message.

Originally-from: Chandan Rajendra <chandan@linux.ibm.com>
Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      1565bdad
    • Eric Biggers's avatar
      fscrypt: invoke crypto API for ESSIV handling · 4006d799
      Eric Biggers authored 
      Instead of open-coding the calculations for ESSIV handling, use an ESSIV
skcipher which does all of this under the hood.  ESSIV was added to the
crypto API in v5.4.

This is based on a patch from Ard Biesheuvel, but reworked to apply
after all the fscrypt changes that went into v5.4.

Tested with 'kvm-xfstests -c ext4,f2fs -g encrypt', including the
ciphertext verification tests for v1 and v2 encryption policies.

Originally-from: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      4006d799
  5. 20 Oct, 2019 6 commits
  7. 19 Oct, 2019 28 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7