* refs/heads/tmp-66aebe2:
Linux 4.19.42
arm64: futex: Bound number of LDXR/STXR loops in FUTEX_WAKE_OP
locking/futex: Allow low-level atomic operations to return -EAGAIN
ASoC: Intel: avoid Oops if DMA setup fails
UAS: fix alignment of scatter/gather segments
Bluetooth: Align minimum encryption key size for LE and BR/EDR connections
Bluetooth: hidp: fix buffer overflow
scsi: qla2xxx: Fix device staying in blocked state
scsi: qla2xxx: Fix incorrect region-size setting in optrom SYSFS routines
scsi: lpfc: change snprintf to scnprintf for possible overflow
soc: sunxi: Fix missing dependency on REGMAP_MMIO
cpufreq: armada-37xx: fix frequency calculation for opp
intel_th: pci: Add Comet Lake support
usb-storage: Set virt_boundary_mask to avoid SG overflows
USB: cdc-acm: fix unthrottle races
USB: serial: f81232: fix interrupt worker not stop
usb: dwc3: Fix default lpm_nyet_threshold value
genirq: Prevent use-after-free and work list corruption
iommu/amd: Set exclusion range correctly
perf/core: Fix perf_event_disable_inatomic() race
platform/x86: pmc_atom: Drop __initconst on dmi table
nvme-fc: correct csn initialization and increments on error
virtio-blk: limit number of hw queues by nr_cpu_ids
ASoC: Intel: kbl: fix wrong number of channels
drm/mediatek: fix possible object reference leak
scsi: csiostor: fix missing data copy in csio_scsi_err_handler()
RDMA/hns: Fix bug that caused srq creation to fail
RDMA/vmw_pvrdma: Fix memory leak on pvrdma_pci_remove
virtio_pci: fix a NULL pointer reference in vp_del_vqs
drm/sun4i: tcon top: Fix NULL/invalid pointer dereference in sun8i_tcon_top_un/bind
slab: fix a crash by reading /proc/slab_allocators
objtool: Add rewind_stack_do_exit() to the noreturn list
ASoC: cs35l35: Disable regulators on driver removal
drm/amd/display: fix cursor black issue
ASoC: rockchip: pdm: fix regmap_ops hang issue
linux/kernel.h: Use parentheses around argument in u64_to_user_ptr()
perf/x86/intel: Initialize TFA MSR
perf/x86/intel: Fix handling of wakeup_events for multi-entry PEBS
drm/mediatek: Fix an error code in mtk_hdmi_dt_parse_pdata()
ASoC: tlv320aic32x4: Fix Common Pins
MIPS: KGDB: fix kgdb support for SMP platforms.
IB/hfi1: Fix the allocation of RSM table
IB/hfi1: Eliminate opcode tests on mr deref
drm/omap: hdmi4_cec: Fix CEC clock handling for PM
ASoC: dapm: Fix NULL pointer dereference in snd_soc_dapm_free_kcontrol
ASoC: cs4270: Set auto-increment bit for register writes
ASoC: stm32: dfsdm: fix debugfs warnings on entry creation
ASoC: stm32: dfsdm: manage multiple prepare
clk: meson-gxbb: round the vdec dividers to closest
ASoC: wm_adsp: Add locking to wm_adsp2_bus_error
ASoC: rt5682: recording has no sound after booting
ASoC: samsung: odroid: Fix clock configuration for 44100 sample rate
ASoC: nau8810: fix the issue of widget with prefixed name
ASoC: nau8824: fix the issue of the widget with prefix name
ASoC:intel:skl:fix a simultaneous playback & capture issue on hda platform
ASoC:soc-pcm:fix a codec fixup issue in TDM case
ASoC: stm32: sai: fix exposed capabilities in spdif mode
ASoC: stm32: sai: fix iec958 controls indexation
ASoC: hdmi-codec: fix S/PDIF DAI
ASoC: tlv320aic3x: fix reset gpio reference counting
staging: most: cdev: fix chrdev_region leak in mod_exit
staging: greybus: power_supply: fix prop-descriptor request size
ubsan: Fix nasty -Wbuiltin-declaration-mismatch GCC-9 warnings
Drivers: hv: vmbus: Remove the undesired put_cpu_ptr() in hv_synic_cleanup()
scsi: libsas: fix a race condition when smp task timeout
net: stmmac: Use bfsize1 in ndesc_init_rx_desc
ANDROID: block/cfq-iosched: make group_idle per io cgroup tunable
ANDROID: cuttlefish_defconfig: Enable CONFIG_CGROUP_SCHEDTUNE
fscrypt: remove filesystem specific build config option
f2fs: use IS_ENCRYPTED() to check encryption status
ext4: use IS_ENCRYPTED() to check encryption status
fscrypt: return -EXDEV for incompatible rename or link into encrypted dir
fscrypt: remove CRYPTO_CTR dependency
fscrypt: add Adiantum support
crypto: speck - remove Speck
Conflicts:
fs/crypto/fscrypt_private.h
fs/ext4/inode.c
include/linux/fscrypt_supp.h
kernel/irq/manage.c
Change-Id: I08093f45a8a82bdb85ace0968863545cb329baaa
Signed-off-by: Ivaylo Georgiev <irgeorgiev@codeaurora.org>
This is a snapshot of the ICE related changes required
for F2FS as of msm-4.14 commit 6fb74ab56(f2fs/fscrypt-ice:
allow merging some IOs).
Change-Id: I92b7c71276c616668a271a3e7a20fc397c089d1c
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
Signed-off-by: Barani Muthukumaran <bmuthuku@codeaurora.org>
In order to have a common code base for fscrypt "post read" processing
for all filesystems which support encryption, this commit removes
filesystem specific build config option (e.g. CONFIG_EXT4_FS_ENCRYPTION)
and replaces it with a build option (i.e. CONFIG_FS_ENCRYPTION) whose
value affects all the filesystems making use of fscrypt.
Reviewed-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Currently, trying to rename or link a regular file, directory, or
symlink into an encrypted directory fails with EPERM when the source
file is unencrypted or is encrypted with a different encryption policy,
and is on the same mountpoint. It is correct for the operation to fail,
but the choice of EPERM breaks tools like 'mv' that know to copy rather
than rename if they see EXDEV, but don't know what to do with EPERM.
Our original motivation for EPERM was to encourage users to securely
handle their data. Encrypting files by "moving" them into an encrypted
directory can be insecure because the unencrypted data may remain in
free space on disk, where it can later be recovered by an attacker.
It's much better to encrypt the data from the start, or at least try to
securely delete the source data e.g. using the 'shred' program.
However, the current behavior hasn't been effective at achieving its
goal because users tend to be confused, hack around it, and complain;
see e.g. https://github.com/google/fscrypt/issues/76. And in some cases
it's actually inconsistent or unnecessary. For example, 'mv'-ing files
between differently encrypted directories doesn't work even in cases
where it can be secure, such as when in userspace the same passphrase
protects both directories. Yet, you *can* already 'mv' unencrypted
files into an encrypted directory if the source files are on a different
mountpoint, even though doing so is often insecure.
There are probably better ways to teach users to securely handle their
files. For example, the 'fscrypt' userspace tool could provide a
command that migrates unencrypted files into an encrypted directory,
acting like 'shred' on the source files and providing appropriate
warnings depending on the type of the source filesystem and disk.
Receiving errors on unimportant files might also force some users to
disable encryption, thus making the behavior counterproductive. It's
desirable to make encryption as unobtrusive as possible.
Therefore, change the error code from EPERM to EXDEV so that tools
looking for EXDEV will fall back to a copy.
This, of course, doesn't prevent users from still doing the right things
to securely manage their files. Note that this also matches the
behavior when a file is renamed between two project quota hierarchies;
so there's precedent for using EXDEV for things other than mountpoints.
xfstests generic/398 will require an update with this change.
[Rewritten from an earlier patch series by Michael Halcrow.]
Cc: Michael Halcrow <mhalcrow@google.com>
Cc: Joe Richey <joerichey@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
This is a snapshot of the crypto drivers as of msm-4.14 commit
367c46b1 (Enable hardware based FBE on f2fs and adapt ext4 fs).
Change-Id: Ifb52ed101d6e971c5823037f7895049b830c78c5
Signed-off-by: Zhen Kong <zkong@codeaurora.org>
Now that all filesystems have been converted to use the symlink helper
functions, they no longer need the declaration of 'struct
fscrypt_symlink_data'. Move it from fscrypt.h to fscrypt_private.h.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Currently, filesystems supporting fscrypt need to implement some tricky
logic when creating encrypted symlinks, including handling a peculiar
on-disk format (struct fscrypt_symlink_data) and correctly calculating
the size of the encrypted symlink. Introduce helper functions to make
things a bit easier:
- fscrypt_prepare_symlink() computes and validates the size the symlink
target will require on-disk.
- fscrypt_encrypt_symlink() creates the encrypted target if needed.
The new helpers actually fix some subtle bugs. First, when checking
whether the symlink target was too long, filesystems didn't account for
the fact that the NUL padding is meant to be truncated if it would cause
the maximum length to be exceeded, as is done for filenames in
directories. Consequently users would receive ENAMETOOLONG when
creating symlinks close to what is supposed to be the maximum length.
For example, with EXT4 with a 4K block size, the maximum symlink target
length in an encrypted directory is supposed to be 4093 bytes (in
comparison to 4095 in an unencrypted directory), but in
FS_POLICY_FLAGS_PAD_32-mode only up to 4064 bytes were accepted.
Second, symlink targets of "." and ".." were not being encrypted, even
though they should be, as these names are special in *directory entries*
but not in symlink targets. Fortunately, we can fix this simply by
starting to encrypt them, as old kernels already accept them in
encrypted form.
Third, the output string length the filesystems were providing when
doing the actual encryption was incorrect, as it was forgotten to
exclude 'sizeof(struct fscrypt_symlink_data)'. Fortunately though, this
bug didn't make a difference.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
fscrypt.h included way too many other headers, given that it is included
by filesystems both with and without encryption support. Trim down the
includes list by moving the needed includes into more appropriate
places, and removing the unneeded ones.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Only fs/crypto/fname.c cares about treating the "." and ".." filenames
specially with regards to encryption, so move fscrypt_is_dot_dotdot()
from fscrypt.h to there.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The encryption modes are validated by fs/crypto/, not by individual
filesystems. Therefore, move fscrypt_valid_enc_modes() from fscrypt.h
to fscrypt_private.h.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Filesystems now only define their fscrypt_operations when they are
compiled with encryption support, so move the fscrypt_operations
declaration from fscrypt.h to fscrypt_supp.h.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
fscrypt_dummy_context_enabled() accesses ->s_cop, which now is only set
when the filesystem is built with encryption support. This didn't
actually matter because no filesystems called it. However, it will
start being used soon, so fix it by moving it from fscrypt.h to
fscrypt_supp.h and stubbing it out in fscrypt_notsupp.h.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Filesystems only ever access 'struct fscrypt_ctx' through fscrypt
functions. But when a filesystem is built without encryption support,
these functions are all stubbed out, so the declaration of fscrypt_ctx
is unneeded. Therefore, move it from fscrypt.h to fscrypt_supp.h.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
fscrypt_control_page() is already split into two versions depending on
whether the filesystem is being built with encryption support or not.
Move them into the appropriate headers.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
fscrypt_has_encryption_key() is already split into two versions
depending on whether the filesystem is being built with encryption
support or not. Move them into the appropriate headers.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Pull fscrypt updates from Ted Ts'o:
"Lots of cleanups, mostly courtesy by Eric Biggers"
* tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/fscrypt:
fscrypt: lock mutex before checking for bounce page pool
fscrypt: add a documentation file for filesystem-level encryption
ext4: switch to fscrypt_prepare_setattr()
ext4: switch to fscrypt_prepare_lookup()
ext4: switch to fscrypt_prepare_rename()
ext4: switch to fscrypt_prepare_link()
ext4: switch to fscrypt_file_open()
fscrypt: new helper function - fscrypt_prepare_setattr()
fscrypt: new helper function - fscrypt_prepare_lookup()
fscrypt: new helper function - fscrypt_prepare_rename()
fscrypt: new helper function - fscrypt_prepare_link()
fscrypt: new helper function - fscrypt_file_open()
fscrypt: new helper function - fscrypt_require_key()
fscrypt: remove unneeded empty fscrypt_operations structs
fscrypt: remove ->is_encrypted()
fscrypt: switch from ->is_encrypted() to IS_ENCRYPTED()
fs, fscrypt: add an S_ENCRYPTED inode flag
fscrypt: clean up include file mess
Introduce a helper function for filesystems to call when processing
->setattr() on a possibly-encrypted inode. It handles enforcing that an
encrypted file can only be truncated if its encryption key is available.
Acked-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Introduce a helper function which prepares to look up the given dentry
in the given directory. If the directory is encrypted, it handles
loading the directory's encryption key, setting the dentry's ->d_op to
fscrypt_d_ops, and setting DCACHE_ENCRYPTED_WITH_KEY if the directory's
encryption key is available.
Note: once all filesystems switch over to this, we'll be able to move
fscrypt_d_ops and fscrypt_set_encrypted_dentry() to fscrypt_private.h.
Acked-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Introduce a helper function which prepares to rename a file into a
possibly encrypted directory. It handles loading the encryption keys
for the source and target directories if needed, and it handles
enforcing that if the target directory (and the source directory for a
cross-rename) is encrypted, then the file being moved into the directory
has the same encryption policy as its containing directory.
Acked-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Introduce a helper function which prepares to link an inode into a
possibly-encrypted directory. It handles setting up the target
directory's encryption key, then verifying that the link won't violate
the constraint that all files in an encrypted directory tree use the
same encryption policy.
Acked-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Add a helper function which checks if an inode is encrypted, and if so,
tries to set up its encryption key. This is a pattern which is
duplicated in multiple places in each of ext4, f2fs, and ubifs --- for
example, when a regular file is asked to be opened or truncated.
Acked-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Now that all callers of fscrypt_operations.is_encrypted() have been
switched to IS_ENCRYPTED(), remove ->is_encrypted().
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Acked-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Filesystems have to include different header files based on whether they
are compiled with encryption support or not. That's nasty and messy.
Instead, rationalise the headers so we have a single include fscrypt.h
and let it decide what internal implementation to include based on the
__FS_HAS_ENCRYPTION define. Filesystems set __FS_HAS_ENCRYPTION to 1
before including linux/fscrypt.h if they are built with encryption
support. Otherwise, they must set __FS_HAS_ENCRYPTION to 0.
Add guards to prevent fscrypt_supp.h and fscrypt_notsupp.h from being
directly included by filesystems.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
[EB: use 1 and 0 rather than defined/undefined]
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
