07 Jan, 2021
1 commit
-
* aosp/upstream-f2fs-stable-linux-5.10.y:
fs-verity: move structs needed for file signing to UAPI header
fs-verity: rename "file measurement" to "file digest"
fs-verity: rename fsverity_signed_digest to fsverity_formatted_digest
fs-verity: remove filenames from file comments
fscrypt: allow deleting files with unsupported encryption policy
fscrypt: unexport fscrypt_get_encryption_info()
fscrypt: move fscrypt_require_key() to fscrypt_private.h
fscrypt: move body of fscrypt_prepare_setattr() out-of-line
fscrypt: introduce fscrypt_prepare_readdir()
ext4: don't call fscrypt_get_encryption_info() from dx_show_leaf()
ubifs: remove ubifs_dir_open()
f2fs: remove f2fs_dir_open()
ext4: remove ext4_dir_open()
fscrypt: simplify master key locking
fscrypt: remove unnecessary calls to fscrypt_require_key()
ubifs: prevent creating duplicate encrypted filenames
f2fs: prevent creating duplicate encrypted filenames
ext4: prevent creating duplicate encrypted filenames
fscrypt: add fscrypt_is_nokey_name()
fscrypt: remove kernel-internal constants from UAPI headerConflicts:
fs/crypto/hooks.cBug: 174873661
Signed-off-by: Jaegeuk Kim
Change-Id: Id56d42fc959242524628752223e9d773a2c8681c
29 Dec, 2020
4 commits
-
Currently it's impossible to delete files that use an unsupported
encryption policy, as the kernel will just return an error when
performing any operation on the top-level encrypted directory, even just
a path lookup into the directory or opening the directory for readdir.More specifically, this occurs in any of the following cases:
- The encryption context has an unrecognized version number. Current
kernels know about v1 and v2, but there could be more versions in the
future.- The encryption context has unrecognized encryption modes
(FSCRYPT_MODE_*) or flags (FSCRYPT_POLICY_FLAG_*), an unrecognized
combination of modes, or reserved bits set.- The encryption key has been added and the encryption modes are
recognized but aren't available in the crypto API -- for example, a
directory is encrypted with FSCRYPT_MODE_ADIANTUM but the kernel
doesn't have CONFIG_CRYPTO_ADIANTUM enabled.It's desirable to return errors for most operations on files that use an
unsupported encryption policy, but the current behavior is too strict.
We need to allow enough to delete files, so that people can't be stuck
with undeletable files when downgrading kernel versions. That includes
allowing directories to be listed and allowing dentries to be looked up.Fix this by modifying the key setup logic to treat an unsupported
encryption policy in the same way as "key unavailable" in the cases that
are required for a recursive delete to work: preparing for a readdir or
a dentry lookup, revalidating a dentry, or checking whether an inode has
the same encryption policy as its parent directory.Reviewed-by: Andreas Dilger
Link: https://lore.kernel.org/r/20201203022041.230976-10-ebiggers@kernel.org
Signed-off-by: Eric Biggers -
Now that fscrypt_get_encryption_info() is only called from files in
fs/crypto/ (due to all key setup now being handled by higher-level
helper functions instead of directly by filesystems), unexport it and
move its declaration to fscrypt_private.h.Reviewed-by: Andreas Dilger
Link: https://lore.kernel.org/r/20201203022041.230976-9-ebiggers@kernel.org
Signed-off-by: Eric Biggers -
The stated reasons for separating fscrypt_master_key::mk_secret_sem from
the standard semaphore contained in every 'struct key' no longer apply.First, due to commit a992b20cd4ee ("fscrypt: add
fscrypt_prepare_new_inode() and fscrypt_set_context()"),
fscrypt_get_encryption_info() is no longer called from within a
filesystem transaction.Second, due to commit d3ec10aa9581 ("KEYS: Don't write out to userspace
while holding key semaphore"), the semaphore for the "keyring" key type
no longer ranks above page faults.That leaves performance as the only possible reason to keep the separate
mk_secret_sem. Specifically, having mk_secret_sem reduces the
contention between setup_file_encryption_key() and
FS_IOC_{ADD,REMOVE}_ENCRYPTION_KEY. However, these ioctls aren't
executed often, so this doesn't seem to be worth the extra complexity.Therefore, simplify the locking design by just using key->sem instead of
mk_secret_sem.Link: https://lore.kernel.org/r/20201117032626.320275-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers -
There isn't really any valid reason to use __FSCRYPT_MODE_MAX or
FSCRYPT_POLICY_FLAGS_VALID in a userspace program. These constants are
only meant to be used by the kernel internally, and they are defined in
the UAPI header next to the mode numbers and flags only so that kernel
developers don't forget to update them when adding new modes or flags.In https://lkml.kernel.org/r/20201005074133.1958633-2-satyat@google.com
there was an example of someone wanting to use __FSCRYPT_MODE_MAX in a
user program, and it was wrong because the program would have broken if
__FSCRYPT_MODE_MAX were ever increased. So having this definition
available is harmful. FSCRYPT_POLICY_FLAGS_VALID has the same problem.So, remove these definitions from the UAPI header. Replace
FSCRYPT_POLICY_FLAGS_VALID with just listing the valid flags explicitly
in the one kernel function that needs it. Move __FSCRYPT_MODE_MAX to
fscrypt_private.h, remove the double underscores (which were only
present to discourage use by userspace), and add a BUILD_BUG_ON() and
comments to (hopefully) ensure it is kept in sync.Keep the old name FS_POLICY_FLAGS_VALID, since it's been around for
longer and there's a greater chance that removing it would break source
compatibility with some program. Indeed, mtd-utils is using it in
an #ifdef, and removing it would introduce compiler warnings (about
FS_POLICY_FLAGS_PAD_* being redefined) into the mtd-utils build.
However, reduce its value to 0x07 so that it only includes the flags
with old names (the ones present before Linux 5.4), and try to make it
clear that it's now "frozen" and no new flags should be added to it.Fixes: 2336d0deb2d4 ("fscrypt: use FSCRYPT_ prefix for uapi constants")
Cc: # v5.4+
Link: https://lore.kernel.org/r/20201024005132.495952-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers
27 Dec, 2020
2 commits
-
In 5.10.3 the commit 3b7c17a81426 ("fscrypt: remove kernel-internal
constants from UAPI header") removes __FSCRYPT_MODE_MAX so we need to
fix up the out-of-tree crypto code in the android12-5.10 branch that
uses it to keep the build working properly.Fixes: 3b7c17a81426 ("fscrypt: remove kernel-internal constants from UAPI header")
Cc: Eric Biggers
Signed-off-by: Greg Kroah-Hartman
Change-Id: I8e6dc371e46d37583c488ccdaec500c46a9734a8 -
Changes in 5.10.3
net: ipconfig: Avoid spurious blank lines in boot log
x86/split-lock: Avoid returning with interrupts enabled
exfat: Avoid allocating upcase table using kcalloc()
soc/tegra: fuse: Fix index bug in get_process_id
usb: mtu3: fix memory corruption in mtu3_debugfs_regset()
USB: serial: option: add interface-number sanity check to flag handling
USB: gadget: f_acm: add support for SuperSpeed Plus
USB: gadget: f_midi: setup SuperSpeed Plus descriptors
usb: gadget: f_fs: Re-use SS descriptors for SuperSpeedPlus
USB: gadget: f_rndis: fix bitrate for SuperSpeed and above
usb: chipidea: ci_hdrc_imx: Pass DISABLE_DEVICE_STREAMING flag to imx6ul
ARM: dts: exynos: fix roles of USB 3.0 ports on Odroid XU
ARM: dts: exynos: fix USB 3.0 VBUS control and over-current pins on Exynos5410
ARM: dts: exynos: fix USB 3.0 pins supply being turned off on Odroid XU
coresight: tmc-etf: Fix NULL ptr dereference in tmc_enable_etf_sink_perf()
coresight: tmc-etr: Check if page is valid before dma_map_page()
coresight: tmc-etr: Fix barrier packet insertion for perf buffer
coresight: etb10: Fix possible NULL ptr dereference in etb_enable_perf()
coresight: etm4x: Skip setting LPOVERRIDE bit for qcom, skip-power-up
coresight: etm4x: Fix accesses to TRCVMIDCTLR1
coresight: etm4x: Fix accesses to TRCCIDCTLR1
coresight: etm4x: Fix accesses to TRCPROCSELR
coresight: etm4x: Handle TRCVIPCSSCTLR accesses
f2fs: fix to seek incorrect data offset in inline data file
f2fs: init dirty_secmap incorrectly
scsi: megaraid_sas: Check user-provided offsets
HID: i2c-hid: add Vero K147 to descriptor override
serial_core: Check for port state when tty is in error state
fscrypt: remove kernel-internal constants from UAPI header
fscrypt: add fscrypt_is_nokey_name()
ubifs: prevent creating duplicate encrypted filenames
ext4: prevent creating duplicate encrypted filenames
f2fs: prevent creating duplicate encrypted filenames
Bluetooth: Fix slab-out-of-bounds read in hci_le_direct_adv_report_evt()
quota: Sanity-check quota file headers on load
fs: quota: fix array-index-out-of-bounds bug by passing correct argument to vfs_cleanup_quota_inode()
media: msi2500: assign SPI bus number dynamically
crypto: af_alg - avoid undefined behavior accessing salg_name
nl80211: validate key indexes for cfg80211_registered_device
md: fix a warning caused by a race between concurrent md_ioctl()s
Linux 5.10.3Signed-off-by: Greg Kroah-Hartman
Change-Id: Ia12e3bc535549040a55f8dfb70921d99882e79f5
26 Dec, 2020
1 commit
-
commit 3ceb6543e9cf6ed87cc1fbc6f23ca2db903564cd upstream.
There isn't really any valid reason to use __FSCRYPT_MODE_MAX or
FSCRYPT_POLICY_FLAGS_VALID in a userspace program. These constants are
only meant to be used by the kernel internally, and they are defined in
the UAPI header next to the mode numbers and flags only so that kernel
developers don't forget to update them when adding new modes or flags.In https://lkml.kernel.org/r/20201005074133.1958633-2-satyat@google.com
there was an example of someone wanting to use __FSCRYPT_MODE_MAX in a
user program, and it was wrong because the program would have broken if
__FSCRYPT_MODE_MAX were ever increased. So having this definition
available is harmful. FSCRYPT_POLICY_FLAGS_VALID has the same problem.So, remove these definitions from the UAPI header. Replace
FSCRYPT_POLICY_FLAGS_VALID with just listing the valid flags explicitly
in the one kernel function that needs it. Move __FSCRYPT_MODE_MAX to
fscrypt_private.h, remove the double underscores (which were only
present to discourage use by userspace), and add a BUILD_BUG_ON() and
comments to (hopefully) ensure it is kept in sync.Keep the old name FS_POLICY_FLAGS_VALID, since it's been around for
longer and there's a greater chance that removing it would break source
compatibility with some program. Indeed, mtd-utils is using it in
an #ifdef, and removing it would introduce compiler warnings (about
FS_POLICY_FLAGS_PAD_* being redefined) into the mtd-utils build.
However, reduce its value to 0x07 so that it only includes the flags
with old names (the ones present before Linux 5.4), and try to make it
clear that it's now "frozen" and no new flags should be added to it.Fixes: 2336d0deb2d4 ("fscrypt: use FSCRYPT_ prefix for uapi constants")
Cc: # v5.4+
Link: https://lore.kernel.org/r/20201024005132.495952-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers
Signed-off-by: Greg Kroah-Hartman
12 Nov, 2020
1 commit
-
…kernel/git/viro/vfs") into android-mainline
Steps on the way to 5.10-rc4
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I9e0fa89c0f6f306fe802ae95c8d01d9ba558e111
07 Nov, 2020
1 commit
-
I_CREATING isn't actually set until the inode has been assigned an inode
number and inserted into the inode hash table. So the WARN_ON() in
fscrypt_setup_iv_ino_lblk_32_key() is wrong, and it can trigger when
creating an encrypted file on ext4. Remove it.This was sometimes causing xfstest generic/602 to fail on ext4. I
didn't notice it before because due to a separate oversight, new inodes
that haven't been assigned an inode number yet don't necessarily have
i_ino == 0 as I had thought, so by chance I never saw the test fail.Fixes: a992b20cd4ee ("fscrypt: add fscrypt_prepare_new_inode() and fscrypt_set_context()")
Reported-by: Theodore Y. Ts'o
Link: https://lore.kernel.org/r/20201031004556.87862-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers
23 Oct, 2020
1 commit
-
…cm/fs/fscrypt/fscrypt") into android-mainline
Steps on the way to 5.10-rc1
Change-Id: Ifceecc1b9f94ea893484002c69aeb7b82d246f64
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
22 Sep, 2020
3 commits
-
The behavior of the test_dummy_encryption mount option is that when a
new file (or directory or symlink) is created in an unencrypted
directory, it's automatically encrypted using a dummy encryption policy.
That's it; in particular, the encryption (or lack thereof) of existing
files (or directories or symlinks) doesn't change.Unfortunately the implementation of test_dummy_encryption is a bit weird
and confusing. When test_dummy_encryption is enabled and a file is
being created in an unencrypted directory, we set up an encryption key
(->i_crypt_info) for the directory. This isn't actually used to do any
encryption, however, since the directory is still unencrypted! Instead,
->i_crypt_info is only used for inheriting the encryption policy.One consequence of this is that the filesystem ends up providing a
"dummy context" (policy + nonce) instead of a "dummy policy". In
commit ed318a6cc0b6 ("fscrypt: support test_dummy_encryption=v2"), I
mistakenly thought this was required. However, actually the nonce only
ends up being used to derive a key that is never used.Another consequence of this implementation is that it allows for
'inode->i_crypt_info != NULL && !IS_ENCRYPTED(inode)', which is an edge
case that can be forgotten about. For example, currently
FS_IOC_GET_ENCRYPTION_POLICY on an unencrypted directory may return the
dummy encryption policy when the filesystem is mounted with
test_dummy_encryption. That seems like the wrong thing to do, since
again, the directory itself is not actually encrypted.Therefore, switch to a more logical and maintainable implementation
where the dummy encryption policy inheritance is done without setting up
keys for unencrypted directories. This involves:- Adding a function fscrypt_policy_to_inherit() which returns the
encryption policy to inherit from a directory. This can be a real
policy, a dummy policy, or no policy.- Replacing struct fscrypt_dummy_context, ->get_dummy_context(), etc.
with struct fscrypt_dummy_policy, ->get_dummy_policy(), etc.- Making fscrypt_fname_encrypted_size() take an fscrypt_policy instead
of an inode.Acked-by: Jaegeuk Kim
Acked-by: Jeff Layton
Link: https://lore.kernel.org/r/20200917041136.178600-13-ebiggers@kernel.org
Signed-off-by: Eric Biggers -
fscrypt_get_encryption_info() has never actually been safe to call in a
context that needs GFP_NOFS, since it calls crypto_alloc_skcipher().crypto_alloc_skcipher() isn't GFP_NOFS-safe, even if called under
memalloc_nofs_save(). This is because it may load kernel modules, and
also because it internally takes crypto_alg_sem. Other tasks can do
GFP_KERNEL allocations while holding crypto_alg_sem for write.The use of fscrypt_init_mutex isn't GFP_NOFS-safe either.
So, stop pretending that fscrypt_get_encryption_info() is nofs-safe.
I.e., when it allocates memory, just use GFP_KERNEL instead of GFP_NOFS.Note, another reason to do this is that GFP_NOFS is deprecated in favor
of using memalloc_nofs_save() in the proper places.Acked-by: Jeff Layton
Link: https://lore.kernel.org/r/20200917041136.178600-10-ebiggers@kernel.org
Signed-off-by: Eric Biggers -
fscrypt_get_encryption_info() is intended to be GFP_NOFS-safe. But
actually it isn't, since it uses functions like crypto_alloc_skcipher()
which aren't GFP_NOFS-safe, even when called under memalloc_nofs_save().
Therefore it can deadlock when called from a context that needs
GFP_NOFS, e.g. during an ext4 transaction or between f2fs_lock_op() and
f2fs_unlock_op(). This happens when creating a new encrypted file.We can't fix this by just not setting up the key for new inodes right
away, since new symlinks need their key to encrypt the symlink target.So we need to set up the new inode's key before starting the
transaction. But just calling fscrypt_get_encryption_info() earlier
doesn't work, since it assumes the encryption context is already set,
and the encryption context can't be set until the transaction.The recently proposed fscrypt support for the ceph filesystem
(https://lkml.kernel.org/linux-fscrypt/20200821182813.52570-1-jlayton@kernel.org/T/#u)
will have this same ordering problem too, since ceph will need to
encrypt new symlinks before setting their encryption context.Finally, f2fs can deadlock when the filesystem is mounted with
'-o test_dummy_encryption' and a new file is created in an existing
unencrypted directory. Similarly, this is caused by holding too many
locks when calling fscrypt_get_encryption_info().To solve all these problems, add new helper functions:
- fscrypt_prepare_new_inode() sets up a new inode's encryption key
(fscrypt_info), using the parent directory's encryption policy and a
new random nonce. It neither reads nor writes the encryption context.- fscrypt_set_context() persists the encryption context of a new inode,
using the information from the fscrypt_info already in memory. This
replaces fscrypt_inherit_context().Temporarily keep fscrypt_inherit_context() around until all filesystems
have been converted to use fscrypt_set_context().Acked-by: Jeff Layton
Link: https://lore.kernel.org/r/20200917041136.178600-2-ebiggers@kernel.org
Signed-off-by: Eric Biggers
12 Aug, 2020
1 commit
-
Fix a checkpatch warning that I fixed when applying
ANDROID-fscrypt-add-support-for-hardware-wrapped-keys.patch to
android12-5.4 (http://aosp/1394286). This gets android-mainline in
sync.This should be folded into
ANDROID-fscrypt-add-support-for-hardware-wrapped-keys.patch.Bug: 160883801
Change-Id: Id615560edf4405a5b748cf402565d8f157298d3b
Signed-off-by: Eric Biggers
05 Aug, 2020
1 commit
-
…pub/scm/linux/kernel/git/jlayton/linux") into android-mainline
Resolve merge conflicts in fs/crypto/ caused by the non-upstream changes
for metadata encryption support [1] and wrapped key support [2].[1] https://android.googlesource.com/kernel/common-patches/+/refs/heads/master/android-mainline/ANDROID-dm-add-dm-default-key-target-for-metadata-encryption.patch
[2] https://android.googlesource.com/kernel/common-patches/+/refs/heads/master/android-mainline/ANDROID-fscrypt-add-support-for-hardware-wrapped-keys.patchConflicts:
fs/crypto/fscrypt_private.h
fs/crypto/inline_crypt.c
fs/crypto/keysetup.c
fs/crypto/keysetup_v1.c
fs/f2fs/data.c
include/linux/fscrypt.hBug: 160885805
Bug: 160883801
Test: kvm-xfstests -c ext4,f2fs -g encrypt
Change-Id: Icdc9e61b2286c78ba04cec1c9dca421bff545716
Signed-off-by: Eric Biggers <ebiggers@google.com>
22 Jul, 2020
2 commits
-
Normally smp_store_release() or cmpxchg_release() is paired with
smp_load_acquire(). Sometimes smp_load_acquire() can be replaced with
the more lightweight READ_ONCE(). However, for this to be safe, all the
published memory must only be accessed in a way that involves the
pointer itself. This may not be the case if allocating the object also
involves initializing a static or global variable, for example.fscrypt_info includes various sub-objects which are internal to and are
allocated by other kernel subsystems such as keyrings and crypto. So by
using READ_ONCE() for ->i_crypt_info, we're relying on internal
implementation details of these other kernel subsystems.Remove this fragile assumption by using smp_load_acquire() instead.
(Note: I haven't seen any real-world problems here. This change is just
fixing the code to be guaranteed correct and less fragile.)Fixes: e37a784d8b6a ("fscrypt: use READ_ONCE() to access ->i_crypt_info")
Link: https://lore.kernel.org/r/20200721225920.114347-5-ebiggers@kernel.org
Signed-off-by: Eric Biggers -
Normally smp_store_release() or cmpxchg_release() is paired with
smp_load_acquire(). Sometimes smp_load_acquire() can be replaced with
the more lightweight READ_ONCE(). However, for this to be safe, all the
published memory must only be accessed in a way that involves the
pointer itself. This may not be the case if allocating the object also
involves initializing a static or global variable, for example.fscrypt_prepared_key includes a pointer to a crypto_skcipher object,
which is internal to and is allocated by the crypto subsystem. By using
READ_ONCE() for it, we're relying on internal implementation details of
the crypto subsystem.Remove this fragile assumption by using smp_load_acquire() instead.
(Note: I haven't seen any real-world problems here. This change is just
fixing the code to be guaranteed correct and less fragile.)Fixes: 5fee36095cda ("fscrypt: add inline encryption support")
Cc: Satya Tangirala
Link: https://lore.kernel.org/r/20200721225920.114347-3-ebiggers@kernel.org
Signed-off-by: Eric Biggers
21 Jul, 2020
1 commit
-
The name "FS_KEY_DERIVATION_NONCE_SIZE" is a bit outdated since due to
the addition of FSCRYPT_POLICY_FLAG_DIRECT_KEY, the file nonce may now
be used as a tweak instead of for key derivation. Also, we're now
prefixing the fscrypt constants with "FSCRYPT_" instead of "FS_".Therefore, rename this constant to FSCRYPT_FILE_NONCE_SIZE.
Link: https://lore.kernel.org/r/20200708215722.147154-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers
09 Jul, 2020
1 commit
-
Add support for inline encryption to fs/crypto/. With "inline
encryption", the block layer handles the decryption/encryption as part
of the bio, instead of the filesystem doing the crypto itself via
Linux's crypto API. This model is needed in order to take advantage of
the inline encryption hardware present on most modern mobile SoCs.To use inline encryption, the filesystem needs to be mounted with
'-o inlinecrypt'. Blk-crypto will then be used instead of the traditional
filesystem-layer crypto whenever possible to encrypt the contents
of any encrypted files in that filesystem. Fscrypt still provides the key
and IV to use, and the actual ciphertext on-disk is still the same;
therefore it's testable using the existing fscrypt ciphertext verification
tests.Note that since blk-crypto has a fallback to Linux's crypto API, and
also supports all the encryption modes currently supported by fscrypt,
this feature is usable and testable even without actual inline
encryption hardware.Per-filesystem changes will be needed to set encryption contexts when
submitting bios and to implement the 'inlinecrypt' mount option. This
patch just adds the common code.Signed-off-by: Satya Tangirala
Reviewed-by: Jaegeuk Kim
Reviewed-by: Eric Biggers
Reviewed-by: Theodore Ts'o
Link: https://lore.kernel.org/r/20200702015607.1215430-3-satyat@google.com
Co-developed-by: Eric Biggers
Signed-off-by: Eric Biggers
18 Jun, 2020
1 commit
-
The block layer patches for inline encryption are now in upstream, so
update Android to the upstream version of inline encryption. The
fscrypt/f2fs/ext4 patches are also updated to the latest version sent
upstream (since they can't be updated separately from the block layer
patches).Changes v6 => v7:
- Keyslot management is now done on a per-request basis rather than a
per-bio basis.
- Storage drivers can now specify the maximum number of bytes they
can accept for the data unit number (DUN) for each crypto algorithm,
and upper layers can specify the minimum number of bytes of DUN they
want with the blk_crypto_key they send with the bio - a driver is
only considered to support a blk_crypto_key if the driver supports at
least as many DUN bytes as the upper layer wants. This is necessary
because storage drivers may not support as many bytes as the
algorithm specification dictates (for e.g. UFS only supports 8 byte
DUNs for AES-256-XTS, even though the algorithm specification
says DUNs are 16 bytes long).
- Introduce SB_INLINECRYPT to keep track of whether inline encryption
is enabled for a filesystem (instead of using an fscrypt_operation).
- Expose keyslot manager declaration and embed it within ufs_hba to
clean up code.
- Make blk-crypto preclude blk-integrity.
- Some bug fixes
- Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't
support inline encryption (yet)Changes v7 => v8:
- Pass a struct blk_ksm_keyslot * around instead of slot numbers which
simplifies some functions and passes around arguments with better types
- Make bios with no encryption context avoid making calls into blk-crypto
by checking for the presence of bi_crypt_context before making the call
- Make blk-integrity preclude inline encryption support at probe time
- Many many cleanupsChanges v8 => v9:
- Don't open code bio_has_crypt_ctx into callers of blk-crypto functions.
- Lots of cleanupsChanges v9 => v10:
- Incorporate Eric's fix for allowing en/decryption to happen as usual via
fscrypt in the case that hardware doesn't support the desired crypto
configuration, but blk-crypto-fallback is disabled. (Introduce
struct blk_crypto_config and blk_crypto_config_supported for fscrypt
to call, to check that either blk-crypto-fallback is enabled or the
device supports the crypto configuration).
- Update docs
- Lots of cleanupsChanges v10 => v11:
- We now allocate a new bio_crypt_ctx for each request instead of
pulling and reusing the one in the bio inserted into the request. The
bio_crypt_ctx of a bio is freed after the bio is ended.
- Make each blk_ksm_keyslot store a pointer to the blk_crypto_key
instead of a copy of the blk_crypto_key, so that each blk_crypto_key
will have its own keyslot. We also won't need to compute the siphash
for a blk_crypto_key anymore.
- Minor cleanupsChanges v11 => v12:
- Inlined some fscrypt functions
- Minor cleanups and improved commentsChanges v12 => v13:
- Updated docs
- Minor cleanups
- rebased onto linux-block/for-nextChanges v13 => fscrypt/f2fs/ext4 upstream patch series
- rename struct fscrypt_info::ci_key to ci_enc_key
- set dun bytes more precisely in fscrypt
- cleanupsBug: 137270441
Test: Test cuttlefish boots both with and without inlinecrypt mount
option specified in fstab, while using both F2FS and EXT4 for
userdata.img. Also verified ciphertext via
"atest -v vts_kernel_encryption_test"
Also tested by running gce-xfstests on both the
auto and encrypt test groups on EXT4 and F2FS both with and
without the inlinecrypt mount option. The UFS changes were
tested on a Pixel 4 device.
Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/
Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/
Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/
Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e
Signed-off-by: Satya Tangirala
Signed-off-by: Eric Biggers
05 Jun, 2020
1 commit
-
…cm/fs/fscrypt/fscrypt") into android-mainline
Baby-steps along the way to 5.8-rc1.
Needed hand-holding for crypto fs changes, thanks to Eric for the
resolutions.Cc: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I7198edbca759839aceeec2598e7a81305756c4d7
22 May, 2020
1 commit
-
The eMMC inline crypto standard will only specify 32 DUN bits (a.k.a. IV
bits), unlike UFS's 64. IV_INO_LBLK_64 is therefore not applicable, but
an encryption format which uses one key per policy and permits the
moving of encrypted file contents (as f2fs's garbage collector requires)
is still desirable.To support such hardware, add a new encryption format IV_INO_LBLK_32
that makes the best use of the 32 bits: the IV is set to
'SipHash-2-4(inode_number) + file_logical_block_number mod 2^32', where
the SipHash key is derived from the fscrypt master key. We hash only
the inode number and not also the block number, because we need to
maintain contiguity of DUNs to merge bios.Unlike with IV_INO_LBLK_64, with this format IV reuse is possible; this
is unavoidable given the size of the DUN. This means this format should
only be used where the requirements of the first paragraph apply.
However, the hash spreads out the IVs in the whole usable range, and the
use of a keyed hash makes it difficult for an attacker to determine
which files use which IVs.Besides the above differences, this flag works like IV_INO_LBLK_64 in
that on ext4 it is only allowed if the stable_inodes feature has been
enabled to prevent inode numbers and the filesystem UUID from changing.Signed-off-by: Eric Biggers
Link: https://lore.kernel.org/r/20200515204141.251098-1-ebiggers@kernel.org
(Resolved conflicts with inline encryption support. Besides the
necessary "straightforward" merge resolutions, also made
fscrypt_get_dun_bytes() aware of IV_INO_LBLK_32 and made IV_INO_LBLK_32
usable with wrapped keys.)Test: 'atest vts_kernel_encryption_test' on Cuttlefish with
the IV_INO_LBLK_32 test added (http://aosp/1315024).Also tested enabling this in the fstab for Cuttlefish
(using http://aosp/1315886).Also ran 'kvm-xfstests -c ext4,f2fs -g encrypt', including my
work-in-progress xfstest for IV_INO_LBLK_32.Bug: 144046242
Change-Id: I57df71d502bde0475efc906a0812102063ff2f2a
Signed-off-by: Eric Biggers
20 May, 2020
1 commit
-
The eMMC inline crypto standard will only specify 32 DUN bits (a.k.a. IV
bits), unlike UFS's 64. IV_INO_LBLK_64 is therefore not applicable, but
an encryption format which uses one key per policy and permits the
moving of encrypted file contents (as f2fs's garbage collector requires)
is still desirable.To support such hardware, add a new encryption format IV_INO_LBLK_32
that makes the best use of the 32 bits: the IV is set to
'SipHash-2-4(inode_number) + file_logical_block_number mod 2^32', where
the SipHash key is derived from the fscrypt master key. We hash only
the inode number and not also the block number, because we need to
maintain contiguity of DUNs to merge bios.Unlike with IV_INO_LBLK_64, with this format IV reuse is possible; this
is unavoidable given the size of the DUN. This means this format should
only be used where the requirements of the first paragraph apply.
However, the hash spreads out the IVs in the whole usable range, and the
use of a keyed hash makes it difficult for an attacker to determine
which files use which IVs.Besides the above differences, this flag works like IV_INO_LBLK_64 in
that on ext4 it is only allowed if the stable_inodes feature has been
enabled to prevent inode numbers and the filesystem UUID from changing.Link: https://lore.kernel.org/r/20200515204141.251098-1-ebiggers@kernel.org
Reviewed-by: Theodore Ts'o
Reviewed-by: Paul Crowley
Signed-off-by: Eric Biggers
19 May, 2020
1 commit
-
v1 encryption policies are deprecated in favor of v2, and some new
features (e.g. encryption+casefolding) are only being added for v2.Therefore, the "test_dummy_encryption" mount option (which is used for
encryption I/O testing with xfstests) needs to support v2 policies.To do this, extend its syntax to be "test_dummy_encryption=v1" or
"test_dummy_encryption=v2". The existing "test_dummy_encryption" (no
argument) also continues to be accepted, to specify the default setting
-- currently v1, but the next patch changes it to v2.To cleanly support both v1 and v2 while also making it easy to support
specifying other encryption settings in the future (say, accepting
"$contents_mode:$filenames_mode:v2"), make ext4 and f2fs maintain a
pointer to the dummy fscrypt_context rather than using mount flags.To avoid concurrency issues, don't allow test_dummy_encryption to be set
or changed during a remount. (The former restriction is new, but
xfstests doesn't run into it, so no one should notice.)Tested with 'gce-xfstests -c {ext4,f2fs}/encrypt -g auto'. On ext4,
there are two regressions, both of which are test bugs: ext4/023 and
ext4/028 fail because they set an xattr and expect it to be stored
inline, but the increase in size of the fscrypt_context from
24 to 40 bytes causes this xattr to be spilled into an external block.Link: https://lore.kernel.org/r/20200512233251.118314-4-ebiggers@kernel.org
Acked-by: Jaegeuk Kim
Reviewed-by: Theodore Ts'o
Signed-off-by: Eric Biggers
13 May, 2020
1 commit
-
Fix all kerneldoc warnings in fs/crypto/ and include/linux/fscrypt.h.
Most of these were due to missing documentation for function parameters.Detected with:
scripts/kernel-doc -v -none fs/crypto/*.{c,h} include/linux/fscrypt.h
This cleanup makes it possible to check new patches for kerneldoc
warnings without having to filter out all the existing ones.For consistency, also adjust some function "brief descriptions" to
include the parentheses and to wrap at 80 characters. (The latter
matches the checkpatch expectation.)Link: https://lore.kernel.org/r/20200511191358.53096-2-ebiggers@kernel.org
Signed-off-by: Eric Biggers
05 Apr, 2020
1 commit
-
When the filesystem is mounted with '-o inlinecrypt', make fscrypt fall
back to filesystem-layer crypto when inline crypto won't work, e.g. due
to the hardware not supporting the encryption algorithm.When blk-crypto-fallback is disabled, this fixes '-o inlinecrypt' to not
break any fscrypt policies that would otherwise work.This is needed for VtsKernelEncryptionTest to pass on some devices.
Bug: 137270441
Bug: 151100202
Test: 'atest vts_kernel_encryption_test' on Pixel 4 with the
inline crypto patches backported, and also on Cuttlefish.
Change-Id: I3e730df4608efb12d7126d1a85faddcccb566764
Signed-off-by: Eric Biggers
01 Apr, 2020
1 commit
-
Pull fscrypt updates from Eric Biggers:
"Add an ioctl FS_IOC_GET_ENCRYPTION_NONCE which retrieves a file's
encryption nonce.This makes it easier to write automated tests which verify that
fscrypt is doing the encryption correctly"* tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/fs/fscrypt/fscrypt:
ubifs: wire up FS_IOC_GET_ENCRYPTION_NONCE
f2fs: wire up FS_IOC_GET_ENCRYPTION_NONCE
ext4: wire up FS_IOC_GET_ENCRYPTION_NONCE
fscrypt: add FS_IOC_GET_ENCRYPTION_NONCE ioctl
20 Mar, 2020
2 commits
-
Add an ioctl FS_IOC_GET_ENCRYPTION_NONCE which retrieves the nonce from
an encrypted file or directory. The nonce is the 16-byte random value
stored in the inode's encryption xattr. It is normally used together
with the master key to derive the inode's actual encryption key.The nonces are needed by automated tests that verify the correctness of
the ciphertext on-disk. Except for the IV_INO_LBLK_64 case, there's no
way to replicate a file's ciphertext without knowing that file's nonce.The nonces aren't secret, and the existing ciphertext verification tests
in xfstests retrieve them from disk using debugfs or dump.f2fs. But in
environments that lack these debugging tools, getting the nonces by
manually parsing the filesystem structure would be very hard.To make this important type of testing much easier, let's just add an
ioctl that retrieves the nonce.Link: https://lore.kernel.org/r/20200314205052.93294-2-ebiggers@kernel.org
Reviewed-by: Theodore Ts'o
Signed-off-by: Eric Biggers -
Add an ioctl FS_IOC_GET_ENCRYPTION_NONCE which retrieves the nonce from
an encrypted file or directory. The nonce is the 16-byte random value
stored in the inode's encryption xattr. It is normally used together
with the master key to derive the inode's actual encryption key.The nonces are needed by automated tests that verify the correctness of
the ciphertext on-disk. Except for the IV_INO_LBLK_64 case, there's no
way to replicate a file's ciphertext without knowing that file's nonce.The nonces aren't secret, and the existing ciphertext verification tests
in xfstests retrieve them from disk using debugfs or dump.f2fs. But in
environments that lack these debugging tools, getting the nonces by
manually parsing the filesystem structure would be very hard.To make this important type of testing much easier, let's just add an
ioctl that retrieves the nonce.Bug: 151100202
Link: https://lore.kernel.org/r/20200314205052.93294-2-ebiggers@kernel.org
Change-Id: Ieef2c57b9257ae38eb2e5c1a018ca6f325bb62dd
Signed-off-by: Eric Biggers
16 Mar, 2020
1 commit
-
Linux 5.6-rc6
Signed-off-by: Greg Kroah-Hartman
Change-Id: I6c2d7aff44ad5a9b75030b72d34ca5dbd5ad3ceb
08 Mar, 2020
1 commit
-
After FS_IOC_REMOVE_ENCRYPTION_KEY removes a key, it syncs the
filesystem and tries to get and put all inodes that were unlocked by the
key so that unused inodes get evicted via fscrypt_drop_inode().
Normally, the inodes are all clean due to the sync.However, after the filesystem is sync'ed, userspace can modify and close
one of the files. (Userspace is *supposed* to close the files before
removing the key. But it doesn't always happen, and the kernel can't
assume it.) This causes the inode to be dirtied and have i_count == 0.
Then, fscrypt_drop_inode() failed to consider this case and indicated
that the inode can be dropped, causing the write to be lost.On f2fs, other problems such as a filesystem freeze could occur due to
the inode being freed while still on f2fs's dirty inode list.Fix this bug by making fscrypt_drop_inode() only drop clean inodes.
I've written an xfstest which detects this bug on ext4, f2fs, and ubifs.
Fixes: b1c0ec3599f4 ("fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl")
Cc: # v5.4+
Link: https://lore.kernel.org/r/20200305084138.653498-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers
13 Feb, 2020
1 commit
-
blk-crypto-fallback does not support wrapped keys, hence
prevent falling back when program_key fails. Add 'is_hw_wrapped'
flag to blk-crypto-key to mention if the key is wrapped
when the key is initialized.Bug: 147209885
Test: Validate FBE, simulate a failure in the underlying blk
device and ensure the call fails without falling back
to blk-crypto-fallback.Change-Id: I8bc301ca1ac9e55ba6ab622e8325486916b45c56
Signed-off-by: Barani Muthukumaran
31 Jan, 2020
1 commit
-
…cm/fs/fscrypt/fscrypt") into android-mainline
Merge the upstream merge of fscrypt-for-linus, to resolve conflicts
between the fscrypt changes that went upstream in 5.6 and the inline
crypto and hardware-wrapped key support that is currently being carried
in the Android common kernels.Conflicts:
fs/crypto/Kconfig
fs/crypto/bio.c
fs/crypto/fname.c
fs/crypto/fscrypt_private.h
fs/crypto/keyring.c
fs/crypto/keysetup.c
include/uapi/linux/fscrypt.hMerge resolution notes:
- In fscrypt_zeroout_range(), split the inline crypto case into a
separate function fscrypt_zeroout_range_inlinecrypt(), as mixing the
two cases together became much harder due to the upstream changes.- Allow the size of fscrypt-provisioning keys to be up to
FSCRYPT_MAX_HW_WRAPPED_KEY_SIZE rather than FSCRYPT_MAX_KEY_SIZE.Change-Id: Ib1e6b9eda8fb5dcfc6bdc8fa89d93f72b088c5f6
Signed-off-by: Eric Biggers <ebiggers@google.com>
23 Jan, 2020
2 commits
-
Now that there's sometimes a second type of per-file key (the dirhash
key), clarify some function names, macros, and documentation that
specifically deal with per-file *encryption* keys.Link: https://lore.kernel.org/r/20200120223201.241390-4-ebiggers@kernel.org
Reviewed-by: Daniel Rosenberg
Signed-off-by: Eric Biggers -
When we allow indexed directories to use both encryption and
casefolding, for the dirhash we can't just hash the ciphertext filenames
that are stored on-disk (as is done currently) because the dirhash must
be case insensitive, but the stored names are case-preserving. Nor can
we hash the plaintext names with an unkeyed hash (or a hash keyed with a
value stored on-disk like ext4's s_hash_seed), since that would leak
information about the names that encryption is meant to protect.Instead, if we can accept a dirhash that's only computable when the
fscrypt key is available, we can hash the plaintext names with a keyed
hash using a secret key derived from the directory's fscrypt master key.
We'll use SipHash-2-4 for this purpose.Prepare for this by deriving a SipHash key for each casefolded encrypted
directory. Make sure to handle deriving the key not only when setting
up the directory's fscrypt_info, but also in the case where the casefold
flag is enabled after the fscrypt_info was already set up. (We could
just always derive the key regardless of casefolding, but that would
introduce unnecessary overhead for people not using casefolding.)Signed-off-by: Daniel Rosenberg
[EB: improved commit message, updated fscrypt.rst, squashed with change
that avoids unnecessarily deriving the key, and many other cleanups]
Link: https://lore.kernel.org/r/20200120223201.241390-3-ebiggers@kernel.org
Signed-off-by: Eric Biggers
21 Jan, 2020
1 commit
-
To prevent keys from being compromised if an attacker acquires read
access to kernel memory, some inline encryption hardware supports
protecting the keys in hardware without software having access to or the
ability to set the plaintext keys. Instead, software only sees "wrapped
keys", which may differ on every boot. The keys can be initially
generated either by software (in which case they need to be imported to
hardware to be wrapped), or directly by the hardware.Add support for this type of hardware by allowing keys to be flagged as
hardware-wrapped and encryption policies to be flagged as needing a
hardware-wrapped key. When used, fscrypt will pass the wrapped key
directly to the inline encryption hardware to encrypt file contents.
The hardware is responsible for internally unwrapping the key and
deriving the actual file contents encryption key.fscrypt also asks the inline encryption hardware to derive a
cryptographically isolated software "secret", which fscrypt then uses as
the master key for all other purposes besides file contents encryption,
e.g. to derive filenames encryption keys and the key identifier.Bug: 147209885
Change-Id: I58d1a37f5ba8cf178b80036b813e0bc99512ef3b
Co-developed-by: Gaurav Kashyap
Signed-off-by: Gaurav Kashyap
Signed-off-by: Barani Muthukumaran
Signed-off-by: Eric Biggers
13 Jan, 2020
1 commit
-
Changes v5 => v6:
- Blk-crypto's kernel crypto API fallback is no longer restricted to
8-byte DUNs. It's also now separately configurable from blk-crypto, and
can be disabled entirely, while still allowing the kernel to use inline
encryption hardware. Further, struct bio_crypt_ctx takes up less space,
and no longer contains the information needed by the crypto API
fallback - the fallback allocates the required memory when necessary.
- Blk-crypto now supports all file content encryption modes supported by
fscrypt.
- Fixed bio merging logic in blk-merge.c
- Fscrypt now supports inline encryption with the direct key policy, since
blk-crypto now has support for larger DUNs.
- Keyslot manager now uses a hashtable to lookup which keyslot contains
any particular key (thanks Eric!)
- Fscrypt support for inline encryption now handles filesystems with
multiple underlying block devices (thanks Eric!)
- Numerous cleanupsBug: 137270441
Test: refer to I26376479ee38259b8c35732cb3a1d7e15f9b05a3
Change-Id: I13e2e327e0b4784b394cb1e7cf32a04856d95f01
Link: https://lore.kernel.org/linux-block/20191218145136.172774-1-satyat@google.com/
Signed-off-by: Satya Tangirala
01 Jan, 2020
2 commits
-
FSCRYPT_POLICY_FLAG_DIRECT_KEY is currently only allowed with Adiantum
encryption. But FS_IOC_SET_ENCRYPTION_POLICY allowed it in combination
with other encryption modes, and an error wasn't reported until later
when the encrypted directory was actually used.Fix it to report the error earlier by validating the correct use of the
DIRECT_KEY flag in fscrypt_supported_policy(), similar to how we
validate the IV_INO_LBLK_64 flag.Link: https://lore.kernel.org/r/20191209211829.239800-3-ebiggers@kernel.org
Signed-off-by: Eric Biggers -
As a sanity check, verify that the allocated crypto_skcipher actually
has the ivsize that fscrypt is assuming it has. This will always be the
case unless there's a bug. But if there ever is such a bug (e.g. like
there was in earlier versions of the ESSIV conversion patch [1]) it's
preferable for it to be immediately obvious, and not rely on the
ciphertext verification tests failing due to uninitialized IV bytes.[1] https://lkml.kernel.org/linux-crypto/20190702215517.GA69157@gmail.com/
Link: https://lore.kernel.org/r/20191209203918.225691-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers