License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
7 years ago
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
|
|
|
|
/*
|
|
|
|
|
* Key setup facility for FS encryption support.
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 2015, Google, Inc.
|
|
|
|
|
*
|
|
|
|
|
* Originally written by Michael Halcrow, Ildar Muslukhov, and Uday Savagaonkar.
|
|
|
|
|
* Heavily modified since then.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <crypto/skcipher.h>
|
|
|
|
|
#include <linux/key.h>
|
|
|
|
|
|
|
|
|
|
#include "fscrypt_private.h"
|
|
|
|
|
|
|
|
|
|
struct fscrypt_mode fscrypt_modes[] = {
|
|
|
|
|
[FSCRYPT_MODE_AES_256_XTS] = {
|
|
|
|
|
.friendly_name = "AES-256-XTS",
|
|
|
|
|
.cipher_str = "xts(aes)",
|
|
|
|
|
.keysize = 64,
|
fscrypt: add Adiantum support / removed speck
Add support for the Adiantum encryption mode to fscrypt. Adiantum is a
tweakable, length-preserving encryption mode with security provably
reducible to that of XChaCha12 and AES-256, subject to a security bound.
It's also a true wide-block mode, unlike XTS. See the paper
"Adiantum: length-preserving encryption for entry-level processors"
(https://eprint.iacr.org/2018/720.pdf) for more details. Also see
commit 059c2a4d8e16 ("crypto: adiantum - add Adiantum support").
On sufficiently long messages, Adiantum's bottlenecks are XChaCha12 and
the NH hash function. These algorithms are fast even on processors
without dedicated crypto instructions. Adiantum makes it feasible to
enable storage encryption on low-end mobile devices that lack AES
instructions; currently such devices are unencrypted. On ARM Cortex-A7,
on 4096-byte messages Adiantum encryption is about 4 times faster than
AES-256-XTS encryption; decryption is about 5 times faster.
In fscrypt, Adiantum is suitable for encrypting both file contents and
names. With filenames, it fixes a known weakness: when two filenames in
a directory share a common prefix of >= 16 bytes, with CTS-CBC their
encrypted filenames share a common prefix too, leaking information.
Adiantum does not have this problem.
Since Adiantum also accepts long tweaks (IVs), it's also safe to use the
master key directly for Adiantum encryption rather than deriving
per-file keys, provided that the per-file nonce is included in the IVs
and the master key isn't used for any other encryption mode. This
configuration saves memory and improves performance. A new fscrypt
policy flag is added to allow users to opt-in to this configuration.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
6 years ago
|
|
|
.ivsize = 16,
|
|
|
|
|
.blk_crypto_mode = BLK_ENCRYPTION_MODE_AES_256_XTS,
|
|
|
|
|
},
|
|
|
|
|
[FSCRYPT_MODE_AES_256_CTS] = {
|
|
|
|
|
.friendly_name = "AES-256-CTS-CBC",
|
|
|
|
|
.cipher_str = "cts(cbc(aes))",
|
|
|
|
|
.keysize = 32,
|
fscrypt: add Adiantum support / removed speck
Add support for the Adiantum encryption mode to fscrypt. Adiantum is a
tweakable, length-preserving encryption mode with security provably
reducible to that of XChaCha12 and AES-256, subject to a security bound.
It's also a true wide-block mode, unlike XTS. See the paper
"Adiantum: length-preserving encryption for entry-level processors"
(https://eprint.iacr.org/2018/720.pdf) for more details. Also see
commit 059c2a4d8e16 ("crypto: adiantum - add Adiantum support").
On sufficiently long messages, Adiantum's bottlenecks are XChaCha12 and
the NH hash function. These algorithms are fast even on processors
without dedicated crypto instructions. Adiantum makes it feasible to
enable storage encryption on low-end mobile devices that lack AES
instructions; currently such devices are unencrypted. On ARM Cortex-A7,
on 4096-byte messages Adiantum encryption is about 4 times faster than
AES-256-XTS encryption; decryption is about 5 times faster.
In fscrypt, Adiantum is suitable for encrypting both file contents and
names. With filenames, it fixes a known weakness: when two filenames in
a directory share a common prefix of >= 16 bytes, with CTS-CBC their
encrypted filenames share a common prefix too, leaking information.
Adiantum does not have this problem.
Since Adiantum also accepts long tweaks (IVs), it's also safe to use the
master key directly for Adiantum encryption rather than deriving
per-file keys, provided that the per-file nonce is included in the IVs
and the master key isn't used for any other encryption mode. This
configuration saves memory and improves performance. A new fscrypt
policy flag is added to allow users to opt-in to this configuration.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
6 years ago
|
|
|
.ivsize = 16,
|
|
|
|
|
},
|
|
|
|
|
[FSCRYPT_MODE_AES_128_CBC] = {
|
|
|
|
|
.friendly_name = "AES-128-CBC-ESSIV",
|
|
|
|
|
.cipher_str = "essiv(cbc(aes),sha256)",
|
|
|
|
|
.keysize = 16,
|
fscrypt: add Adiantum support / removed speck
Add support for the Adiantum encryption mode to fscrypt. Adiantum is a
tweakable, length-preserving encryption mode with security provably
reducible to that of XChaCha12 and AES-256, subject to a security bound.
It's also a true wide-block mode, unlike XTS. See the paper
"Adiantum: length-preserving encryption for entry-level processors"
(https://eprint.iacr.org/2018/720.pdf) for more details. Also see
commit 059c2a4d8e16 ("crypto: adiantum - add Adiantum support").
On sufficiently long messages, Adiantum's bottlenecks are XChaCha12 and
the NH hash function. These algorithms are fast even on processors
without dedicated crypto instructions. Adiantum makes it feasible to
enable storage encryption on low-end mobile devices that lack AES
instructions; currently such devices are unencrypted. On ARM Cortex-A7,
on 4096-byte messages Adiantum encryption is about 4 times faster than
AES-256-XTS encryption; decryption is about 5 times faster.
In fscrypt, Adiantum is suitable for encrypting both file contents and
names. With filenames, it fixes a known weakness: when two filenames in
a directory share a common prefix of >= 16 bytes, with CTS-CBC their
encrypted filenames share a common prefix too, leaking information.
Adiantum does not have this problem.
Since Adiantum also accepts long tweaks (IVs), it's also safe to use the
master key directly for Adiantum encryption rather than deriving
per-file keys, provided that the per-file nonce is included in the IVs
and the master key isn't used for any other encryption mode. This
configuration saves memory and improves performance. A new fscrypt
policy flag is added to allow users to opt-in to this configuration.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
6 years ago
|
|
|
.ivsize = 16,
|
|
|
|
|
.blk_crypto_mode = BLK_ENCRYPTION_MODE_AES_128_CBC_ESSIV,
|
|
|
|
|
},
|
|
|
|
|
[FSCRYPT_MODE_AES_128_CTS] = {
|
|
|
|
|
.friendly_name = "AES-128-CTS-CBC",
|
|
|
|
|
.cipher_str = "cts(cbc(aes))",
|
|
|
|
|
.keysize = 16,
|
fscrypt: add Adiantum support / removed speck
Add support for the Adiantum encryption mode to fscrypt. Adiantum is a
tweakable, length-preserving encryption mode with security provably
reducible to that of XChaCha12 and AES-256, subject to a security bound.
It's also a true wide-block mode, unlike XTS. See the paper
"Adiantum: length-preserving encryption for entry-level processors"
(https://eprint.iacr.org/2018/720.pdf) for more details. Also see
commit 059c2a4d8e16 ("crypto: adiantum - add Adiantum support").
On sufficiently long messages, Adiantum's bottlenecks are XChaCha12 and
the NH hash function. These algorithms are fast even on processors
without dedicated crypto instructions. Adiantum makes it feasible to
enable storage encryption on low-end mobile devices that lack AES
instructions; currently such devices are unencrypted. On ARM Cortex-A7,
on 4096-byte messages Adiantum encryption is about 4 times faster than
AES-256-XTS encryption; decryption is about 5 times faster.
In fscrypt, Adiantum is suitable for encrypting both file contents and
names. With filenames, it fixes a known weakness: when two filenames in
a directory share a common prefix of >= 16 bytes, with CTS-CBC their
encrypted filenames share a common prefix too, leaking information.
Adiantum does not have this problem.
Since Adiantum also accepts long tweaks (IVs), it's also safe to use the
master key directly for Adiantum encryption rather than deriving
per-file keys, provided that the per-file nonce is included in the IVs
and the master key isn't used for any other encryption mode. This
configuration saves memory and improves performance. A new fscrypt
policy flag is added to allow users to opt-in to this configuration.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
6 years ago
|
|
|
.ivsize = 16,
|
|
|
|
|
},
|
|
|
|
|
[FSCRYPT_MODE_ADIANTUM] = {
|
fscrypt: add Adiantum support / removed speck
Add support for the Adiantum encryption mode to fscrypt. Adiantum is a
tweakable, length-preserving encryption mode with security provably
reducible to that of XChaCha12 and AES-256, subject to a security bound.
It's also a true wide-block mode, unlike XTS. See the paper
"Adiantum: length-preserving encryption for entry-level processors"
(https://eprint.iacr.org/2018/720.pdf) for more details. Also see
commit 059c2a4d8e16 ("crypto: adiantum - add Adiantum support").
On sufficiently long messages, Adiantum's bottlenecks are XChaCha12 and
the NH hash function. These algorithms are fast even on processors
without dedicated crypto instructions. Adiantum makes it feasible to
enable storage encryption on low-end mobile devices that lack AES
instructions; currently such devices are unencrypted. On ARM Cortex-A7,
on 4096-byte messages Adiantum encryption is about 4 times faster than
AES-256-XTS encryption; decryption is about 5 times faster.
In fscrypt, Adiantum is suitable for encrypting both file contents and
names. With filenames, it fixes a known weakness: when two filenames in
a directory share a common prefix of >= 16 bytes, with CTS-CBC their
encrypted filenames share a common prefix too, leaking information.
Adiantum does not have this problem.
Since Adiantum also accepts long tweaks (IVs), it's also safe to use the
master key directly for Adiantum encryption rather than deriving
per-file keys, provided that the per-file nonce is included in the IVs
and the master key isn't used for any other encryption mode. This
configuration saves memory and improves performance. A new fscrypt
policy flag is added to allow users to opt-in to this configuration.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
6 years ago
|
|
|
.friendly_name = "Adiantum",
|
|
|
|
|
.cipher_str = "adiantum(xchacha12,aes)",
|
|
|
|
|
.keysize = 32,
|
fscrypt: add Adiantum support / removed speck
Add support for the Adiantum encryption mode to fscrypt. Adiantum is a
tweakable, length-preserving encryption mode with security provably
reducible to that of XChaCha12 and AES-256, subject to a security bound.
It's also a true wide-block mode, unlike XTS. See the paper
"Adiantum: length-preserving encryption for entry-level processors"
(https://eprint.iacr.org/2018/720.pdf) for more details. Also see
commit 059c2a4d8e16 ("crypto: adiantum - add Adiantum support").
On sufficiently long messages, Adiantum's bottlenecks are XChaCha12 and
the NH hash function. These algorithms are fast even on processors
without dedicated crypto instructions. Adiantum makes it feasible to
enable storage encryption on low-end mobile devices that lack AES
instructions; currently such devices are unencrypted. On ARM Cortex-A7,
on 4096-byte messages Adiantum encryption is about 4 times faster than
AES-256-XTS encryption; decryption is about 5 times faster.
In fscrypt, Adiantum is suitable for encrypting both file contents and
names. With filenames, it fixes a known weakness: when two filenames in
a directory share a common prefix of >= 16 bytes, with CTS-CBC their
encrypted filenames share a common prefix too, leaking information.
Adiantum does not have this problem.
Since Adiantum also accepts long tweaks (IVs), it's also safe to use the
master key directly for Adiantum encryption rather than deriving
per-file keys, provided that the per-file nonce is included in the IVs
and the master key isn't used for any other encryption mode. This
configuration saves memory and improves performance. A new fscrypt
policy flag is added to allow users to opt-in to this configuration.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
6 years ago
|
|
|
.ivsize = 32,
|
|
|
|
|
.blk_crypto_mode = BLK_ENCRYPTION_MODE_ADIANTUM,
|
|
|
|
|
},
|
Merge android-4.14.151 (2bb70f4) into msm-4.14
* refs/heads/tmp-2bb70f4:
ANDROID: virtio: virtio_input: Set the amount of multitouch slots in virtio input
ANDROID: dummy_cpufreq: Implement get()
rtlwifi: Fix potential overflow on P2P code
ANDROID: cpufreq: create dummy cpufreq driver
ANDROID: Allow DRM_IOCTL_MODE_*_DUMB for render clients.
ANDROID: sdcardfs: evict dentries on fscrypt key removal
ANDROID: fscrypt: add key removal notifier chain
ANDROID: Move from clang r353983c to r365631c
ANDROID: move up spin_unlock_bh() ahead of remove_proc_entry()
BACKPORT: arm64: tags: Preserve tags for addresses translated via TTBR1
UPSTREAM: arm64: memory: Implement __tag_set() as common function
UPSTREAM: arm64/mm: fix variable 'tag' set but not used
UPSTREAM: arm64: avoid clang warning about self-assignment
ANDROID: refactor build.config files to remove duplication
UPSTREAM: mm: vmalloc: show number of vmalloc pages in /proc/meminfo
BACKPORT: PM/sleep: Expose suspend stats in sysfs
UPSTREAM: power: supply: Init device wakeup after device_add()
UPSTREAM: PM / wakeup: Unexport wakeup_source_sysfs_{add,remove}()
UPSTREAM: PM / wakeup: Register wakeup class kobj after device is added
BACKPORT: PM / wakeup: Fix sysfs registration error path
BACKPORT: PM / wakeup: Show wakeup sources stats in sysfs
UPSTREAM: PM / wakeup: Print warn if device gets enabled as wakeup source during sleep
UPSTREAM: PM / wakeup: Use wakeup_source_register() in wakelock.c
UPSTREAM: PM / wakeup: Only update last time for active wakeup sources
UPSTREAM: PM / core: Add support to skip power management in device/driver model
cuttlefish-4.14: Enable CONFIG_DM_SNAPSHOT
ANDROID: cuttlefish_defconfig: Enable BPF_JIT and BPF_JIT_ALWAYS_ON
UPSTREAM: netfilter: xt_IDLETIMER: fix sysfs callback function type
UPSTREAM: mm: untag user pointers in mmap/munmap/mremap/brk
UPSTREAM: vfio/type1: untag user pointers in vaddr_get_pfn
UPSTREAM: media/v4l2-core: untag user pointers in videobuf_dma_contig_user_get
UPSTREAM: drm/radeon: untag user pointers in radeon_gem_userptr_ioctl
BACKPORT: drm/amdgpu: untag user pointers
UPSTREAM: userfaultfd: untag user pointers
UPSTREAM: fs/namespace: untag user pointers in copy_mount_options
UPSTREAM: mm: untag user pointers in get_vaddr_frames
UPSTREAM: mm: untag user pointers in mm/gup.c
BACKPORT: mm: untag user pointers passed to memory syscalls
BACKPORT: lib: untag user pointers in strn*_user
UPSTREAM: arm64: Fix reference to docs for ARM64_TAGGED_ADDR_ABI
UPSTREAM: selftests, arm64: add kernel headers path for tags_test
BACKPORT: arm64: Relax Documentation/arm64/tagged-pointers.rst
UPSTREAM: arm64: Define Documentation/arm64/tagged-address-abi.rst
UPSTREAM: arm64: Change the tagged_addr sysctl control semantics to only prevent the opt-in
UPSTREAM: arm64: Tighten the PR_{SET, GET}_TAGGED_ADDR_CTRL prctl() unused arguments
UPSTREAM: selftests, arm64: fix uninitialized symbol in tags_test.c
UPSTREAM: arm64: mm: Really fix sparse warning in untagged_addr()
UPSTREAM: selftests, arm64: add a selftest for passing tagged pointers to kernel
BACKPORT: arm64: Introduce prctl() options to control the tagged user addresses ABI
UPSTREAM: thread_info: Add update_thread_flag() helpers
UPSTREAM: arm64: untag user pointers in access_ok and __uaccess_mask_ptr
UPSTREAM: uaccess: add noop untagged_addr definition
BACKPORT: block: annotate refault stalls from IO submission
ext4: add verity flag check for dax
ANDROID: usb: gadget: Fix dependency for f_accessory
ANDROID: sched: fair: balance for single core cluster
UPSTREAM: mm/kasan: fix false positive invalid-free reports with CONFIG_KASAN_SW_TAGS=y
f2fs: add a condition to detect overflow in f2fs_ioc_gc_range()
f2fs: fix to add missing F2FS_IO_ALIGNED() condition
f2fs: fix to fallback to buffered IO in IO aligned mode
f2fs: fix to handle error path correctly in f2fs_map_blocks
f2fs: fix extent corrupotion during directIO in LFS mode
f2fs: check all the data segments against all node ones
f2fs: Add a small clarification to CONFIG_FS_F2FS_FS_SECURITY
f2fs: fix inode rwsem regression
f2fs: fix to avoid accessing uninitialized field of inode page in is_alive()
f2fs: avoid infinite GC loop due to stale atomic files
f2fs: Fix indefinite loop in f2fs_gc()
f2fs: convert inline_data in prior to i_size_write
f2fs: fix error path of f2fs_convert_inline_page()
f2fs: add missing documents of reserve_root/resuid/resgid
f2fs: fix flushing node pages when checkpoint is disabled
f2fs: enhance f2fs_is_checkpoint_ready()'s readability
f2fs: clean up __bio_alloc()'s parameter
f2fs: fix wrong error injection path in inc_valid_block_count()
f2fs: fix to writeout dirty inode during node flush
f2fs: optimize case-insensitive lookups
f2fs: introduce f2fs_match_name() for cleanup
f2fs: Fix indefinite loop in f2fs_gc()
f2fs: allocate memory in batch in build_sit_info()
f2fs: fix to avoid data corruption by forbidding SSR overwrite
f2fs: Fix build error while CONFIG_NLS=m
Revert "f2fs: avoid out-of-range memory access"
f2fs: cleanup the code in build_sit_entries.
f2fs: fix wrong available node count calculation
f2fs: remove duplicate code in f2fs_file_write_iter
f2fs: fix to migrate blocks correctly during defragment
f2fs: use wrapped f2fs_cp_error()
f2fs: fix to use more generic EOPNOTSUPP
f2fs: use wrapped IS_SWAPFILE()
f2fs: Support case-insensitive file name lookups
f2fs: include charset encoding information in the superblock
fs: Reserve flag for casefolding
f2fs: fix to avoid call kvfree under spinlock
fs: f2fs: Remove unnecessary checks of SM_I(sbi) in update_general_status()
f2fs: disallow direct IO in atomic write
f2fs: fix to handle quota_{on,off} correctly
f2fs: fix to detect cp error in f2fs_setxattr()
f2fs: fix to spread f2fs_is_checkpoint_ready()
f2fs: support fiemap() for directory inode
f2fs: fix to avoid discard command leak
f2fs: fix to avoid tagging SBI_QUOTA_NEED_REPAIR incorrectly
f2fs: fix to drop meta/node pages during umount
f2fs: disallow switching io_bits option during remount
f2fs: fix panic of IO alignment feature
f2fs: introduce {page,io}_is_mergeable() for readability
f2fs: fix livelock in swapfile writes
f2fs: add fs-verity support
ext4: update on-disk format documentation for fs-verity
ext4: add fs-verity read support
ext4: add basic fs-verity support
fs-verity: support builtin file signatures
fs-verity: add SHA-512 support
fs-verity: implement FS_IOC_MEASURE_VERITY ioctl
fs-verity: implement FS_IOC_ENABLE_VERITY ioctl
fs-verity: add data verification hooks for ->readpages()
fs-verity: add the hook for file ->setattr()
fs-verity: add the hook for file ->open()
fs-verity: add inode and superblock fields
fs-verity: add Kconfig and the helper functions for hashing
fs: uapi: define verity bit for FS_IOC_GETFLAGS
fs-verity: add UAPI header
fs-verity: add MAINTAINERS file entry
fs-verity: add a documentation file
ext4: fix kernel oops caused by spurious casefold flag
ext4: fix coverity warning on error path of filename setup
ext4: optimize case-insensitive lookups
ext4: fix dcache lookup of !casefolded directories
unicode: update to Unicode 12.1.0 final
unicode: add missing check for an error return from utf8lookup()
ext4: export /sys/fs/ext4/feature/casefold if Unicode support is present
unicode: refactor the rule for regenerating utf8data.h
ext4: Support case-insensitive file name lookups
ext4: include charset encoding information in the superblock
unicode: update unicode database unicode version 12.1.0
unicode: introduce test module for normalized utf8 implementation
unicode: implement higher level API for string handling
unicode: reduce the size of utf8data[]
unicode: introduce code for UTF-8 normalization
unicode: introduce UTF-8 character database
ext4 crypto: fix to check feature status before get policy
fscrypt: document the new ioctls and policy version
ubifs: wire up new fscrypt ioctls
f2fs: wire up new fscrypt ioctls
ext4: wire up new fscrypt ioctls
fscrypt: require that key be added when setting a v2 encryption policy
fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY_ALL_USERS ioctl
fscrypt: allow unprivileged users to add/remove keys for v2 policies
fscrypt: v2 encryption policy support
fscrypt: add an HKDF-SHA512 implementation
fscrypt: add FS_IOC_GET_ENCRYPTION_KEY_STATUS ioctl
fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl
fscrypt: add FS_IOC_ADD_ENCRYPTION_KEY ioctl
fscrypt: rename keyinfo.c to keysetup.c
fscrypt: move v1 policy key setup to keysetup_v1.c
fscrypt: refactor key setup code in preparation for v2 policies
fscrypt: rename fscrypt_master_key to fscrypt_direct_key
fscrypt: add ->ci_inode to fscrypt_info
fscrypt: use FSCRYPT_* definitions, not FS_*
fscrypt: use FSCRYPT_ prefix for uapi constants
fs, fscrypt: move uapi definitions to new header <linux/fscrypt.h>
fscrypt: use ENOPKG when crypto API support missing
fscrypt: improve warnings for missing crypto API support
fscrypt: improve warning messages for unsupported encryption contexts
fscrypt: make fscrypt_msg() take inode instead of super_block
fscrypt: clean up base64 encoding/decoding
fscrypt: remove loadable module related code
ANDROID: arm64: bpf: implement arch_bpf_jit_check_func
ANDROID: bpf: validate bpf_func when BPF_JIT is enabled with CFI
UPSTREAM: kcm: use BPF_PROG_RUN
UPSTREAM: psi: get poll_work to run when calling poll syscall next time
UPSTREAM: sched/psi: Do not require setsched permission from the trigger creator
UPSTREAM: sched/psi: Reduce psimon FIFO priority
BACKPORT: arm64: Add support for relocating the kernel with RELR relocations
ANDROID: Log which device failed to suspend in dpm_suspend_start()
ANDROID: Revert "ANDROID: sched: Disallow WALT with CFS bandwidth control"
ANDROID: sched: WALT: Add support for CFS_BANDWIDTH
ANDROID: sched: WALT: Refactor cumulative runnable average fixup
ANDROID: sched: Disallow WALT with CFS bandwidth control
fscrypt: document testing with xfstests
fscrypt: remove selection of CONFIG_CRYPTO_SHA256
fscrypt: remove unnecessary includes of ratelimit.h
fscrypt: don't set policy for a dead directory
fscrypt: decrypt only the needed blocks in __fscrypt_decrypt_bio()
fscrypt: support decrypting multiple filesystem blocks per page
fscrypt: introduce fscrypt_decrypt_block_inplace()
fscrypt: handle blocksize < PAGE_SIZE in fscrypt_zeroout_range()
fscrypt: support encrypting multiple filesystem blocks per page
fscrypt: introduce fscrypt_encrypt_block_inplace()
fscrypt: clean up some BUG_ON()s in block encryption/decryption
fscrypt: rename fscrypt_do_page_crypto() to fscrypt_crypt_block()
fscrypt: remove the "write" part of struct fscrypt_ctx
fscrypt: simplify bounce page handling
ANDROID: fiq_debugger: remove
UPSTREAM: lib/test_meminit.c: use GFP_ATOMIC in RCU critical section
UPSTREAM: mm: slub: Fix slab walking for init_on_free
UPSTREAM: lib/test_meminit.c: minor test fixes
UPSTREAM: lib/test_meminit.c: fix -Wmaybe-uninitialized false positive
UPSTREAM: lib: introduce test_meminit module
UPSTREAM: mm: init: report memory auto-initialization features at boot time
BACKPORT: mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
UPSTREAM: arm64: move jump_label_init() before parse_early_param()
ANDROID: Add a tracepoint for mapping inode to full path
BACKPORT: arch: add pidfd and io_uring syscalls everywhere
UPSTREAM: dma-buf: add show_fdinfo handler
UPSTREAM: dma-buf: add DMA_BUF_SET_NAME ioctls
BACKPORT: dma-buf: give each buffer a full-fledged inode
ANDROID: fix kernelci build-break
UPSTREAM: drm/virtio: Fix cache entry creation race.
UPSTREAM: drm/virtio: Wake up all waiters when capset response comes in.
UPSTREAM: drm/virtio: Ensure cached capset entries are valid before copying.
UPSTREAM: drm/virtio: use u64_to_user_ptr macro
UPSTREAM: drm/virtio: remove irrelevant DRM_UNLOCKED flag
UPSTREAM: drm/virtio: Remove redundant return type
UPSTREAM: drm/virtio: allocate fences with GFP_KERNEL
UPSTREAM: drm/virtio: add trace events for commands
UPSTREAM: drm/virtio: trace drm_fence_emit
BACKPORT: drm/virtio: set seqno for dma-fence
BACKPORT: drm/virtio: move drm_connector_update_edid_property() call
UPSTREAM: drm/virtio: add missing drm_atomic_helper_shutdown() call.
BACKPORT: drm/virtio: rework resource creation workflow.
UPSTREAM: drm/virtio: params struct for virtio_gpu_cmd_create_resource_3d()
BACKPORT: drm/virtio: params struct for virtio_gpu_cmd_create_resource()
BACKPORT: drm/virtio: use struct to pass params to virtio_gpu_object_create()
UPSTREAM: drm/virtio: add virtio-gpu-features debugfs file.
UPSTREAM: drm/virtio: remove set but not used variable 'vgdev'
BACKPORT: drm/virtio: implement prime export
UPSTREAM: drm/virtio: remove prime pin/unpin callbacks.
UPSTREAM: drm/virtio: implement prime mmap
UPSTREAM: drm/virtio: drop virtio_gpu_fence_cleanup()
UPSTREAM: drm/virtio: fix pageflip flush
UPSTREAM: drm/virtio: log error responses
UPSTREAM: drm/virtio: Add missing virtqueue reset
UPSTREAM: drm/virtio: Remove incorrect kfree()
UPSTREAM: drm/virtio: virtio_gpu_cmd_resource_create_3d: drop unused fence arg
UPSTREAM: drm/virtio: fence: pass plain pointer
BACKPORT: drm/virtio: add edid support
UPSTREAM: virtio-gpu: add VIRTIO_GPU_F_EDID feature
BACKPORT: drm/virtio: fix memory leak of vfpriv on error return path
UPSTREAM: drm/virtio: bump driver version after explicit synchronization addition
UPSTREAM: drm/virtio: add in/out fence support for explicit synchronization
UPSTREAM: drm/virtio: add uapi for in and out explicit fences
UPSTREAM: drm/virtio: add virtio_gpu_alloc_fence()
UPSTREAM: drm/virtio: Handle error from virtio_gpu_resource_id_get
UPSTREAM: gpu/drm/virtio/virtgpu_vq.c: Use kmem_cache_zalloc
UPSTREAM: drm/virtio: fix resource id handling
UPSTREAM: drm/virtio: drop resource_id argument.
UPSTREAM: drm/virtio: use virtio_gpu_object->hw_res_handle in virtio_gpu_resource_create_ioctl()
UPSTREAM: drm/virtio: use virtio_gpu_object->hw_res_handle in virtio_gpu_mode_dumb_create()
UPSTREAM: drm/virtio: use virtio_gpu_object->hw_res_handle in virtio_gpufb_create()
BACKPORT: drm/virtio: track created object state
UPSTREAM: drm/virtio: document drm_dev_set_unique workaround
UPSTREAM: virtio: Support prime objects vmap/vunmap
UPSTREAM: virtio: Rework virtio_gpu_object_kmap()
UPSTREAM: virtio: Add virtio_gpu_object_kunmap()
UPSTREAM: drm/virtio: pass virtio_gpu_object to virtio_gpu_cmd_transfer_to_host_{2d, 3d}
UPSTREAM: drm/virtio: add dma sync for dma mapped virtio gpu framebuffer pages
UPSTREAM: drm/virtio: Remove set but not used variable 'bo'
UPSTREAM: drm/virtio: add iommu support.
UPSTREAM: drm/virtio: add virtio_gpu_object_detach() function
UPSTREAM: drm/virtio: track virtual output state
UPSTREAM: drm/virtio: fix bounds check in virtio_gpu_cmd_get_capset()
UPSTREAM: gpu: drm: virtio: code cleanup
UPSTREAM: drm/virtio: Place GEM BOs in drm_framebuffer
UPSTREAM: drm/virtio: fix mode_valid's return type
UPSTREAM: drm/virtio: Add spaces around operators
UPSTREAM: drm/virtio: Remove multiple blank lines
UPSTREAM: drm/virtio: Replace 'unsigned' for 'unsigned int'
UPSTREAM: drm/virtio: Remove return from void function
UPSTREAM: drm/virtio: Add */ in block comments to separate line
UPSTREAM: drm/virtio: Add blank line after variable declarations
UPSTREAM: drm/virtio: Add tabs at the start of a line
UPSTREAM: drm/virtio: Don't return invalid caps on timeout
UPSTREAM: virtgpu: remove redundant task_comm copying
UPSTREAM: drm/virtio: add create_handle support.
UPSTREAM: drm: virtio: replace reference/unreference with get/put
UPSTREAM: drm/virtio: Replace instances of reference/unreference with get/put
UPSTREAM: drm: byteorder: add DRM_FORMAT_HOST_*
UPSTREAM: drm: add drm_connector_attach_edid_property()
BACKPORT: drm/prime: Add drm_gem_prime_mmap()
f2fs: fix build error on android tracepoints
ANDROID: cuttlefish_defconfig: Enable CAN/VCAN
UPSTREAM: pidfd: fix a poll race when setting exit_state
BACKPORT: arch: wire-up pidfd_open()
BACKPORT: pid: add pidfd_open()
UPSTREAM: pidfd: add polling support
UPSTREAM: signal: improve comments
UPSTREAM: fork: do not release lock that wasn't taken
BACKPORT: signal: support CLONE_PIDFD with pidfd_send_signal
BACKPORT: clone: add CLONE_PIDFD
UPSTREAM: Make anon_inodes unconditional
UPSTREAM: signal: use fdget() since we don't allow O_PATH
UPSTREAM: signal: don't silently convert SI_USER signals to non-current pidfd
BACKPORT: signal: add pidfd_send_signal() syscall
UPSTREAM: net-ipv6-ndisc: add support for RFC7710 RA Captive Portal Identifier
ANDROID: fix up 9p filesystem due to CFI non-upstream patches
f2fs: use EINVAL for superblock with invalid magic
f2fs: fix to read source block before invalidating it
f2fs: remove redundant check from f2fs_setflags_common()
f2fs: use generic checking function for FS_IOC_FSSETXATTR
f2fs: use generic checking and prep function for FS_IOC_SETFLAGS
ubifs, fscrypt: cache decrypted symlink target in ->i_link
vfs: use READ_ONCE() to access ->i_link
fs, fscrypt: clear DCACHE_ENCRYPTED_NAME when unaliasing directory
ANDROID: (arm64) cuttlefish_defconfig: enable CONFIG_CPU_FREQ_TIMES
ANDROID: xfrm: remove in_compat_syscall() checks
ANDROID: enable CONFIG_RTC_DRV_TEST on cuttlefish
UPSTREAM: binder: Set end of SG buffer area properly.
ANDROID: x86_64_cuttlefish_defconfig: enable CONFIG_CPU_FREQ_TIMES
ANDROID: f2fs: add android fsync tracepoint
ANDROID: f2fs: fix wrong android tracepoint
fscrypt: cache decrypted symlink target in ->i_link
fscrypt: fix race where ->lookup() marks plaintext dentry as ciphertext
fscrypt: only set dentry_operations on ciphertext dentries
fscrypt: fix race allowing rename() and link() of ciphertext dentries
fscrypt: clean up and improve dentry revalidation
fscrypt: use READ_ONCE() to access ->i_crypt_info
fscrypt: remove WARN_ON_ONCE() when decryption fails
fscrypt: drop inode argument from fscrypt_get_ctx()
f2fs: improve print log in f2fs_sanity_check_ckpt()
f2fs: avoid out-of-range memory access
f2fs: fix to avoid long latency during umount
f2fs: allow all the users to pin a file
f2fs: support swap file w/ DIO
f2fs: allocate blocks for pinned file
f2fs: fix is_idle() check for discard type
f2fs: add a rw_sem to cover quota flag changes
f2fs: set SBI_NEED_FSCK for xattr corruption case
f2fs: use generic EFSBADCRC/EFSCORRUPTED
f2fs: Use DIV_ROUND_UP() instead of open-coding
f2fs: print kernel message if filesystem is inconsistent
f2fs: introduce f2fs_<level> macros to wrap f2fs_printk()
f2fs: avoid get_valid_blocks() for cleanup
f2fs: ioctl for removing a range from F2FS
f2fs: only set project inherit bit for directory
f2fs: separate f2fs i_flags from fs_flags and ext4 i_flags
UPSTREAM: kasan: initialize tag to 0xff in __kasan_kmalloc
UPSTREAM: x86/boot: Provide KASAN compatible aliases for string routines
UPSTREAM: mm/kasan: Remove the ULONG_MAX stack trace hackery
UPSTREAM: x86/uaccess, kasan: Fix KASAN vs SMAP
UPSTREAM: x86/uaccess: Introduce user_access_{save,restore}()
UPSTREAM: kasan: fix variable 'tag' set but not used warning
UPSTREAM: Revert "x86_64: Increase stack size for KASAN_EXTRA"
UPSTREAM: kasan: fix coccinelle warnings in kasan_p*_table
UPSTREAM: kasan: fix kasan_check_read/write definitions
BACKPORT: kasan: remove use after scope bugs detection.
BACKPORT: kasan: turn off asan-stack for clang-8 and earlier
UPSTREAM: slub: fix a crash with SLUB_DEBUG + KASAN_SW_TAGS
UPSTREAM: kasan, slab: remove redundant kasan_slab_alloc hooks
UPSTREAM: kasan, slab: make freelist stored without tags
UPSTREAM: kasan, slab: fix conflicts with CONFIG_HARDENED_USERCOPY
UPSTREAM: kasan: prevent tracing of tags.c
UPSTREAM: kasan: fix random seed generation for tag-based mode
UPSTREAM: slub: fix SLAB_CONSISTENCY_CHECKS + KASAN_SW_TAGS
UPSTREAM: kasan, slub: fix more conflicts with CONFIG_SLAB_FREELIST_HARDENED
UPSTREAM: kasan, slub: fix conflicts with CONFIG_SLAB_FREELIST_HARDENED
UPSTREAM: kasan, slub: move kasan_poison_slab hook before page_address
UPSTREAM: kasan, kmemleak: pass tagged pointers to kmemleak
UPSTREAM: kasan: fix assigning tags twice
UPSTREAM: kasan: mark file common so ftrace doesn't trace it
UPSTREAM: kasan, arm64: remove redundant ARCH_SLAB_MINALIGN define
UPSTREAM: kasan: fix krealloc handling for tag-based mode
UPSTREAM: kasan: make tag based mode work with CONFIG_HARDENED_USERCOPY
UPSTREAM: kasan, arm64: use ARCH_SLAB_MINALIGN instead of manual aligning
BACKPORT: mm/memblock.c: skip kmemleak for kasan_init()
UPSTREAM: kasan: add SPDX-License-Identifier mark to source files
BACKPORT: kasan: update documentation
UPSTREAM: kasan, arm64: select HAVE_ARCH_KASAN_SW_TAGS
UPSTREAM: kasan: add __must_check annotations to kasan hooks
BACKPORT: kasan, mm, arm64: tag non slab memory allocated via pagealloc
UPSTREAM: kasan, arm64: add brk handler for inline instrumentation
UPSTREAM: kasan: add hooks implementation for tag-based mode
UPSTREAM: mm: move obj_to_index to include/linux/slab_def.h
UPSTREAM: kasan: add bug reporting routines for tag-based mode
UPSTREAM: kasan: split out generic_report.c from report.c
UPSTREAM: kasan, mm: perform untagged pointers comparison in krealloc
BACKPORT: kasan, arm64: enable top byte ignore for the kernel
BACKPORT: kasan, arm64: fix up fault handling logic
UPSTREAM: kasan: preassign tags to objects with ctors or SLAB_TYPESAFE_BY_RCU
UPSTREAM: kasan, arm64: untag address in _virt_addr_is_linear
UPSTREAM: kasan: add tag related helper functions
BACKPORT: arm64: move untagged_addr macro from uaccess.h to memory.h
BACKPORT: kasan: initialize shadow to 0xff for tag-based mode
BACKPORT: kasan: rename kasan_zero_page to kasan_early_shadow_page
BACKPORT: kasan, arm64: adjust shadow size for tag-based mode
BACKPORT: kasan: add CONFIG_KASAN_GENERIC and CONFIG_KASAN_SW_TAGS
UPSTREAM: kasan: rename source files to reflect the new naming scheme
BACKPORT: kasan: move common generic and tag-based code to common.c
UPSTREAM: kasan, slub: handle pointer tags in early_kmem_cache_node_alloc
UPSTREAM: kasan, mm: change hooks signatures
UPSTREAM: arm64: add EXPORT_SYMBOL_NOKASAN()
BACKPORT: compiler: remove __no_sanitize_address_or_inline again
UPSTREAM: mm/kasan/quarantine.c: make quarantine_lock a raw_spinlock_t
UPSTREAM: lib/test_kasan.c: add tests for several string/memory API functions
UPSTREAM: arm64: lib: use C string functions with KASAN enabled
UPSTREAM: compiler: introduce __no_sanitize_address_or_inline
UPSTREAM: arm64: Fix typo in a comment in arch/arm64/mm/kasan_init.c
BACKPORT: kernel/memremap, kasan: make ZONE_DEVICE with work with KASAN
BACKPORT: mm/mempool.c: remove unused argument in kasan_unpoison_element() and remove_element()
UPSTREAM: kasan: only select SLUB_DEBUG with SYSFS=y
UPSTREAM: kasan: depend on CONFIG_SLUB_DEBUG
UPSTREAM: KASAN: prohibit KASAN+STRUCTLEAK combination
UPSTREAM: arm64: kasan: avoid pfn_to_nid() before page array is initialized
UPSTREAM: kasan: fix invalid-free test crashing the kernel
UPSTREAM: kasan, slub: fix handling of kasan_slab_free hook
UPSTREAM: slab, slub: skip unnecessary kasan_cache_shutdown()
BACKPORT: kasan: make kasan_cache_create() work with 32-bit slab cache sizes
UPSTREAM: locking/atomics: Instrument cmpxchg_double*()
UPSTREAM: locking/atomics: Instrument xchg()
UPSTREAM: locking/atomics: Simplify cmpxchg() instrumentation
UPSTREAM: locking/atomics/x86: Reduce arch_cmpxchg64*() instrumentation
UPSTREAM: locking/atomic, asm-generic, x86: Add comments for atomic instrumentation
UPSTREAM: locking/atomic, asm-generic: Add KASAN instrumentation to atomic operations
UPSTREAM: locking/atomic/x86: Switch atomic.h to use atomic-instrumented.h
UPSTREAM: locking/atomic, asm-generic: Add asm-generic/atomic-instrumented.h
BACKPORT: kasan, arm64: clean up KASAN_SHADOW_SCALE_SHIFT usage
UPSTREAM: kasan: clean up KASAN_SHADOW_SCALE_SHIFT usage
UPSTREAM: kasan: fix prototype author email address
UPSTREAM: kasan: detect invalid frees
UPSTREAM: kasan: unify code between kasan_slab_free() and kasan_poison_kfree()
UPSTREAM: kasan: detect invalid frees for large mempool objects
UPSTREAM: kasan: don't use __builtin_return_address(1)
UPSTREAM: kasan: detect invalid frees for large objects
UPSTREAM: kasan: add functions for unpoisoning stack variables
UPSTREAM: kasan: add tests for alloca poisoning
UPSTREAM: kasan: support alloca() poisoning
UPSTREAM: kasan/Makefile: support LLVM style asan parameters
BACKPORT: kasan: add compiler support for clang
BACKPORT: fs: dcache: Revert "manually unpoison dname after allocation to shut up kasan's reports"
UPSTREAM: fs/dcache: Use read_word_at_a_time() in dentry_string_cmp()
UPSTREAM: lib/strscpy: Shut up KASAN false-positives in strscpy()
UPSTREAM: compiler.h: Add read_word_at_a_time() function.
UPSTREAM: compiler.h, kasan: Avoid duplicating __read_once_size_nocheck()
UPSTREAM: arm64/mm/kasan: don't use vmemmap_populate() to initialize shadow
UPSTREAM: Documentation/features/KASAN: mark KASAN as supported only on 64-bit on x86
f2fs: Add option to limit required GC for checkpoint=disable
f2fs: Fix accounting for unusable blocks
f2fs: Fix root reserved on remount
f2fs: Lower threshold for disable_cp_again
f2fs: fix sparse warning
f2fs: fix f2fs_show_options to show nodiscard mount option
f2fs: add error prints for debugging mount failure
f2fs: fix to do sanity check on segment bitmap of LFS curseg
f2fs: add missing sysfs entries in documentation
f2fs: fix to avoid deadloop if data_flush is on
f2fs: always assume that the device is idle under gc_urgent
f2fs: add bio cache for IPU
f2fs: allow ssr block allocation during checkpoint=disable period
f2fs: fix to check layout on last valid checkpoint park
Conflicts:
arch/arm64/configs/cuttlefish_defconfig
arch/arm64/include/asm/memory.h
arch/arm64/include/asm/thread_info.h
arch/x86/configs/x86_64_cuttlefish_defconfig
build.config.common
drivers/dma-buf/dma-buf.c
fs/crypto/Makefile
fs/crypto/bio.c
fs/crypto/fscrypt_private.h
fs/crypto/keyinfo.c
fs/ext4/page-io.c
fs/f2fs/data.c
fs/f2fs/f2fs.h
fs/f2fs/inode.c
fs/f2fs/segment.c
fs/userfaultfd.c
include/linux/dma-buf.h
include/linux/fscrypt.h
include/linux/kasan.h
include/linux/platform_data/ds2482.h
include/uapi/linux/fs.h
kernel/sched/deadline.c
kernel/sched/fair.c
kernel/sched/rt.c
kernel/sched/sched.h
kernel/sched/stop_task.c
kernel/sched/walt.c
kernel/sched/walt.h
lib/test_kasan.c
mm/kasan/common.c
mm/kasan/kasan.h
mm/kasan/report.c
mm/slub.c
mm/vmalloc.c
scripts/Makefile.kasan
Changed below files to fix build errors:
drivers/char/diag/diagchar_core.c
drivers/power/supply/qcom/battery.c
drivers/power/supply/qcom/smb1390-charger-psy.c
drivers/power/supply/qcom/smb1390-charger.c
drivers/power/supply/qcom/step-chg-jeita.c
fs/crypto/fscrypt_ice.c
fs/crypto/fscrypt_private.h
fs/f2fs/inode.c
include/uapi/linux/fscrypt.h
net/qrtr/qrtr.c
gen_headers_arm.bp
gen_headers_arm64.bp
Extra added fixes in fs/f2fs/data.c for FBE:
* Fix FBE regression with 9937c21ce1 ("f2fs: add bio cache
for IPU"). The above commit is not setting the DUN for
bio, due to which the bio's could get corrupted when FBE
is enabled.
* The f2fs_merge_page_bio() incorrectly uses the bio after
it is submitted for IO when fscrypt_mergeable_bio()
returns false. Fix it by making the submitted bio NULL
so that a new bio gets allocated for the next/new page.
Ignored the below scheduler patches as they are already present:
ANDROID: sched: WALT: Add support for CFS_BANDWIDTH
ANDROID: sched: WALT: Refactor cumulative runnable average fixup
picked below patches from 4.14.159 and 4.14.172 versions to fix issues
0e39aa9d5 "UPSTREAM: arm64: Validate tagged addresses in access_ok() called from kernel threads"
352902650 "fscrypt: support passing a keyring key to FS_IOC_ADD_ENCRYPTION_KEY"
Change-Id: I205b796ee125fa6e9d27fa30f881e4e8fe8bea29
Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
Signed-off-by: Blagovest Kolenichev <bkolenichev@codeaurora.org>
5 years ago
|
|
|
[FSCRYPT_MODE_PRIVATE] = {
|
|
|
|
|
.friendly_name = "ice",
|
|
|
|
|
.cipher_str = "xts(aes)",
|
Merge android-4.14.151 (2bb70f4) into msm-4.14
* refs/heads/tmp-2bb70f4:
ANDROID: virtio: virtio_input: Set the amount of multitouch slots in virtio input
ANDROID: dummy_cpufreq: Implement get()
rtlwifi: Fix potential overflow on P2P code
ANDROID: cpufreq: create dummy cpufreq driver
ANDROID: Allow DRM_IOCTL_MODE_*_DUMB for render clients.
ANDROID: sdcardfs: evict dentries on fscrypt key removal
ANDROID: fscrypt: add key removal notifier chain
ANDROID: Move from clang r353983c to r365631c
ANDROID: move up spin_unlock_bh() ahead of remove_proc_entry()
BACKPORT: arm64: tags: Preserve tags for addresses translated via TTBR1
UPSTREAM: arm64: memory: Implement __tag_set() as common function
UPSTREAM: arm64/mm: fix variable 'tag' set but not used
UPSTREAM: arm64: avoid clang warning about self-assignment
ANDROID: refactor build.config files to remove duplication
UPSTREAM: mm: vmalloc: show number of vmalloc pages in /proc/meminfo
BACKPORT: PM/sleep: Expose suspend stats in sysfs
UPSTREAM: power: supply: Init device wakeup after device_add()
UPSTREAM: PM / wakeup: Unexport wakeup_source_sysfs_{add,remove}()
UPSTREAM: PM / wakeup: Register wakeup class kobj after device is added
BACKPORT: PM / wakeup: Fix sysfs registration error path
BACKPORT: PM / wakeup: Show wakeup sources stats in sysfs
UPSTREAM: PM / wakeup: Print warn if device gets enabled as wakeup source during sleep
UPSTREAM: PM / wakeup: Use wakeup_source_register() in wakelock.c
UPSTREAM: PM / wakeup: Only update last time for active wakeup sources
UPSTREAM: PM / core: Add support to skip power management in device/driver model
cuttlefish-4.14: Enable CONFIG_DM_SNAPSHOT
ANDROID: cuttlefish_defconfig: Enable BPF_JIT and BPF_JIT_ALWAYS_ON
UPSTREAM: netfilter: xt_IDLETIMER: fix sysfs callback function type
UPSTREAM: mm: untag user pointers in mmap/munmap/mremap/brk
UPSTREAM: vfio/type1: untag user pointers in vaddr_get_pfn
UPSTREAM: media/v4l2-core: untag user pointers in videobuf_dma_contig_user_get
UPSTREAM: drm/radeon: untag user pointers in radeon_gem_userptr_ioctl
BACKPORT: drm/amdgpu: untag user pointers
UPSTREAM: userfaultfd: untag user pointers
UPSTREAM: fs/namespace: untag user pointers in copy_mount_options
UPSTREAM: mm: untag user pointers in get_vaddr_frames
UPSTREAM: mm: untag user pointers in mm/gup.c
BACKPORT: mm: untag user pointers passed to memory syscalls
BACKPORT: lib: untag user pointers in strn*_user
UPSTREAM: arm64: Fix reference to docs for ARM64_TAGGED_ADDR_ABI
UPSTREAM: selftests, arm64: add kernel headers path for tags_test
BACKPORT: arm64: Relax Documentation/arm64/tagged-pointers.rst
UPSTREAM: arm64: Define Documentation/arm64/tagged-address-abi.rst
UPSTREAM: arm64: Change the tagged_addr sysctl control semantics to only prevent the opt-in
UPSTREAM: arm64: Tighten the PR_{SET, GET}_TAGGED_ADDR_CTRL prctl() unused arguments
UPSTREAM: selftests, arm64: fix uninitialized symbol in tags_test.c
UPSTREAM: arm64: mm: Really fix sparse warning in untagged_addr()
UPSTREAM: selftests, arm64: add a selftest for passing tagged pointers to kernel
BACKPORT: arm64: Introduce prctl() options to control the tagged user addresses ABI
UPSTREAM: thread_info: Add update_thread_flag() helpers
UPSTREAM: arm64: untag user pointers in access_ok and __uaccess_mask_ptr
UPSTREAM: uaccess: add noop untagged_addr definition
BACKPORT: block: annotate refault stalls from IO submission
ext4: add verity flag check for dax
ANDROID: usb: gadget: Fix dependency for f_accessory
ANDROID: sched: fair: balance for single core cluster
UPSTREAM: mm/kasan: fix false positive invalid-free reports with CONFIG_KASAN_SW_TAGS=y
f2fs: add a condition to detect overflow in f2fs_ioc_gc_range()
f2fs: fix to add missing F2FS_IO_ALIGNED() condition
f2fs: fix to fallback to buffered IO in IO aligned mode
f2fs: fix to handle error path correctly in f2fs_map_blocks
f2fs: fix extent corrupotion during directIO in LFS mode
f2fs: check all the data segments against all node ones
f2fs: Add a small clarification to CONFIG_FS_F2FS_FS_SECURITY
f2fs: fix inode rwsem regression
f2fs: fix to avoid accessing uninitialized field of inode page in is_alive()
f2fs: avoid infinite GC loop due to stale atomic files
f2fs: Fix indefinite loop in f2fs_gc()
f2fs: convert inline_data in prior to i_size_write
f2fs: fix error path of f2fs_convert_inline_page()
f2fs: add missing documents of reserve_root/resuid/resgid
f2fs: fix flushing node pages when checkpoint is disabled
f2fs: enhance f2fs_is_checkpoint_ready()'s readability
f2fs: clean up __bio_alloc()'s parameter
f2fs: fix wrong error injection path in inc_valid_block_count()
f2fs: fix to writeout dirty inode during node flush
f2fs: optimize case-insensitive lookups
f2fs: introduce f2fs_match_name() for cleanup
f2fs: Fix indefinite loop in f2fs_gc()
f2fs: allocate memory in batch in build_sit_info()
f2fs: fix to avoid data corruption by forbidding SSR overwrite
f2fs: Fix build error while CONFIG_NLS=m
Revert "f2fs: avoid out-of-range memory access"
f2fs: cleanup the code in build_sit_entries.
f2fs: fix wrong available node count calculation
f2fs: remove duplicate code in f2fs_file_write_iter
f2fs: fix to migrate blocks correctly during defragment
f2fs: use wrapped f2fs_cp_error()
f2fs: fix to use more generic EOPNOTSUPP
f2fs: use wrapped IS_SWAPFILE()
f2fs: Support case-insensitive file name lookups
f2fs: include charset encoding information in the superblock
fs: Reserve flag for casefolding
f2fs: fix to avoid call kvfree under spinlock
fs: f2fs: Remove unnecessary checks of SM_I(sbi) in update_general_status()
f2fs: disallow direct IO in atomic write
f2fs: fix to handle quota_{on,off} correctly
f2fs: fix to detect cp error in f2fs_setxattr()
f2fs: fix to spread f2fs_is_checkpoint_ready()
f2fs: support fiemap() for directory inode
f2fs: fix to avoid discard command leak
f2fs: fix to avoid tagging SBI_QUOTA_NEED_REPAIR incorrectly
f2fs: fix to drop meta/node pages during umount
f2fs: disallow switching io_bits option during remount
f2fs: fix panic of IO alignment feature
f2fs: introduce {page,io}_is_mergeable() for readability
f2fs: fix livelock in swapfile writes
f2fs: add fs-verity support
ext4: update on-disk format documentation for fs-verity
ext4: add fs-verity read support
ext4: add basic fs-verity support
fs-verity: support builtin file signatures
fs-verity: add SHA-512 support
fs-verity: implement FS_IOC_MEASURE_VERITY ioctl
fs-verity: implement FS_IOC_ENABLE_VERITY ioctl
fs-verity: add data verification hooks for ->readpages()
fs-verity: add the hook for file ->setattr()
fs-verity: add the hook for file ->open()
fs-verity: add inode and superblock fields
fs-verity: add Kconfig and the helper functions for hashing
fs: uapi: define verity bit for FS_IOC_GETFLAGS
fs-verity: add UAPI header
fs-verity: add MAINTAINERS file entry
fs-verity: add a documentation file
ext4: fix kernel oops caused by spurious casefold flag
ext4: fix coverity warning on error path of filename setup
ext4: optimize case-insensitive lookups
ext4: fix dcache lookup of !casefolded directories
unicode: update to Unicode 12.1.0 final
unicode: add missing check for an error return from utf8lookup()
ext4: export /sys/fs/ext4/feature/casefold if Unicode support is present
unicode: refactor the rule for regenerating utf8data.h
ext4: Support case-insensitive file name lookups
ext4: include charset encoding information in the superblock
unicode: update unicode database unicode version 12.1.0
unicode: introduce test module for normalized utf8 implementation
unicode: implement higher level API for string handling
unicode: reduce the size of utf8data[]
unicode: introduce code for UTF-8 normalization
unicode: introduce UTF-8 character database
ext4 crypto: fix to check feature status before get policy
fscrypt: document the new ioctls and policy version
ubifs: wire up new fscrypt ioctls
f2fs: wire up new fscrypt ioctls
ext4: wire up new fscrypt ioctls
fscrypt: require that key be added when setting a v2 encryption policy
fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY_ALL_USERS ioctl
fscrypt: allow unprivileged users to add/remove keys for v2 policies
fscrypt: v2 encryption policy support
fscrypt: add an HKDF-SHA512 implementation
fscrypt: add FS_IOC_GET_ENCRYPTION_KEY_STATUS ioctl
fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl
fscrypt: add FS_IOC_ADD_ENCRYPTION_KEY ioctl
fscrypt: rename keyinfo.c to keysetup.c
fscrypt: move v1 policy key setup to keysetup_v1.c
fscrypt: refactor key setup code in preparation for v2 policies
fscrypt: rename fscrypt_master_key to fscrypt_direct_key
fscrypt: add ->ci_inode to fscrypt_info
fscrypt: use FSCRYPT_* definitions, not FS_*
fscrypt: use FSCRYPT_ prefix for uapi constants
fs, fscrypt: move uapi definitions to new header <linux/fscrypt.h>
fscrypt: use ENOPKG when crypto API support missing
fscrypt: improve warnings for missing crypto API support
fscrypt: improve warning messages for unsupported encryption contexts
fscrypt: make fscrypt_msg() take inode instead of super_block
fscrypt: clean up base64 encoding/decoding
fscrypt: remove loadable module related code
ANDROID: arm64: bpf: implement arch_bpf_jit_check_func
ANDROID: bpf: validate bpf_func when BPF_JIT is enabled with CFI
UPSTREAM: kcm: use BPF_PROG_RUN
UPSTREAM: psi: get poll_work to run when calling poll syscall next time
UPSTREAM: sched/psi: Do not require setsched permission from the trigger creator
UPSTREAM: sched/psi: Reduce psimon FIFO priority
BACKPORT: arm64: Add support for relocating the kernel with RELR relocations
ANDROID: Log which device failed to suspend in dpm_suspend_start()
ANDROID: Revert "ANDROID: sched: Disallow WALT with CFS bandwidth control"
ANDROID: sched: WALT: Add support for CFS_BANDWIDTH
ANDROID: sched: WALT: Refactor cumulative runnable average fixup
ANDROID: sched: Disallow WALT with CFS bandwidth control
fscrypt: document testing with xfstests
fscrypt: remove selection of CONFIG_CRYPTO_SHA256
fscrypt: remove unnecessary includes of ratelimit.h
fscrypt: don't set policy for a dead directory
fscrypt: decrypt only the needed blocks in __fscrypt_decrypt_bio()
fscrypt: support decrypting multiple filesystem blocks per page
fscrypt: introduce fscrypt_decrypt_block_inplace()
fscrypt: handle blocksize < PAGE_SIZE in fscrypt_zeroout_range()
fscrypt: support encrypting multiple filesystem blocks per page
fscrypt: introduce fscrypt_encrypt_block_inplace()
fscrypt: clean up some BUG_ON()s in block encryption/decryption
fscrypt: rename fscrypt_do_page_crypto() to fscrypt_crypt_block()
fscrypt: remove the "write" part of struct fscrypt_ctx
fscrypt: simplify bounce page handling
ANDROID: fiq_debugger: remove
UPSTREAM: lib/test_meminit.c: use GFP_ATOMIC in RCU critical section
UPSTREAM: mm: slub: Fix slab walking for init_on_free
UPSTREAM: lib/test_meminit.c: minor test fixes
UPSTREAM: lib/test_meminit.c: fix -Wmaybe-uninitialized false positive
UPSTREAM: lib: introduce test_meminit module
UPSTREAM: mm: init: report memory auto-initialization features at boot time
BACKPORT: mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
UPSTREAM: arm64: move jump_label_init() before parse_early_param()
ANDROID: Add a tracepoint for mapping inode to full path
BACKPORT: arch: add pidfd and io_uring syscalls everywhere
UPSTREAM: dma-buf: add show_fdinfo handler
UPSTREAM: dma-buf: add DMA_BUF_SET_NAME ioctls
BACKPORT: dma-buf: give each buffer a full-fledged inode
ANDROID: fix kernelci build-break
UPSTREAM: drm/virtio: Fix cache entry creation race.
UPSTREAM: drm/virtio: Wake up all waiters when capset response comes in.
UPSTREAM: drm/virtio: Ensure cached capset entries are valid before copying.
UPSTREAM: drm/virtio: use u64_to_user_ptr macro
UPSTREAM: drm/virtio: remove irrelevant DRM_UNLOCKED flag
UPSTREAM: drm/virtio: Remove redundant return type
UPSTREAM: drm/virtio: allocate fences with GFP_KERNEL
UPSTREAM: drm/virtio: add trace events for commands
UPSTREAM: drm/virtio: trace drm_fence_emit
BACKPORT: drm/virtio: set seqno for dma-fence
BACKPORT: drm/virtio: move drm_connector_update_edid_property() call
UPSTREAM: drm/virtio: add missing drm_atomic_helper_shutdown() call.
BACKPORT: drm/virtio: rework resource creation workflow.
UPSTREAM: drm/virtio: params struct for virtio_gpu_cmd_create_resource_3d()
BACKPORT: drm/virtio: params struct for virtio_gpu_cmd_create_resource()
BACKPORT: drm/virtio: use struct to pass params to virtio_gpu_object_create()
UPSTREAM: drm/virtio: add virtio-gpu-features debugfs file.
UPSTREAM: drm/virtio: remove set but not used variable 'vgdev'
BACKPORT: drm/virtio: implement prime export
UPSTREAM: drm/virtio: remove prime pin/unpin callbacks.
UPSTREAM: drm/virtio: implement prime mmap
UPSTREAM: drm/virtio: drop virtio_gpu_fence_cleanup()
UPSTREAM: drm/virtio: fix pageflip flush
UPSTREAM: drm/virtio: log error responses
UPSTREAM: drm/virtio: Add missing virtqueue reset
UPSTREAM: drm/virtio: Remove incorrect kfree()
UPSTREAM: drm/virtio: virtio_gpu_cmd_resource_create_3d: drop unused fence arg
UPSTREAM: drm/virtio: fence: pass plain pointer
BACKPORT: drm/virtio: add edid support
UPSTREAM: virtio-gpu: add VIRTIO_GPU_F_EDID feature
BACKPORT: drm/virtio: fix memory leak of vfpriv on error return path
UPSTREAM: drm/virtio: bump driver version after explicit synchronization addition
UPSTREAM: drm/virtio: add in/out fence support for explicit synchronization
UPSTREAM: drm/virtio: add uapi for in and out explicit fences
UPSTREAM: drm/virtio: add virtio_gpu_alloc_fence()
UPSTREAM: drm/virtio: Handle error from virtio_gpu_resource_id_get
UPSTREAM: gpu/drm/virtio/virtgpu_vq.c: Use kmem_cache_zalloc
UPSTREAM: drm/virtio: fix resource id handling
UPSTREAM: drm/virtio: drop resource_id argument.
UPSTREAM: drm/virtio: use virtio_gpu_object->hw_res_handle in virtio_gpu_resource_create_ioctl()
UPSTREAM: drm/virtio: use virtio_gpu_object->hw_res_handle in virtio_gpu_mode_dumb_create()
UPSTREAM: drm/virtio: use virtio_gpu_object->hw_res_handle in virtio_gpufb_create()
BACKPORT: drm/virtio: track created object state
UPSTREAM: drm/virtio: document drm_dev_set_unique workaround
UPSTREAM: virtio: Support prime objects vmap/vunmap
UPSTREAM: virtio: Rework virtio_gpu_object_kmap()
UPSTREAM: virtio: Add virtio_gpu_object_kunmap()
UPSTREAM: drm/virtio: pass virtio_gpu_object to virtio_gpu_cmd_transfer_to_host_{2d, 3d}
UPSTREAM: drm/virtio: add dma sync for dma mapped virtio gpu framebuffer pages
UPSTREAM: drm/virtio: Remove set but not used variable 'bo'
UPSTREAM: drm/virtio: add iommu support.
UPSTREAM: drm/virtio: add virtio_gpu_object_detach() function
UPSTREAM: drm/virtio: track virtual output state
UPSTREAM: drm/virtio: fix bounds check in virtio_gpu_cmd_get_capset()
UPSTREAM: gpu: drm: virtio: code cleanup
UPSTREAM: drm/virtio: Place GEM BOs in drm_framebuffer
UPSTREAM: drm/virtio: fix mode_valid's return type
UPSTREAM: drm/virtio: Add spaces around operators
UPSTREAM: drm/virtio: Remove multiple blank lines
UPSTREAM: drm/virtio: Replace 'unsigned' for 'unsigned int'
UPSTREAM: drm/virtio: Remove return from void function
UPSTREAM: drm/virtio: Add */ in block comments to separate line
UPSTREAM: drm/virtio: Add blank line after variable declarations
UPSTREAM: drm/virtio: Add tabs at the start of a line
UPSTREAM: drm/virtio: Don't return invalid caps on timeout
UPSTREAM: virtgpu: remove redundant task_comm copying
UPSTREAM: drm/virtio: add create_handle support.
UPSTREAM: drm: virtio: replace reference/unreference with get/put
UPSTREAM: drm/virtio: Replace instances of reference/unreference with get/put
UPSTREAM: drm: byteorder: add DRM_FORMAT_HOST_*
UPSTREAM: drm: add drm_connector_attach_edid_property()
BACKPORT: drm/prime: Add drm_gem_prime_mmap()
f2fs: fix build error on android tracepoints
ANDROID: cuttlefish_defconfig: Enable CAN/VCAN
UPSTREAM: pidfd: fix a poll race when setting exit_state
BACKPORT: arch: wire-up pidfd_open()
BACKPORT: pid: add pidfd_open()
UPSTREAM: pidfd: add polling support
UPSTREAM: signal: improve comments
UPSTREAM: fork: do not release lock that wasn't taken
BACKPORT: signal: support CLONE_PIDFD with pidfd_send_signal
BACKPORT: clone: add CLONE_PIDFD
UPSTREAM: Make anon_inodes unconditional
UPSTREAM: signal: use fdget() since we don't allow O_PATH
UPSTREAM: signal: don't silently convert SI_USER signals to non-current pidfd
BACKPORT: signal: add pidfd_send_signal() syscall
UPSTREAM: net-ipv6-ndisc: add support for RFC7710 RA Captive Portal Identifier
ANDROID: fix up 9p filesystem due to CFI non-upstream patches
f2fs: use EINVAL for superblock with invalid magic
f2fs: fix to read source block before invalidating it
f2fs: remove redundant check from f2fs_setflags_common()
f2fs: use generic checking function for FS_IOC_FSSETXATTR
f2fs: use generic checking and prep function for FS_IOC_SETFLAGS
ubifs, fscrypt: cache decrypted symlink target in ->i_link
vfs: use READ_ONCE() to access ->i_link
fs, fscrypt: clear DCACHE_ENCRYPTED_NAME when unaliasing directory
ANDROID: (arm64) cuttlefish_defconfig: enable CONFIG_CPU_FREQ_TIMES
ANDROID: xfrm: remove in_compat_syscall() checks
ANDROID: enable CONFIG_RTC_DRV_TEST on cuttlefish
UPSTREAM: binder: Set end of SG buffer area properly.
ANDROID: x86_64_cuttlefish_defconfig: enable CONFIG_CPU_FREQ_TIMES
ANDROID: f2fs: add android fsync tracepoint
ANDROID: f2fs: fix wrong android tracepoint
fscrypt: cache decrypted symlink target in ->i_link
fscrypt: fix race where ->lookup() marks plaintext dentry as ciphertext
fscrypt: only set dentry_operations on ciphertext dentries
fscrypt: fix race allowing rename() and link() of ciphertext dentries
fscrypt: clean up and improve dentry revalidation
fscrypt: use READ_ONCE() to access ->i_crypt_info
fscrypt: remove WARN_ON_ONCE() when decryption fails
fscrypt: drop inode argument from fscrypt_get_ctx()
f2fs: improve print log in f2fs_sanity_check_ckpt()
f2fs: avoid out-of-range memory access
f2fs: fix to avoid long latency during umount
f2fs: allow all the users to pin a file
f2fs: support swap file w/ DIO
f2fs: allocate blocks for pinned file
f2fs: fix is_idle() check for discard type
f2fs: add a rw_sem to cover quota flag changes
f2fs: set SBI_NEED_FSCK for xattr corruption case
f2fs: use generic EFSBADCRC/EFSCORRUPTED
f2fs: Use DIV_ROUND_UP() instead of open-coding
f2fs: print kernel message if filesystem is inconsistent
f2fs: introduce f2fs_<level> macros to wrap f2fs_printk()
f2fs: avoid get_valid_blocks() for cleanup
f2fs: ioctl for removing a range from F2FS
f2fs: only set project inherit bit for directory
f2fs: separate f2fs i_flags from fs_flags and ext4 i_flags
UPSTREAM: kasan: initialize tag to 0xff in __kasan_kmalloc
UPSTREAM: x86/boot: Provide KASAN compatible aliases for string routines
UPSTREAM: mm/kasan: Remove the ULONG_MAX stack trace hackery
UPSTREAM: x86/uaccess, kasan: Fix KASAN vs SMAP
UPSTREAM: x86/uaccess: Introduce user_access_{save,restore}()
UPSTREAM: kasan: fix variable 'tag' set but not used warning
UPSTREAM: Revert "x86_64: Increase stack size for KASAN_EXTRA"
UPSTREAM: kasan: fix coccinelle warnings in kasan_p*_table
UPSTREAM: kasan: fix kasan_check_read/write definitions
BACKPORT: kasan: remove use after scope bugs detection.
BACKPORT: kasan: turn off asan-stack for clang-8 and earlier
UPSTREAM: slub: fix a crash with SLUB_DEBUG + KASAN_SW_TAGS
UPSTREAM: kasan, slab: remove redundant kasan_slab_alloc hooks
UPSTREAM: kasan, slab: make freelist stored without tags
UPSTREAM: kasan, slab: fix conflicts with CONFIG_HARDENED_USERCOPY
UPSTREAM: kasan: prevent tracing of tags.c
UPSTREAM: kasan: fix random seed generation for tag-based mode
UPSTREAM: slub: fix SLAB_CONSISTENCY_CHECKS + KASAN_SW_TAGS
UPSTREAM: kasan, slub: fix more conflicts with CONFIG_SLAB_FREELIST_HARDENED
UPSTREAM: kasan, slub: fix conflicts with CONFIG_SLAB_FREELIST_HARDENED
UPSTREAM: kasan, slub: move kasan_poison_slab hook before page_address
UPSTREAM: kasan, kmemleak: pass tagged pointers to kmemleak
UPSTREAM: kasan: fix assigning tags twice
UPSTREAM: kasan: mark file common so ftrace doesn't trace it
UPSTREAM: kasan, arm64: remove redundant ARCH_SLAB_MINALIGN define
UPSTREAM: kasan: fix krealloc handling for tag-based mode
UPSTREAM: kasan: make tag based mode work with CONFIG_HARDENED_USERCOPY
UPSTREAM: kasan, arm64: use ARCH_SLAB_MINALIGN instead of manual aligning
BACKPORT: mm/memblock.c: skip kmemleak for kasan_init()
UPSTREAM: kasan: add SPDX-License-Identifier mark to source files
BACKPORT: kasan: update documentation
UPSTREAM: kasan, arm64: select HAVE_ARCH_KASAN_SW_TAGS
UPSTREAM: kasan: add __must_check annotations to kasan hooks
BACKPORT: kasan, mm, arm64: tag non slab memory allocated via pagealloc
UPSTREAM: kasan, arm64: add brk handler for inline instrumentation
UPSTREAM: kasan: add hooks implementation for tag-based mode
UPSTREAM: mm: move obj_to_index to include/linux/slab_def.h
UPSTREAM: kasan: add bug reporting routines for tag-based mode
UPSTREAM: kasan: split out generic_report.c from report.c
UPSTREAM: kasan, mm: perform untagged pointers comparison in krealloc
BACKPORT: kasan, arm64: enable top byte ignore for the kernel
BACKPORT: kasan, arm64: fix up fault handling logic
UPSTREAM: kasan: preassign tags to objects with ctors or SLAB_TYPESAFE_BY_RCU
UPSTREAM: kasan, arm64: untag address in _virt_addr_is_linear
UPSTREAM: kasan: add tag related helper functions
BACKPORT: arm64: move untagged_addr macro from uaccess.h to memory.h
BACKPORT: kasan: initialize shadow to 0xff for tag-based mode
BACKPORT: kasan: rename kasan_zero_page to kasan_early_shadow_page
BACKPORT: kasan, arm64: adjust shadow size for tag-based mode
BACKPORT: kasan: add CONFIG_KASAN_GENERIC and CONFIG_KASAN_SW_TAGS
UPSTREAM: kasan: rename source files to reflect the new naming scheme
BACKPORT: kasan: move common generic and tag-based code to common.c
UPSTREAM: kasan, slub: handle pointer tags in early_kmem_cache_node_alloc
UPSTREAM: kasan, mm: change hooks signatures
UPSTREAM: arm64: add EXPORT_SYMBOL_NOKASAN()
BACKPORT: compiler: remove __no_sanitize_address_or_inline again
UPSTREAM: mm/kasan/quarantine.c: make quarantine_lock a raw_spinlock_t
UPSTREAM: lib/test_kasan.c: add tests for several string/memory API functions
UPSTREAM: arm64: lib: use C string functions with KASAN enabled
UPSTREAM: compiler: introduce __no_sanitize_address_or_inline
UPSTREAM: arm64: Fix typo in a comment in arch/arm64/mm/kasan_init.c
BACKPORT: kernel/memremap, kasan: make ZONE_DEVICE with work with KASAN
BACKPORT: mm/mempool.c: remove unused argument in kasan_unpoison_element() and remove_element()
UPSTREAM: kasan: only select SLUB_DEBUG with SYSFS=y
UPSTREAM: kasan: depend on CONFIG_SLUB_DEBUG
UPSTREAM: KASAN: prohibit KASAN+STRUCTLEAK combination
UPSTREAM: arm64: kasan: avoid pfn_to_nid() before page array is initialized
UPSTREAM: kasan: fix invalid-free test crashing the kernel
UPSTREAM: kasan, slub: fix handling of kasan_slab_free hook
UPSTREAM: slab, slub: skip unnecessary kasan_cache_shutdown()
BACKPORT: kasan: make kasan_cache_create() work with 32-bit slab cache sizes
UPSTREAM: locking/atomics: Instrument cmpxchg_double*()
UPSTREAM: locking/atomics: Instrument xchg()
UPSTREAM: locking/atomics: Simplify cmpxchg() instrumentation
UPSTREAM: locking/atomics/x86: Reduce arch_cmpxchg64*() instrumentation
UPSTREAM: locking/atomic, asm-generic, x86: Add comments for atomic instrumentation
UPSTREAM: locking/atomic, asm-generic: Add KASAN instrumentation to atomic operations
UPSTREAM: locking/atomic/x86: Switch atomic.h to use atomic-instrumented.h
UPSTREAM: locking/atomic, asm-generic: Add asm-generic/atomic-instrumented.h
BACKPORT: kasan, arm64: clean up KASAN_SHADOW_SCALE_SHIFT usage
UPSTREAM: kasan: clean up KASAN_SHADOW_SCALE_SHIFT usage
UPSTREAM: kasan: fix prototype author email address
UPSTREAM: kasan: detect invalid frees
UPSTREAM: kasan: unify code between kasan_slab_free() and kasan_poison_kfree()
UPSTREAM: kasan: detect invalid frees for large mempool objects
UPSTREAM: kasan: don't use __builtin_return_address(1)
UPSTREAM: kasan: detect invalid frees for large objects
UPSTREAM: kasan: add functions for unpoisoning stack variables
UPSTREAM: kasan: add tests for alloca poisoning
UPSTREAM: kasan: support alloca() poisoning
UPSTREAM: kasan/Makefile: support LLVM style asan parameters
BACKPORT: kasan: add compiler support for clang
BACKPORT: fs: dcache: Revert "manually unpoison dname after allocation to shut up kasan's reports"
UPSTREAM: fs/dcache: Use read_word_at_a_time() in dentry_string_cmp()
UPSTREAM: lib/strscpy: Shut up KASAN false-positives in strscpy()
UPSTREAM: compiler.h: Add read_word_at_a_time() function.
UPSTREAM: compiler.h, kasan: Avoid duplicating __read_once_size_nocheck()
UPSTREAM: arm64/mm/kasan: don't use vmemmap_populate() to initialize shadow
UPSTREAM: Documentation/features/KASAN: mark KASAN as supported only on 64-bit on x86
f2fs: Add option to limit required GC for checkpoint=disable
f2fs: Fix accounting for unusable blocks
f2fs: Fix root reserved on remount
f2fs: Lower threshold for disable_cp_again
f2fs: fix sparse warning
f2fs: fix f2fs_show_options to show nodiscard mount option
f2fs: add error prints for debugging mount failure
f2fs: fix to do sanity check on segment bitmap of LFS curseg
f2fs: add missing sysfs entries in documentation
f2fs: fix to avoid deadloop if data_flush is on
f2fs: always assume that the device is idle under gc_urgent
f2fs: add bio cache for IPU
f2fs: allow ssr block allocation during checkpoint=disable period
f2fs: fix to check layout on last valid checkpoint park
Conflicts:
arch/arm64/configs/cuttlefish_defconfig
arch/arm64/include/asm/memory.h
arch/arm64/include/asm/thread_info.h
arch/x86/configs/x86_64_cuttlefish_defconfig
build.config.common
drivers/dma-buf/dma-buf.c
fs/crypto/Makefile
fs/crypto/bio.c
fs/crypto/fscrypt_private.h
fs/crypto/keyinfo.c
fs/ext4/page-io.c
fs/f2fs/data.c
fs/f2fs/f2fs.h
fs/f2fs/inode.c
fs/f2fs/segment.c
fs/userfaultfd.c
include/linux/dma-buf.h
include/linux/fscrypt.h
include/linux/kasan.h
include/linux/platform_data/ds2482.h
include/uapi/linux/fs.h
kernel/sched/deadline.c
kernel/sched/fair.c
kernel/sched/rt.c
kernel/sched/sched.h
kernel/sched/stop_task.c
kernel/sched/walt.c
kernel/sched/walt.h
lib/test_kasan.c
mm/kasan/common.c
mm/kasan/kasan.h
mm/kasan/report.c
mm/slub.c
mm/vmalloc.c
scripts/Makefile.kasan
Changed below files to fix build errors:
drivers/char/diag/diagchar_core.c
drivers/power/supply/qcom/battery.c
drivers/power/supply/qcom/smb1390-charger-psy.c
drivers/power/supply/qcom/smb1390-charger.c
drivers/power/supply/qcom/step-chg-jeita.c
fs/crypto/fscrypt_ice.c
fs/crypto/fscrypt_private.h
fs/f2fs/inode.c
include/uapi/linux/fscrypt.h
net/qrtr/qrtr.c
gen_headers_arm.bp
gen_headers_arm64.bp
Extra added fixes in fs/f2fs/data.c for FBE:
* Fix FBE regression with 9937c21ce1 ("f2fs: add bio cache
for IPU"). The above commit is not setting the DUN for
bio, due to which the bio's could get corrupted when FBE
is enabled.
* The f2fs_merge_page_bio() incorrectly uses the bio after
it is submitted for IO when fscrypt_mergeable_bio()
returns false. Fix it by making the submitted bio NULL
so that a new bio gets allocated for the next/new page.
Ignored the below scheduler patches as they are already present:
ANDROID: sched: WALT: Add support for CFS_BANDWIDTH
ANDROID: sched: WALT: Refactor cumulative runnable average fixup
picked below patches from 4.14.159 and 4.14.172 versions to fix issues
0e39aa9d5 "UPSTREAM: arm64: Validate tagged addresses in access_ok() called from kernel threads"
352902650 "fscrypt: support passing a keyring key to FS_IOC_ADD_ENCRYPTION_KEY"
Change-Id: I205b796ee125fa6e9d27fa30f881e4e8fe8bea29
Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
Signed-off-by: Blagovest Kolenichev <bkolenichev@codeaurora.org>
5 years ago
|
|
|
.keysize = 64,
|
|
|
|
|
.ivsize = 16,
|
|
|
|
|
.blk_crypto_mode = BLK_ENCRYPTION_MODE_AES_256_XTS,
|
Merge android-4.14.151 (2bb70f4) into msm-4.14
* refs/heads/tmp-2bb70f4:
ANDROID: virtio: virtio_input: Set the amount of multitouch slots in virtio input
ANDROID: dummy_cpufreq: Implement get()
rtlwifi: Fix potential overflow on P2P code
ANDROID: cpufreq: create dummy cpufreq driver
ANDROID: Allow DRM_IOCTL_MODE_*_DUMB for render clients.
ANDROID: sdcardfs: evict dentries on fscrypt key removal
ANDROID: fscrypt: add key removal notifier chain
ANDROID: Move from clang r353983c to r365631c
ANDROID: move up spin_unlock_bh() ahead of remove_proc_entry()
BACKPORT: arm64: tags: Preserve tags for addresses translated via TTBR1
UPSTREAM: arm64: memory: Implement __tag_set() as common function
UPSTREAM: arm64/mm: fix variable 'tag' set but not used
UPSTREAM: arm64: avoid clang warning about self-assignment
ANDROID: refactor build.config files to remove duplication
UPSTREAM: mm: vmalloc: show number of vmalloc pages in /proc/meminfo
BACKPORT: PM/sleep: Expose suspend stats in sysfs
UPSTREAM: power: supply: Init device wakeup after device_add()
UPSTREAM: PM / wakeup: Unexport wakeup_source_sysfs_{add,remove}()
UPSTREAM: PM / wakeup: Register wakeup class kobj after device is added
BACKPORT: PM / wakeup: Fix sysfs registration error path
BACKPORT: PM / wakeup: Show wakeup sources stats in sysfs
UPSTREAM: PM / wakeup: Print warn if device gets enabled as wakeup source during sleep
UPSTREAM: PM / wakeup: Use wakeup_source_register() in wakelock.c
UPSTREAM: PM / wakeup: Only update last time for active wakeup sources
UPSTREAM: PM / core: Add support to skip power management in device/driver model
cuttlefish-4.14: Enable CONFIG_DM_SNAPSHOT
ANDROID: cuttlefish_defconfig: Enable BPF_JIT and BPF_JIT_ALWAYS_ON
UPSTREAM: netfilter: xt_IDLETIMER: fix sysfs callback function type
UPSTREAM: mm: untag user pointers in mmap/munmap/mremap/brk
UPSTREAM: vfio/type1: untag user pointers in vaddr_get_pfn
UPSTREAM: media/v4l2-core: untag user pointers in videobuf_dma_contig_user_get
UPSTREAM: drm/radeon: untag user pointers in radeon_gem_userptr_ioctl
BACKPORT: drm/amdgpu: untag user pointers
UPSTREAM: userfaultfd: untag user pointers
UPSTREAM: fs/namespace: untag user pointers in copy_mount_options
UPSTREAM: mm: untag user pointers in get_vaddr_frames
UPSTREAM: mm: untag user pointers in mm/gup.c
BACKPORT: mm: untag user pointers passed to memory syscalls
BACKPORT: lib: untag user pointers in strn*_user
UPSTREAM: arm64: Fix reference to docs for ARM64_TAGGED_ADDR_ABI
UPSTREAM: selftests, arm64: add kernel headers path for tags_test
BACKPORT: arm64: Relax Documentation/arm64/tagged-pointers.rst
UPSTREAM: arm64: Define Documentation/arm64/tagged-address-abi.rst
UPSTREAM: arm64: Change the tagged_addr sysctl control semantics to only prevent the opt-in
UPSTREAM: arm64: Tighten the PR_{SET, GET}_TAGGED_ADDR_CTRL prctl() unused arguments
UPSTREAM: selftests, arm64: fix uninitialized symbol in tags_test.c
UPSTREAM: arm64: mm: Really fix sparse warning in untagged_addr()
UPSTREAM: selftests, arm64: add a selftest for passing tagged pointers to kernel
BACKPORT: arm64: Introduce prctl() options to control the tagged user addresses ABI
UPSTREAM: thread_info: Add update_thread_flag() helpers
UPSTREAM: arm64: untag user pointers in access_ok and __uaccess_mask_ptr
UPSTREAM: uaccess: add noop untagged_addr definition
BACKPORT: block: annotate refault stalls from IO submission
ext4: add verity flag check for dax
ANDROID: usb: gadget: Fix dependency for f_accessory
ANDROID: sched: fair: balance for single core cluster
UPSTREAM: mm/kasan: fix false positive invalid-free reports with CONFIG_KASAN_SW_TAGS=y
f2fs: add a condition to detect overflow in f2fs_ioc_gc_range()
f2fs: fix to add missing F2FS_IO_ALIGNED() condition
f2fs: fix to fallback to buffered IO in IO aligned mode
f2fs: fix to handle error path correctly in f2fs_map_blocks
f2fs: fix extent corrupotion during directIO in LFS mode
f2fs: check all the data segments against all node ones
f2fs: Add a small clarification to CONFIG_FS_F2FS_FS_SECURITY
f2fs: fix inode rwsem regression
f2fs: fix to avoid accessing uninitialized field of inode page in is_alive()
f2fs: avoid infinite GC loop due to stale atomic files
f2fs: Fix indefinite loop in f2fs_gc()
f2fs: convert inline_data in prior to i_size_write
f2fs: fix error path of f2fs_convert_inline_page()
f2fs: add missing documents of reserve_root/resuid/resgid
f2fs: fix flushing node pages when checkpoint is disabled
f2fs: enhance f2fs_is_checkpoint_ready()'s readability
f2fs: clean up __bio_alloc()'s parameter
f2fs: fix wrong error injection path in inc_valid_block_count()
f2fs: fix to writeout dirty inode during node flush
f2fs: optimize case-insensitive lookups
f2fs: introduce f2fs_match_name() for cleanup
f2fs: Fix indefinite loop in f2fs_gc()
f2fs: allocate memory in batch in build_sit_info()
f2fs: fix to avoid data corruption by forbidding SSR overwrite
f2fs: Fix build error while CONFIG_NLS=m
Revert "f2fs: avoid out-of-range memory access"
f2fs: cleanup the code in build_sit_entries.
f2fs: fix wrong available node count calculation
f2fs: remove duplicate code in f2fs_file_write_iter
f2fs: fix to migrate blocks correctly during defragment
f2fs: use wrapped f2fs_cp_error()
f2fs: fix to use more generic EOPNOTSUPP
f2fs: use wrapped IS_SWAPFILE()
f2fs: Support case-insensitive file name lookups
f2fs: include charset encoding information in the superblock
fs: Reserve flag for casefolding
f2fs: fix to avoid call kvfree under spinlock
fs: f2fs: Remove unnecessary checks of SM_I(sbi) in update_general_status()
f2fs: disallow direct IO in atomic write
f2fs: fix to handle quota_{on,off} correctly
f2fs: fix to detect cp error in f2fs_setxattr()
f2fs: fix to spread f2fs_is_checkpoint_ready()
f2fs: support fiemap() for directory inode
f2fs: fix to avoid discard command leak
f2fs: fix to avoid tagging SBI_QUOTA_NEED_REPAIR incorrectly
f2fs: fix to drop meta/node pages during umount
f2fs: disallow switching io_bits option during remount
f2fs: fix panic of IO alignment feature
f2fs: introduce {page,io}_is_mergeable() for readability
f2fs: fix livelock in swapfile writes
f2fs: add fs-verity support
ext4: update on-disk format documentation for fs-verity
ext4: add fs-verity read support
ext4: add basic fs-verity support
fs-verity: support builtin file signatures
fs-verity: add SHA-512 support
fs-verity: implement FS_IOC_MEASURE_VERITY ioctl
fs-verity: implement FS_IOC_ENABLE_VERITY ioctl
fs-verity: add data verification hooks for ->readpages()
fs-verity: add the hook for file ->setattr()
fs-verity: add the hook for file ->open()
fs-verity: add inode and superblock fields
fs-verity: add Kconfig and the helper functions for hashing
fs: uapi: define verity bit for FS_IOC_GETFLAGS
fs-verity: add UAPI header
fs-verity: add MAINTAINERS file entry
fs-verity: add a documentation file
ext4: fix kernel oops caused by spurious casefold flag
ext4: fix coverity warning on error path of filename setup
ext4: optimize case-insensitive lookups
ext4: fix dcache lookup of !casefolded directories
unicode: update to Unicode 12.1.0 final
unicode: add missing check for an error return from utf8lookup()
ext4: export /sys/fs/ext4/feature/casefold if Unicode support is present
unicode: refactor the rule for regenerating utf8data.h
ext4: Support case-insensitive file name lookups
ext4: include charset encoding information in the superblock
unicode: update unicode database unicode version 12.1.0
unicode: introduce test module for normalized utf8 implementation
unicode: implement higher level API for string handling
unicode: reduce the size of utf8data[]
unicode: introduce code for UTF-8 normalization
unicode: introduce UTF-8 character database
ext4 crypto: fix to check feature status before get policy
fscrypt: document the new ioctls and policy version
ubifs: wire up new fscrypt ioctls
f2fs: wire up new fscrypt ioctls
ext4: wire up new fscrypt ioctls
fscrypt: require that key be added when setting a v2 encryption policy
fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY_ALL_USERS ioctl
fscrypt: allow unprivileged users to add/remove keys for v2 policies
fscrypt: v2 encryption policy support
fscrypt: add an HKDF-SHA512 implementation
fscrypt: add FS_IOC_GET_ENCRYPTION_KEY_STATUS ioctl
fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl
fscrypt: add FS_IOC_ADD_ENCRYPTION_KEY ioctl
fscrypt: rename keyinfo.c to keysetup.c
fscrypt: move v1 policy key setup to keysetup_v1.c
fscrypt: refactor key setup code in preparation for v2 policies
fscrypt: rename fscrypt_master_key to fscrypt_direct_key
fscrypt: add ->ci_inode to fscrypt_info
fscrypt: use FSCRYPT_* definitions, not FS_*
fscrypt: use FSCRYPT_ prefix for uapi constants
fs, fscrypt: move uapi definitions to new header <linux/fscrypt.h>
fscrypt: use ENOPKG when crypto API support missing
fscrypt: improve warnings for missing crypto API support
fscrypt: improve warning messages for unsupported encryption contexts
fscrypt: make fscrypt_msg() take inode instead of super_block
fscrypt: clean up base64 encoding/decoding
fscrypt: remove loadable module related code
ANDROID: arm64: bpf: implement arch_bpf_jit_check_func
ANDROID: bpf: validate bpf_func when BPF_JIT is enabled with CFI
UPSTREAM: kcm: use BPF_PROG_RUN
UPSTREAM: psi: get poll_work to run when calling poll syscall next time
UPSTREAM: sched/psi: Do not require setsched permission from the trigger creator
UPSTREAM: sched/psi: Reduce psimon FIFO priority
BACKPORT: arm64: Add support for relocating the kernel with RELR relocations
ANDROID: Log which device failed to suspend in dpm_suspend_start()
ANDROID: Revert "ANDROID: sched: Disallow WALT with CFS bandwidth control"
ANDROID: sched: WALT: Add support for CFS_BANDWIDTH
ANDROID: sched: WALT: Refactor cumulative runnable average fixup
ANDROID: sched: Disallow WALT with CFS bandwidth control
fscrypt: document testing with xfstests
fscrypt: remove selection of CONFIG_CRYPTO_SHA256
fscrypt: remove unnecessary includes of ratelimit.h
fscrypt: don't set policy for a dead directory
fscrypt: decrypt only the needed blocks in __fscrypt_decrypt_bio()
fscrypt: support decrypting multiple filesystem blocks per page
fscrypt: introduce fscrypt_decrypt_block_inplace()
fscrypt: handle blocksize < PAGE_SIZE in fscrypt_zeroout_range()
fscrypt: support encrypting multiple filesystem blocks per page
fscrypt: introduce fscrypt_encrypt_block_inplace()
fscrypt: clean up some BUG_ON()s in block encryption/decryption
fscrypt: rename fscrypt_do_page_crypto() to fscrypt_crypt_block()
fscrypt: remove the "write" part of struct fscrypt_ctx
fscrypt: simplify bounce page handling
ANDROID: fiq_debugger: remove
UPSTREAM: lib/test_meminit.c: use GFP_ATOMIC in RCU critical section
UPSTREAM: mm: slub: Fix slab walking for init_on_free
UPSTREAM: lib/test_meminit.c: minor test fixes
UPSTREAM: lib/test_meminit.c: fix -Wmaybe-uninitialized false positive
UPSTREAM: lib: introduce test_meminit module
UPSTREAM: mm: init: report memory auto-initialization features at boot time
BACKPORT: mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
UPSTREAM: arm64: move jump_label_init() before parse_early_param()
ANDROID: Add a tracepoint for mapping inode to full path
BACKPORT: arch: add pidfd and io_uring syscalls everywhere
UPSTREAM: dma-buf: add show_fdinfo handler
UPSTREAM: dma-buf: add DMA_BUF_SET_NAME ioctls
BACKPORT: dma-buf: give each buffer a full-fledged inode
ANDROID: fix kernelci build-break
UPSTREAM: drm/virtio: Fix cache entry creation race.
UPSTREAM: drm/virtio: Wake up all waiters when capset response comes in.
UPSTREAM: drm/virtio: Ensure cached capset entries are valid before copying.
UPSTREAM: drm/virtio: use u64_to_user_ptr macro
UPSTREAM: drm/virtio: remove irrelevant DRM_UNLOCKED flag
UPSTREAM: drm/virtio: Remove redundant return type
UPSTREAM: drm/virtio: allocate fences with GFP_KERNEL
UPSTREAM: drm/virtio: add trace events for commands
UPSTREAM: drm/virtio: trace drm_fence_emit
BACKPORT: drm/virtio: set seqno for dma-fence
BACKPORT: drm/virtio: move drm_connector_update_edid_property() call
UPSTREAM: drm/virtio: add missing drm_atomic_helper_shutdown() call.
BACKPORT: drm/virtio: rework resource creation workflow.
UPSTREAM: drm/virtio: params struct for virtio_gpu_cmd_create_resource_3d()
BACKPORT: drm/virtio: params struct for virtio_gpu_cmd_create_resource()
BACKPORT: drm/virtio: use struct to pass params to virtio_gpu_object_create()
UPSTREAM: drm/virtio: add virtio-gpu-features debugfs file.
UPSTREAM: drm/virtio: remove set but not used variable 'vgdev'
BACKPORT: drm/virtio: implement prime export
UPSTREAM: drm/virtio: remove prime pin/unpin callbacks.
UPSTREAM: drm/virtio: implement prime mmap
UPSTREAM: drm/virtio: drop virtio_gpu_fence_cleanup()
UPSTREAM: drm/virtio: fix pageflip flush
UPSTREAM: drm/virtio: log error responses
UPSTREAM: drm/virtio: Add missing virtqueue reset
UPSTREAM: drm/virtio: Remove incorrect kfree()
UPSTREAM: drm/virtio: virtio_gpu_cmd_resource_create_3d: drop unused fence arg
UPSTREAM: drm/virtio: fence: pass plain pointer
BACKPORT: drm/virtio: add edid support
UPSTREAM: virtio-gpu: add VIRTIO_GPU_F_EDID feature
BACKPORT: drm/virtio: fix memory leak of vfpriv on error return path
UPSTREAM: drm/virtio: bump driver version after explicit synchronization addition
UPSTREAM: drm/virtio: add in/out fence support for explicit synchronization
UPSTREAM: drm/virtio: add uapi for in and out explicit fences
UPSTREAM: drm/virtio: add virtio_gpu_alloc_fence()
UPSTREAM: drm/virtio: Handle error from virtio_gpu_resource_id_get
UPSTREAM: gpu/drm/virtio/virtgpu_vq.c: Use kmem_cache_zalloc
UPSTREAM: drm/virtio: fix resource id handling
UPSTREAM: drm/virtio: drop resource_id argument.
UPSTREAM: drm/virtio: use virtio_gpu_object->hw_res_handle in virtio_gpu_resource_create_ioctl()
UPSTREAM: drm/virtio: use virtio_gpu_object->hw_res_handle in virtio_gpu_mode_dumb_create()
UPSTREAM: drm/virtio: use virtio_gpu_object->hw_res_handle in virtio_gpufb_create()
BACKPORT: drm/virtio: track created object state
UPSTREAM: drm/virtio: document drm_dev_set_unique workaround
UPSTREAM: virtio: Support prime objects vmap/vunmap
UPSTREAM: virtio: Rework virtio_gpu_object_kmap()
UPSTREAM: virtio: Add virtio_gpu_object_kunmap()
UPSTREAM: drm/virtio: pass virtio_gpu_object to virtio_gpu_cmd_transfer_to_host_{2d, 3d}
UPSTREAM: drm/virtio: add dma sync for dma mapped virtio gpu framebuffer pages
UPSTREAM: drm/virtio: Remove set but not used variable 'bo'
UPSTREAM: drm/virtio: add iommu support.
UPSTREAM: drm/virtio: add virtio_gpu_object_detach() function
UPSTREAM: drm/virtio: track virtual output state
UPSTREAM: drm/virtio: fix bounds check in virtio_gpu_cmd_get_capset()
UPSTREAM: gpu: drm: virtio: code cleanup
UPSTREAM: drm/virtio: Place GEM BOs in drm_framebuffer
UPSTREAM: drm/virtio: fix mode_valid's return type
UPSTREAM: drm/virtio: Add spaces around operators
UPSTREAM: drm/virtio: Remove multiple blank lines
UPSTREAM: drm/virtio: Replace 'unsigned' for 'unsigned int'
UPSTREAM: drm/virtio: Remove return from void function
UPSTREAM: drm/virtio: Add */ in block comments to separate line
UPSTREAM: drm/virtio: Add blank line after variable declarations
UPSTREAM: drm/virtio: Add tabs at the start of a line
UPSTREAM: drm/virtio: Don't return invalid caps on timeout
UPSTREAM: virtgpu: remove redundant task_comm copying
UPSTREAM: drm/virtio: add create_handle support.
UPSTREAM: drm: virtio: replace reference/unreference with get/put
UPSTREAM: drm/virtio: Replace instances of reference/unreference with get/put
UPSTREAM: drm: byteorder: add DRM_FORMAT_HOST_*
UPSTREAM: drm: add drm_connector_attach_edid_property()
BACKPORT: drm/prime: Add drm_gem_prime_mmap()
f2fs: fix build error on android tracepoints
ANDROID: cuttlefish_defconfig: Enable CAN/VCAN
UPSTREAM: pidfd: fix a poll race when setting exit_state
BACKPORT: arch: wire-up pidfd_open()
BACKPORT: pid: add pidfd_open()
UPSTREAM: pidfd: add polling support
UPSTREAM: signal: improve comments
UPSTREAM: fork: do not release lock that wasn't taken
BACKPORT: signal: support CLONE_PIDFD with pidfd_send_signal
BACKPORT: clone: add CLONE_PIDFD
UPSTREAM: Make anon_inodes unconditional
UPSTREAM: signal: use fdget() since we don't allow O_PATH
UPSTREAM: signal: don't silently convert SI_USER signals to non-current pidfd
BACKPORT: signal: add pidfd_send_signal() syscall
UPSTREAM: net-ipv6-ndisc: add support for RFC7710 RA Captive Portal Identifier
ANDROID: fix up 9p filesystem due to CFI non-upstream patches
f2fs: use EINVAL for superblock with invalid magic
f2fs: fix to read source block before invalidating it
f2fs: remove redundant check from f2fs_setflags_common()
f2fs: use generic checking function for FS_IOC_FSSETXATTR
f2fs: use generic checking and prep function for FS_IOC_SETFLAGS
ubifs, fscrypt: cache decrypted symlink target in ->i_link
vfs: use READ_ONCE() to access ->i_link
fs, fscrypt: clear DCACHE_ENCRYPTED_NAME when unaliasing directory
ANDROID: (arm64) cuttlefish_defconfig: enable CONFIG_CPU_FREQ_TIMES
ANDROID: xfrm: remove in_compat_syscall() checks
ANDROID: enable CONFIG_RTC_DRV_TEST on cuttlefish
UPSTREAM: binder: Set end of SG buffer area properly.
ANDROID: x86_64_cuttlefish_defconfig: enable CONFIG_CPU_FREQ_TIMES
ANDROID: f2fs: add android fsync tracepoint
ANDROID: f2fs: fix wrong android tracepoint
fscrypt: cache decrypted symlink target in ->i_link
fscrypt: fix race where ->lookup() marks plaintext dentry as ciphertext
fscrypt: only set dentry_operations on ciphertext dentries
fscrypt: fix race allowing rename() and link() of ciphertext dentries
fscrypt: clean up and improve dentry revalidation
fscrypt: use READ_ONCE() to access ->i_crypt_info
fscrypt: remove WARN_ON_ONCE() when decryption fails
fscrypt: drop inode argument from fscrypt_get_ctx()
f2fs: improve print log in f2fs_sanity_check_ckpt()
f2fs: avoid out-of-range memory access
f2fs: fix to avoid long latency during umount
f2fs: allow all the users to pin a file
f2fs: support swap file w/ DIO
f2fs: allocate blocks for pinned file
f2fs: fix is_idle() check for discard type
f2fs: add a rw_sem to cover quota flag changes
f2fs: set SBI_NEED_FSCK for xattr corruption case
f2fs: use generic EFSBADCRC/EFSCORRUPTED
f2fs: Use DIV_ROUND_UP() instead of open-coding
f2fs: print kernel message if filesystem is inconsistent
f2fs: introduce f2fs_<level> macros to wrap f2fs_printk()
f2fs: avoid get_valid_blocks() for cleanup
f2fs: ioctl for removing a range from F2FS
f2fs: only set project inherit bit for directory
f2fs: separate f2fs i_flags from fs_flags and ext4 i_flags
UPSTREAM: kasan: initialize tag to 0xff in __kasan_kmalloc
UPSTREAM: x86/boot: Provide KASAN compatible aliases for string routines
UPSTREAM: mm/kasan: Remove the ULONG_MAX stack trace hackery
UPSTREAM: x86/uaccess, kasan: Fix KASAN vs SMAP
UPSTREAM: x86/uaccess: Introduce user_access_{save,restore}()
UPSTREAM: kasan: fix variable 'tag' set but not used warning
UPSTREAM: Revert "x86_64: Increase stack size for KASAN_EXTRA"
UPSTREAM: kasan: fix coccinelle warnings in kasan_p*_table
UPSTREAM: kasan: fix kasan_check_read/write definitions
BACKPORT: kasan: remove use after scope bugs detection.
BACKPORT: kasan: turn off asan-stack for clang-8 and earlier
UPSTREAM: slub: fix a crash with SLUB_DEBUG + KASAN_SW_TAGS
UPSTREAM: kasan, slab: remove redundant kasan_slab_alloc hooks
UPSTREAM: kasan, slab: make freelist stored without tags
UPSTREAM: kasan, slab: fix conflicts with CONFIG_HARDENED_USERCOPY
UPSTREAM: kasan: prevent tracing of tags.c
UPSTREAM: kasan: fix random seed generation for tag-based mode
UPSTREAM: slub: fix SLAB_CONSISTENCY_CHECKS + KASAN_SW_TAGS
UPSTREAM: kasan, slub: fix more conflicts with CONFIG_SLAB_FREELIST_HARDENED
UPSTREAM: kasan, slub: fix conflicts with CONFIG_SLAB_FREELIST_HARDENED
UPSTREAM: kasan, slub: move kasan_poison_slab hook before page_address
UPSTREAM: kasan, kmemleak: pass tagged pointers to kmemleak
UPSTREAM: kasan: fix assigning tags twice
UPSTREAM: kasan: mark file common so ftrace doesn't trace it
UPSTREAM: kasan, arm64: remove redundant ARCH_SLAB_MINALIGN define
UPSTREAM: kasan: fix krealloc handling for tag-based mode
UPSTREAM: kasan: make tag based mode work with CONFIG_HARDENED_USERCOPY
UPSTREAM: kasan, arm64: use ARCH_SLAB_MINALIGN instead of manual aligning
BACKPORT: mm/memblock.c: skip kmemleak for kasan_init()
UPSTREAM: kasan: add SPDX-License-Identifier mark to source files
BACKPORT: kasan: update documentation
UPSTREAM: kasan, arm64: select HAVE_ARCH_KASAN_SW_TAGS
UPSTREAM: kasan: add __must_check annotations to kasan hooks
BACKPORT: kasan, mm, arm64: tag non slab memory allocated via pagealloc
UPSTREAM: kasan, arm64: add brk handler for inline instrumentation
UPSTREAM: kasan: add hooks implementation for tag-based mode
UPSTREAM: mm: move obj_to_index to include/linux/slab_def.h
UPSTREAM: kasan: add bug reporting routines for tag-based mode
UPSTREAM: kasan: split out generic_report.c from report.c
UPSTREAM: kasan, mm: perform untagged pointers comparison in krealloc
BACKPORT: kasan, arm64: enable top byte ignore for the kernel
BACKPORT: kasan, arm64: fix up fault handling logic
UPSTREAM: kasan: preassign tags to objects with ctors or SLAB_TYPESAFE_BY_RCU
UPSTREAM: kasan, arm64: untag address in _virt_addr_is_linear
UPSTREAM: kasan: add tag related helper functions
BACKPORT: arm64: move untagged_addr macro from uaccess.h to memory.h
BACKPORT: kasan: initialize shadow to 0xff for tag-based mode
BACKPORT: kasan: rename kasan_zero_page to kasan_early_shadow_page
BACKPORT: kasan, arm64: adjust shadow size for tag-based mode
BACKPORT: kasan: add CONFIG_KASAN_GENERIC and CONFIG_KASAN_SW_TAGS
UPSTREAM: kasan: rename source files to reflect the new naming scheme
BACKPORT: kasan: move common generic and tag-based code to common.c
UPSTREAM: kasan, slub: handle pointer tags in early_kmem_cache_node_alloc
UPSTREAM: kasan, mm: change hooks signatures
UPSTREAM: arm64: add EXPORT_SYMBOL_NOKASAN()
BACKPORT: compiler: remove __no_sanitize_address_or_inline again
UPSTREAM: mm/kasan/quarantine.c: make quarantine_lock a raw_spinlock_t
UPSTREAM: lib/test_kasan.c: add tests for several string/memory API functions
UPSTREAM: arm64: lib: use C string functions with KASAN enabled
UPSTREAM: compiler: introduce __no_sanitize_address_or_inline
UPSTREAM: arm64: Fix typo in a comment in arch/arm64/mm/kasan_init.c
BACKPORT: kernel/memremap, kasan: make ZONE_DEVICE with work with KASAN
BACKPORT: mm/mempool.c: remove unused argument in kasan_unpoison_element() and remove_element()
UPSTREAM: kasan: only select SLUB_DEBUG with SYSFS=y
UPSTREAM: kasan: depend on CONFIG_SLUB_DEBUG
UPSTREAM: KASAN: prohibit KASAN+STRUCTLEAK combination
UPSTREAM: arm64: kasan: avoid pfn_to_nid() before page array is initialized
UPSTREAM: kasan: fix invalid-free test crashing the kernel
UPSTREAM: kasan, slub: fix handling of kasan_slab_free hook
UPSTREAM: slab, slub: skip unnecessary kasan_cache_shutdown()
BACKPORT: kasan: make kasan_cache_create() work with 32-bit slab cache sizes
UPSTREAM: locking/atomics: Instrument cmpxchg_double*()
UPSTREAM: locking/atomics: Instrument xchg()
UPSTREAM: locking/atomics: Simplify cmpxchg() instrumentation
UPSTREAM: locking/atomics/x86: Reduce arch_cmpxchg64*() instrumentation
UPSTREAM: locking/atomic, asm-generic, x86: Add comments for atomic instrumentation
UPSTREAM: locking/atomic, asm-generic: Add KASAN instrumentation to atomic operations
UPSTREAM: locking/atomic/x86: Switch atomic.h to use atomic-instrumented.h
UPSTREAM: locking/atomic, asm-generic: Add asm-generic/atomic-instrumented.h
BACKPORT: kasan, arm64: clean up KASAN_SHADOW_SCALE_SHIFT usage
UPSTREAM: kasan: clean up KASAN_SHADOW_SCALE_SHIFT usage
UPSTREAM: kasan: fix prototype author email address
UPSTREAM: kasan: detect invalid frees
UPSTREAM: kasan: unify code between kasan_slab_free() and kasan_poison_kfree()
UPSTREAM: kasan: detect invalid frees for large mempool objects
UPSTREAM: kasan: don't use __builtin_return_address(1)
UPSTREAM: kasan: detect invalid frees for large objects
UPSTREAM: kasan: add functions for unpoisoning stack variables
UPSTREAM: kasan: add tests for alloca poisoning
UPSTREAM: kasan: support alloca() poisoning
UPSTREAM: kasan/Makefile: support LLVM style asan parameters
BACKPORT: kasan: add compiler support for clang
BACKPORT: fs: dcache: Revert "manually unpoison dname after allocation to shut up kasan's reports"
UPSTREAM: fs/dcache: Use read_word_at_a_time() in dentry_string_cmp()
UPSTREAM: lib/strscpy: Shut up KASAN false-positives in strscpy()
UPSTREAM: compiler.h: Add read_word_at_a_time() function.
UPSTREAM: compiler.h, kasan: Avoid duplicating __read_once_size_nocheck()
UPSTREAM: arm64/mm/kasan: don't use vmemmap_populate() to initialize shadow
UPSTREAM: Documentation/features/KASAN: mark KASAN as supported only on 64-bit on x86
f2fs: Add option to limit required GC for checkpoint=disable
f2fs: Fix accounting for unusable blocks
f2fs: Fix root reserved on remount
f2fs: Lower threshold for disable_cp_again
f2fs: fix sparse warning
f2fs: fix f2fs_show_options to show nodiscard mount option
f2fs: add error prints for debugging mount failure
f2fs: fix to do sanity check on segment bitmap of LFS curseg
f2fs: add missing sysfs entries in documentation
f2fs: fix to avoid deadloop if data_flush is on
f2fs: always assume that the device is idle under gc_urgent
f2fs: add bio cache for IPU
f2fs: allow ssr block allocation during checkpoint=disable period
f2fs: fix to check layout on last valid checkpoint park
Conflicts:
arch/arm64/configs/cuttlefish_defconfig
arch/arm64/include/asm/memory.h
arch/arm64/include/asm/thread_info.h
arch/x86/configs/x86_64_cuttlefish_defconfig
build.config.common
drivers/dma-buf/dma-buf.c
fs/crypto/Makefile
fs/crypto/bio.c
fs/crypto/fscrypt_private.h
fs/crypto/keyinfo.c
fs/ext4/page-io.c
fs/f2fs/data.c
fs/f2fs/f2fs.h
fs/f2fs/inode.c
fs/f2fs/segment.c
fs/userfaultfd.c
include/linux/dma-buf.h
include/linux/fscrypt.h
include/linux/kasan.h
include/linux/platform_data/ds2482.h
include/uapi/linux/fs.h
kernel/sched/deadline.c
kernel/sched/fair.c
kernel/sched/rt.c
kernel/sched/sched.h
kernel/sched/stop_task.c
kernel/sched/walt.c
kernel/sched/walt.h
lib/test_kasan.c
mm/kasan/common.c
mm/kasan/kasan.h
mm/kasan/report.c
mm/slub.c
mm/vmalloc.c
scripts/Makefile.kasan
Changed below files to fix build errors:
drivers/char/diag/diagchar_core.c
drivers/power/supply/qcom/battery.c
drivers/power/supply/qcom/smb1390-charger-psy.c
drivers/power/supply/qcom/smb1390-charger.c
drivers/power/supply/qcom/step-chg-jeita.c
fs/crypto/fscrypt_ice.c
fs/crypto/fscrypt_private.h
fs/f2fs/inode.c
include/uapi/linux/fscrypt.h
net/qrtr/qrtr.c
gen_headers_arm.bp
gen_headers_arm64.bp
Extra added fixes in fs/f2fs/data.c for FBE:
* Fix FBE regression with 9937c21ce1 ("f2fs: add bio cache
for IPU"). The above commit is not setting the DUN for
bio, due to which the bio's could get corrupted when FBE
is enabled.
* The f2fs_merge_page_bio() incorrectly uses the bio after
it is submitted for IO when fscrypt_mergeable_bio()
returns false. Fix it by making the submitted bio NULL
so that a new bio gets allocated for the next/new page.
Ignored the below scheduler patches as they are already present:
ANDROID: sched: WALT: Add support for CFS_BANDWIDTH
ANDROID: sched: WALT: Refactor cumulative runnable average fixup
picked below patches from 4.14.159 and 4.14.172 versions to fix issues
0e39aa9d5 "UPSTREAM: arm64: Validate tagged addresses in access_ok() called from kernel threads"
352902650 "fscrypt: support passing a keyring key to FS_IOC_ADD_ENCRYPTION_KEY"
Change-Id: I205b796ee125fa6e9d27fa30f881e4e8fe8bea29
Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
Signed-off-by: Blagovest Kolenichev <bkolenichev@codeaurora.org>
5 years ago
|
|
|
},
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_FSCRYPT_SDP
|
|
|
|
|
static int derive_fek(struct inode *inode,
|
|
|
|
|
struct fscrypt_info *crypt_info,
|
|
|
|
|
u8 *fek, u32 fek_len);
|
|
|
|
|
#endif
|
|
|
|
|
|
BACKPORT: FROMLIST: fscrypt: add support for IV_INO_LBLK_32 policies
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 <ebiggers@google.com>
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 <ebiggers@google.com>
Git-commit: a52238353e6711ae8ef8f3b462cece3b05aead8f
Git-repo: https://android.googlesource.com/kernel/common/+/refs/heads/android-4.14-stable
[neersoni@codeaurora.org: back port the changes and fixed merge
conflicts in fscrypt_privat.h and inline_crypt.c files]
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
5 years ago
|
|
|
static DEFINE_MUTEX(fscrypt_mode_key_setup_mutex);
|
|
|
|
|
|
|
|
|
|
static struct fscrypt_mode *
|
fscrypt: v2 encryption policy support
Add a new fscrypt policy version, "v2". It has the following changes
from the original policy version, which we call "v1" (*):
- Master keys (the user-provided encryption keys) are only ever used as
input to HKDF-SHA512. This is more flexible and less error-prone, and
it avoids the quirks and limitations of the AES-128-ECB based KDF.
Three classes of cryptographically isolated subkeys are defined:
- Per-file keys, like used in v1 policies except for the new KDF.
- Per-mode keys. These implement the semantics of the DIRECT_KEY
flag, which for v1 policies made the master key be used directly.
These are also planned to be used for inline encryption when
support for it is added.
- Key identifiers (see below).
- Each master key is identified by a 16-byte master_key_identifier,
which is derived from the key itself using HKDF-SHA512. This prevents
users from associating the wrong key with an encrypted file or
directory. This was easily possible with v1 policies, which
identified the key by an arbitrary 8-byte master_key_descriptor.
- The key must be provided in the filesystem-level keyring, not in a
process-subscribed keyring.
The following UAPI additions are made:
- The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
- A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
getting the v1 or v2 encryption policy of an encrypted file or
directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
be used because it did not have a way for userspace to indicate which
policy structure is expected. The new ioctl includes a size field, so
it is extensible to future fscrypt policy versions.
- The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
encryption policies. Such keys are kept logically separate from keys
for v1 encryption policies, and are identified by 'identifier' rather
than by 'descriptor'. The 'identifier' need not be provided when
adding a key, since the kernel will calculate it anyway.
This patch temporarily keeps adding/removing v2 policy keys behind the
same permission check done for adding/removing v1 policy keys:
capable(CAP_SYS_ADMIN). However, the next patch will carefully take
advantage of the cryptographically secure master_key_identifier to allow
non-root users to add/remove v2 policy keys, thus providing a full
replacement for v1 policies.
(*) Actually, in the API fscrypt_policy::version is 0 while on-disk
fscrypt_context::format is 1. But I believe it makes the most sense
to advance both to '2' to have them be in sync, and to consider the
numbering to start at 1 except for the API quirk.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
select_encryption_mode(const union fscrypt_policy *policy,
|
|
|
|
|
const struct inode *inode)
|
|
|
|
|
{
|
|
|
|
|
if (S_ISREG(inode->i_mode))
|
|
|
|
|
return &fscrypt_modes[fscrypt_policy_contents_mode(policy)];
|
|
|
|
|
|
|
|
|
|
if (S_ISDIR(inode->i_mode) || S_ISLNK(inode->i_mode))
|
|
|
|
|
return &fscrypt_modes[fscrypt_policy_fnames_mode(policy)];
|
|
|
|
|
|
|
|
|
|
WARN_ONCE(1, "fscrypt: filesystem tried to load encryption info for inode %lu, which is not encryptable (file type %d)\n",
|
|
|
|
|
inode->i_ino, (inode->i_mode & S_IFMT));
|
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Create a symmetric cipher object for the given encryption mode and key */
|
|
|
|
|
static struct crypto_skcipher *
|
|
|
|
|
fscrypt_allocate_skcipher(struct fscrypt_mode *mode, const u8 *raw_key,
|
|
|
|
|
const struct inode *inode)
|
fscrypt: add Adiantum support / removed speck
Add support for the Adiantum encryption mode to fscrypt. Adiantum is a
tweakable, length-preserving encryption mode with security provably
reducible to that of XChaCha12 and AES-256, subject to a security bound.
It's also a true wide-block mode, unlike XTS. See the paper
"Adiantum: length-preserving encryption for entry-level processors"
(https://eprint.iacr.org/2018/720.pdf) for more details. Also see
commit 059c2a4d8e16 ("crypto: adiantum - add Adiantum support").
On sufficiently long messages, Adiantum's bottlenecks are XChaCha12 and
the NH hash function. These algorithms are fast even on processors
without dedicated crypto instructions. Adiantum makes it feasible to
enable storage encryption on low-end mobile devices that lack AES
instructions; currently such devices are unencrypted. On ARM Cortex-A7,
on 4096-byte messages Adiantum encryption is about 4 times faster than
AES-256-XTS encryption; decryption is about 5 times faster.
In fscrypt, Adiantum is suitable for encrypting both file contents and
names. With filenames, it fixes a known weakness: when two filenames in
a directory share a common prefix of >= 16 bytes, with CTS-CBC their
encrypted filenames share a common prefix too, leaking information.
Adiantum does not have this problem.
Since Adiantum also accepts long tweaks (IVs), it's also safe to use the
master key directly for Adiantum encryption rather than deriving
per-file keys, provided that the per-file nonce is included in the IVs
and the master key isn't used for any other encryption mode. This
configuration saves memory and improves performance. A new fscrypt
policy flag is added to allow users to opt-in to this configuration.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
6 years ago
|
|
|
{
|
|
|
|
|
struct crypto_skcipher *tfm;
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
tfm = crypto_alloc_skcipher(mode->cipher_str, 0, 0);
|
|
|
|
|
if (IS_ERR(tfm)) {
|
|
|
|
|
if (PTR_ERR(tfm) == -ENOENT) {
|
|
|
|
|
fscrypt_warn(inode,
|
|
|
|
|
"Missing crypto API support for %s (API name: \"%s\")",
|
|
|
|
|
mode->friendly_name, mode->cipher_str);
|
|
|
|
|
return ERR_PTR(-ENOPKG);
|
|
|
|
|
}
|
|
|
|
|
fscrypt_err(inode, "Error allocating '%s' transform: %ld",
|
|
|
|
|
mode->cipher_str, PTR_ERR(tfm));
|
fscrypt: add Adiantum support / removed speck
Add support for the Adiantum encryption mode to fscrypt. Adiantum is a
tweakable, length-preserving encryption mode with security provably
reducible to that of XChaCha12 and AES-256, subject to a security bound.
It's also a true wide-block mode, unlike XTS. See the paper
"Adiantum: length-preserving encryption for entry-level processors"
(https://eprint.iacr.org/2018/720.pdf) for more details. Also see
commit 059c2a4d8e16 ("crypto: adiantum - add Adiantum support").
On sufficiently long messages, Adiantum's bottlenecks are XChaCha12 and
the NH hash function. These algorithms are fast even on processors
without dedicated crypto instructions. Adiantum makes it feasible to
enable storage encryption on low-end mobile devices that lack AES
instructions; currently such devices are unencrypted. On ARM Cortex-A7,
on 4096-byte messages Adiantum encryption is about 4 times faster than
AES-256-XTS encryption; decryption is about 5 times faster.
In fscrypt, Adiantum is suitable for encrypting both file contents and
names. With filenames, it fixes a known weakness: when two filenames in
a directory share a common prefix of >= 16 bytes, with CTS-CBC their
encrypted filenames share a common prefix too, leaking information.
Adiantum does not have this problem.
Since Adiantum also accepts long tweaks (IVs), it's also safe to use the
master key directly for Adiantum encryption rather than deriving
per-file keys, provided that the per-file nonce is included in the IVs
and the master key isn't used for any other encryption mode. This
configuration saves memory and improves performance. A new fscrypt
policy flag is added to allow users to opt-in to this configuration.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
6 years ago
|
|
|
return tfm;
|
|
|
|
|
}
|
|
|
|
|
if (!xchg(&mode->logged_impl_name, 1)) {
|
fscrypt: add Adiantum support / removed speck
Add support for the Adiantum encryption mode to fscrypt. Adiantum is a
tweakable, length-preserving encryption mode with security provably
reducible to that of XChaCha12 and AES-256, subject to a security bound.
It's also a true wide-block mode, unlike XTS. See the paper
"Adiantum: length-preserving encryption for entry-level processors"
(https://eprint.iacr.org/2018/720.pdf) for more details. Also see
commit 059c2a4d8e16 ("crypto: adiantum - add Adiantum support").
On sufficiently long messages, Adiantum's bottlenecks are XChaCha12 and
the NH hash function. These algorithms are fast even on processors
without dedicated crypto instructions. Adiantum makes it feasible to
enable storage encryption on low-end mobile devices that lack AES
instructions; currently such devices are unencrypted. On ARM Cortex-A7,
on 4096-byte messages Adiantum encryption is about 4 times faster than
AES-256-XTS encryption; decryption is about 5 times faster.
In fscrypt, Adiantum is suitable for encrypting both file contents and
names. With filenames, it fixes a known weakness: when two filenames in
a directory share a common prefix of >= 16 bytes, with CTS-CBC their
encrypted filenames share a common prefix too, leaking information.
Adiantum does not have this problem.
Since Adiantum also accepts long tweaks (IVs), it's also safe to use the
master key directly for Adiantum encryption rather than deriving
per-file keys, provided that the per-file nonce is included in the IVs
and the master key isn't used for any other encryption mode. This
configuration saves memory and improves performance. A new fscrypt
policy flag is added to allow users to opt-in to this configuration.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
6 years ago
|
|
|
/*
|
|
|
|
|
* fscrypt performance can vary greatly depending on which
|
|
|
|
|
* crypto algorithm implementation is used. Help people debug
|
|
|
|
|
* performance problems by logging the ->cra_driver_name the
|
|
|
|
|
* first time a mode is used.
|
fscrypt: add Adiantum support / removed speck
Add support for the Adiantum encryption mode to fscrypt. Adiantum is a
tweakable, length-preserving encryption mode with security provably
reducible to that of XChaCha12 and AES-256, subject to a security bound.
It's also a true wide-block mode, unlike XTS. See the paper
"Adiantum: length-preserving encryption for entry-level processors"
(https://eprint.iacr.org/2018/720.pdf) for more details. Also see
commit 059c2a4d8e16 ("crypto: adiantum - add Adiantum support").
On sufficiently long messages, Adiantum's bottlenecks are XChaCha12 and
the NH hash function. These algorithms are fast even on processors
without dedicated crypto instructions. Adiantum makes it feasible to
enable storage encryption on low-end mobile devices that lack AES
instructions; currently such devices are unencrypted. On ARM Cortex-A7,
on 4096-byte messages Adiantum encryption is about 4 times faster than
AES-256-XTS encryption; decryption is about 5 times faster.
In fscrypt, Adiantum is suitable for encrypting both file contents and
names. With filenames, it fixes a known weakness: when two filenames in
a directory share a common prefix of >= 16 bytes, with CTS-CBC their
encrypted filenames share a common prefix too, leaking information.
Adiantum does not have this problem.
Since Adiantum also accepts long tweaks (IVs), it's also safe to use the
master key directly for Adiantum encryption rather than deriving
per-file keys, provided that the per-file nonce is included in the IVs
and the master key isn't used for any other encryption mode. This
configuration saves memory and improves performance. A new fscrypt
policy flag is added to allow users to opt-in to this configuration.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
6 years ago
|
|
|
*/
|
|
|
|
|
pr_info("fscrypt: %s using implementation \"%s\"\n",
|
|
|
|
|
mode->friendly_name, crypto_skcipher_driver_name(tfm));
|
|
|
|
|
}
|
|
|
|
|
if (WARN_ON(crypto_skcipher_ivsize(tfm) != mode->ivsize)) {
|
|
|
|
|
err = -EINVAL;
|
|
|
|
|
goto err_free_tfm;
|
fscrypt: add Adiantum support / removed speck
Add support for the Adiantum encryption mode to fscrypt. Adiantum is a
tweakable, length-preserving encryption mode with security provably
reducible to that of XChaCha12 and AES-256, subject to a security bound.
It's also a true wide-block mode, unlike XTS. See the paper
"Adiantum: length-preserving encryption for entry-level processors"
(https://eprint.iacr.org/2018/720.pdf) for more details. Also see
commit 059c2a4d8e16 ("crypto: adiantum - add Adiantum support").
On sufficiently long messages, Adiantum's bottlenecks are XChaCha12 and
the NH hash function. These algorithms are fast even on processors
without dedicated crypto instructions. Adiantum makes it feasible to
enable storage encryption on low-end mobile devices that lack AES
instructions; currently such devices are unencrypted. On ARM Cortex-A7,
on 4096-byte messages Adiantum encryption is about 4 times faster than
AES-256-XTS encryption; decryption is about 5 times faster.
In fscrypt, Adiantum is suitable for encrypting both file contents and
names. With filenames, it fixes a known weakness: when two filenames in
a directory share a common prefix of >= 16 bytes, with CTS-CBC their
encrypted filenames share a common prefix too, leaking information.
Adiantum does not have this problem.
Since Adiantum also accepts long tweaks (IVs), it's also safe to use the
master key directly for Adiantum encryption rather than deriving
per-file keys, provided that the per-file nonce is included in the IVs
and the master key isn't used for any other encryption mode. This
configuration saves memory and improves performance. A new fscrypt
policy flag is added to allow users to opt-in to this configuration.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
6 years ago
|
|
|
}
|
|
|
|
|
crypto_skcipher_set_flags(tfm, CRYPTO_TFM_REQ_WEAK_KEY);
|
|
|
|
|
err = crypto_skcipher_setkey(tfm, raw_key, mode->keysize);
|
|
|
|
|
if (err)
|
|
|
|
|
goto err_free_tfm;
|
|
|
|
|
|
|
|
|
|
return tfm;
|
|
|
|
|
|
|
|
|
|
err_free_tfm:
|
|
|
|
|
crypto_free_skcipher(tfm);
|
|
|
|
|
return ERR_PTR(err);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Prepare the crypto transform object or blk-crypto key in @prep_key, given the
|
|
|
|
|
* raw key, encryption mode, and flag indicating which encryption implementation
|
|
|
|
|
* (fs-layer or blk-crypto) will be used.
|
|
|
|
|
*/
|
|
|
|
|
int fscrypt_prepare_key(struct fscrypt_prepared_key *prep_key,
|
|
|
|
|
const u8 *raw_key, unsigned int raw_key_size,
|
|
|
|
|
bool is_hw_wrapped, const struct fscrypt_info *ci)
|
fscrypt: add Adiantum support / removed speck
Add support for the Adiantum encryption mode to fscrypt. Adiantum is a
tweakable, length-preserving encryption mode with security provably
reducible to that of XChaCha12 and AES-256, subject to a security bound.
It's also a true wide-block mode, unlike XTS. See the paper
"Adiantum: length-preserving encryption for entry-level processors"
(https://eprint.iacr.org/2018/720.pdf) for more details. Also see
commit 059c2a4d8e16 ("crypto: adiantum - add Adiantum support").
On sufficiently long messages, Adiantum's bottlenecks are XChaCha12 and
the NH hash function. These algorithms are fast even on processors
without dedicated crypto instructions. Adiantum makes it feasible to
enable storage encryption on low-end mobile devices that lack AES
instructions; currently such devices are unencrypted. On ARM Cortex-A7,
on 4096-byte messages Adiantum encryption is about 4 times faster than
AES-256-XTS encryption; decryption is about 5 times faster.
In fscrypt, Adiantum is suitable for encrypting both file contents and
names. With filenames, it fixes a known weakness: when two filenames in
a directory share a common prefix of >= 16 bytes, with CTS-CBC their
encrypted filenames share a common prefix too, leaking information.
Adiantum does not have this problem.
Since Adiantum also accepts long tweaks (IVs), it's also safe to use the
master key directly for Adiantum encryption rather than deriving
per-file keys, provided that the per-file nonce is included in the IVs
and the master key isn't used for any other encryption mode. This
configuration saves memory and improves performance. A new fscrypt
policy flag is added to allow users to opt-in to this configuration.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
6 years ago
|
|
|
{
|
|
|
|
|
struct crypto_skcipher *tfm;
|
|
|
|
|
|
|
|
|
|
if (fscrypt_using_inline_encryption(ci))
|
|
|
|
|
return fscrypt_prepare_inline_crypt_key(prep_key,
|
|
|
|
|
raw_key, raw_key_size, is_hw_wrapped, ci);
|
|
|
|
|
|
|
|
|
|
if (WARN_ON(is_hw_wrapped || raw_key_size != ci->ci_mode->keysize))
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
|
|
tfm = fscrypt_allocate_skcipher(ci->ci_mode, raw_key, ci->ci_inode);
|
|
|
|
|
if (IS_ERR(tfm))
|
|
|
|
|
return PTR_ERR(tfm);
|
|
|
|
|
/*
|
|
|
|
|
* Pairs with READ_ONCE() in fscrypt_is_key_prepared(). (Only matters
|
|
|
|
|
* for the per-mode keys, which are shared by multiple inodes.)
|
|
|
|
|
*/
|
|
|
|
|
smp_store_release(&prep_key->tfm, tfm);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Destroy a crypto transform object and/or blk-crypto key. */
|
|
|
|
|
void fscrypt_destroy_prepared_key(struct fscrypt_prepared_key *prep_key)
|
|
|
|
|
{
|
|
|
|
|
crypto_free_skcipher(prep_key->tfm);
|
|
|
|
|
fscrypt_destroy_inline_crypt_key(prep_key);
|
|
|
|
|
}
|
fscrypt: add Adiantum support / removed speck
Add support for the Adiantum encryption mode to fscrypt. Adiantum is a
tweakable, length-preserving encryption mode with security provably
reducible to that of XChaCha12 and AES-256, subject to a security bound.
It's also a true wide-block mode, unlike XTS. See the paper
"Adiantum: length-preserving encryption for entry-level processors"
(https://eprint.iacr.org/2018/720.pdf) for more details. Also see
commit 059c2a4d8e16 ("crypto: adiantum - add Adiantum support").
On sufficiently long messages, Adiantum's bottlenecks are XChaCha12 and
the NH hash function. These algorithms are fast even on processors
without dedicated crypto instructions. Adiantum makes it feasible to
enable storage encryption on low-end mobile devices that lack AES
instructions; currently such devices are unencrypted. On ARM Cortex-A7,
on 4096-byte messages Adiantum encryption is about 4 times faster than
AES-256-XTS encryption; decryption is about 5 times faster.
In fscrypt, Adiantum is suitable for encrypting both file contents and
names. With filenames, it fixes a known weakness: when two filenames in
a directory share a common prefix of >= 16 bytes, with CTS-CBC their
encrypted filenames share a common prefix too, leaking information.
Adiantum does not have this problem.
Since Adiantum also accepts long tweaks (IVs), it's also safe to use the
master key directly for Adiantum encryption rather than deriving
per-file keys, provided that the per-file nonce is included in the IVs
and the master key isn't used for any other encryption mode. This
configuration saves memory and improves performance. A new fscrypt
policy flag is added to allow users to opt-in to this configuration.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
6 years ago
|
|
|
|
|
|
|
|
/* Given a per-file encryption key, set up the file's crypto transform object */
|
|
|
|
|
int fscrypt_set_per_file_enc_key(struct fscrypt_info *ci, const u8 *raw_key)
|
|
|
|
|
{
|
fscrypt: add support for IV_INO_LBLK_64 policies
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: Paul Crowley <paulcrowley@google.com>
Co-developed-by: Satya Tangirala <satyat@google.com>
Signed-off-by: Satya Tangirala <satyat@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
ci->ci_owns_key = true;
|
|
|
|
|
return fscrypt_prepare_key(&ci->ci_key, raw_key, ci->ci_mode->keysize,
|
|
|
|
|
false /*is_hw_wrapped*/, ci);
|
fscrypt: add Adiantum support / removed speck
Add support for the Adiantum encryption mode to fscrypt. Adiantum is a
tweakable, length-preserving encryption mode with security provably
reducible to that of XChaCha12 and AES-256, subject to a security bound.
It's also a true wide-block mode, unlike XTS. See the paper
"Adiantum: length-preserving encryption for entry-level processors"
(https://eprint.iacr.org/2018/720.pdf) for more details. Also see
commit 059c2a4d8e16 ("crypto: adiantum - add Adiantum support").
On sufficiently long messages, Adiantum's bottlenecks are XChaCha12 and
the NH hash function. These algorithms are fast even on processors
without dedicated crypto instructions. Adiantum makes it feasible to
enable storage encryption on low-end mobile devices that lack AES
instructions; currently such devices are unencrypted. On ARM Cortex-A7,
on 4096-byte messages Adiantum encryption is about 4 times faster than
AES-256-XTS encryption; decryption is about 5 times faster.
In fscrypt, Adiantum is suitable for encrypting both file contents and
names. With filenames, it fixes a known weakness: when two filenames in
a directory share a common prefix of >= 16 bytes, with CTS-CBC their
encrypted filenames share a common prefix too, leaking information.
Adiantum does not have this problem.
Since Adiantum also accepts long tweaks (IVs), it's also safe to use the
master key directly for Adiantum encryption rather than deriving
per-file keys, provided that the per-file nonce is included in the IVs
and the master key isn't used for any other encryption mode. This
configuration saves memory and improves performance. A new fscrypt
policy flag is added to allow users to opt-in to this configuration.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
6 years ago
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int setup_per_mode_enc_key(struct fscrypt_info *ci,
|
|
|
|
|
struct fscrypt_master_key *mk,
|
|
|
|
|
struct fscrypt_prepared_key *keys,
|
|
|
|
|
u8 hkdf_context, bool include_fs_uuid)
|
fscrypt: v2 encryption policy support
Add a new fscrypt policy version, "v2". It has the following changes
from the original policy version, which we call "v1" (*):
- Master keys (the user-provided encryption keys) are only ever used as
input to HKDF-SHA512. This is more flexible and less error-prone, and
it avoids the quirks and limitations of the AES-128-ECB based KDF.
Three classes of cryptographically isolated subkeys are defined:
- Per-file keys, like used in v1 policies except for the new KDF.
- Per-mode keys. These implement the semantics of the DIRECT_KEY
flag, which for v1 policies made the master key be used directly.
These are also planned to be used for inline encryption when
support for it is added.
- Key identifiers (see below).
- Each master key is identified by a 16-byte master_key_identifier,
which is derived from the key itself using HKDF-SHA512. This prevents
users from associating the wrong key with an encrypted file or
directory. This was easily possible with v1 policies, which
identified the key by an arbitrary 8-byte master_key_descriptor.
- The key must be provided in the filesystem-level keyring, not in a
process-subscribed keyring.
The following UAPI additions are made:
- The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
- A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
getting the v1 or v2 encryption policy of an encrypted file or
directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
be used because it did not have a way for userspace to indicate which
policy structure is expected. The new ioctl includes a size field, so
it is extensible to future fscrypt policy versions.
- The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
encryption policies. Such keys are kept logically separate from keys
for v1 encryption policies, and are identified by 'identifier' rather
than by 'descriptor'. The 'identifier' need not be provided when
adding a key, since the kernel will calculate it anyway.
This patch temporarily keeps adding/removing v2 policy keys behind the
same permission check done for adding/removing v1 policy keys:
capable(CAP_SYS_ADMIN). However, the next patch will carefully take
advantage of the cryptographically secure master_key_identifier to allow
non-root users to add/remove v2 policy keys, thus providing a full
replacement for v1 policies.
(*) Actually, in the API fscrypt_policy::version is 0 while on-disk
fscrypt_context::format is 1. But I believe it makes the most sense
to advance both to '2' to have them be in sync, and to consider the
numbering to start at 1 except for the API quirk.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
{
|
fscrypt: add support for IV_INO_LBLK_64 policies
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: Paul Crowley <paulcrowley@google.com>
Co-developed-by: Satya Tangirala <satyat@google.com>
Signed-off-by: Satya Tangirala <satyat@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
const struct inode *inode = ci->ci_inode;
|
|
|
|
|
const struct super_block *sb = inode->i_sb;
|
fscrypt: v2 encryption policy support
Add a new fscrypt policy version, "v2". It has the following changes
from the original policy version, which we call "v1" (*):
- Master keys (the user-provided encryption keys) are only ever used as
input to HKDF-SHA512. This is more flexible and less error-prone, and
it avoids the quirks and limitations of the AES-128-ECB based KDF.
Three classes of cryptographically isolated subkeys are defined:
- Per-file keys, like used in v1 policies except for the new KDF.
- Per-mode keys. These implement the semantics of the DIRECT_KEY
flag, which for v1 policies made the master key be used directly.
These are also planned to be used for inline encryption when
support for it is added.
- Key identifiers (see below).
- Each master key is identified by a 16-byte master_key_identifier,
which is derived from the key itself using HKDF-SHA512. This prevents
users from associating the wrong key with an encrypted file or
directory. This was easily possible with v1 policies, which
identified the key by an arbitrary 8-byte master_key_descriptor.
- The key must be provided in the filesystem-level keyring, not in a
process-subscribed keyring.
The following UAPI additions are made:
- The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
- A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
getting the v1 or v2 encryption policy of an encrypted file or
directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
be used because it did not have a way for userspace to indicate which
policy structure is expected. The new ioctl includes a size field, so
it is extensible to future fscrypt policy versions.
- The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
encryption policies. Such keys are kept logically separate from keys
for v1 encryption policies, and are identified by 'identifier' rather
than by 'descriptor'. The 'identifier' need not be provided when
adding a key, since the kernel will calculate it anyway.
This patch temporarily keeps adding/removing v2 policy keys behind the
same permission check done for adding/removing v1 policy keys:
capable(CAP_SYS_ADMIN). However, the next patch will carefully take
advantage of the cryptographically secure master_key_identifier to allow
non-root users to add/remove v2 policy keys, thus providing a full
replacement for v1 policies.
(*) Actually, in the API fscrypt_policy::version is 0 while on-disk
fscrypt_context::format is 1. But I believe it makes the most sense
to advance both to '2' to have them be in sync, and to consider the
numbering to start at 1 except for the API quirk.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
struct fscrypt_mode *mode = ci->ci_mode;
|
|
|
|
|
const u8 mode_num = mode - fscrypt_modes;
|
|
|
|
|
struct fscrypt_prepared_key *prep_key;
|
fscrypt: v2 encryption policy support
Add a new fscrypt policy version, "v2". It has the following changes
from the original policy version, which we call "v1" (*):
- Master keys (the user-provided encryption keys) are only ever used as
input to HKDF-SHA512. This is more flexible and less error-prone, and
it avoids the quirks and limitations of the AES-128-ECB based KDF.
Three classes of cryptographically isolated subkeys are defined:
- Per-file keys, like used in v1 policies except for the new KDF.
- Per-mode keys. These implement the semantics of the DIRECT_KEY
flag, which for v1 policies made the master key be used directly.
These are also planned to be used for inline encryption when
support for it is added.
- Key identifiers (see below).
- Each master key is identified by a 16-byte master_key_identifier,
which is derived from the key itself using HKDF-SHA512. This prevents
users from associating the wrong key with an encrypted file or
directory. This was easily possible with v1 policies, which
identified the key by an arbitrary 8-byte master_key_descriptor.
- The key must be provided in the filesystem-level keyring, not in a
process-subscribed keyring.
The following UAPI additions are made:
- The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
- A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
getting the v1 or v2 encryption policy of an encrypted file or
directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
be used because it did not have a way for userspace to indicate which
policy structure is expected. The new ioctl includes a size field, so
it is extensible to future fscrypt policy versions.
- The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
encryption policies. Such keys are kept logically separate from keys
for v1 encryption policies, and are identified by 'identifier' rather
than by 'descriptor'. The 'identifier' need not be provided when
adding a key, since the kernel will calculate it anyway.
This patch temporarily keeps adding/removing v2 policy keys behind the
same permission check done for adding/removing v1 policy keys:
capable(CAP_SYS_ADMIN). However, the next patch will carefully take
advantage of the cryptographically secure master_key_identifier to allow
non-root users to add/remove v2 policy keys, thus providing a full
replacement for v1 policies.
(*) Actually, in the API fscrypt_policy::version is 0 while on-disk
fscrypt_context::format is 1. But I believe it makes the most sense
to advance both to '2' to have them be in sync, and to consider the
numbering to start at 1 except for the API quirk.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
u8 mode_key[FSCRYPT_MAX_KEY_SIZE];
|
fscrypt: add support for IV_INO_LBLK_64 policies
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: Paul Crowley <paulcrowley@google.com>
Co-developed-by: Satya Tangirala <satyat@google.com>
Signed-off-by: Satya Tangirala <satyat@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
u8 hkdf_info[sizeof(mode_num) + sizeof(sb->s_uuid)];
|
|
|
|
|
unsigned int hkdf_infolen = 0;
|
fscrypt: v2 encryption policy support
Add a new fscrypt policy version, "v2". It has the following changes
from the original policy version, which we call "v1" (*):
- Master keys (the user-provided encryption keys) are only ever used as
input to HKDF-SHA512. This is more flexible and less error-prone, and
it avoids the quirks and limitations of the AES-128-ECB based KDF.
Three classes of cryptographically isolated subkeys are defined:
- Per-file keys, like used in v1 policies except for the new KDF.
- Per-mode keys. These implement the semantics of the DIRECT_KEY
flag, which for v1 policies made the master key be used directly.
These are also planned to be used for inline encryption when
support for it is added.
- Key identifiers (see below).
- Each master key is identified by a 16-byte master_key_identifier,
which is derived from the key itself using HKDF-SHA512. This prevents
users from associating the wrong key with an encrypted file or
directory. This was easily possible with v1 policies, which
identified the key by an arbitrary 8-byte master_key_descriptor.
- The key must be provided in the filesystem-level keyring, not in a
process-subscribed keyring.
The following UAPI additions are made:
- The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
- A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
getting the v1 or v2 encryption policy of an encrypted file or
directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
be used because it did not have a way for userspace to indicate which
policy structure is expected. The new ioctl includes a size field, so
it is extensible to future fscrypt policy versions.
- The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
encryption policies. Such keys are kept logically separate from keys
for v1 encryption policies, and are identified by 'identifier' rather
than by 'descriptor'. The 'identifier' need not be provided when
adding a key, since the kernel will calculate it anyway.
This patch temporarily keeps adding/removing v2 policy keys behind the
same permission check done for adding/removing v1 policy keys:
capable(CAP_SYS_ADMIN). However, the next patch will carefully take
advantage of the cryptographically secure master_key_identifier to allow
non-root users to add/remove v2 policy keys, thus providing a full
replacement for v1 policies.
(*) Actually, in the API fscrypt_policy::version is 0 while on-disk
fscrypt_context::format is 1. But I believe it makes the most sense
to advance both to '2' to have them be in sync, and to consider the
numbering to start at 1 except for the API quirk.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
int err;
|
|
|
|
|
|
fscrypt: add support for IV_INO_LBLK_64 policies
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: Paul Crowley <paulcrowley@google.com>
Co-developed-by: Satya Tangirala <satyat@google.com>
Signed-off-by: Satya Tangirala <satyat@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
if (WARN_ON(mode_num > __FSCRYPT_MODE_MAX))
|
fscrypt: v2 encryption policy support
Add a new fscrypt policy version, "v2". It has the following changes
from the original policy version, which we call "v1" (*):
- Master keys (the user-provided encryption keys) are only ever used as
input to HKDF-SHA512. This is more flexible and less error-prone, and
it avoids the quirks and limitations of the AES-128-ECB based KDF.
Three classes of cryptographically isolated subkeys are defined:
- Per-file keys, like used in v1 policies except for the new KDF.
- Per-mode keys. These implement the semantics of the DIRECT_KEY
flag, which for v1 policies made the master key be used directly.
These are also planned to be used for inline encryption when
support for it is added.
- Key identifiers (see below).
- Each master key is identified by a 16-byte master_key_identifier,
which is derived from the key itself using HKDF-SHA512. This prevents
users from associating the wrong key with an encrypted file or
directory. This was easily possible with v1 policies, which
identified the key by an arbitrary 8-byte master_key_descriptor.
- The key must be provided in the filesystem-level keyring, not in a
process-subscribed keyring.
The following UAPI additions are made:
- The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
- A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
getting the v1 or v2 encryption policy of an encrypted file or
directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
be used because it did not have a way for userspace to indicate which
policy structure is expected. The new ioctl includes a size field, so
it is extensible to future fscrypt policy versions.
- The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
encryption policies. Such keys are kept logically separate from keys
for v1 encryption policies, and are identified by 'identifier' rather
than by 'descriptor'. The 'identifier' need not be provided when
adding a key, since the kernel will calculate it anyway.
This patch temporarily keeps adding/removing v2 policy keys behind the
same permission check done for adding/removing v1 policy keys:
capable(CAP_SYS_ADMIN). However, the next patch will carefully take
advantage of the cryptographically secure master_key_identifier to allow
non-root users to add/remove v2 policy keys, thus providing a full
replacement for v1 policies.
(*) Actually, in the API fscrypt_policy::version is 0 while on-disk
fscrypt_context::format is 1. But I believe it makes the most sense
to advance both to '2' to have them be in sync, and to consider the
numbering to start at 1 except for the API quirk.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
|
|
prep_key = &keys[mode_num];
|
|
|
|
|
if (fscrypt_is_key_prepared(prep_key, ci)) {
|
|
|
|
|
ci->ci_key = *prep_key;
|
|
|
|
|
return 0;
|
fscrypt: add support for IV_INO_LBLK_64 policies
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: Paul Crowley <paulcrowley@google.com>
Co-developed-by: Satya Tangirala <satyat@google.com>
Signed-off-by: Satya Tangirala <satyat@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
}
|
fscrypt: v2 encryption policy support
Add a new fscrypt policy version, "v2". It has the following changes
from the original policy version, which we call "v1" (*):
- Master keys (the user-provided encryption keys) are only ever used as
input to HKDF-SHA512. This is more flexible and less error-prone, and
it avoids the quirks and limitations of the AES-128-ECB based KDF.
Three classes of cryptographically isolated subkeys are defined:
- Per-file keys, like used in v1 policies except for the new KDF.
- Per-mode keys. These implement the semantics of the DIRECT_KEY
flag, which for v1 policies made the master key be used directly.
These are also planned to be used for inline encryption when
support for it is added.
- Key identifiers (see below).
- Each master key is identified by a 16-byte master_key_identifier,
which is derived from the key itself using HKDF-SHA512. This prevents
users from associating the wrong key with an encrypted file or
directory. This was easily possible with v1 policies, which
identified the key by an arbitrary 8-byte master_key_descriptor.
- The key must be provided in the filesystem-level keyring, not in a
process-subscribed keyring.
The following UAPI additions are made:
- The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
- A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
getting the v1 or v2 encryption policy of an encrypted file or
directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
be used because it did not have a way for userspace to indicate which
policy structure is expected. The new ioctl includes a size field, so
it is extensible to future fscrypt policy versions.
- The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
encryption policies. Such keys are kept logically separate from keys
for v1 encryption policies, and are identified by 'identifier' rather
than by 'descriptor'. The 'identifier' need not be provided when
adding a key, since the kernel will calculate it anyway.
This patch temporarily keeps adding/removing v2 policy keys behind the
same permission check done for adding/removing v1 policy keys:
capable(CAP_SYS_ADMIN). However, the next patch will carefully take
advantage of the cryptographically secure master_key_identifier to allow
non-root users to add/remove v2 policy keys, thus providing a full
replacement for v1 policies.
(*) Actually, in the API fscrypt_policy::version is 0 while on-disk
fscrypt_context::format is 1. But I believe it makes the most sense
to advance both to '2' to have them be in sync, and to consider the
numbering to start at 1 except for the API quirk.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
|
BACKPORT: FROMLIST: fscrypt: add support for IV_INO_LBLK_32 policies
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 <ebiggers@google.com>
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 <ebiggers@google.com>
Git-commit: a52238353e6711ae8ef8f3b462cece3b05aead8f
Git-repo: https://android.googlesource.com/kernel/common/+/refs/heads/android-4.14-stable
[neersoni@codeaurora.org: back port the changes and fixed merge
conflicts in fscrypt_privat.h and inline_crypt.c files]
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
5 years ago
|
|
|
mutex_lock(&fscrypt_mode_key_setup_mutex);
|
|
|
|
|
|
|
|
|
|
if (fscrypt_is_key_prepared(prep_key, ci))
|
|
|
|
|
goto done_unlock;
|
|
|
|
|
|
|
|
|
|
if (mk->mk_secret.is_hw_wrapped && S_ISREG(inode->i_mode)) {
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
if (!fscrypt_using_inline_encryption(ci)) {
|
|
|
|
|
fscrypt_warn(ci->ci_inode,
|
|
|
|
|
"Hardware-wrapped keys require inline encryption (-o inlinecrypt)");
|
|
|
|
|
err = -EINVAL;
|
|
|
|
|
goto out_unlock;
|
|
|
|
|
}
|
|
|
|
|
for (i = 0; i <= __FSCRYPT_MODE_MAX; i++) {
|
|
|
|
|
if (fscrypt_is_key_prepared(&keys[i], ci)) {
|
|
|
|
|
fscrypt_warn(ci->ci_inode,
|
|
|
|
|
"Each hardware-wrapped key can only be used with one encryption mode");
|
|
|
|
|
err = -EINVAL;
|
|
|
|
|
goto out_unlock;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
err = fscrypt_prepare_key(prep_key, mk->mk_secret.raw,
|
|
|
|
|
mk->mk_secret.size, true, ci);
|
|
|
|
|
if (err)
|
|
|
|
|
goto out_unlock;
|
|
|
|
|
} else {
|
|
|
|
|
BUILD_BUG_ON(sizeof(mode_num) != 1);
|
|
|
|
|
BUILD_BUG_ON(sizeof(sb->s_uuid) != 16);
|
|
|
|
|
BUILD_BUG_ON(sizeof(hkdf_info) != 17);
|
|
|
|
|
hkdf_info[hkdf_infolen++] = mode_num;
|
|
|
|
|
if (include_fs_uuid) {
|
|
|
|
|
memcpy(&hkdf_info[hkdf_infolen], &sb->s_uuid,
|
|
|
|
|
sizeof(sb->s_uuid));
|
|
|
|
|
hkdf_infolen += sizeof(sb->s_uuid);
|
|
|
|
|
}
|
|
|
|
|
err = fscrypt_hkdf_expand(&mk->mk_secret.hkdf,
|
|
|
|
|
hkdf_context, hkdf_info, hkdf_infolen,
|
|
|
|
|
mode_key, mode->keysize);
|
|
|
|
|
if (err)
|
|
|
|
|
goto out_unlock;
|
|
|
|
|
err = fscrypt_prepare_key(prep_key, mode_key, mode->keysize,
|
|
|
|
|
false /*is_hw_wrapped*/, ci);
|
|
|
|
|
memzero_explicit(mode_key, mode->keysize);
|
|
|
|
|
if (err)
|
|
|
|
|
goto out_unlock;
|
fscrypt: v2 encryption policy support
Add a new fscrypt policy version, "v2". It has the following changes
from the original policy version, which we call "v1" (*):
- Master keys (the user-provided encryption keys) are only ever used as
input to HKDF-SHA512. This is more flexible and less error-prone, and
it avoids the quirks and limitations of the AES-128-ECB based KDF.
Three classes of cryptographically isolated subkeys are defined:
- Per-file keys, like used in v1 policies except for the new KDF.
- Per-mode keys. These implement the semantics of the DIRECT_KEY
flag, which for v1 policies made the master key be used directly.
These are also planned to be used for inline encryption when
support for it is added.
- Key identifiers (see below).
- Each master key is identified by a 16-byte master_key_identifier,
which is derived from the key itself using HKDF-SHA512. This prevents
users from associating the wrong key with an encrypted file or
directory. This was easily possible with v1 policies, which
identified the key by an arbitrary 8-byte master_key_descriptor.
- The key must be provided in the filesystem-level keyring, not in a
process-subscribed keyring.
The following UAPI additions are made:
- The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
- A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
getting the v1 or v2 encryption policy of an encrypted file or
directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
be used because it did not have a way for userspace to indicate which
policy structure is expected. The new ioctl includes a size field, so
it is extensible to future fscrypt policy versions.
- The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
encryption policies. Such keys are kept logically separate from keys
for v1 encryption policies, and are identified by 'identifier' rather
than by 'descriptor'. The 'identifier' need not be provided when
adding a key, since the kernel will calculate it anyway.
This patch temporarily keeps adding/removing v2 policy keys behind the
same permission check done for adding/removing v1 policy keys:
capable(CAP_SYS_ADMIN). However, the next patch will carefully take
advantage of the cryptographically secure master_key_identifier to allow
non-root users to add/remove v2 policy keys, thus providing a full
replacement for v1 policies.
(*) Actually, in the API fscrypt_policy::version is 0 while on-disk
fscrypt_context::format is 1. But I believe it makes the most sense
to advance both to '2' to have them be in sync, and to consider the
numbering to start at 1 except for the API quirk.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
}
|
|
|
|
|
done_unlock:
|
|
|
|
|
ci->ci_key = *prep_key;
|
|
|
|
|
|
|
|
|
|
err = 0;
|
|
|
|
|
out_unlock:
|
BACKPORT: FROMLIST: fscrypt: add support for IV_INO_LBLK_32 policies
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 <ebiggers@google.com>
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 <ebiggers@google.com>
Git-commit: a52238353e6711ae8ef8f3b462cece3b05aead8f
Git-repo: https://android.googlesource.com/kernel/common/+/refs/heads/android-4.14-stable
[neersoni@codeaurora.org: back port the changes and fixed merge
conflicts in fscrypt_privat.h and inline_crypt.c files]
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
5 years ago
|
|
|
mutex_unlock(&fscrypt_mode_key_setup_mutex);
|
|
|
|
|
return err;
|
fscrypt: v2 encryption policy support
Add a new fscrypt policy version, "v2". It has the following changes
from the original policy version, which we call "v1" (*):
- Master keys (the user-provided encryption keys) are only ever used as
input to HKDF-SHA512. This is more flexible and less error-prone, and
it avoids the quirks and limitations of the AES-128-ECB based KDF.
Three classes of cryptographically isolated subkeys are defined:
- Per-file keys, like used in v1 policies except for the new KDF.
- Per-mode keys. These implement the semantics of the DIRECT_KEY
flag, which for v1 policies made the master key be used directly.
These are also planned to be used for inline encryption when
support for it is added.
- Key identifiers (see below).
- Each master key is identified by a 16-byte master_key_identifier,
which is derived from the key itself using HKDF-SHA512. This prevents
users from associating the wrong key with an encrypted file or
directory. This was easily possible with v1 policies, which
identified the key by an arbitrary 8-byte master_key_descriptor.
- The key must be provided in the filesystem-level keyring, not in a
process-subscribed keyring.
The following UAPI additions are made:
- The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
- A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
getting the v1 or v2 encryption policy of an encrypted file or
directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
be used because it did not have a way for userspace to indicate which
policy structure is expected. The new ioctl includes a size field, so
it is extensible to future fscrypt policy versions.
- The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
encryption policies. Such keys are kept logically separate from keys
for v1 encryption policies, and are identified by 'identifier' rather
than by 'descriptor'. The 'identifier' need not be provided when
adding a key, since the kernel will calculate it anyway.
This patch temporarily keeps adding/removing v2 policy keys behind the
same permission check done for adding/removing v1 policy keys:
capable(CAP_SYS_ADMIN). However, the next patch will carefully take
advantage of the cryptographically secure master_key_identifier to allow
non-root users to add/remove v2 policy keys, thus providing a full
replacement for v1 policies.
(*) Actually, in the API fscrypt_policy::version is 0 while on-disk
fscrypt_context::format is 1. But I believe it makes the most sense
to advance both to '2' to have them be in sync, and to consider the
numbering to start at 1 except for the API quirk.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int fscrypt_derive_dirhash_key(struct fscrypt_info *ci,
|
|
|
|
|
const struct fscrypt_master_key *mk)
|
|
|
|
|
{
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
err = fscrypt_hkdf_expand(&mk->mk_secret.hkdf, HKDF_CONTEXT_DIRHASH_KEY,
|
|
|
|
|
ci->ci_nonce, FS_KEY_DERIVATION_NONCE_SIZE,
|
|
|
|
|
(u8 *)&ci->ci_dirhash_key,
|
|
|
|
|
sizeof(ci->ci_dirhash_key));
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
ci->ci_dirhash_key_initialized = true;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
BACKPORT: FROMLIST: fscrypt: add support for IV_INO_LBLK_32 policies
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 <ebiggers@google.com>
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 <ebiggers@google.com>
Git-commit: a52238353e6711ae8ef8f3b462cece3b05aead8f
Git-repo: https://android.googlesource.com/kernel/common/+/refs/heads/android-4.14-stable
[neersoni@codeaurora.org: back port the changes and fixed merge
conflicts in fscrypt_privat.h and inline_crypt.c files]
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
5 years ago
|
|
|
static int fscrypt_setup_iv_ino_lblk_32_key(struct fscrypt_info *ci,
|
|
|
|
|
struct fscrypt_master_key *mk)
|
|
|
|
|
{
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
err = setup_per_mode_enc_key(ci, mk, mk->mk_iv_ino_lblk_32_keys,
|
|
|
|
|
HKDF_CONTEXT_IV_INO_LBLK_32_KEY, true);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
|
|
/* pairs with smp_store_release() below */
|
|
|
|
|
if (!smp_load_acquire(&mk->mk_ino_hash_key_initialized)) {
|
|
|
|
|
|
|
|
|
|
mutex_lock(&fscrypt_mode_key_setup_mutex);
|
|
|
|
|
|
|
|
|
|
if (mk->mk_ino_hash_key_initialized)
|
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
|
|
err = fscrypt_hkdf_expand(&mk->mk_secret.hkdf,
|
|
|
|
|
HKDF_CONTEXT_INODE_HASH_KEY, NULL, 0,
|
|
|
|
|
(u8 *)&mk->mk_ino_hash_key,
|
|
|
|
|
sizeof(mk->mk_ino_hash_key));
|
|
|
|
|
if (err)
|
|
|
|
|
goto unlock;
|
|
|
|
|
/* pairs with smp_load_acquire() above */
|
|
|
|
|
smp_store_release(&mk->mk_ino_hash_key_initialized, true);
|
|
|
|
|
unlock:
|
|
|
|
|
mutex_unlock(&fscrypt_mode_key_setup_mutex);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ci->ci_hashed_ino = (u32)siphash_1u64(ci->ci_inode->i_ino,
|
|
|
|
|
&mk->mk_ino_hash_key);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
fscrypt: v2 encryption policy support
Add a new fscrypt policy version, "v2". It has the following changes
from the original policy version, which we call "v1" (*):
- Master keys (the user-provided encryption keys) are only ever used as
input to HKDF-SHA512. This is more flexible and less error-prone, and
it avoids the quirks and limitations of the AES-128-ECB based KDF.
Three classes of cryptographically isolated subkeys are defined:
- Per-file keys, like used in v1 policies except for the new KDF.
- Per-mode keys. These implement the semantics of the DIRECT_KEY
flag, which for v1 policies made the master key be used directly.
These are also planned to be used for inline encryption when
support for it is added.
- Key identifiers (see below).
- Each master key is identified by a 16-byte master_key_identifier,
which is derived from the key itself using HKDF-SHA512. This prevents
users from associating the wrong key with an encrypted file or
directory. This was easily possible with v1 policies, which
identified the key by an arbitrary 8-byte master_key_descriptor.
- The key must be provided in the filesystem-level keyring, not in a
process-subscribed keyring.
The following UAPI additions are made:
- The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
- A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
getting the v1 or v2 encryption policy of an encrypted file or
directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
be used because it did not have a way for userspace to indicate which
policy structure is expected. The new ioctl includes a size field, so
it is extensible to future fscrypt policy versions.
- The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
encryption policies. Such keys are kept logically separate from keys
for v1 encryption policies, and are identified by 'identifier' rather
than by 'descriptor'. The 'identifier' need not be provided when
adding a key, since the kernel will calculate it anyway.
This patch temporarily keeps adding/removing v2 policy keys behind the
same permission check done for adding/removing v1 policy keys:
capable(CAP_SYS_ADMIN). However, the next patch will carefully take
advantage of the cryptographically secure master_key_identifier to allow
non-root users to add/remove v2 policy keys, thus providing a full
replacement for v1 policies.
(*) Actually, in the API fscrypt_policy::version is 0 while on-disk
fscrypt_context::format is 1. But I believe it makes the most sense
to advance both to '2' to have them be in sync, and to consider the
numbering to start at 1 except for the API quirk.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
static int fscrypt_setup_v2_file_key(struct fscrypt_info *ci,
|
|
|
|
|
struct fscrypt_master_key *mk)
|
|
|
|
|
{
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_FSCRYPT_SDP
|
|
|
|
|
if (fscrypt_sdp_is_classified(ci)) {
|
|
|
|
|
u8 derived_key[FSCRYPT_MAX_KEY_SIZE];
|
|
|
|
|
err = derive_fek(ci->ci_inode, ci, derived_key, ci->ci_mode->keysize);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
|
|
err = fscrypt_set_per_file_enc_key(ci, derived_key);
|
|
|
|
|
memzero_explicit(derived_key, ci->ci_mode->keysize);
|
|
|
|
|
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
|
|
fscrypt_sdp_update_conv_status(ci);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
if (mk->mk_secret.is_hw_wrapped &&
|
BACKPORT: FROMLIST: fscrypt: add support for IV_INO_LBLK_32 policies
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 <ebiggers@google.com>
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 <ebiggers@google.com>
Git-commit: a52238353e6711ae8ef8f3b462cece3b05aead8f
Git-repo: https://android.googlesource.com/kernel/common/+/refs/heads/android-4.14-stable
[neersoni@codeaurora.org: back port the changes and fixed merge
conflicts in fscrypt_privat.h and inline_crypt.c files]
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
5 years ago
|
|
|
!(ci->ci_policy.v2.flags & (FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64 |
|
|
|
|
|
FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32))) {
|
|
|
|
|
fscrypt_warn(ci->ci_inode,
|
BACKPORT: FROMLIST: fscrypt: add support for IV_INO_LBLK_32 policies
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 <ebiggers@google.com>
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 <ebiggers@google.com>
Git-commit: a52238353e6711ae8ef8f3b462cece3b05aead8f
Git-repo: https://android.googlesource.com/kernel/common/+/refs/heads/android-4.14-stable
[neersoni@codeaurora.org: back port the changes and fixed merge
conflicts in fscrypt_privat.h and inline_crypt.c files]
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
5 years ago
|
|
|
"Hardware-wrapped keys are only supported with IV_INO_LBLK policies");
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
fscrypt: v2 encryption policy support
Add a new fscrypt policy version, "v2". It has the following changes
from the original policy version, which we call "v1" (*):
- Master keys (the user-provided encryption keys) are only ever used as
input to HKDF-SHA512. This is more flexible and less error-prone, and
it avoids the quirks and limitations of the AES-128-ECB based KDF.
Three classes of cryptographically isolated subkeys are defined:
- Per-file keys, like used in v1 policies except for the new KDF.
- Per-mode keys. These implement the semantics of the DIRECT_KEY
flag, which for v1 policies made the master key be used directly.
These are also planned to be used for inline encryption when
support for it is added.
- Key identifiers (see below).
- Each master key is identified by a 16-byte master_key_identifier,
which is derived from the key itself using HKDF-SHA512. This prevents
users from associating the wrong key with an encrypted file or
directory. This was easily possible with v1 policies, which
identified the key by an arbitrary 8-byte master_key_descriptor.
- The key must be provided in the filesystem-level keyring, not in a
process-subscribed keyring.
The following UAPI additions are made:
- The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
- A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
getting the v1 or v2 encryption policy of an encrypted file or
directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
be used because it did not have a way for userspace to indicate which
policy structure is expected. The new ioctl includes a size field, so
it is extensible to future fscrypt policy versions.
- The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
encryption policies. Such keys are kept logically separate from keys
for v1 encryption policies, and are identified by 'identifier' rather
than by 'descriptor'. The 'identifier' need not be provided when
adding a key, since the kernel will calculate it anyway.
This patch temporarily keeps adding/removing v2 policy keys behind the
same permission check done for adding/removing v1 policy keys:
capable(CAP_SYS_ADMIN). However, the next patch will carefully take
advantage of the cryptographically secure master_key_identifier to allow
non-root users to add/remove v2 policy keys, thus providing a full
replacement for v1 policies.
(*) Actually, in the API fscrypt_policy::version is 0 while on-disk
fscrypt_context::format is 1. But I believe it makes the most sense
to advance both to '2' to have them be in sync, and to consider the
numbering to start at 1 except for the API quirk.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
if (ci->ci_policy.v2.flags & FSCRYPT_POLICY_FLAG_DIRECT_KEY) {
|
|
|
|
|
/*
|
|
|
|
|
* DIRECT_KEY: instead of deriving per-file encryption keys, the
|
|
|
|
|
* per-file nonce will be included in all the IVs. But unlike
|
|
|
|
|
* v1 policies, for v2 policies in this case we don't encrypt
|
|
|
|
|
* with the master key directly but rather derive a per-mode
|
|
|
|
|
* encryption key. This ensures that the master key is
|
|
|
|
|
* consistently used only for HKDF, avoiding key reuse issues.
|
fscrypt: v2 encryption policy support
Add a new fscrypt policy version, "v2". It has the following changes
from the original policy version, which we call "v1" (*):
- Master keys (the user-provided encryption keys) are only ever used as
input to HKDF-SHA512. This is more flexible and less error-prone, and
it avoids the quirks and limitations of the AES-128-ECB based KDF.
Three classes of cryptographically isolated subkeys are defined:
- Per-file keys, like used in v1 policies except for the new KDF.
- Per-mode keys. These implement the semantics of the DIRECT_KEY
flag, which for v1 policies made the master key be used directly.
These are also planned to be used for inline encryption when
support for it is added.
- Key identifiers (see below).
- Each master key is identified by a 16-byte master_key_identifier,
which is derived from the key itself using HKDF-SHA512. This prevents
users from associating the wrong key with an encrypted file or
directory. This was easily possible with v1 policies, which
identified the key by an arbitrary 8-byte master_key_descriptor.
- The key must be provided in the filesystem-level keyring, not in a
process-subscribed keyring.
The following UAPI additions are made:
- The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
- A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
getting the v1 or v2 encryption policy of an encrypted file or
directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
be used because it did not have a way for userspace to indicate which
policy structure is expected. The new ioctl includes a size field, so
it is extensible to future fscrypt policy versions.
- The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
encryption policies. Such keys are kept logically separate from keys
for v1 encryption policies, and are identified by 'identifier' rather
than by 'descriptor'. The 'identifier' need not be provided when
adding a key, since the kernel will calculate it anyway.
This patch temporarily keeps adding/removing v2 policy keys behind the
same permission check done for adding/removing v1 policy keys:
capable(CAP_SYS_ADMIN). However, the next patch will carefully take
advantage of the cryptographically secure master_key_identifier to allow
non-root users to add/remove v2 policy keys, thus providing a full
replacement for v1 policies.
(*) Actually, in the API fscrypt_policy::version is 0 while on-disk
fscrypt_context::format is 1. But I believe it makes the most sense
to advance both to '2' to have them be in sync, and to consider the
numbering to start at 1 except for the API quirk.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
*/
|
|
|
|
|
err = setup_per_mode_enc_key(ci, mk, mk->mk_direct_keys,
|
|
|
|
|
HKDF_CONTEXT_DIRECT_KEY, false);
|
fscrypt: add support for IV_INO_LBLK_64 policies
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: Paul Crowley <paulcrowley@google.com>
Co-developed-by: Satya Tangirala <satyat@google.com>
Signed-off-by: Satya Tangirala <satyat@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
} else if (ci->ci_policy.v2.flags &
|
|
|
|
|
FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64) {
|
|
|
|
|
/*
|
|
|
|
|
* IV_INO_LBLK_64: encryption keys are derived from (master_key,
|
|
|
|
|
* mode_num, filesystem_uuid), and inode number is included in
|
|
|
|
|
* the IVs. This format is optimized for use with inline
|
BACKPORT: FROMLIST: fscrypt: add support for IV_INO_LBLK_32 policies
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 <ebiggers@google.com>
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 <ebiggers@google.com>
Git-commit: a52238353e6711ae8ef8f3b462cece3b05aead8f
Git-repo: https://android.googlesource.com/kernel/common/+/refs/heads/android-4.14-stable
[neersoni@codeaurora.org: back port the changes and fixed merge
conflicts in fscrypt_privat.h and inline_crypt.c files]
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
5 years ago
|
|
|
* encryption hardware compliant with the UFS standard.
|
fscrypt: add support for IV_INO_LBLK_64 policies
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: Paul Crowley <paulcrowley@google.com>
Co-developed-by: Satya Tangirala <satyat@google.com>
Signed-off-by: Satya Tangirala <satyat@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
*/
|
|
|
|
|
err = setup_per_mode_enc_key(ci, mk, mk->mk_iv_ino_lblk_64_keys,
|
|
|
|
|
HKDF_CONTEXT_IV_INO_LBLK_64_KEY,
|
|
|
|
|
true);
|
BACKPORT: FROMLIST: fscrypt: add support for IV_INO_LBLK_32 policies
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 <ebiggers@google.com>
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 <ebiggers@google.com>
Git-commit: a52238353e6711ae8ef8f3b462cece3b05aead8f
Git-repo: https://android.googlesource.com/kernel/common/+/refs/heads/android-4.14-stable
[neersoni@codeaurora.org: back port the changes and fixed merge
conflicts in fscrypt_privat.h and inline_crypt.c files]
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
5 years ago
|
|
|
} else if (ci->ci_policy.v2.flags &
|
|
|
|
|
FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32) {
|
|
|
|
|
err = fscrypt_setup_iv_ino_lblk_32_key(ci, mk);
|
|
|
|
|
} else {
|
|
|
|
|
u8 derived_key[FSCRYPT_MAX_KEY_SIZE];
|
fscrypt: v2 encryption policy support
Add a new fscrypt policy version, "v2". It has the following changes
from the original policy version, which we call "v1" (*):
- Master keys (the user-provided encryption keys) are only ever used as
input to HKDF-SHA512. This is more flexible and less error-prone, and
it avoids the quirks and limitations of the AES-128-ECB based KDF.
Three classes of cryptographically isolated subkeys are defined:
- Per-file keys, like used in v1 policies except for the new KDF.
- Per-mode keys. These implement the semantics of the DIRECT_KEY
flag, which for v1 policies made the master key be used directly.
These are also planned to be used for inline encryption when
support for it is added.
- Key identifiers (see below).
- Each master key is identified by a 16-byte master_key_identifier,
which is derived from the key itself using HKDF-SHA512. This prevents
users from associating the wrong key with an encrypted file or
directory. This was easily possible with v1 policies, which
identified the key by an arbitrary 8-byte master_key_descriptor.
- The key must be provided in the filesystem-level keyring, not in a
process-subscribed keyring.
The following UAPI additions are made:
- The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
- A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
getting the v1 or v2 encryption policy of an encrypted file or
directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
be used because it did not have a way for userspace to indicate which
policy structure is expected. The new ioctl includes a size field, so
it is extensible to future fscrypt policy versions.
- The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
encryption policies. Such keys are kept logically separate from keys
for v1 encryption policies, and are identified by 'identifier' rather
than by 'descriptor'. The 'identifier' need not be provided when
adding a key, since the kernel will calculate it anyway.
This patch temporarily keeps adding/removing v2 policy keys behind the
same permission check done for adding/removing v1 policy keys:
capable(CAP_SYS_ADMIN). However, the next patch will carefully take
advantage of the cryptographically secure master_key_identifier to allow
non-root users to add/remove v2 policy keys, thus providing a full
replacement for v1 policies.
(*) Actually, in the API fscrypt_policy::version is 0 while on-disk
fscrypt_context::format is 1. But I believe it makes the most sense
to advance both to '2' to have them be in sync, and to consider the
numbering to start at 1 except for the API quirk.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
|
|
|
|
|
err = fscrypt_hkdf_expand(&mk->mk_secret.hkdf,
|
|
|
|
|
HKDF_CONTEXT_PER_FILE_ENC_KEY,
|
|
|
|
|
ci->ci_nonce,
|
|
|
|
|
FS_KEY_DERIVATION_NONCE_SIZE,
|
|
|
|
|
derived_key, ci->ci_mode->keysize);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
|
|
err = fscrypt_set_per_file_enc_key(ci, derived_key);
|
|
|
|
|
memzero_explicit(derived_key, ci->ci_mode->keysize);
|
|
|
|
|
}
|
fscrypt: v2 encryption policy support
Add a new fscrypt policy version, "v2". It has the following changes
from the original policy version, which we call "v1" (*):
- Master keys (the user-provided encryption keys) are only ever used as
input to HKDF-SHA512. This is more flexible and less error-prone, and
it avoids the quirks and limitations of the AES-128-ECB based KDF.
Three classes of cryptographically isolated subkeys are defined:
- Per-file keys, like used in v1 policies except for the new KDF.
- Per-mode keys. These implement the semantics of the DIRECT_KEY
flag, which for v1 policies made the master key be used directly.
These are also planned to be used for inline encryption when
support for it is added.
- Key identifiers (see below).
- Each master key is identified by a 16-byte master_key_identifier,
which is derived from the key itself using HKDF-SHA512. This prevents
users from associating the wrong key with an encrypted file or
directory. This was easily possible with v1 policies, which
identified the key by an arbitrary 8-byte master_key_descriptor.
- The key must be provided in the filesystem-level keyring, not in a
process-subscribed keyring.
The following UAPI additions are made:
- The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
- A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
getting the v1 or v2 encryption policy of an encrypted file or
directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
be used because it did not have a way for userspace to indicate which
policy structure is expected. The new ioctl includes a size field, so
it is extensible to future fscrypt policy versions.
- The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
encryption policies. Such keys are kept logically separate from keys
for v1 encryption policies, and are identified by 'identifier' rather
than by 'descriptor'. The 'identifier' need not be provided when
adding a key, since the kernel will calculate it anyway.
This patch temporarily keeps adding/removing v2 policy keys behind the
same permission check done for adding/removing v1 policy keys:
capable(CAP_SYS_ADMIN). However, the next patch will carefully take
advantage of the cryptographically secure master_key_identifier to allow
non-root users to add/remove v2 policy keys, thus providing a full
replacement for v1 policies.
(*) Actually, in the API fscrypt_policy::version is 0 while on-disk
fscrypt_context::format is 1. But I believe it makes the most sense
to advance both to '2' to have them be in sync, and to consider the
numbering to start at 1 except for the API quirk.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
|
|
/* Derive a secret dirhash key for directories that need it. */
|
|
|
|
|
if (S_ISDIR(ci->ci_inode->i_mode) && IS_CASEFOLDED(ci->ci_inode)) {
|
|
|
|
|
err = fscrypt_derive_dirhash_key(ci, mk);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
fscrypt: v2 encryption policy support
Add a new fscrypt policy version, "v2". It has the following changes
from the original policy version, which we call "v1" (*):
- Master keys (the user-provided encryption keys) are only ever used as
input to HKDF-SHA512. This is more flexible and less error-prone, and
it avoids the quirks and limitations of the AES-128-ECB based KDF.
Three classes of cryptographically isolated subkeys are defined:
- Per-file keys, like used in v1 policies except for the new KDF.
- Per-mode keys. These implement the semantics of the DIRECT_KEY
flag, which for v1 policies made the master key be used directly.
These are also planned to be used for inline encryption when
support for it is added.
- Key identifiers (see below).
- Each master key is identified by a 16-byte master_key_identifier,
which is derived from the key itself using HKDF-SHA512. This prevents
users from associating the wrong key with an encrypted file or
directory. This was easily possible with v1 policies, which
identified the key by an arbitrary 8-byte master_key_descriptor.
- The key must be provided in the filesystem-level keyring, not in a
process-subscribed keyring.
The following UAPI additions are made:
- The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
- A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
getting the v1 or v2 encryption policy of an encrypted file or
directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
be used because it did not have a way for userspace to indicate which
policy structure is expected. The new ioctl includes a size field, so
it is extensible to future fscrypt policy versions.
- The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
encryption policies. Such keys are kept logically separate from keys
for v1 encryption policies, and are identified by 'identifier' rather
than by 'descriptor'. The 'identifier' need not be provided when
adding a key, since the kernel will calculate it anyway.
This patch temporarily keeps adding/removing v2 policy keys behind the
same permission check done for adding/removing v1 policy keys:
capable(CAP_SYS_ADMIN). However, the next patch will carefully take
advantage of the cryptographically secure master_key_identifier to allow
non-root users to add/remove v2 policy keys, thus providing a full
replacement for v1 policies.
(*) Actually, in the API fscrypt_policy::version is 0 while on-disk
fscrypt_context::format is 1. But I believe it makes the most sense
to advance both to '2' to have them be in sync, and to consider the
numbering to start at 1 except for the API quirk.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Find the master key, then set up the inode's actual encryption key.
|
fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl
Add a new fscrypt ioctl, FS_IOC_REMOVE_ENCRYPTION_KEY. This ioctl
removes an encryption key that was added by FS_IOC_ADD_ENCRYPTION_KEY.
It wipes the secret key itself, then "locks" the encrypted files and
directories that had been unlocked using that key -- implemented by
evicting the relevant dentries and inodes from the VFS caches.
The problem this solves is that many fscrypt users want the ability to
remove encryption keys, causing the corresponding encrypted directories
to appear "locked" (presented in ciphertext form) again. Moreover,
users want removing an encryption key to *really* remove it, in the
sense that the removed keys cannot be recovered even if kernel memory is
compromised, e.g. by the exploit of a kernel security vulnerability or
by a physical attack. This is desirable after a user logs out of the
system, for example. In many cases users even already assume this to be
the case and are surprised to hear when it's not.
It is not sufficient to simply unlink the master key from the keyring
(or to revoke or invalidate it), since the actual encryption transform
objects are still pinned in memory by their inodes. Therefore, to
really remove a key we must also evict the relevant inodes.
Currently one workaround is to run 'sync && echo 2 >
/proc/sys/vm/drop_caches'. But, that evicts all unused inodes in the
system rather than just the inodes associated with the key being
removed, causing severe performance problems. Moreover, it requires
root privileges, so regular users can't "lock" their encrypted files.
Another workaround, used in Chromium OS kernels, is to add a new
VFS-level ioctl FS_IOC_DROP_CACHE which is a more restricted version of
drop_caches that operates on a single super_block. It does:
shrink_dcache_sb(sb);
invalidate_inodes(sb, false);
But it's still a hack. Yet, the major users of filesystem encryption
want this feature badly enough that they are actually using these hacks.
To properly solve the problem, start maintaining a list of the inodes
which have been "unlocked" using each master key. Originally this
wasn't possible because the kernel didn't keep track of in-use master
keys at all. But, with the ->s_master_keys keyring it is now possible.
Then, add an ioctl FS_IOC_REMOVE_ENCRYPTION_KEY. It finds the specified
master key in ->s_master_keys, then wipes the secret key itself, which
prevents any additional inodes from being unlocked with the key. Then,
it syncs the filesystem and evicts the inodes in the key's list. The
normal inode eviction code will free and wipe the per-file keys (in
->i_crypt_info). Note that freeing ->i_crypt_info without evicting the
inodes was also considered, but would have been racy.
Some inodes may still be in use when a master key is removed, and we
can't simply revoke random file descriptors, mmap's, etc. Thus, the
ioctl simply skips in-use inodes, and returns -EBUSY to indicate that
some inodes weren't evicted. The master key *secret* is still removed,
but the fscrypt_master_key struct remains to keep track of the remaining
inodes. Userspace can then retry the ioctl to evict the remaining
inodes. Alternatively, if userspace adds the key again, the refreshed
secret will be associated with the existing list of inodes so they
remain correctly tracked for future key removals.
The ioctl doesn't wipe pagecache pages. Thus, we tolerate that after a
kernel compromise some portions of plaintext file contents may still be
recoverable from memory. This can be solved by enabling page poisoning
system-wide, which security conscious users may choose to do. But it's
very difficult to solve otherwise, e.g. note that plaintext file
contents may have been read in other places than pagecache pages.
Like FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY is
initially restricted to privileged users only. This is sufficient for
some use cases, but not all. A later patch will relax this restriction,
but it will require introducing key hashes, among other changes.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
*
|
|
|
|
|
* If the master key is found in the filesystem-level keyring, then the
|
|
|
|
|
* corresponding 'struct key' is returned in *master_key_ret with
|
fscrypt: allow unprivileged users to add/remove keys for v2 policies
Allow the FS_IOC_ADD_ENCRYPTION_KEY and FS_IOC_REMOVE_ENCRYPTION_KEY
ioctls to be used by non-root users to add and remove encryption keys
from the filesystem-level crypto keyrings, subject to limitations.
Motivation: while privileged fscrypt key management is sufficient for
some users (e.g. Android and Chromium OS, where a privileged process
manages all keys), the old API by design also allows non-root users to
set up and use encrypted directories, and we don't want to regress on
that. Especially, we don't want to force users to continue using the
old API, running into the visibility mismatch between files and keyrings
and being unable to "lock" encrypted directories.
Intuitively, the ioctls have to be privileged since they manipulate
filesystem-level state. However, it's actually safe to make them
unprivileged if we very carefully enforce some specific limitations.
First, each key must be identified by a cryptographic hash so that a
user can't add the wrong key for another user's files. For v2
encryption policies, we use the key_identifier for this. v1 policies
don't have this, so managing keys for them remains privileged.
Second, each key a user adds is charged to their quota for the keyrings
service. Thus, a user can't exhaust memory by adding a huge number of
keys. By default each non-root user is allowed up to 200 keys; this can
be changed using the existing sysctl 'kernel.keys.maxkeys'.
Third, if multiple users add the same key, we keep track of those users
of the key (of which there remains a single copy), and won't really
remove the key, i.e. "lock" the encrypted files, until all those users
have removed it. This prevents denial of service attacks that would be
possible under simpler schemes, such allowing the first user who added a
key to remove it -- since that could be a malicious user who has
compromised the key. Of course, encryption keys should be kept secret,
but the idea is that using encryption should never be *less* secure than
not using encryption, even if your key was compromised.
We tolerate that a user will be unable to really remove a key, i.e.
unable to "lock" their encrypted files, if another user has added the
same key. But in a sense, this is actually a good thing because it will
avoid providing a false notion of security where a key appears to have
been removed when actually it's still in memory, available to any
attacker who compromises the operating system kernel.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
* ->mk_secret_sem read-locked. This is needed to ensure that only one task
|
|
|
|
|
* links the fscrypt_info into ->mk_decrypted_inodes (as multiple tasks may race
|
|
|
|
|
* to create an fscrypt_info for the same inode), and to synchronize the master
|
|
|
|
|
* key being removed with a new inode starting to use it.
|
|
|
|
|
*/
|
fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl
Add a new fscrypt ioctl, FS_IOC_REMOVE_ENCRYPTION_KEY. This ioctl
removes an encryption key that was added by FS_IOC_ADD_ENCRYPTION_KEY.
It wipes the secret key itself, then "locks" the encrypted files and
directories that had been unlocked using that key -- implemented by
evicting the relevant dentries and inodes from the VFS caches.
The problem this solves is that many fscrypt users want the ability to
remove encryption keys, causing the corresponding encrypted directories
to appear "locked" (presented in ciphertext form) again. Moreover,
users want removing an encryption key to *really* remove it, in the
sense that the removed keys cannot be recovered even if kernel memory is
compromised, e.g. by the exploit of a kernel security vulnerability or
by a physical attack. This is desirable after a user logs out of the
system, for example. In many cases users even already assume this to be
the case and are surprised to hear when it's not.
It is not sufficient to simply unlink the master key from the keyring
(or to revoke or invalidate it), since the actual encryption transform
objects are still pinned in memory by their inodes. Therefore, to
really remove a key we must also evict the relevant inodes.
Currently one workaround is to run 'sync && echo 2 >
/proc/sys/vm/drop_caches'. But, that evicts all unused inodes in the
system rather than just the inodes associated with the key being
removed, causing severe performance problems. Moreover, it requires
root privileges, so regular users can't "lock" their encrypted files.
Another workaround, used in Chromium OS kernels, is to add a new
VFS-level ioctl FS_IOC_DROP_CACHE which is a more restricted version of
drop_caches that operates on a single super_block. It does:
shrink_dcache_sb(sb);
invalidate_inodes(sb, false);
But it's still a hack. Yet, the major users of filesystem encryption
want this feature badly enough that they are actually using these hacks.
To properly solve the problem, start maintaining a list of the inodes
which have been "unlocked" using each master key. Originally this
wasn't possible because the kernel didn't keep track of in-use master
keys at all. But, with the ->s_master_keys keyring it is now possible.
Then, add an ioctl FS_IOC_REMOVE_ENCRYPTION_KEY. It finds the specified
master key in ->s_master_keys, then wipes the secret key itself, which
prevents any additional inodes from being unlocked with the key. Then,
it syncs the filesystem and evicts the inodes in the key's list. The
normal inode eviction code will free and wipe the per-file keys (in
->i_crypt_info). Note that freeing ->i_crypt_info without evicting the
inodes was also considered, but would have been racy.
Some inodes may still be in use when a master key is removed, and we
can't simply revoke random file descriptors, mmap's, etc. Thus, the
ioctl simply skips in-use inodes, and returns -EBUSY to indicate that
some inodes weren't evicted. The master key *secret* is still removed,
but the fscrypt_master_key struct remains to keep track of the remaining
inodes. Userspace can then retry the ioctl to evict the remaining
inodes. Alternatively, if userspace adds the key again, the refreshed
secret will be associated with the existing list of inodes so they
remain correctly tracked for future key removals.
The ioctl doesn't wipe pagecache pages. Thus, we tolerate that after a
kernel compromise some portions of plaintext file contents may still be
recoverable from memory. This can be solved by enabling page poisoning
system-wide, which security conscious users may choose to do. But it's
very difficult to solve otherwise, e.g. note that plaintext file
contents may have been read in other places than pagecache pages.
Like FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY is
initially restricted to privileged users only. This is sufficient for
some use cases, but not all. A later patch will relax this restriction,
but it will require introducing key hashes, among other changes.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
static int setup_file_encryption_key(struct fscrypt_info *ci,
|
|
|
|
|
struct key **master_key_ret)
|
|
|
|
|
{
|
fscrypt: add FS_IOC_ADD_ENCRYPTION_KEY ioctl
Add a new fscrypt ioctl, FS_IOC_ADD_ENCRYPTION_KEY. This ioctl adds an
encryption key to the filesystem's fscrypt keyring ->s_master_keys,
making any files encrypted with that key appear "unlocked".
Why we need this
~~~~~~~~~~~~~~~~
The main problem is that the "locked/unlocked" (ciphertext/plaintext)
status of encrypted files is global, but the fscrypt keys are not.
fscrypt only looks for keys in the keyring(s) the process accessing the
filesystem is subscribed to: the thread keyring, process keyring, and
session keyring, where the session keyring may contain the user keyring.
Therefore, userspace has to put fscrypt keys in the keyrings for
individual users or sessions. But this means that when a process with a
different keyring tries to access encrypted files, whether they appear
"unlocked" or not is nondeterministic. This is because it depends on
whether the files are currently present in the inode cache.
Fixing this by consistently providing each process its own view of the
filesystem depending on whether it has the key or not isn't feasible due
to how the VFS caches work. Furthermore, while sometimes users expect
this behavior, it is misguided for two reasons. First, it would be an
OS-level access control mechanism largely redundant with existing access
control mechanisms such as UNIX file permissions, ACLs, LSMs, etc.
Encryption is actually for protecting the data at rest.
Second, almost all users of fscrypt actually do need the keys to be
global. The largest users of fscrypt, Android and Chromium OS, achieve
this by having PID 1 create a "session keyring" that is inherited by
every process. This works, but it isn't scalable because it prevents
session keyrings from being used for any other purpose.
On general-purpose Linux distros, the 'fscrypt' userspace tool [1] can't
similarly abuse the session keyring, so to make 'sudo' work on all
systems it has to link all the user keyrings into root's user keyring
[2]. This is ugly and raises security concerns. Moreover it can't make
the keys available to system services, such as sshd trying to access the
user's '~/.ssh' directory (see [3], [4]) or NetworkManager trying to
read certificates from the user's home directory (see [5]); or to Docker
containers (see [6], [7]).
By having an API to add a key to the *filesystem* we'll be able to fix
the above bugs, remove userspace workarounds, and clearly express the
intended semantics: the locked/unlocked status of an encrypted directory
is global, and encryption is orthogonal to OS-level access control.
Why not use the add_key() syscall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We use an ioctl for this API rather than the existing add_key() system
call because the ioctl gives us the flexibility needed to implement
fscrypt-specific semantics that will be introduced in later patches:
- Supporting key removal with the semantics such that the secret is
removed immediately and any unused inodes using the key are evicted;
also, the eviction of any in-use inodes can be retried.
- Calculating a key-dependent cryptographic identifier and returning it
to userspace.
- Allowing keys to be added and removed by non-root users, but only keys
for v2 encryption policies; and to prevent denial-of-service attacks,
users can only remove keys they themselves have added, and a key is
only really removed after all users who added it have removed it.
Trying to shoehorn these semantics into the keyrings syscalls would be
very difficult, whereas the ioctls make things much easier.
However, to reuse code the implementation still uses the keyrings
service internally. Thus we get lockless RCU-mode key lookups without
having to re-implement it, and the keys automatically show up in
/proc/keys for debugging purposes.
References:
[1] https://github.com/google/fscrypt
[2] https://goo.gl/55cCrI#heading=h.vf09isp98isb
[3] https://github.com/google/fscrypt/issues/111#issuecomment-444347939
[4] https://github.com/google/fscrypt/issues/116
[5] https://bugs.launchpad.net/ubuntu/+source/fscrypt/+bug/1770715
[6] https://github.com/google/fscrypt/issues/128
[7] https://askubuntu.com/questions/1130306/cannot-run-docker-on-an-encrypted-filesystem
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
struct key *key;
|
|
|
|
|
struct fscrypt_master_key *mk = NULL;
|
|
|
|
|
struct fscrypt_key_specifier mk_spec;
|
|
|
|
|
int err;
|
|
|
|
|
|
fscrypt: v2 encryption policy support
Add a new fscrypt policy version, "v2". It has the following changes
from the original policy version, which we call "v1" (*):
- Master keys (the user-provided encryption keys) are only ever used as
input to HKDF-SHA512. This is more flexible and less error-prone, and
it avoids the quirks and limitations of the AES-128-ECB based KDF.
Three classes of cryptographically isolated subkeys are defined:
- Per-file keys, like used in v1 policies except for the new KDF.
- Per-mode keys. These implement the semantics of the DIRECT_KEY
flag, which for v1 policies made the master key be used directly.
These are also planned to be used for inline encryption when
support for it is added.
- Key identifiers (see below).
- Each master key is identified by a 16-byte master_key_identifier,
which is derived from the key itself using HKDF-SHA512. This prevents
users from associating the wrong key with an encrypted file or
directory. This was easily possible with v1 policies, which
identified the key by an arbitrary 8-byte master_key_descriptor.
- The key must be provided in the filesystem-level keyring, not in a
process-subscribed keyring.
The following UAPI additions are made:
- The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
- A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
getting the v1 or v2 encryption policy of an encrypted file or
directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
be used because it did not have a way for userspace to indicate which
policy structure is expected. The new ioctl includes a size field, so
it is extensible to future fscrypt policy versions.
- The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
encryption policies. Such keys are kept logically separate from keys
for v1 encryption policies, and are identified by 'identifier' rather
than by 'descriptor'. The 'identifier' need not be provided when
adding a key, since the kernel will calculate it anyway.
This patch temporarily keeps adding/removing v2 policy keys behind the
same permission check done for adding/removing v1 policy keys:
capable(CAP_SYS_ADMIN). However, the next patch will carefully take
advantage of the cryptographically secure master_key_identifier to allow
non-root users to add/remove v2 policy keys, thus providing a full
replacement for v1 policies.
(*) Actually, in the API fscrypt_policy::version is 0 while on-disk
fscrypt_context::format is 1. But I believe it makes the most sense
to advance both to '2' to have them be in sync, and to consider the
numbering to start at 1 except for the API quirk.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
switch (ci->ci_policy.version) {
|
|
|
|
|
case FSCRYPT_POLICY_V1:
|
|
|
|
|
mk_spec.type = FSCRYPT_KEY_SPEC_TYPE_DESCRIPTOR;
|
|
|
|
|
memcpy(mk_spec.u.descriptor,
|
|
|
|
|
ci->ci_policy.v1.master_key_descriptor,
|
|
|
|
|
FSCRYPT_KEY_DESCRIPTOR_SIZE);
|
|
|
|
|
break;
|
|
|
|
|
case FSCRYPT_POLICY_V2:
|
|
|
|
|
mk_spec.type = FSCRYPT_KEY_SPEC_TYPE_IDENTIFIER;
|
|
|
|
|
memcpy(mk_spec.u.identifier,
|
|
|
|
|
ci->ci_policy.v2.master_key_identifier,
|
|
|
|
|
FSCRYPT_KEY_IDENTIFIER_SIZE);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
WARN_ON(1);
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
fscrypt: add FS_IOC_ADD_ENCRYPTION_KEY ioctl
Add a new fscrypt ioctl, FS_IOC_ADD_ENCRYPTION_KEY. This ioctl adds an
encryption key to the filesystem's fscrypt keyring ->s_master_keys,
making any files encrypted with that key appear "unlocked".
Why we need this
~~~~~~~~~~~~~~~~
The main problem is that the "locked/unlocked" (ciphertext/plaintext)
status of encrypted files is global, but the fscrypt keys are not.
fscrypt only looks for keys in the keyring(s) the process accessing the
filesystem is subscribed to: the thread keyring, process keyring, and
session keyring, where the session keyring may contain the user keyring.
Therefore, userspace has to put fscrypt keys in the keyrings for
individual users or sessions. But this means that when a process with a
different keyring tries to access encrypted files, whether they appear
"unlocked" or not is nondeterministic. This is because it depends on
whether the files are currently present in the inode cache.
Fixing this by consistently providing each process its own view of the
filesystem depending on whether it has the key or not isn't feasible due
to how the VFS caches work. Furthermore, while sometimes users expect
this behavior, it is misguided for two reasons. First, it would be an
OS-level access control mechanism largely redundant with existing access
control mechanisms such as UNIX file permissions, ACLs, LSMs, etc.
Encryption is actually for protecting the data at rest.
Second, almost all users of fscrypt actually do need the keys to be
global. The largest users of fscrypt, Android and Chromium OS, achieve
this by having PID 1 create a "session keyring" that is inherited by
every process. This works, but it isn't scalable because it prevents
session keyrings from being used for any other purpose.
On general-purpose Linux distros, the 'fscrypt' userspace tool [1] can't
similarly abuse the session keyring, so to make 'sudo' work on all
systems it has to link all the user keyrings into root's user keyring
[2]. This is ugly and raises security concerns. Moreover it can't make
the keys available to system services, such as sshd trying to access the
user's '~/.ssh' directory (see [3], [4]) or NetworkManager trying to
read certificates from the user's home directory (see [5]); or to Docker
containers (see [6], [7]).
By having an API to add a key to the *filesystem* we'll be able to fix
the above bugs, remove userspace workarounds, and clearly express the
intended semantics: the locked/unlocked status of an encrypted directory
is global, and encryption is orthogonal to OS-level access control.
Why not use the add_key() syscall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We use an ioctl for this API rather than the existing add_key() system
call because the ioctl gives us the flexibility needed to implement
fscrypt-specific semantics that will be introduced in later patches:
- Supporting key removal with the semantics such that the secret is
removed immediately and any unused inodes using the key are evicted;
also, the eviction of any in-use inodes can be retried.
- Calculating a key-dependent cryptographic identifier and returning it
to userspace.
- Allowing keys to be added and removed by non-root users, but only keys
for v2 encryption policies; and to prevent denial-of-service attacks,
users can only remove keys they themselves have added, and a key is
only really removed after all users who added it have removed it.
Trying to shoehorn these semantics into the keyrings syscalls would be
very difficult, whereas the ioctls make things much easier.
However, to reuse code the implementation still uses the keyrings
service internally. Thus we get lockless RCU-mode key lookups without
having to re-implement it, and the keys automatically show up in
/proc/keys for debugging purposes.
References:
[1] https://github.com/google/fscrypt
[2] https://goo.gl/55cCrI#heading=h.vf09isp98isb
[3] https://github.com/google/fscrypt/issues/111#issuecomment-444347939
[4] https://github.com/google/fscrypt/issues/116
[5] https://bugs.launchpad.net/ubuntu/+source/fscrypt/+bug/1770715
[6] https://github.com/google/fscrypt/issues/128
[7] https://askubuntu.com/questions/1130306/cannot-run-docker-on-an-encrypted-filesystem
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
|
|
|
|
|
key = fscrypt_find_master_key(ci->ci_inode->i_sb, &mk_spec);
|
|
|
|
|
if (IS_ERR(key)) {
|
fscrypt: v2 encryption policy support
Add a new fscrypt policy version, "v2". It has the following changes
from the original policy version, which we call "v1" (*):
- Master keys (the user-provided encryption keys) are only ever used as
input to HKDF-SHA512. This is more flexible and less error-prone, and
it avoids the quirks and limitations of the AES-128-ECB based KDF.
Three classes of cryptographically isolated subkeys are defined:
- Per-file keys, like used in v1 policies except for the new KDF.
- Per-mode keys. These implement the semantics of the DIRECT_KEY
flag, which for v1 policies made the master key be used directly.
These are also planned to be used for inline encryption when
support for it is added.
- Key identifiers (see below).
- Each master key is identified by a 16-byte master_key_identifier,
which is derived from the key itself using HKDF-SHA512. This prevents
users from associating the wrong key with an encrypted file or
directory. This was easily possible with v1 policies, which
identified the key by an arbitrary 8-byte master_key_descriptor.
- The key must be provided in the filesystem-level keyring, not in a
process-subscribed keyring.
The following UAPI additions are made:
- The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
- A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
getting the v1 or v2 encryption policy of an encrypted file or
directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
be used because it did not have a way for userspace to indicate which
policy structure is expected. The new ioctl includes a size field, so
it is extensible to future fscrypt policy versions.
- The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
encryption policies. Such keys are kept logically separate from keys
for v1 encryption policies, and are identified by 'identifier' rather
than by 'descriptor'. The 'identifier' need not be provided when
adding a key, since the kernel will calculate it anyway.
This patch temporarily keeps adding/removing v2 policy keys behind the
same permission check done for adding/removing v1 policy keys:
capable(CAP_SYS_ADMIN). However, the next patch will carefully take
advantage of the cryptographically secure master_key_identifier to allow
non-root users to add/remove v2 policy keys, thus providing a full
replacement for v1 policies.
(*) Actually, in the API fscrypt_policy::version is 0 while on-disk
fscrypt_context::format is 1. But I believe it makes the most sense
to advance both to '2' to have them be in sync, and to consider the
numbering to start at 1 except for the API quirk.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
if (key != ERR_PTR(-ENOKEY) ||
|
|
|
|
|
ci->ci_policy.version != FSCRYPT_POLICY_V1)
|
fscrypt: add FS_IOC_ADD_ENCRYPTION_KEY ioctl
Add a new fscrypt ioctl, FS_IOC_ADD_ENCRYPTION_KEY. This ioctl adds an
encryption key to the filesystem's fscrypt keyring ->s_master_keys,
making any files encrypted with that key appear "unlocked".
Why we need this
~~~~~~~~~~~~~~~~
The main problem is that the "locked/unlocked" (ciphertext/plaintext)
status of encrypted files is global, but the fscrypt keys are not.
fscrypt only looks for keys in the keyring(s) the process accessing the
filesystem is subscribed to: the thread keyring, process keyring, and
session keyring, where the session keyring may contain the user keyring.
Therefore, userspace has to put fscrypt keys in the keyrings for
individual users or sessions. But this means that when a process with a
different keyring tries to access encrypted files, whether they appear
"unlocked" or not is nondeterministic. This is because it depends on
whether the files are currently present in the inode cache.
Fixing this by consistently providing each process its own view of the
filesystem depending on whether it has the key or not isn't feasible due
to how the VFS caches work. Furthermore, while sometimes users expect
this behavior, it is misguided for two reasons. First, it would be an
OS-level access control mechanism largely redundant with existing access
control mechanisms such as UNIX file permissions, ACLs, LSMs, etc.
Encryption is actually for protecting the data at rest.
Second, almost all users of fscrypt actually do need the keys to be
global. The largest users of fscrypt, Android and Chromium OS, achieve
this by having PID 1 create a "session keyring" that is inherited by
every process. This works, but it isn't scalable because it prevents
session keyrings from being used for any other purpose.
On general-purpose Linux distros, the 'fscrypt' userspace tool [1] can't
similarly abuse the session keyring, so to make 'sudo' work on all
systems it has to link all the user keyrings into root's user keyring
[2]. This is ugly and raises security concerns. Moreover it can't make
the keys available to system services, such as sshd trying to access the
user's '~/.ssh' directory (see [3], [4]) or NetworkManager trying to
read certificates from the user's home directory (see [5]); or to Docker
containers (see [6], [7]).
By having an API to add a key to the *filesystem* we'll be able to fix
the above bugs, remove userspace workarounds, and clearly express the
intended semantics: the locked/unlocked status of an encrypted directory
is global, and encryption is orthogonal to OS-level access control.
Why not use the add_key() syscall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We use an ioctl for this API rather than the existing add_key() system
call because the ioctl gives us the flexibility needed to implement
fscrypt-specific semantics that will be introduced in later patches:
- Supporting key removal with the semantics such that the secret is
removed immediately and any unused inodes using the key are evicted;
also, the eviction of any in-use inodes can be retried.
- Calculating a key-dependent cryptographic identifier and returning it
to userspace.
- Allowing keys to be added and removed by non-root users, but only keys
for v2 encryption policies; and to prevent denial-of-service attacks,
users can only remove keys they themselves have added, and a key is
only really removed after all users who added it have removed it.
Trying to shoehorn these semantics into the keyrings syscalls would be
very difficult, whereas the ioctls make things much easier.
However, to reuse code the implementation still uses the keyrings
service internally. Thus we get lockless RCU-mode key lookups without
having to re-implement it, and the keys automatically show up in
/proc/keys for debugging purposes.
References:
[1] https://github.com/google/fscrypt
[2] https://goo.gl/55cCrI#heading=h.vf09isp98isb
[3] https://github.com/google/fscrypt/issues/111#issuecomment-444347939
[4] https://github.com/google/fscrypt/issues/116
[5] https://bugs.launchpad.net/ubuntu/+source/fscrypt/+bug/1770715
[6] https://github.com/google/fscrypt/issues/128
[7] https://askubuntu.com/questions/1130306/cannot-run-docker-on-an-encrypted-filesystem
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
return PTR_ERR(key);
|
|
|
|
|
|
|
|
|
|
err = fscrypt_select_encryption_impl(ci, false);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
fscrypt: v2 encryption policy support
Add a new fscrypt policy version, "v2". It has the following changes
from the original policy version, which we call "v1" (*):
- Master keys (the user-provided encryption keys) are only ever used as
input to HKDF-SHA512. This is more flexible and less error-prone, and
it avoids the quirks and limitations of the AES-128-ECB based KDF.
Three classes of cryptographically isolated subkeys are defined:
- Per-file keys, like used in v1 policies except for the new KDF.
- Per-mode keys. These implement the semantics of the DIRECT_KEY
flag, which for v1 policies made the master key be used directly.
These are also planned to be used for inline encryption when
support for it is added.
- Key identifiers (see below).
- Each master key is identified by a 16-byte master_key_identifier,
which is derived from the key itself using HKDF-SHA512. This prevents
users from associating the wrong key with an encrypted file or
directory. This was easily possible with v1 policies, which
identified the key by an arbitrary 8-byte master_key_descriptor.
- The key must be provided in the filesystem-level keyring, not in a
process-subscribed keyring.
The following UAPI additions are made:
- The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
- A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
getting the v1 or v2 encryption policy of an encrypted file or
directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
be used because it did not have a way for userspace to indicate which
policy structure is expected. The new ioctl includes a size field, so
it is extensible to future fscrypt policy versions.
- The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
encryption policies. Such keys are kept logically separate from keys
for v1 encryption policies, and are identified by 'identifier' rather
than by 'descriptor'. The 'identifier' need not be provided when
adding a key, since the kernel will calculate it anyway.
This patch temporarily keeps adding/removing v2 policy keys behind the
same permission check done for adding/removing v1 policy keys:
capable(CAP_SYS_ADMIN). However, the next patch will carefully take
advantage of the cryptographically secure master_key_identifier to allow
non-root users to add/remove v2 policy keys, thus providing a full
replacement for v1 policies.
(*) Actually, in the API fscrypt_policy::version is 0 while on-disk
fscrypt_context::format is 1. But I believe it makes the most sense
to advance both to '2' to have them be in sync, and to consider the
numbering to start at 1 except for the API quirk.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
/*
|
|
|
|
|
* As a legacy fallback for v1 policies, search for the key in
|
|
|
|
|
* the current task's subscribed keyrings too. Don't move this
|
|
|
|
|
* to before the search of ->s_master_keys, since users
|
|
|
|
|
* shouldn't be able to override filesystem-level keys.
|
|
|
|
|
*/
|
fscrypt: add FS_IOC_ADD_ENCRYPTION_KEY ioctl
Add a new fscrypt ioctl, FS_IOC_ADD_ENCRYPTION_KEY. This ioctl adds an
encryption key to the filesystem's fscrypt keyring ->s_master_keys,
making any files encrypted with that key appear "unlocked".
Why we need this
~~~~~~~~~~~~~~~~
The main problem is that the "locked/unlocked" (ciphertext/plaintext)
status of encrypted files is global, but the fscrypt keys are not.
fscrypt only looks for keys in the keyring(s) the process accessing the
filesystem is subscribed to: the thread keyring, process keyring, and
session keyring, where the session keyring may contain the user keyring.
Therefore, userspace has to put fscrypt keys in the keyrings for
individual users or sessions. But this means that when a process with a
different keyring tries to access encrypted files, whether they appear
"unlocked" or not is nondeterministic. This is because it depends on
whether the files are currently present in the inode cache.
Fixing this by consistently providing each process its own view of the
filesystem depending on whether it has the key or not isn't feasible due
to how the VFS caches work. Furthermore, while sometimes users expect
this behavior, it is misguided for two reasons. First, it would be an
OS-level access control mechanism largely redundant with existing access
control mechanisms such as UNIX file permissions, ACLs, LSMs, etc.
Encryption is actually for protecting the data at rest.
Second, almost all users of fscrypt actually do need the keys to be
global. The largest users of fscrypt, Android and Chromium OS, achieve
this by having PID 1 create a "session keyring" that is inherited by
every process. This works, but it isn't scalable because it prevents
session keyrings from being used for any other purpose.
On general-purpose Linux distros, the 'fscrypt' userspace tool [1] can't
similarly abuse the session keyring, so to make 'sudo' work on all
systems it has to link all the user keyrings into root's user keyring
[2]. This is ugly and raises security concerns. Moreover it can't make
the keys available to system services, such as sshd trying to access the
user's '~/.ssh' directory (see [3], [4]) or NetworkManager trying to
read certificates from the user's home directory (see [5]); or to Docker
containers (see [6], [7]).
By having an API to add a key to the *filesystem* we'll be able to fix
the above bugs, remove userspace workarounds, and clearly express the
intended semantics: the locked/unlocked status of an encrypted directory
is global, and encryption is orthogonal to OS-level access control.
Why not use the add_key() syscall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We use an ioctl for this API rather than the existing add_key() system
call because the ioctl gives us the flexibility needed to implement
fscrypt-specific semantics that will be introduced in later patches:
- Supporting key removal with the semantics such that the secret is
removed immediately and any unused inodes using the key are evicted;
also, the eviction of any in-use inodes can be retried.
- Calculating a key-dependent cryptographic identifier and returning it
to userspace.
- Allowing keys to be added and removed by non-root users, but only keys
for v2 encryption policies; and to prevent denial-of-service attacks,
users can only remove keys they themselves have added, and a key is
only really removed after all users who added it have removed it.
Trying to shoehorn these semantics into the keyrings syscalls would be
very difficult, whereas the ioctls make things much easier.
However, to reuse code the implementation still uses the keyrings
service internally. Thus we get lockless RCU-mode key lookups without
having to re-implement it, and the keys automatically show up in
/proc/keys for debugging purposes.
References:
[1] https://github.com/google/fscrypt
[2] https://goo.gl/55cCrI#heading=h.vf09isp98isb
[3] https://github.com/google/fscrypt/issues/111#issuecomment-444347939
[4] https://github.com/google/fscrypt/issues/116
[5] https://bugs.launchpad.net/ubuntu/+source/fscrypt/+bug/1770715
[6] https://github.com/google/fscrypt/issues/128
[7] https://askubuntu.com/questions/1130306/cannot-run-docker-on-an-encrypted-filesystem
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
return fscrypt_setup_v1_file_key_via_subscribed_keyrings(ci);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
mk = key->payload.data[0];
|
fscrypt: allow unprivileged users to add/remove keys for v2 policies
Allow the FS_IOC_ADD_ENCRYPTION_KEY and FS_IOC_REMOVE_ENCRYPTION_KEY
ioctls to be used by non-root users to add and remove encryption keys
from the filesystem-level crypto keyrings, subject to limitations.
Motivation: while privileged fscrypt key management is sufficient for
some users (e.g. Android and Chromium OS, where a privileged process
manages all keys), the old API by design also allows non-root users to
set up and use encrypted directories, and we don't want to regress on
that. Especially, we don't want to force users to continue using the
old API, running into the visibility mismatch between files and keyrings
and being unable to "lock" encrypted directories.
Intuitively, the ioctls have to be privileged since they manipulate
filesystem-level state. However, it's actually safe to make them
unprivileged if we very carefully enforce some specific limitations.
First, each key must be identified by a cryptographic hash so that a
user can't add the wrong key for another user's files. For v2
encryption policies, we use the key_identifier for this. v1 policies
don't have this, so managing keys for them remains privileged.
Second, each key a user adds is charged to their quota for the keyrings
service. Thus, a user can't exhaust memory by adding a huge number of
keys. By default each non-root user is allowed up to 200 keys; this can
be changed using the existing sysctl 'kernel.keys.maxkeys'.
Third, if multiple users add the same key, we keep track of those users
of the key (of which there remains a single copy), and won't really
remove the key, i.e. "lock" the encrypted files, until all those users
have removed it. This prevents denial of service attacks that would be
possible under simpler schemes, such allowing the first user who added a
key to remove it -- since that could be a malicious user who has
compromised the key. Of course, encryption keys should be kept secret,
but the idea is that using encryption should never be *less* secure than
not using encryption, even if your key was compromised.
We tolerate that a user will be unable to really remove a key, i.e.
unable to "lock" their encrypted files, if another user has added the
same key. But in a sense, this is actually a good thing because it will
avoid providing a false notion of security where a key appears to have
been removed when actually it's still in memory, available to any
attacker who compromises the operating system kernel.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
down_read(&mk->mk_secret_sem);
|
fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl
Add a new fscrypt ioctl, FS_IOC_REMOVE_ENCRYPTION_KEY. This ioctl
removes an encryption key that was added by FS_IOC_ADD_ENCRYPTION_KEY.
It wipes the secret key itself, then "locks" the encrypted files and
directories that had been unlocked using that key -- implemented by
evicting the relevant dentries and inodes from the VFS caches.
The problem this solves is that many fscrypt users want the ability to
remove encryption keys, causing the corresponding encrypted directories
to appear "locked" (presented in ciphertext form) again. Moreover,
users want removing an encryption key to *really* remove it, in the
sense that the removed keys cannot be recovered even if kernel memory is
compromised, e.g. by the exploit of a kernel security vulnerability or
by a physical attack. This is desirable after a user logs out of the
system, for example. In many cases users even already assume this to be
the case and are surprised to hear when it's not.
It is not sufficient to simply unlink the master key from the keyring
(or to revoke or invalidate it), since the actual encryption transform
objects are still pinned in memory by their inodes. Therefore, to
really remove a key we must also evict the relevant inodes.
Currently one workaround is to run 'sync && echo 2 >
/proc/sys/vm/drop_caches'. But, that evicts all unused inodes in the
system rather than just the inodes associated with the key being
removed, causing severe performance problems. Moreover, it requires
root privileges, so regular users can't "lock" their encrypted files.
Another workaround, used in Chromium OS kernels, is to add a new
VFS-level ioctl FS_IOC_DROP_CACHE which is a more restricted version of
drop_caches that operates on a single super_block. It does:
shrink_dcache_sb(sb);
invalidate_inodes(sb, false);
But it's still a hack. Yet, the major users of filesystem encryption
want this feature badly enough that they are actually using these hacks.
To properly solve the problem, start maintaining a list of the inodes
which have been "unlocked" using each master key. Originally this
wasn't possible because the kernel didn't keep track of in-use master
keys at all. But, with the ->s_master_keys keyring it is now possible.
Then, add an ioctl FS_IOC_REMOVE_ENCRYPTION_KEY. It finds the specified
master key in ->s_master_keys, then wipes the secret key itself, which
prevents any additional inodes from being unlocked with the key. Then,
it syncs the filesystem and evicts the inodes in the key's list. The
normal inode eviction code will free and wipe the per-file keys (in
->i_crypt_info). Note that freeing ->i_crypt_info without evicting the
inodes was also considered, but would have been racy.
Some inodes may still be in use when a master key is removed, and we
can't simply revoke random file descriptors, mmap's, etc. Thus, the
ioctl simply skips in-use inodes, and returns -EBUSY to indicate that
some inodes weren't evicted. The master key *secret* is still removed,
but the fscrypt_master_key struct remains to keep track of the remaining
inodes. Userspace can then retry the ioctl to evict the remaining
inodes. Alternatively, if userspace adds the key again, the refreshed
secret will be associated with the existing list of inodes so they
remain correctly tracked for future key removals.
The ioctl doesn't wipe pagecache pages. Thus, we tolerate that after a
kernel compromise some portions of plaintext file contents may still be
recoverable from memory. This can be solved by enabling page poisoning
system-wide, which security conscious users may choose to do. But it's
very difficult to solve otherwise, e.g. note that plaintext file
contents may have been read in other places than pagecache pages.
Like FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY is
initially restricted to privileged users only. This is sufficient for
some use cases, but not all. A later patch will relax this restriction,
but it will require introducing key hashes, among other changes.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
|
|
|
|
|
/* Has the secret been removed (via FS_IOC_REMOVE_ENCRYPTION_KEY)? */
|
|
|
|
|
if (!is_master_key_secret_present(&mk->mk_secret)) {
|
|
|
|
|
err = -ENOKEY;
|
|
|
|
|
goto out_release_key;
|
|
|
|
|
}
|
fscrypt: add FS_IOC_ADD_ENCRYPTION_KEY ioctl
Add a new fscrypt ioctl, FS_IOC_ADD_ENCRYPTION_KEY. This ioctl adds an
encryption key to the filesystem's fscrypt keyring ->s_master_keys,
making any files encrypted with that key appear "unlocked".
Why we need this
~~~~~~~~~~~~~~~~
The main problem is that the "locked/unlocked" (ciphertext/plaintext)
status of encrypted files is global, but the fscrypt keys are not.
fscrypt only looks for keys in the keyring(s) the process accessing the
filesystem is subscribed to: the thread keyring, process keyring, and
session keyring, where the session keyring may contain the user keyring.
Therefore, userspace has to put fscrypt keys in the keyrings for
individual users or sessions. But this means that when a process with a
different keyring tries to access encrypted files, whether they appear
"unlocked" or not is nondeterministic. This is because it depends on
whether the files are currently present in the inode cache.
Fixing this by consistently providing each process its own view of the
filesystem depending on whether it has the key or not isn't feasible due
to how the VFS caches work. Furthermore, while sometimes users expect
this behavior, it is misguided for two reasons. First, it would be an
OS-level access control mechanism largely redundant with existing access
control mechanisms such as UNIX file permissions, ACLs, LSMs, etc.
Encryption is actually for protecting the data at rest.
Second, almost all users of fscrypt actually do need the keys to be
global. The largest users of fscrypt, Android and Chromium OS, achieve
this by having PID 1 create a "session keyring" that is inherited by
every process. This works, but it isn't scalable because it prevents
session keyrings from being used for any other purpose.
On general-purpose Linux distros, the 'fscrypt' userspace tool [1] can't
similarly abuse the session keyring, so to make 'sudo' work on all
systems it has to link all the user keyrings into root's user keyring
[2]. This is ugly and raises security concerns. Moreover it can't make
the keys available to system services, such as sshd trying to access the
user's '~/.ssh' directory (see [3], [4]) or NetworkManager trying to
read certificates from the user's home directory (see [5]); or to Docker
containers (see [6], [7]).
By having an API to add a key to the *filesystem* we'll be able to fix
the above bugs, remove userspace workarounds, and clearly express the
intended semantics: the locked/unlocked status of an encrypted directory
is global, and encryption is orthogonal to OS-level access control.
Why not use the add_key() syscall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We use an ioctl for this API rather than the existing add_key() system
call because the ioctl gives us the flexibility needed to implement
fscrypt-specific semantics that will be introduced in later patches:
- Supporting key removal with the semantics such that the secret is
removed immediately and any unused inodes using the key are evicted;
also, the eviction of any in-use inodes can be retried.
- Calculating a key-dependent cryptographic identifier and returning it
to userspace.
- Allowing keys to be added and removed by non-root users, but only keys
for v2 encryption policies; and to prevent denial-of-service attacks,
users can only remove keys they themselves have added, and a key is
only really removed after all users who added it have removed it.
Trying to shoehorn these semantics into the keyrings syscalls would be
very difficult, whereas the ioctls make things much easier.
However, to reuse code the implementation still uses the keyrings
service internally. Thus we get lockless RCU-mode key lookups without
having to re-implement it, and the keys automatically show up in
/proc/keys for debugging purposes.
References:
[1] https://github.com/google/fscrypt
[2] https://goo.gl/55cCrI#heading=h.vf09isp98isb
[3] https://github.com/google/fscrypt/issues/111#issuecomment-444347939
[4] https://github.com/google/fscrypt/issues/116
[5] https://bugs.launchpad.net/ubuntu/+source/fscrypt/+bug/1770715
[6] https://github.com/google/fscrypt/issues/128
[7] https://askubuntu.com/questions/1130306/cannot-run-docker-on-an-encrypted-filesystem
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
|
fscrypt: v2 encryption policy support
Add a new fscrypt policy version, "v2". It has the following changes
from the original policy version, which we call "v1" (*):
- Master keys (the user-provided encryption keys) are only ever used as
input to HKDF-SHA512. This is more flexible and less error-prone, and
it avoids the quirks and limitations of the AES-128-ECB based KDF.
Three classes of cryptographically isolated subkeys are defined:
- Per-file keys, like used in v1 policies except for the new KDF.
- Per-mode keys. These implement the semantics of the DIRECT_KEY
flag, which for v1 policies made the master key be used directly.
These are also planned to be used for inline encryption when
support for it is added.
- Key identifiers (see below).
- Each master key is identified by a 16-byte master_key_identifier,
which is derived from the key itself using HKDF-SHA512. This prevents
users from associating the wrong key with an encrypted file or
directory. This was easily possible with v1 policies, which
identified the key by an arbitrary 8-byte master_key_descriptor.
- The key must be provided in the filesystem-level keyring, not in a
process-subscribed keyring.
The following UAPI additions are made:
- The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
- A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
getting the v1 or v2 encryption policy of an encrypted file or
directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
be used because it did not have a way for userspace to indicate which
policy structure is expected. The new ioctl includes a size field, so
it is extensible to future fscrypt policy versions.
- The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
encryption policies. Such keys are kept logically separate from keys
for v1 encryption policies, and are identified by 'identifier' rather
than by 'descriptor'. The 'identifier' need not be provided when
adding a key, since the kernel will calculate it anyway.
This patch temporarily keeps adding/removing v2 policy keys behind the
same permission check done for adding/removing v1 policy keys:
capable(CAP_SYS_ADMIN). However, the next patch will carefully take
advantage of the cryptographically secure master_key_identifier to allow
non-root users to add/remove v2 policy keys, thus providing a full
replacement for v1 policies.
(*) Actually, in the API fscrypt_policy::version is 0 while on-disk
fscrypt_context::format is 1. But I believe it makes the most sense
to advance both to '2' to have them be in sync, and to consider the
numbering to start at 1 except for the API quirk.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
/*
|
|
|
|
|
* Require that the master key be at least as long as the derived key.
|
|
|
|
|
* Otherwise, the derived key cannot possibly contain as much entropy as
|
|
|
|
|
* that required by the encryption mode it will be used for. For v1
|
|
|
|
|
* policies it's also required for the KDF to work at all.
|
|
|
|
|
*/
|
fscrypt: add FS_IOC_ADD_ENCRYPTION_KEY ioctl
Add a new fscrypt ioctl, FS_IOC_ADD_ENCRYPTION_KEY. This ioctl adds an
encryption key to the filesystem's fscrypt keyring ->s_master_keys,
making any files encrypted with that key appear "unlocked".
Why we need this
~~~~~~~~~~~~~~~~
The main problem is that the "locked/unlocked" (ciphertext/plaintext)
status of encrypted files is global, but the fscrypt keys are not.
fscrypt only looks for keys in the keyring(s) the process accessing the
filesystem is subscribed to: the thread keyring, process keyring, and
session keyring, where the session keyring may contain the user keyring.
Therefore, userspace has to put fscrypt keys in the keyrings for
individual users or sessions. But this means that when a process with a
different keyring tries to access encrypted files, whether they appear
"unlocked" or not is nondeterministic. This is because it depends on
whether the files are currently present in the inode cache.
Fixing this by consistently providing each process its own view of the
filesystem depending on whether it has the key or not isn't feasible due
to how the VFS caches work. Furthermore, while sometimes users expect
this behavior, it is misguided for two reasons. First, it would be an
OS-level access control mechanism largely redundant with existing access
control mechanisms such as UNIX file permissions, ACLs, LSMs, etc.
Encryption is actually for protecting the data at rest.
Second, almost all users of fscrypt actually do need the keys to be
global. The largest users of fscrypt, Android and Chromium OS, achieve
this by having PID 1 create a "session keyring" that is inherited by
every process. This works, but it isn't scalable because it prevents
session keyrings from being used for any other purpose.
On general-purpose Linux distros, the 'fscrypt' userspace tool [1] can't
similarly abuse the session keyring, so to make 'sudo' work on all
systems it has to link all the user keyrings into root's user keyring
[2]. This is ugly and raises security concerns. Moreover it can't make
the keys available to system services, such as sshd trying to access the
user's '~/.ssh' directory (see [3], [4]) or NetworkManager trying to
read certificates from the user's home directory (see [5]); or to Docker
containers (see [6], [7]).
By having an API to add a key to the *filesystem* we'll be able to fix
the above bugs, remove userspace workarounds, and clearly express the
intended semantics: the locked/unlocked status of an encrypted directory
is global, and encryption is orthogonal to OS-level access control.
Why not use the add_key() syscall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We use an ioctl for this API rather than the existing add_key() system
call because the ioctl gives us the flexibility needed to implement
fscrypt-specific semantics that will be introduced in later patches:
- Supporting key removal with the semantics such that the secret is
removed immediately and any unused inodes using the key are evicted;
also, the eviction of any in-use inodes can be retried.
- Calculating a key-dependent cryptographic identifier and returning it
to userspace.
- Allowing keys to be added and removed by non-root users, but only keys
for v2 encryption policies; and to prevent denial-of-service attacks,
users can only remove keys they themselves have added, and a key is
only really removed after all users who added it have removed it.
Trying to shoehorn these semantics into the keyrings syscalls would be
very difficult, whereas the ioctls make things much easier.
However, to reuse code the implementation still uses the keyrings
service internally. Thus we get lockless RCU-mode key lookups without
having to re-implement it, and the keys automatically show up in
/proc/keys for debugging purposes.
References:
[1] https://github.com/google/fscrypt
[2] https://goo.gl/55cCrI#heading=h.vf09isp98isb
[3] https://github.com/google/fscrypt/issues/111#issuecomment-444347939
[4] https://github.com/google/fscrypt/issues/116
[5] https://bugs.launchpad.net/ubuntu/+source/fscrypt/+bug/1770715
[6] https://github.com/google/fscrypt/issues/128
[7] https://askubuntu.com/questions/1130306/cannot-run-docker-on-an-encrypted-filesystem
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
if (mk->mk_secret.size < ci->ci_mode->keysize) {
|
|
|
|
|
fscrypt_warn(NULL,
|
|
|
|
|
"key with %s %*phN is too short (got %u bytes, need %u+ bytes)",
|
|
|
|
|
master_key_spec_type(&mk_spec),
|
|
|
|
|
master_key_spec_len(&mk_spec), (u8 *)&mk_spec.u,
|
|
|
|
|
mk->mk_secret.size, ci->ci_mode->keysize);
|
|
|
|
|
err = -ENOKEY;
|
|
|
|
|
goto out_release_key;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
err = fscrypt_select_encryption_impl(ci, mk->mk_secret.is_hw_wrapped);
|
|
|
|
|
if (err)
|
|
|
|
|
goto out_release_key;
|
|
|
|
|
|
fscrypt: v2 encryption policy support
Add a new fscrypt policy version, "v2". It has the following changes
from the original policy version, which we call "v1" (*):
- Master keys (the user-provided encryption keys) are only ever used as
input to HKDF-SHA512. This is more flexible and less error-prone, and
it avoids the quirks and limitations of the AES-128-ECB based KDF.
Three classes of cryptographically isolated subkeys are defined:
- Per-file keys, like used in v1 policies except for the new KDF.
- Per-mode keys. These implement the semantics of the DIRECT_KEY
flag, which for v1 policies made the master key be used directly.
These are also planned to be used for inline encryption when
support for it is added.
- Key identifiers (see below).
- Each master key is identified by a 16-byte master_key_identifier,
which is derived from the key itself using HKDF-SHA512. This prevents
users from associating the wrong key with an encrypted file or
directory. This was easily possible with v1 policies, which
identified the key by an arbitrary 8-byte master_key_descriptor.
- The key must be provided in the filesystem-level keyring, not in a
process-subscribed keyring.
The following UAPI additions are made:
- The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
- A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
getting the v1 or v2 encryption policy of an encrypted file or
directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
be used because it did not have a way for userspace to indicate which
policy structure is expected. The new ioctl includes a size field, so
it is extensible to future fscrypt policy versions.
- The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
encryption policies. Such keys are kept logically separate from keys
for v1 encryption policies, and are identified by 'identifier' rather
than by 'descriptor'. The 'identifier' need not be provided when
adding a key, since the kernel will calculate it anyway.
This patch temporarily keeps adding/removing v2 policy keys behind the
same permission check done for adding/removing v1 policy keys:
capable(CAP_SYS_ADMIN). However, the next patch will carefully take
advantage of the cryptographically secure master_key_identifier to allow
non-root users to add/remove v2 policy keys, thus providing a full
replacement for v1 policies.
(*) Actually, in the API fscrypt_policy::version is 0 while on-disk
fscrypt_context::format is 1. But I believe it makes the most sense
to advance both to '2' to have them be in sync, and to consider the
numbering to start at 1 except for the API quirk.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
switch (ci->ci_policy.version) {
|
|
|
|
|
case FSCRYPT_POLICY_V1:
|
|
|
|
|
err = fscrypt_setup_v1_file_key(ci, mk->mk_secret.raw);
|
|
|
|
|
break;
|
|
|
|
|
case FSCRYPT_POLICY_V2:
|
|
|
|
|
err = fscrypt_setup_v2_file_key(ci, mk);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
WARN_ON(1);
|
|
|
|
|
err = -EINVAL;
|
|
|
|
|
break;
|
|
|
|
|
}
|
fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl
Add a new fscrypt ioctl, FS_IOC_REMOVE_ENCRYPTION_KEY. This ioctl
removes an encryption key that was added by FS_IOC_ADD_ENCRYPTION_KEY.
It wipes the secret key itself, then "locks" the encrypted files and
directories that had been unlocked using that key -- implemented by
evicting the relevant dentries and inodes from the VFS caches.
The problem this solves is that many fscrypt users want the ability to
remove encryption keys, causing the corresponding encrypted directories
to appear "locked" (presented in ciphertext form) again. Moreover,
users want removing an encryption key to *really* remove it, in the
sense that the removed keys cannot be recovered even if kernel memory is
compromised, e.g. by the exploit of a kernel security vulnerability or
by a physical attack. This is desirable after a user logs out of the
system, for example. In many cases users even already assume this to be
the case and are surprised to hear when it's not.
It is not sufficient to simply unlink the master key from the keyring
(or to revoke or invalidate it), since the actual encryption transform
objects are still pinned in memory by their inodes. Therefore, to
really remove a key we must also evict the relevant inodes.
Currently one workaround is to run 'sync && echo 2 >
/proc/sys/vm/drop_caches'. But, that evicts all unused inodes in the
system rather than just the inodes associated with the key being
removed, causing severe performance problems. Moreover, it requires
root privileges, so regular users can't "lock" their encrypted files.
Another workaround, used in Chromium OS kernels, is to add a new
VFS-level ioctl FS_IOC_DROP_CACHE which is a more restricted version of
drop_caches that operates on a single super_block. It does:
shrink_dcache_sb(sb);
invalidate_inodes(sb, false);
But it's still a hack. Yet, the major users of filesystem encryption
want this feature badly enough that they are actually using these hacks.
To properly solve the problem, start maintaining a list of the inodes
which have been "unlocked" using each master key. Originally this
wasn't possible because the kernel didn't keep track of in-use master
keys at all. But, with the ->s_master_keys keyring it is now possible.
Then, add an ioctl FS_IOC_REMOVE_ENCRYPTION_KEY. It finds the specified
master key in ->s_master_keys, then wipes the secret key itself, which
prevents any additional inodes from being unlocked with the key. Then,
it syncs the filesystem and evicts the inodes in the key's list. The
normal inode eviction code will free and wipe the per-file keys (in
->i_crypt_info). Note that freeing ->i_crypt_info without evicting the
inodes was also considered, but would have been racy.
Some inodes may still be in use when a master key is removed, and we
can't simply revoke random file descriptors, mmap's, etc. Thus, the
ioctl simply skips in-use inodes, and returns -EBUSY to indicate that
some inodes weren't evicted. The master key *secret* is still removed,
but the fscrypt_master_key struct remains to keep track of the remaining
inodes. Userspace can then retry the ioctl to evict the remaining
inodes. Alternatively, if userspace adds the key again, the refreshed
secret will be associated with the existing list of inodes so they
remain correctly tracked for future key removals.
The ioctl doesn't wipe pagecache pages. Thus, we tolerate that after a
kernel compromise some portions of plaintext file contents may still be
recoverable from memory. This can be solved by enabling page poisoning
system-wide, which security conscious users may choose to do. But it's
very difficult to solve otherwise, e.g. note that plaintext file
contents may have been read in other places than pagecache pages.
Like FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY is
initially restricted to privileged users only. This is sufficient for
some use cases, but not all. A later patch will relax this restriction,
but it will require introducing key hashes, among other changes.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
if (err)
|
|
|
|
|
goto out_release_key;
|
|
|
|
|
|
|
|
|
|
*master_key_ret = key;
|
|
|
|
|
return 0;
|
fscrypt: add FS_IOC_ADD_ENCRYPTION_KEY ioctl
Add a new fscrypt ioctl, FS_IOC_ADD_ENCRYPTION_KEY. This ioctl adds an
encryption key to the filesystem's fscrypt keyring ->s_master_keys,
making any files encrypted with that key appear "unlocked".
Why we need this
~~~~~~~~~~~~~~~~
The main problem is that the "locked/unlocked" (ciphertext/plaintext)
status of encrypted files is global, but the fscrypt keys are not.
fscrypt only looks for keys in the keyring(s) the process accessing the
filesystem is subscribed to: the thread keyring, process keyring, and
session keyring, where the session keyring may contain the user keyring.
Therefore, userspace has to put fscrypt keys in the keyrings for
individual users or sessions. But this means that when a process with a
different keyring tries to access encrypted files, whether they appear
"unlocked" or not is nondeterministic. This is because it depends on
whether the files are currently present in the inode cache.
Fixing this by consistently providing each process its own view of the
filesystem depending on whether it has the key or not isn't feasible due
to how the VFS caches work. Furthermore, while sometimes users expect
this behavior, it is misguided for two reasons. First, it would be an
OS-level access control mechanism largely redundant with existing access
control mechanisms such as UNIX file permissions, ACLs, LSMs, etc.
Encryption is actually for protecting the data at rest.
Second, almost all users of fscrypt actually do need the keys to be
global. The largest users of fscrypt, Android and Chromium OS, achieve
this by having PID 1 create a "session keyring" that is inherited by
every process. This works, but it isn't scalable because it prevents
session keyrings from being used for any other purpose.
On general-purpose Linux distros, the 'fscrypt' userspace tool [1] can't
similarly abuse the session keyring, so to make 'sudo' work on all
systems it has to link all the user keyrings into root's user keyring
[2]. This is ugly and raises security concerns. Moreover it can't make
the keys available to system services, such as sshd trying to access the
user's '~/.ssh' directory (see [3], [4]) or NetworkManager trying to
read certificates from the user's home directory (see [5]); or to Docker
containers (see [6], [7]).
By having an API to add a key to the *filesystem* we'll be able to fix
the above bugs, remove userspace workarounds, and clearly express the
intended semantics: the locked/unlocked status of an encrypted directory
is global, and encryption is orthogonal to OS-level access control.
Why not use the add_key() syscall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We use an ioctl for this API rather than the existing add_key() system
call because the ioctl gives us the flexibility needed to implement
fscrypt-specific semantics that will be introduced in later patches:
- Supporting key removal with the semantics such that the secret is
removed immediately and any unused inodes using the key are evicted;
also, the eviction of any in-use inodes can be retried.
- Calculating a key-dependent cryptographic identifier and returning it
to userspace.
- Allowing keys to be added and removed by non-root users, but only keys
for v2 encryption policies; and to prevent denial-of-service attacks,
users can only remove keys they themselves have added, and a key is
only really removed after all users who added it have removed it.
Trying to shoehorn these semantics into the keyrings syscalls would be
very difficult, whereas the ioctls make things much easier.
However, to reuse code the implementation still uses the keyrings
service internally. Thus we get lockless RCU-mode key lookups without
having to re-implement it, and the keys automatically show up in
/proc/keys for debugging purposes.
References:
[1] https://github.com/google/fscrypt
[2] https://goo.gl/55cCrI#heading=h.vf09isp98isb
[3] https://github.com/google/fscrypt/issues/111#issuecomment-444347939
[4] https://github.com/google/fscrypt/issues/116
[5] https://bugs.launchpad.net/ubuntu/+source/fscrypt/+bug/1770715
[6] https://github.com/google/fscrypt/issues/128
[7] https://askubuntu.com/questions/1130306/cannot-run-docker-on-an-encrypted-filesystem
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
|
|
|
|
|
out_release_key:
|
fscrypt: allow unprivileged users to add/remove keys for v2 policies
Allow the FS_IOC_ADD_ENCRYPTION_KEY and FS_IOC_REMOVE_ENCRYPTION_KEY
ioctls to be used by non-root users to add and remove encryption keys
from the filesystem-level crypto keyrings, subject to limitations.
Motivation: while privileged fscrypt key management is sufficient for
some users (e.g. Android and Chromium OS, where a privileged process
manages all keys), the old API by design also allows non-root users to
set up and use encrypted directories, and we don't want to regress on
that. Especially, we don't want to force users to continue using the
old API, running into the visibility mismatch between files and keyrings
and being unable to "lock" encrypted directories.
Intuitively, the ioctls have to be privileged since they manipulate
filesystem-level state. However, it's actually safe to make them
unprivileged if we very carefully enforce some specific limitations.
First, each key must be identified by a cryptographic hash so that a
user can't add the wrong key for another user's files. For v2
encryption policies, we use the key_identifier for this. v1 policies
don't have this, so managing keys for them remains privileged.
Second, each key a user adds is charged to their quota for the keyrings
service. Thus, a user can't exhaust memory by adding a huge number of
keys. By default each non-root user is allowed up to 200 keys; this can
be changed using the existing sysctl 'kernel.keys.maxkeys'.
Third, if multiple users add the same key, we keep track of those users
of the key (of which there remains a single copy), and won't really
remove the key, i.e. "lock" the encrypted files, until all those users
have removed it. This prevents denial of service attacks that would be
possible under simpler schemes, such allowing the first user who added a
key to remove it -- since that could be a malicious user who has
compromised the key. Of course, encryption keys should be kept secret,
but the idea is that using encryption should never be *less* secure than
not using encryption, even if your key was compromised.
We tolerate that a user will be unable to really remove a key, i.e.
unable to "lock" their encrypted files, if another user has added the
same key. But in a sense, this is actually a good thing because it will
avoid providing a false notion of security where a key appears to have
been removed when actually it's still in memory, available to any
attacker who compromises the operating system kernel.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
up_read(&mk->mk_secret_sem);
|
fscrypt: add FS_IOC_ADD_ENCRYPTION_KEY ioctl
Add a new fscrypt ioctl, FS_IOC_ADD_ENCRYPTION_KEY. This ioctl adds an
encryption key to the filesystem's fscrypt keyring ->s_master_keys,
making any files encrypted with that key appear "unlocked".
Why we need this
~~~~~~~~~~~~~~~~
The main problem is that the "locked/unlocked" (ciphertext/plaintext)
status of encrypted files is global, but the fscrypt keys are not.
fscrypt only looks for keys in the keyring(s) the process accessing the
filesystem is subscribed to: the thread keyring, process keyring, and
session keyring, where the session keyring may contain the user keyring.
Therefore, userspace has to put fscrypt keys in the keyrings for
individual users or sessions. But this means that when a process with a
different keyring tries to access encrypted files, whether they appear
"unlocked" or not is nondeterministic. This is because it depends on
whether the files are currently present in the inode cache.
Fixing this by consistently providing each process its own view of the
filesystem depending on whether it has the key or not isn't feasible due
to how the VFS caches work. Furthermore, while sometimes users expect
this behavior, it is misguided for two reasons. First, it would be an
OS-level access control mechanism largely redundant with existing access
control mechanisms such as UNIX file permissions, ACLs, LSMs, etc.
Encryption is actually for protecting the data at rest.
Second, almost all users of fscrypt actually do need the keys to be
global. The largest users of fscrypt, Android and Chromium OS, achieve
this by having PID 1 create a "session keyring" that is inherited by
every process. This works, but it isn't scalable because it prevents
session keyrings from being used for any other purpose.
On general-purpose Linux distros, the 'fscrypt' userspace tool [1] can't
similarly abuse the session keyring, so to make 'sudo' work on all
systems it has to link all the user keyrings into root's user keyring
[2]. This is ugly and raises security concerns. Moreover it can't make
the keys available to system services, such as sshd trying to access the
user's '~/.ssh' directory (see [3], [4]) or NetworkManager trying to
read certificates from the user's home directory (see [5]); or to Docker
containers (see [6], [7]).
By having an API to add a key to the *filesystem* we'll be able to fix
the above bugs, remove userspace workarounds, and clearly express the
intended semantics: the locked/unlocked status of an encrypted directory
is global, and encryption is orthogonal to OS-level access control.
Why not use the add_key() syscall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We use an ioctl for this API rather than the existing add_key() system
call because the ioctl gives us the flexibility needed to implement
fscrypt-specific semantics that will be introduced in later patches:
- Supporting key removal with the semantics such that the secret is
removed immediately and any unused inodes using the key are evicted;
also, the eviction of any in-use inodes can be retried.
- Calculating a key-dependent cryptographic identifier and returning it
to userspace.
- Allowing keys to be added and removed by non-root users, but only keys
for v2 encryption policies; and to prevent denial-of-service attacks,
users can only remove keys they themselves have added, and a key is
only really removed after all users who added it have removed it.
Trying to shoehorn these semantics into the keyrings syscalls would be
very difficult, whereas the ioctls make things much easier.
However, to reuse code the implementation still uses the keyrings
service internally. Thus we get lockless RCU-mode key lookups without
having to re-implement it, and the keys automatically show up in
/proc/keys for debugging purposes.
References:
[1] https://github.com/google/fscrypt
[2] https://goo.gl/55cCrI#heading=h.vf09isp98isb
[3] https://github.com/google/fscrypt/issues/111#issuecomment-444347939
[4] https://github.com/google/fscrypt/issues/116
[5] https://bugs.launchpad.net/ubuntu/+source/fscrypt/+bug/1770715
[6] https://github.com/google/fscrypt/issues/128
[7] https://askubuntu.com/questions/1130306/cannot-run-docker-on-an-encrypted-filesystem
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
key_put(key);
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
fscrypt: add Adiantum support / removed speck
Add support for the Adiantum encryption mode to fscrypt. Adiantum is a
tweakable, length-preserving encryption mode with security provably
reducible to that of XChaCha12 and AES-256, subject to a security bound.
It's also a true wide-block mode, unlike XTS. See the paper
"Adiantum: length-preserving encryption for entry-level processors"
(https://eprint.iacr.org/2018/720.pdf) for more details. Also see
commit 059c2a4d8e16 ("crypto: adiantum - add Adiantum support").
On sufficiently long messages, Adiantum's bottlenecks are XChaCha12 and
the NH hash function. These algorithms are fast even on processors
without dedicated crypto instructions. Adiantum makes it feasible to
enable storage encryption on low-end mobile devices that lack AES
instructions; currently such devices are unencrypted. On ARM Cortex-A7,
on 4096-byte messages Adiantum encryption is about 4 times faster than
AES-256-XTS encryption; decryption is about 5 times faster.
In fscrypt, Adiantum is suitable for encrypting both file contents and
names. With filenames, it fixes a known weakness: when two filenames in
a directory share a common prefix of >= 16 bytes, with CTS-CBC their
encrypted filenames share a common prefix too, leaking information.
Adiantum does not have this problem.
Since Adiantum also accepts long tweaks (IVs), it's also safe to use the
master key directly for Adiantum encryption rather than deriving
per-file keys, provided that the per-file nonce is included in the IVs
and the master key isn't used for any other encryption mode. This
configuration saves memory and improves performance. A new fscrypt
policy flag is added to allow users to opt-in to this configuration.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
6 years ago
|
|
|
static void put_crypt_info(struct fscrypt_info *ci)
|
|
|
|
|
{
|
fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl
Add a new fscrypt ioctl, FS_IOC_REMOVE_ENCRYPTION_KEY. This ioctl
removes an encryption key that was added by FS_IOC_ADD_ENCRYPTION_KEY.
It wipes the secret key itself, then "locks" the encrypted files and
directories that had been unlocked using that key -- implemented by
evicting the relevant dentries and inodes from the VFS caches.
The problem this solves is that many fscrypt users want the ability to
remove encryption keys, causing the corresponding encrypted directories
to appear "locked" (presented in ciphertext form) again. Moreover,
users want removing an encryption key to *really* remove it, in the
sense that the removed keys cannot be recovered even if kernel memory is
compromised, e.g. by the exploit of a kernel security vulnerability or
by a physical attack. This is desirable after a user logs out of the
system, for example. In many cases users even already assume this to be
the case and are surprised to hear when it's not.
It is not sufficient to simply unlink the master key from the keyring
(or to revoke or invalidate it), since the actual encryption transform
objects are still pinned in memory by their inodes. Therefore, to
really remove a key we must also evict the relevant inodes.
Currently one workaround is to run 'sync && echo 2 >
/proc/sys/vm/drop_caches'. But, that evicts all unused inodes in the
system rather than just the inodes associated with the key being
removed, causing severe performance problems. Moreover, it requires
root privileges, so regular users can't "lock" their encrypted files.
Another workaround, used in Chromium OS kernels, is to add a new
VFS-level ioctl FS_IOC_DROP_CACHE which is a more restricted version of
drop_caches that operates on a single super_block. It does:
shrink_dcache_sb(sb);
invalidate_inodes(sb, false);
But it's still a hack. Yet, the major users of filesystem encryption
want this feature badly enough that they are actually using these hacks.
To properly solve the problem, start maintaining a list of the inodes
which have been "unlocked" using each master key. Originally this
wasn't possible because the kernel didn't keep track of in-use master
keys at all. But, with the ->s_master_keys keyring it is now possible.
Then, add an ioctl FS_IOC_REMOVE_ENCRYPTION_KEY. It finds the specified
master key in ->s_master_keys, then wipes the secret key itself, which
prevents any additional inodes from being unlocked with the key. Then,
it syncs the filesystem and evicts the inodes in the key's list. The
normal inode eviction code will free and wipe the per-file keys (in
->i_crypt_info). Note that freeing ->i_crypt_info without evicting the
inodes was also considered, but would have been racy.
Some inodes may still be in use when a master key is removed, and we
can't simply revoke random file descriptors, mmap's, etc. Thus, the
ioctl simply skips in-use inodes, and returns -EBUSY to indicate that
some inodes weren't evicted. The master key *secret* is still removed,
but the fscrypt_master_key struct remains to keep track of the remaining
inodes. Userspace can then retry the ioctl to evict the remaining
inodes. Alternatively, if userspace adds the key again, the refreshed
secret will be associated with the existing list of inodes so they
remain correctly tracked for future key removals.
The ioctl doesn't wipe pagecache pages. Thus, we tolerate that after a
kernel compromise some portions of plaintext file contents may still be
recoverable from memory. This can be solved by enabling page poisoning
system-wide, which security conscious users may choose to do. But it's
very difficult to solve otherwise, e.g. note that plaintext file
contents may have been read in other places than pagecache pages.
Like FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY is
initially restricted to privileged users only. This is sufficient for
some use cases, but not all. A later patch will relax this restriction,
but it will require introducing key hashes, among other changes.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
struct key *key;
|
|
|
|
|
|
fscrypt: add Adiantum support / removed speck
Add support for the Adiantum encryption mode to fscrypt. Adiantum is a
tweakable, length-preserving encryption mode with security provably
reducible to that of XChaCha12 and AES-256, subject to a security bound.
It's also a true wide-block mode, unlike XTS. See the paper
"Adiantum: length-preserving encryption for entry-level processors"
(https://eprint.iacr.org/2018/720.pdf) for more details. Also see
commit 059c2a4d8e16 ("crypto: adiantum - add Adiantum support").
On sufficiently long messages, Adiantum's bottlenecks are XChaCha12 and
the NH hash function. These algorithms are fast even on processors
without dedicated crypto instructions. Adiantum makes it feasible to
enable storage encryption on low-end mobile devices that lack AES
instructions; currently such devices are unencrypted. On ARM Cortex-A7,
on 4096-byte messages Adiantum encryption is about 4 times faster than
AES-256-XTS encryption; decryption is about 5 times faster.
In fscrypt, Adiantum is suitable for encrypting both file contents and
names. With filenames, it fixes a known weakness: when two filenames in
a directory share a common prefix of >= 16 bytes, with CTS-CBC their
encrypted filenames share a common prefix too, leaking information.
Adiantum does not have this problem.
Since Adiantum also accepts long tweaks (IVs), it's also safe to use the
master key directly for Adiantum encryption rather than deriving
per-file keys, provided that the per-file nonce is included in the IVs
and the master key isn't used for any other encryption mode. This
configuration saves memory and improves performance. A new fscrypt
policy flag is added to allow users to opt-in to this configuration.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
6 years ago
|
|
|
if (!ci)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_FSCRYPT_SDP
|
|
|
|
|
fscrypt_sdp_put_sdp_info(ci->ci_sdp_info);
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
if (ci->ci_direct_key)
|
|
|
|
|
fscrypt_put_direct_key(ci->ci_direct_key);
|
|
|
|
|
else if (ci->ci_owns_key) {
|
|
|
|
|
if (fscrypt_policy_contents_mode(&ci->ci_policy) !=
|
|
|
|
|
FSCRYPT_MODE_PRIVATE) {
|
|
|
|
|
fscrypt_destroy_prepared_key(&ci->ci_key);
|
|
|
|
|
} else {
|
|
|
|
|
crypto_free_skcipher(ci->ci_key.tfm);
|
|
|
|
|
#ifdef CONFIG_FS_ENCRYPTION_INLINE_CRYPT
|
|
|
|
|
if (ci->ci_key.blk_key)
|
|
|
|
|
kzfree(ci->ci_key.blk_key);
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
}
|
fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl
Add a new fscrypt ioctl, FS_IOC_REMOVE_ENCRYPTION_KEY. This ioctl
removes an encryption key that was added by FS_IOC_ADD_ENCRYPTION_KEY.
It wipes the secret key itself, then "locks" the encrypted files and
directories that had been unlocked using that key -- implemented by
evicting the relevant dentries and inodes from the VFS caches.
The problem this solves is that many fscrypt users want the ability to
remove encryption keys, causing the corresponding encrypted directories
to appear "locked" (presented in ciphertext form) again. Moreover,
users want removing an encryption key to *really* remove it, in the
sense that the removed keys cannot be recovered even if kernel memory is
compromised, e.g. by the exploit of a kernel security vulnerability or
by a physical attack. This is desirable after a user logs out of the
system, for example. In many cases users even already assume this to be
the case and are surprised to hear when it's not.
It is not sufficient to simply unlink the master key from the keyring
(or to revoke or invalidate it), since the actual encryption transform
objects are still pinned in memory by their inodes. Therefore, to
really remove a key we must also evict the relevant inodes.
Currently one workaround is to run 'sync && echo 2 >
/proc/sys/vm/drop_caches'. But, that evicts all unused inodes in the
system rather than just the inodes associated with the key being
removed, causing severe performance problems. Moreover, it requires
root privileges, so regular users can't "lock" their encrypted files.
Another workaround, used in Chromium OS kernels, is to add a new
VFS-level ioctl FS_IOC_DROP_CACHE which is a more restricted version of
drop_caches that operates on a single super_block. It does:
shrink_dcache_sb(sb);
invalidate_inodes(sb, false);
But it's still a hack. Yet, the major users of filesystem encryption
want this feature badly enough that they are actually using these hacks.
To properly solve the problem, start maintaining a list of the inodes
which have been "unlocked" using each master key. Originally this
wasn't possible because the kernel didn't keep track of in-use master
keys at all. But, with the ->s_master_keys keyring it is now possible.
Then, add an ioctl FS_IOC_REMOVE_ENCRYPTION_KEY. It finds the specified
master key in ->s_master_keys, then wipes the secret key itself, which
prevents any additional inodes from being unlocked with the key. Then,
it syncs the filesystem and evicts the inodes in the key's list. The
normal inode eviction code will free and wipe the per-file keys (in
->i_crypt_info). Note that freeing ->i_crypt_info without evicting the
inodes was also considered, but would have been racy.
Some inodes may still be in use when a master key is removed, and we
can't simply revoke random file descriptors, mmap's, etc. Thus, the
ioctl simply skips in-use inodes, and returns -EBUSY to indicate that
some inodes weren't evicted. The master key *secret* is still removed,
but the fscrypt_master_key struct remains to keep track of the remaining
inodes. Userspace can then retry the ioctl to evict the remaining
inodes. Alternatively, if userspace adds the key again, the refreshed
secret will be associated with the existing list of inodes so they
remain correctly tracked for future key removals.
The ioctl doesn't wipe pagecache pages. Thus, we tolerate that after a
kernel compromise some portions of plaintext file contents may still be
recoverable from memory. This can be solved by enabling page poisoning
system-wide, which security conscious users may choose to do. But it's
very difficult to solve otherwise, e.g. note that plaintext file
contents may have been read in other places than pagecache pages.
Like FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY is
initially restricted to privileged users only. This is sufficient for
some use cases, but not all. A later patch will relax this restriction,
but it will require introducing key hashes, among other changes.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
key = ci->ci_master_key;
|
|
|
|
|
if (key) {
|
|
|
|
|
struct fscrypt_master_key *mk = key->payload.data[0];
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Remove this inode from the list of inodes that were unlocked
|
|
|
|
|
* with the master key.
|
|
|
|
|
*
|
|
|
|
|
* In addition, if we're removing the last inode from a key that
|
|
|
|
|
* already had its secret removed, invalidate the key so that it
|
|
|
|
|
* gets removed from ->s_master_keys.
|
|
|
|
|
*/
|
|
|
|
|
spin_lock(&mk->mk_decrypted_inodes_lock);
|
|
|
|
|
list_del(&ci->ci_master_key_link);
|
|
|
|
|
spin_unlock(&mk->mk_decrypted_inodes_lock);
|
|
|
|
|
if (refcount_dec_and_test(&mk->mk_refcount))
|
|
|
|
|
key_invalidate(key);
|
|
|
|
|
key_put(key);
|
|
|
|
|
}
|
|
|
|
|
memzero_explicit(ci, sizeof(*ci));
|
fscrypt: add Adiantum support / removed speck
Add support for the Adiantum encryption mode to fscrypt. Adiantum is a
tweakable, length-preserving encryption mode with security provably
reducible to that of XChaCha12 and AES-256, subject to a security bound.
It's also a true wide-block mode, unlike XTS. See the paper
"Adiantum: length-preserving encryption for entry-level processors"
(https://eprint.iacr.org/2018/720.pdf) for more details. Also see
commit 059c2a4d8e16 ("crypto: adiantum - add Adiantum support").
On sufficiently long messages, Adiantum's bottlenecks are XChaCha12 and
the NH hash function. These algorithms are fast even on processors
without dedicated crypto instructions. Adiantum makes it feasible to
enable storage encryption on low-end mobile devices that lack AES
instructions; currently such devices are unencrypted. On ARM Cortex-A7,
on 4096-byte messages Adiantum encryption is about 4 times faster than
AES-256-XTS encryption; decryption is about 5 times faster.
In fscrypt, Adiantum is suitable for encrypting both file contents and
names. With filenames, it fixes a known weakness: when two filenames in
a directory share a common prefix of >= 16 bytes, with CTS-CBC their
encrypted filenames share a common prefix too, leaking information.
Adiantum does not have this problem.
Since Adiantum also accepts long tweaks (IVs), it's also safe to use the
master key directly for Adiantum encryption rather than deriving
per-file keys, provided that the per-file nonce is included in the IVs
and the master key isn't used for any other encryption mode. This
configuration saves memory and improves performance. A new fscrypt
policy flag is added to allow users to opt-in to this configuration.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
6 years ago
|
|
|
kmem_cache_free(fscrypt_info_cachep, ci);
|
|
|
|
|
}
|
|
|
|
|
|
fscrypt: remove broken support for detecting keyring key revocation
Filesystem encryption ostensibly supported revoking a keyring key that
had been used to "unlock" encrypted files, causing those files to become
"locked" again. This was, however, buggy for several reasons, the most
severe of which was that when key revocation happened to be detected for
an inode, its fscrypt_info was immediately freed, even while other
threads could be using it for encryption or decryption concurrently.
This could be exploited to crash the kernel or worse.
This patch fixes the use-after-free by removing the code which detects
the keyring key having been revoked, invalidated, or expired. Instead,
an encrypted inode that is "unlocked" now simply remains unlocked until
it is evicted from memory. Note that this is no worse than the case for
block device-level encryption, e.g. dm-crypt, and it still remains
possible for a privileged user to evict unused pages, inodes, and
dentries by running 'sync; echo 3 > /proc/sys/vm/drop_caches', or by
simply unmounting the filesystem. In fact, one of those actions was
already needed anyway for key revocation to work even somewhat sanely.
This change is not expected to break any applications.
In the future I'd like to implement a real API for fscrypt key
revocation that interacts sanely with ongoing filesystem operations ---
waiting for existing operations to complete and blocking new operations,
and invalidating and sanitizing key material and plaintext from the VFS
caches. But this is a hard problem, and for now this bug must be fixed.
This bug affected almost all versions of ext4, f2fs, and ubifs
encryption, and it was potentially reachable in any kernel configured
with encryption support (CONFIG_EXT4_ENCRYPTION=y,
CONFIG_EXT4_FS_ENCRYPTION=y, CONFIG_F2FS_FS_ENCRYPTION=y, or
CONFIG_UBIFS_FS_ENCRYPTION=y). Note that older kernels did not use the
shared fs/crypto/ code, but due to the potential security implications
of this bug, it may still be worthwhile to backport this fix to them.
Fixes: b7236e21d55f ("ext4 crypto: reorganize how we store keys in the inode")
Cc: stable@vger.kernel.org # v4.2+
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Acked-by: Michael Halcrow <mhalcrow@google.com>
8 years ago
|
|
|
int fscrypt_get_encryption_info(struct inode *inode)
|
|
|
|
|
{
|
|
|
|
|
struct fscrypt_info *crypt_info;
|
fscrypt: v2 encryption policy support
Add a new fscrypt policy version, "v2". It has the following changes
from the original policy version, which we call "v1" (*):
- Master keys (the user-provided encryption keys) are only ever used as
input to HKDF-SHA512. This is more flexible and less error-prone, and
it avoids the quirks and limitations of the AES-128-ECB based KDF.
Three classes of cryptographically isolated subkeys are defined:
- Per-file keys, like used in v1 policies except for the new KDF.
- Per-mode keys. These implement the semantics of the DIRECT_KEY
flag, which for v1 policies made the master key be used directly.
These are also planned to be used for inline encryption when
support for it is added.
- Key identifiers (see below).
- Each master key is identified by a 16-byte master_key_identifier,
which is derived from the key itself using HKDF-SHA512. This prevents
users from associating the wrong key with an encrypted file or
directory. This was easily possible with v1 policies, which
identified the key by an arbitrary 8-byte master_key_descriptor.
- The key must be provided in the filesystem-level keyring, not in a
process-subscribed keyring.
The following UAPI additions are made:
- The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
- A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
getting the v1 or v2 encryption policy of an encrypted file or
directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
be used because it did not have a way for userspace to indicate which
policy structure is expected. The new ioctl includes a size field, so
it is extensible to future fscrypt policy versions.
- The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
encryption policies. Such keys are kept logically separate from keys
for v1 encryption policies, and are identified by 'identifier' rather
than by 'descriptor'. The 'identifier' need not be provided when
adding a key, since the kernel will calculate it anyway.
This patch temporarily keeps adding/removing v2 policy keys behind the
same permission check done for adding/removing v1 policy keys:
capable(CAP_SYS_ADMIN). However, the next patch will carefully take
advantage of the cryptographically secure master_key_identifier to allow
non-root users to add/remove v2 policy keys, thus providing a full
replacement for v1 policies.
(*) Actually, in the API fscrypt_policy::version is 0 while on-disk
fscrypt_context::format is 1. But I believe it makes the most sense
to advance both to '2' to have them be in sync, and to consider the
numbering to start at 1 except for the API quirk.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
union fscrypt_context ctx;
|
|
|
|
|
struct fscrypt_mode *mode;
|
fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl
Add a new fscrypt ioctl, FS_IOC_REMOVE_ENCRYPTION_KEY. This ioctl
removes an encryption key that was added by FS_IOC_ADD_ENCRYPTION_KEY.
It wipes the secret key itself, then "locks" the encrypted files and
directories that had been unlocked using that key -- implemented by
evicting the relevant dentries and inodes from the VFS caches.
The problem this solves is that many fscrypt users want the ability to
remove encryption keys, causing the corresponding encrypted directories
to appear "locked" (presented in ciphertext form) again. Moreover,
users want removing an encryption key to *really* remove it, in the
sense that the removed keys cannot be recovered even if kernel memory is
compromised, e.g. by the exploit of a kernel security vulnerability or
by a physical attack. This is desirable after a user logs out of the
system, for example. In many cases users even already assume this to be
the case and are surprised to hear when it's not.
It is not sufficient to simply unlink the master key from the keyring
(or to revoke or invalidate it), since the actual encryption transform
objects are still pinned in memory by their inodes. Therefore, to
really remove a key we must also evict the relevant inodes.
Currently one workaround is to run 'sync && echo 2 >
/proc/sys/vm/drop_caches'. But, that evicts all unused inodes in the
system rather than just the inodes associated with the key being
removed, causing severe performance problems. Moreover, it requires
root privileges, so regular users can't "lock" their encrypted files.
Another workaround, used in Chromium OS kernels, is to add a new
VFS-level ioctl FS_IOC_DROP_CACHE which is a more restricted version of
drop_caches that operates on a single super_block. It does:
shrink_dcache_sb(sb);
invalidate_inodes(sb, false);
But it's still a hack. Yet, the major users of filesystem encryption
want this feature badly enough that they are actually using these hacks.
To properly solve the problem, start maintaining a list of the inodes
which have been "unlocked" using each master key. Originally this
wasn't possible because the kernel didn't keep track of in-use master
keys at all. But, with the ->s_master_keys keyring it is now possible.
Then, add an ioctl FS_IOC_REMOVE_ENCRYPTION_KEY. It finds the specified
master key in ->s_master_keys, then wipes the secret key itself, which
prevents any additional inodes from being unlocked with the key. Then,
it syncs the filesystem and evicts the inodes in the key's list. The
normal inode eviction code will free and wipe the per-file keys (in
->i_crypt_info). Note that freeing ->i_crypt_info without evicting the
inodes was also considered, but would have been racy.
Some inodes may still be in use when a master key is removed, and we
can't simply revoke random file descriptors, mmap's, etc. Thus, the
ioctl simply skips in-use inodes, and returns -EBUSY to indicate that
some inodes weren't evicted. The master key *secret* is still removed,
but the fscrypt_master_key struct remains to keep track of the remaining
inodes. Userspace can then retry the ioctl to evict the remaining
inodes. Alternatively, if userspace adds the key again, the refreshed
secret will be associated with the existing list of inodes so they
remain correctly tracked for future key removals.
The ioctl doesn't wipe pagecache pages. Thus, we tolerate that after a
kernel compromise some portions of plaintext file contents may still be
recoverable from memory. This can be solved by enabling page poisoning
system-wide, which security conscious users may choose to do. But it's
very difficult to solve otherwise, e.g. note that plaintext file
contents may have been read in other places than pagecache pages.
Like FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY is
initially restricted to privileged users only. This is sufficient for
some use cases, but not all. A later patch will relax this restriction,
but it will require introducing key hashes, among other changes.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
struct key *master_key = NULL;
|
|
|
|
|
int res;
|
|
|
|
|
|
|
|
|
|
if (fscrypt_has_encryption_key(inode))
|
fscrypt: remove broken support for detecting keyring key revocation
Filesystem encryption ostensibly supported revoking a keyring key that
had been used to "unlock" encrypted files, causing those files to become
"locked" again. This was, however, buggy for several reasons, the most
severe of which was that when key revocation happened to be detected for
an inode, its fscrypt_info was immediately freed, even while other
threads could be using it for encryption or decryption concurrently.
This could be exploited to crash the kernel or worse.
This patch fixes the use-after-free by removing the code which detects
the keyring key having been revoked, invalidated, or expired. Instead,
an encrypted inode that is "unlocked" now simply remains unlocked until
it is evicted from memory. Note that this is no worse than the case for
block device-level encryption, e.g. dm-crypt, and it still remains
possible for a privileged user to evict unused pages, inodes, and
dentries by running 'sync; echo 3 > /proc/sys/vm/drop_caches', or by
simply unmounting the filesystem. In fact, one of those actions was
already needed anyway for key revocation to work even somewhat sanely.
This change is not expected to break any applications.
In the future I'd like to implement a real API for fscrypt key
revocation that interacts sanely with ongoing filesystem operations ---
waiting for existing operations to complete and blocking new operations,
and invalidating and sanitizing key material and plaintext from the VFS
caches. But this is a hard problem, and for now this bug must be fixed.
This bug affected almost all versions of ext4, f2fs, and ubifs
encryption, and it was potentially reachable in any kernel configured
with encryption support (CONFIG_EXT4_ENCRYPTION=y,
CONFIG_EXT4_FS_ENCRYPTION=y, CONFIG_F2FS_FS_ENCRYPTION=y, or
CONFIG_UBIFS_FS_ENCRYPTION=y). Note that older kernels did not use the
shared fs/crypto/ code, but due to the potential security implications
of this bug, it may still be worthwhile to backport this fix to them.
Fixes: b7236e21d55f ("ext4 crypto: reorganize how we store keys in the inode")
Cc: stable@vger.kernel.org # v4.2+
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Acked-by: Michael Halcrow <mhalcrow@google.com>
8 years ago
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
res = fscrypt_initialize(inode->i_sb->s_cop->flags);
|
|
|
|
|
if (res)
|
|
|
|
|
return res;
|
|
|
|
|
|
|
|
|
|
res = inode->i_sb->s_cop->get_context(inode, &ctx, sizeof(ctx));
|
|
|
|
|
if (res < 0) {
|
fscrypt: support test_dummy_encryption=v2
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 <jaegeuk@kernel.org>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
const union fscrypt_context *dummy_ctx =
|
|
|
|
|
fscrypt_get_dummy_context(inode->i_sb);
|
|
|
|
|
|
|
|
|
|
if (IS_ENCRYPTED(inode) || !dummy_ctx) {
|
|
|
|
|
fscrypt_warn(inode,
|
|
|
|
|
"Error %d getting encryption context",
|
|
|
|
|
res);
|
|
|
|
|
return res;
|
|
|
|
|
}
|
|
|
|
|
/* Fake up a context for an unencrypted directory */
|
fscrypt: support test_dummy_encryption=v2
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 <jaegeuk@kernel.org>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
res = fscrypt_context_size(dummy_ctx);
|
|
|
|
|
memcpy(&ctx, dummy_ctx, res);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#if defined(CONFIG_FSCRYPT_SDP) || defined(CONFIG_DDAR)
|
|
|
|
|
switch (ctx.version) {
|
|
|
|
|
case FSCRYPT_CONTEXT_V1: {
|
|
|
|
|
if (res == offsetof(struct fscrypt_context_v1, knox_flags)) {
|
|
|
|
|
ctx.v1.knox_flags = 0;
|
|
|
|
|
res = sizeof(ctx.v1);
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case FSCRYPT_CONTEXT_V2: {
|
|
|
|
|
if (res == offsetof(struct fscrypt_context_v2, knox_flags)) {
|
|
|
|
|
ctx.v2.knox_flags = 0;
|
|
|
|
|
res = sizeof(ctx.v2);
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
fscrypt: add Adiantum support / removed speck
Add support for the Adiantum encryption mode to fscrypt. Adiantum is a
tweakable, length-preserving encryption mode with security provably
reducible to that of XChaCha12 and AES-256, subject to a security bound.
It's also a true wide-block mode, unlike XTS. See the paper
"Adiantum: length-preserving encryption for entry-level processors"
(https://eprint.iacr.org/2018/720.pdf) for more details. Also see
commit 059c2a4d8e16 ("crypto: adiantum - add Adiantum support").
On sufficiently long messages, Adiantum's bottlenecks are XChaCha12 and
the NH hash function. These algorithms are fast even on processors
without dedicated crypto instructions. Adiantum makes it feasible to
enable storage encryption on low-end mobile devices that lack AES
instructions; currently such devices are unencrypted. On ARM Cortex-A7,
on 4096-byte messages Adiantum encryption is about 4 times faster than
AES-256-XTS encryption; decryption is about 5 times faster.
In fscrypt, Adiantum is suitable for encrypting both file contents and
names. With filenames, it fixes a known weakness: when two filenames in
a directory share a common prefix of >= 16 bytes, with CTS-CBC their
encrypted filenames share a common prefix too, leaking information.
Adiantum does not have this problem.
Since Adiantum also accepts long tweaks (IVs), it's also safe to use the
master key directly for Adiantum encryption rather than deriving
per-file keys, provided that the per-file nonce is included in the IVs
and the master key isn't used for any other encryption mode. This
configuration saves memory and improves performance. A new fscrypt
policy flag is added to allow users to opt-in to this configuration.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
6 years ago
|
|
|
crypt_info = kmem_cache_zalloc(fscrypt_info_cachep, GFP_NOFS);
|
|
|
|
|
if (!crypt_info)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_FSCRYPT_SDP
|
|
|
|
|
crypt_info->ci_sdp_info = NULL;
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
crypt_info->ci_inode = inode;
|
|
|
|
|
|
fscrypt: v2 encryption policy support
Add a new fscrypt policy version, "v2". It has the following changes
from the original policy version, which we call "v1" (*):
- Master keys (the user-provided encryption keys) are only ever used as
input to HKDF-SHA512. This is more flexible and less error-prone, and
it avoids the quirks and limitations of the AES-128-ECB based KDF.
Three classes of cryptographically isolated subkeys are defined:
- Per-file keys, like used in v1 policies except for the new KDF.
- Per-mode keys. These implement the semantics of the DIRECT_KEY
flag, which for v1 policies made the master key be used directly.
These are also planned to be used for inline encryption when
support for it is added.
- Key identifiers (see below).
- Each master key is identified by a 16-byte master_key_identifier,
which is derived from the key itself using HKDF-SHA512. This prevents
users from associating the wrong key with an encrypted file or
directory. This was easily possible with v1 policies, which
identified the key by an arbitrary 8-byte master_key_descriptor.
- The key must be provided in the filesystem-level keyring, not in a
process-subscribed keyring.
The following UAPI additions are made:
- The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
- A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
getting the v1 or v2 encryption policy of an encrypted file or
directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
be used because it did not have a way for userspace to indicate which
policy structure is expected. The new ioctl includes a size field, so
it is extensible to future fscrypt policy versions.
- The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
encryption policies. Such keys are kept logically separate from keys
for v1 encryption policies, and are identified by 'identifier' rather
than by 'descriptor'. The 'identifier' need not be provided when
adding a key, since the kernel will calculate it anyway.
This patch temporarily keeps adding/removing v2 policy keys behind the
same permission check done for adding/removing v1 policy keys:
capable(CAP_SYS_ADMIN). However, the next patch will carefully take
advantage of the cryptographically secure master_key_identifier to allow
non-root users to add/remove v2 policy keys, thus providing a full
replacement for v1 policies.
(*) Actually, in the API fscrypt_policy::version is 0 while on-disk
fscrypt_context::format is 1. But I believe it makes the most sense
to advance both to '2' to have them be in sync, and to consider the
numbering to start at 1 except for the API quirk.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
res = fscrypt_policy_from_context(&crypt_info->ci_policy, &ctx, res);
|
|
|
|
|
if (res) {
|
|
|
|
|
fscrypt_warn(inode,
|
|
|
|
|
"Unrecognized or corrupt encryption context");
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
memcpy(crypt_info->ci_nonce, fscrypt_context_nonce(&ctx),
|
|
|
|
|
FS_KEY_DERIVATION_NONCE_SIZE);
|
fscrypt: v2 encryption policy support
Add a new fscrypt policy version, "v2". It has the following changes
from the original policy version, which we call "v1" (*):
- Master keys (the user-provided encryption keys) are only ever used as
input to HKDF-SHA512. This is more flexible and less error-prone, and
it avoids the quirks and limitations of the AES-128-ECB based KDF.
Three classes of cryptographically isolated subkeys are defined:
- Per-file keys, like used in v1 policies except for the new KDF.
- Per-mode keys. These implement the semantics of the DIRECT_KEY
flag, which for v1 policies made the master key be used directly.
These are also planned to be used for inline encryption when
support for it is added.
- Key identifiers (see below).
- Each master key is identified by a 16-byte master_key_identifier,
which is derived from the key itself using HKDF-SHA512. This prevents
users from associating the wrong key with an encrypted file or
directory. This was easily possible with v1 policies, which
identified the key by an arbitrary 8-byte master_key_descriptor.
- The key must be provided in the filesystem-level keyring, not in a
process-subscribed keyring.
The following UAPI additions are made:
- The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
- A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
getting the v1 or v2 encryption policy of an encrypted file or
directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
be used because it did not have a way for userspace to indicate which
policy structure is expected. The new ioctl includes a size field, so
it is extensible to future fscrypt policy versions.
- The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
encryption policies. Such keys are kept logically separate from keys
for v1 encryption policies, and are identified by 'identifier' rather
than by 'descriptor'. The 'identifier' need not be provided when
adding a key, since the kernel will calculate it anyway.
This patch temporarily keeps adding/removing v2 policy keys behind the
same permission check done for adding/removing v1 policy keys:
capable(CAP_SYS_ADMIN). However, the next patch will carefully take
advantage of the cryptographically secure master_key_identifier to allow
non-root users to add/remove v2 policy keys, thus providing a full
replacement for v1 policies.
(*) Actually, in the API fscrypt_policy::version is 0 while on-disk
fscrypt_context::format is 1. But I believe it makes the most sense
to advance both to '2' to have them be in sync, and to consider the
numbering to start at 1 except for the API quirk.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
|
|
|
|
|
if (!fscrypt_supported_policy(&crypt_info->ci_policy, inode)) {
|
|
|
|
|
res = -EINVAL;
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
|
fscrypt: v2 encryption policy support
Add a new fscrypt policy version, "v2". It has the following changes
from the original policy version, which we call "v1" (*):
- Master keys (the user-provided encryption keys) are only ever used as
input to HKDF-SHA512. This is more flexible and less error-prone, and
it avoids the quirks and limitations of the AES-128-ECB based KDF.
Three classes of cryptographically isolated subkeys are defined:
- Per-file keys, like used in v1 policies except for the new KDF.
- Per-mode keys. These implement the semantics of the DIRECT_KEY
flag, which for v1 policies made the master key be used directly.
These are also planned to be used for inline encryption when
support for it is added.
- Key identifiers (see below).
- Each master key is identified by a 16-byte master_key_identifier,
which is derived from the key itself using HKDF-SHA512. This prevents
users from associating the wrong key with an encrypted file or
directory. This was easily possible with v1 policies, which
identified the key by an arbitrary 8-byte master_key_descriptor.
- The key must be provided in the filesystem-level keyring, not in a
process-subscribed keyring.
The following UAPI additions are made:
- The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
- A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
getting the v1 or v2 encryption policy of an encrypted file or
directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
be used because it did not have a way for userspace to indicate which
policy structure is expected. The new ioctl includes a size field, so
it is extensible to future fscrypt policy versions.
- The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
encryption policies. Such keys are kept logically separate from keys
for v1 encryption policies, and are identified by 'identifier' rather
than by 'descriptor'. The 'identifier' need not be provided when
adding a key, since the kernel will calculate it anyway.
This patch temporarily keeps adding/removing v2 policy keys behind the
same permission check done for adding/removing v1 policy keys:
capable(CAP_SYS_ADMIN). However, the next patch will carefully take
advantage of the cryptographically secure master_key_identifier to allow
non-root users to add/remove v2 policy keys, thus providing a full
replacement for v1 policies.
(*) Actually, in the API fscrypt_policy::version is 0 while on-disk
fscrypt_context::format is 1. But I believe it makes the most sense
to advance both to '2' to have them be in sync, and to consider the
numbering to start at 1 except for the API quirk.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
mode = select_encryption_mode(&crypt_info->ci_policy, inode);
|
|
|
|
|
if (IS_ERR(mode)) {
|
|
|
|
|
res = PTR_ERR(mode);
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
fscrypt: add Adiantum support / removed speck
Add support for the Adiantum encryption mode to fscrypt. Adiantum is a
tweakable, length-preserving encryption mode with security provably
reducible to that of XChaCha12 and AES-256, subject to a security bound.
It's also a true wide-block mode, unlike XTS. See the paper
"Adiantum: length-preserving encryption for entry-level processors"
(https://eprint.iacr.org/2018/720.pdf) for more details. Also see
commit 059c2a4d8e16 ("crypto: adiantum - add Adiantum support").
On sufficiently long messages, Adiantum's bottlenecks are XChaCha12 and
the NH hash function. These algorithms are fast even on processors
without dedicated crypto instructions. Adiantum makes it feasible to
enable storage encryption on low-end mobile devices that lack AES
instructions; currently such devices are unencrypted. On ARM Cortex-A7,
on 4096-byte messages Adiantum encryption is about 4 times faster than
AES-256-XTS encryption; decryption is about 5 times faster.
In fscrypt, Adiantum is suitable for encrypting both file contents and
names. With filenames, it fixes a known weakness: when two filenames in
a directory share a common prefix of >= 16 bytes, with CTS-CBC their
encrypted filenames share a common prefix too, leaking information.
Adiantum does not have this problem.
Since Adiantum also accepts long tweaks (IVs), it's also safe to use the
master key directly for Adiantum encryption rather than deriving
per-file keys, provided that the per-file nonce is included in the IVs
and the master key isn't used for any other encryption mode. This
configuration saves memory and improves performance. A new fscrypt
policy flag is added to allow users to opt-in to this configuration.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
6 years ago
|
|
|
WARN_ON(mode->ivsize > FSCRYPT_MAX_IV_SIZE);
|
|
|
|
|
crypt_info->ci_mode = mode;
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_FSCRYPT_SDP
|
|
|
|
|
if (fscrypt_sdp_protected(&ctx)) {
|
|
|
|
|
crypt_info->ci_sdp_info = fscrypt_sdp_alloc_sdp_info();
|
|
|
|
|
if (!crypt_info->ci_sdp_info) {
|
|
|
|
|
res = -ENOMEM;
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
res = fscrypt_sdp_update_sdp_info(inode, &ctx, crypt_info);
|
|
|
|
|
if (res)
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl
Add a new fscrypt ioctl, FS_IOC_REMOVE_ENCRYPTION_KEY. This ioctl
removes an encryption key that was added by FS_IOC_ADD_ENCRYPTION_KEY.
It wipes the secret key itself, then "locks" the encrypted files and
directories that had been unlocked using that key -- implemented by
evicting the relevant dentries and inodes from the VFS caches.
The problem this solves is that many fscrypt users want the ability to
remove encryption keys, causing the corresponding encrypted directories
to appear "locked" (presented in ciphertext form) again. Moreover,
users want removing an encryption key to *really* remove it, in the
sense that the removed keys cannot be recovered even if kernel memory is
compromised, e.g. by the exploit of a kernel security vulnerability or
by a physical attack. This is desirable after a user logs out of the
system, for example. In many cases users even already assume this to be
the case and are surprised to hear when it's not.
It is not sufficient to simply unlink the master key from the keyring
(or to revoke or invalidate it), since the actual encryption transform
objects are still pinned in memory by their inodes. Therefore, to
really remove a key we must also evict the relevant inodes.
Currently one workaround is to run 'sync && echo 2 >
/proc/sys/vm/drop_caches'. But, that evicts all unused inodes in the
system rather than just the inodes associated with the key being
removed, causing severe performance problems. Moreover, it requires
root privileges, so regular users can't "lock" their encrypted files.
Another workaround, used in Chromium OS kernels, is to add a new
VFS-level ioctl FS_IOC_DROP_CACHE which is a more restricted version of
drop_caches that operates on a single super_block. It does:
shrink_dcache_sb(sb);
invalidate_inodes(sb, false);
But it's still a hack. Yet, the major users of filesystem encryption
want this feature badly enough that they are actually using these hacks.
To properly solve the problem, start maintaining a list of the inodes
which have been "unlocked" using each master key. Originally this
wasn't possible because the kernel didn't keep track of in-use master
keys at all. But, with the ->s_master_keys keyring it is now possible.
Then, add an ioctl FS_IOC_REMOVE_ENCRYPTION_KEY. It finds the specified
master key in ->s_master_keys, then wipes the secret key itself, which
prevents any additional inodes from being unlocked with the key. Then,
it syncs the filesystem and evicts the inodes in the key's list. The
normal inode eviction code will free and wipe the per-file keys (in
->i_crypt_info). Note that freeing ->i_crypt_info without evicting the
inodes was also considered, but would have been racy.
Some inodes may still be in use when a master key is removed, and we
can't simply revoke random file descriptors, mmap's, etc. Thus, the
ioctl simply skips in-use inodes, and returns -EBUSY to indicate that
some inodes weren't evicted. The master key *secret* is still removed,
but the fscrypt_master_key struct remains to keep track of the remaining
inodes. Userspace can then retry the ioctl to evict the remaining
inodes. Alternatively, if userspace adds the key again, the refreshed
secret will be associated with the existing list of inodes so they
remain correctly tracked for future key removals.
The ioctl doesn't wipe pagecache pages. Thus, we tolerate that after a
kernel compromise some portions of plaintext file contents may still be
recoverable from memory. This can be solved by enabling page poisoning
system-wide, which security conscious users may choose to do. But it's
very difficult to solve otherwise, e.g. note that plaintext file
contents may have been read in other places than pagecache pages.
Like FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY is
initially restricted to privileged users only. This is sufficient for
some use cases, but not all. A later patch will relax this restriction,
but it will require introducing key hashes, among other changes.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
res = setup_file_encryption_key(crypt_info, &master_key);
|
|
|
|
|
if (res)
|
|
|
|
|
goto out;
|
|
|
|
|
|
fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl
Add a new fscrypt ioctl, FS_IOC_REMOVE_ENCRYPTION_KEY. This ioctl
removes an encryption key that was added by FS_IOC_ADD_ENCRYPTION_KEY.
It wipes the secret key itself, then "locks" the encrypted files and
directories that had been unlocked using that key -- implemented by
evicting the relevant dentries and inodes from the VFS caches.
The problem this solves is that many fscrypt users want the ability to
remove encryption keys, causing the corresponding encrypted directories
to appear "locked" (presented in ciphertext form) again. Moreover,
users want removing an encryption key to *really* remove it, in the
sense that the removed keys cannot be recovered even if kernel memory is
compromised, e.g. by the exploit of a kernel security vulnerability or
by a physical attack. This is desirable after a user logs out of the
system, for example. In many cases users even already assume this to be
the case and are surprised to hear when it's not.
It is not sufficient to simply unlink the master key from the keyring
(or to revoke or invalidate it), since the actual encryption transform
objects are still pinned in memory by their inodes. Therefore, to
really remove a key we must also evict the relevant inodes.
Currently one workaround is to run 'sync && echo 2 >
/proc/sys/vm/drop_caches'. But, that evicts all unused inodes in the
system rather than just the inodes associated with the key being
removed, causing severe performance problems. Moreover, it requires
root privileges, so regular users can't "lock" their encrypted files.
Another workaround, used in Chromium OS kernels, is to add a new
VFS-level ioctl FS_IOC_DROP_CACHE which is a more restricted version of
drop_caches that operates on a single super_block. It does:
shrink_dcache_sb(sb);
invalidate_inodes(sb, false);
But it's still a hack. Yet, the major users of filesystem encryption
want this feature badly enough that they are actually using these hacks.
To properly solve the problem, start maintaining a list of the inodes
which have been "unlocked" using each master key. Originally this
wasn't possible because the kernel didn't keep track of in-use master
keys at all. But, with the ->s_master_keys keyring it is now possible.
Then, add an ioctl FS_IOC_REMOVE_ENCRYPTION_KEY. It finds the specified
master key in ->s_master_keys, then wipes the secret key itself, which
prevents any additional inodes from being unlocked with the key. Then,
it syncs the filesystem and evicts the inodes in the key's list. The
normal inode eviction code will free and wipe the per-file keys (in
->i_crypt_info). Note that freeing ->i_crypt_info without evicting the
inodes was also considered, but would have been racy.
Some inodes may still be in use when a master key is removed, and we
can't simply revoke random file descriptors, mmap's, etc. Thus, the
ioctl simply skips in-use inodes, and returns -EBUSY to indicate that
some inodes weren't evicted. The master key *secret* is still removed,
but the fscrypt_master_key struct remains to keep track of the remaining
inodes. Userspace can then retry the ioctl to evict the remaining
inodes. Alternatively, if userspace adds the key again, the refreshed
secret will be associated with the existing list of inodes so they
remain correctly tracked for future key removals.
The ioctl doesn't wipe pagecache pages. Thus, we tolerate that after a
kernel compromise some portions of plaintext file contents may still be
recoverable from memory. This can be solved by enabling page poisoning
system-wide, which security conscious users may choose to do. But it's
very difficult to solve otherwise, e.g. note that plaintext file
contents may have been read in other places than pagecache pages.
Like FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY is
initially restricted to privileged users only. This is sufficient for
some use cases, but not all. A later patch will relax this restriction,
but it will require introducing key hashes, among other changes.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
if (cmpxchg_release(&inode->i_crypt_info, NULL, crypt_info) == NULL) {
|
|
|
|
|
if (master_key) {
|
|
|
|
|
struct fscrypt_master_key *mk =
|
|
|
|
|
master_key->payload.data[0];
|
|
|
|
|
|
|
|
|
|
refcount_inc(&mk->mk_refcount);
|
|
|
|
|
crypt_info->ci_master_key = key_get(master_key);
|
|
|
|
|
spin_lock(&mk->mk_decrypted_inodes_lock);
|
|
|
|
|
list_add(&crypt_info->ci_master_key_link,
|
|
|
|
|
&mk->mk_decrypted_inodes);
|
|
|
|
|
spin_unlock(&mk->mk_decrypted_inodes_lock);
|
|
|
|
|
}
|
fscrypt: remove broken support for detecting keyring key revocation
Filesystem encryption ostensibly supported revoking a keyring key that
had been used to "unlock" encrypted files, causing those files to become
"locked" again. This was, however, buggy for several reasons, the most
severe of which was that when key revocation happened to be detected for
an inode, its fscrypt_info was immediately freed, even while other
threads could be using it for encryption or decryption concurrently.
This could be exploited to crash the kernel or worse.
This patch fixes the use-after-free by removing the code which detects
the keyring key having been revoked, invalidated, or expired. Instead,
an encrypted inode that is "unlocked" now simply remains unlocked until
it is evicted from memory. Note that this is no worse than the case for
block device-level encryption, e.g. dm-crypt, and it still remains
possible for a privileged user to evict unused pages, inodes, and
dentries by running 'sync; echo 3 > /proc/sys/vm/drop_caches', or by
simply unmounting the filesystem. In fact, one of those actions was
already needed anyway for key revocation to work even somewhat sanely.
This change is not expected to break any applications.
In the future I'd like to implement a real API for fscrypt key
revocation that interacts sanely with ongoing filesystem operations ---
waiting for existing operations to complete and blocking new operations,
and invalidating and sanitizing key material and plaintext from the VFS
caches. But this is a hard problem, and for now this bug must be fixed.
This bug affected almost all versions of ext4, f2fs, and ubifs
encryption, and it was potentially reachable in any kernel configured
with encryption support (CONFIG_EXT4_ENCRYPTION=y,
CONFIG_EXT4_FS_ENCRYPTION=y, CONFIG_F2FS_FS_ENCRYPTION=y, or
CONFIG_UBIFS_FS_ENCRYPTION=y). Note that older kernels did not use the
shared fs/crypto/ code, but due to the potential security implications
of this bug, it may still be worthwhile to backport this fix to them.
Fixes: b7236e21d55f ("ext4 crypto: reorganize how we store keys in the inode")
Cc: stable@vger.kernel.org # v4.2+
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Acked-by: Michael Halcrow <mhalcrow@google.com>
8 years ago
|
|
|
crypt_info = NULL;
|
fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl
Add a new fscrypt ioctl, FS_IOC_REMOVE_ENCRYPTION_KEY. This ioctl
removes an encryption key that was added by FS_IOC_ADD_ENCRYPTION_KEY.
It wipes the secret key itself, then "locks" the encrypted files and
directories that had been unlocked using that key -- implemented by
evicting the relevant dentries and inodes from the VFS caches.
The problem this solves is that many fscrypt users want the ability to
remove encryption keys, causing the corresponding encrypted directories
to appear "locked" (presented in ciphertext form) again. Moreover,
users want removing an encryption key to *really* remove it, in the
sense that the removed keys cannot be recovered even if kernel memory is
compromised, e.g. by the exploit of a kernel security vulnerability or
by a physical attack. This is desirable after a user logs out of the
system, for example. In many cases users even already assume this to be
the case and are surprised to hear when it's not.
It is not sufficient to simply unlink the master key from the keyring
(or to revoke or invalidate it), since the actual encryption transform
objects are still pinned in memory by their inodes. Therefore, to
really remove a key we must also evict the relevant inodes.
Currently one workaround is to run 'sync && echo 2 >
/proc/sys/vm/drop_caches'. But, that evicts all unused inodes in the
system rather than just the inodes associated with the key being
removed, causing severe performance problems. Moreover, it requires
root privileges, so regular users can't "lock" their encrypted files.
Another workaround, used in Chromium OS kernels, is to add a new
VFS-level ioctl FS_IOC_DROP_CACHE which is a more restricted version of
drop_caches that operates on a single super_block. It does:
shrink_dcache_sb(sb);
invalidate_inodes(sb, false);
But it's still a hack. Yet, the major users of filesystem encryption
want this feature badly enough that they are actually using these hacks.
To properly solve the problem, start maintaining a list of the inodes
which have been "unlocked" using each master key. Originally this
wasn't possible because the kernel didn't keep track of in-use master
keys at all. But, with the ->s_master_keys keyring it is now possible.
Then, add an ioctl FS_IOC_REMOVE_ENCRYPTION_KEY. It finds the specified
master key in ->s_master_keys, then wipes the secret key itself, which
prevents any additional inodes from being unlocked with the key. Then,
it syncs the filesystem and evicts the inodes in the key's list. The
normal inode eviction code will free and wipe the per-file keys (in
->i_crypt_info). Note that freeing ->i_crypt_info without evicting the
inodes was also considered, but would have been racy.
Some inodes may still be in use when a master key is removed, and we
can't simply revoke random file descriptors, mmap's, etc. Thus, the
ioctl simply skips in-use inodes, and returns -EBUSY to indicate that
some inodes weren't evicted. The master key *secret* is still removed,
but the fscrypt_master_key struct remains to keep track of the remaining
inodes. Userspace can then retry the ioctl to evict the remaining
inodes. Alternatively, if userspace adds the key again, the refreshed
secret will be associated with the existing list of inodes so they
remain correctly tracked for future key removals.
The ioctl doesn't wipe pagecache pages. Thus, we tolerate that after a
kernel compromise some portions of plaintext file contents may still be
recoverable from memory. This can be solved by enabling page poisoning
system-wide, which security conscious users may choose to do. But it's
very difficult to solve otherwise, e.g. note that plaintext file
contents may have been read in other places than pagecache pages.
Like FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY is
initially restricted to privileged users only. This is sufficient for
some use cases, but not all. A later patch will relax this restriction,
but it will require introducing key hashes, among other changes.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
}
|
|
|
|
|
#ifdef CONFIG_FSCRYPT_SDP
|
|
|
|
|
if (crypt_info == NULL) //Call only when i_crypt_info is loaded initially
|
|
|
|
|
fscrypt_sdp_finalize_tasks(inode);
|
|
|
|
|
#endif
|
fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl
Add a new fscrypt ioctl, FS_IOC_REMOVE_ENCRYPTION_KEY. This ioctl
removes an encryption key that was added by FS_IOC_ADD_ENCRYPTION_KEY.
It wipes the secret key itself, then "locks" the encrypted files and
directories that had been unlocked using that key -- implemented by
evicting the relevant dentries and inodes from the VFS caches.
The problem this solves is that many fscrypt users want the ability to
remove encryption keys, causing the corresponding encrypted directories
to appear "locked" (presented in ciphertext form) again. Moreover,
users want removing an encryption key to *really* remove it, in the
sense that the removed keys cannot be recovered even if kernel memory is
compromised, e.g. by the exploit of a kernel security vulnerability or
by a physical attack. This is desirable after a user logs out of the
system, for example. In many cases users even already assume this to be
the case and are surprised to hear when it's not.
It is not sufficient to simply unlink the master key from the keyring
(or to revoke or invalidate it), since the actual encryption transform
objects are still pinned in memory by their inodes. Therefore, to
really remove a key we must also evict the relevant inodes.
Currently one workaround is to run 'sync && echo 2 >
/proc/sys/vm/drop_caches'. But, that evicts all unused inodes in the
system rather than just the inodes associated with the key being
removed, causing severe performance problems. Moreover, it requires
root privileges, so regular users can't "lock" their encrypted files.
Another workaround, used in Chromium OS kernels, is to add a new
VFS-level ioctl FS_IOC_DROP_CACHE which is a more restricted version of
drop_caches that operates on a single super_block. It does:
shrink_dcache_sb(sb);
invalidate_inodes(sb, false);
But it's still a hack. Yet, the major users of filesystem encryption
want this feature badly enough that they are actually using these hacks.
To properly solve the problem, start maintaining a list of the inodes
which have been "unlocked" using each master key. Originally this
wasn't possible because the kernel didn't keep track of in-use master
keys at all. But, with the ->s_master_keys keyring it is now possible.
Then, add an ioctl FS_IOC_REMOVE_ENCRYPTION_KEY. It finds the specified
master key in ->s_master_keys, then wipes the secret key itself, which
prevents any additional inodes from being unlocked with the key. Then,
it syncs the filesystem and evicts the inodes in the key's list. The
normal inode eviction code will free and wipe the per-file keys (in
->i_crypt_info). Note that freeing ->i_crypt_info without evicting the
inodes was also considered, but would have been racy.
Some inodes may still be in use when a master key is removed, and we
can't simply revoke random file descriptors, mmap's, etc. Thus, the
ioctl simply skips in-use inodes, and returns -EBUSY to indicate that
some inodes weren't evicted. The master key *secret* is still removed,
but the fscrypt_master_key struct remains to keep track of the remaining
inodes. Userspace can then retry the ioctl to evict the remaining
inodes. Alternatively, if userspace adds the key again, the refreshed
secret will be associated with the existing list of inodes so they
remain correctly tracked for future key removals.
The ioctl doesn't wipe pagecache pages. Thus, we tolerate that after a
kernel compromise some portions of plaintext file contents may still be
recoverable from memory. This can be solved by enabling page poisoning
system-wide, which security conscious users may choose to do. But it's
very difficult to solve otherwise, e.g. note that plaintext file
contents may have been read in other places than pagecache pages.
Like FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY is
initially restricted to privileged users only. This is sufficient for
some use cases, but not all. A later patch will relax this restriction,
but it will require introducing key hashes, among other changes.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
res = 0;
|
|
|
|
|
out:
|
fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl
Add a new fscrypt ioctl, FS_IOC_REMOVE_ENCRYPTION_KEY. This ioctl
removes an encryption key that was added by FS_IOC_ADD_ENCRYPTION_KEY.
It wipes the secret key itself, then "locks" the encrypted files and
directories that had been unlocked using that key -- implemented by
evicting the relevant dentries and inodes from the VFS caches.
The problem this solves is that many fscrypt users want the ability to
remove encryption keys, causing the corresponding encrypted directories
to appear "locked" (presented in ciphertext form) again. Moreover,
users want removing an encryption key to *really* remove it, in the
sense that the removed keys cannot be recovered even if kernel memory is
compromised, e.g. by the exploit of a kernel security vulnerability or
by a physical attack. This is desirable after a user logs out of the
system, for example. In many cases users even already assume this to be
the case and are surprised to hear when it's not.
It is not sufficient to simply unlink the master key from the keyring
(or to revoke or invalidate it), since the actual encryption transform
objects are still pinned in memory by their inodes. Therefore, to
really remove a key we must also evict the relevant inodes.
Currently one workaround is to run 'sync && echo 2 >
/proc/sys/vm/drop_caches'. But, that evicts all unused inodes in the
system rather than just the inodes associated with the key being
removed, causing severe performance problems. Moreover, it requires
root privileges, so regular users can't "lock" their encrypted files.
Another workaround, used in Chromium OS kernels, is to add a new
VFS-level ioctl FS_IOC_DROP_CACHE which is a more restricted version of
drop_caches that operates on a single super_block. It does:
shrink_dcache_sb(sb);
invalidate_inodes(sb, false);
But it's still a hack. Yet, the major users of filesystem encryption
want this feature badly enough that they are actually using these hacks.
To properly solve the problem, start maintaining a list of the inodes
which have been "unlocked" using each master key. Originally this
wasn't possible because the kernel didn't keep track of in-use master
keys at all. But, with the ->s_master_keys keyring it is now possible.
Then, add an ioctl FS_IOC_REMOVE_ENCRYPTION_KEY. It finds the specified
master key in ->s_master_keys, then wipes the secret key itself, which
prevents any additional inodes from being unlocked with the key. Then,
it syncs the filesystem and evicts the inodes in the key's list. The
normal inode eviction code will free and wipe the per-file keys (in
->i_crypt_info). Note that freeing ->i_crypt_info without evicting the
inodes was also considered, but would have been racy.
Some inodes may still be in use when a master key is removed, and we
can't simply revoke random file descriptors, mmap's, etc. Thus, the
ioctl simply skips in-use inodes, and returns -EBUSY to indicate that
some inodes weren't evicted. The master key *secret* is still removed,
but the fscrypt_master_key struct remains to keep track of the remaining
inodes. Userspace can then retry the ioctl to evict the remaining
inodes. Alternatively, if userspace adds the key again, the refreshed
secret will be associated with the existing list of inodes so they
remain correctly tracked for future key removals.
The ioctl doesn't wipe pagecache pages. Thus, we tolerate that after a
kernel compromise some portions of plaintext file contents may still be
recoverable from memory. This can be solved by enabling page poisoning
system-wide, which security conscious users may choose to do. But it's
very difficult to solve otherwise, e.g. note that plaintext file
contents may have been read in other places than pagecache pages.
Like FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY is
initially restricted to privileged users only. This is sufficient for
some use cases, but not all. A later patch will relax this restriction,
but it will require introducing key hashes, among other changes.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
if (master_key) {
|
fscrypt: allow unprivileged users to add/remove keys for v2 policies
Allow the FS_IOC_ADD_ENCRYPTION_KEY and FS_IOC_REMOVE_ENCRYPTION_KEY
ioctls to be used by non-root users to add and remove encryption keys
from the filesystem-level crypto keyrings, subject to limitations.
Motivation: while privileged fscrypt key management is sufficient for
some users (e.g. Android and Chromium OS, where a privileged process
manages all keys), the old API by design also allows non-root users to
set up and use encrypted directories, and we don't want to regress on
that. Especially, we don't want to force users to continue using the
old API, running into the visibility mismatch between files and keyrings
and being unable to "lock" encrypted directories.
Intuitively, the ioctls have to be privileged since they manipulate
filesystem-level state. However, it's actually safe to make them
unprivileged if we very carefully enforce some specific limitations.
First, each key must be identified by a cryptographic hash so that a
user can't add the wrong key for another user's files. For v2
encryption policies, we use the key_identifier for this. v1 policies
don't have this, so managing keys for them remains privileged.
Second, each key a user adds is charged to their quota for the keyrings
service. Thus, a user can't exhaust memory by adding a huge number of
keys. By default each non-root user is allowed up to 200 keys; this can
be changed using the existing sysctl 'kernel.keys.maxkeys'.
Third, if multiple users add the same key, we keep track of those users
of the key (of which there remains a single copy), and won't really
remove the key, i.e. "lock" the encrypted files, until all those users
have removed it. This prevents denial of service attacks that would be
possible under simpler schemes, such allowing the first user who added a
key to remove it -- since that could be a malicious user who has
compromised the key. Of course, encryption keys should be kept secret,
but the idea is that using encryption should never be *less* secure than
not using encryption, even if your key was compromised.
We tolerate that a user will be unable to really remove a key, i.e.
unable to "lock" their encrypted files, if another user has added the
same key. But in a sense, this is actually a good thing because it will
avoid providing a false notion of security where a key appears to have
been removed when actually it's still in memory, available to any
attacker who compromises the operating system kernel.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
struct fscrypt_master_key *mk = master_key->payload.data[0];
|
|
|
|
|
|
|
|
|
|
up_read(&mk->mk_secret_sem);
|
fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl
Add a new fscrypt ioctl, FS_IOC_REMOVE_ENCRYPTION_KEY. This ioctl
removes an encryption key that was added by FS_IOC_ADD_ENCRYPTION_KEY.
It wipes the secret key itself, then "locks" the encrypted files and
directories that had been unlocked using that key -- implemented by
evicting the relevant dentries and inodes from the VFS caches.
The problem this solves is that many fscrypt users want the ability to
remove encryption keys, causing the corresponding encrypted directories
to appear "locked" (presented in ciphertext form) again. Moreover,
users want removing an encryption key to *really* remove it, in the
sense that the removed keys cannot be recovered even if kernel memory is
compromised, e.g. by the exploit of a kernel security vulnerability or
by a physical attack. This is desirable after a user logs out of the
system, for example. In many cases users even already assume this to be
the case and are surprised to hear when it's not.
It is not sufficient to simply unlink the master key from the keyring
(or to revoke or invalidate it), since the actual encryption transform
objects are still pinned in memory by their inodes. Therefore, to
really remove a key we must also evict the relevant inodes.
Currently one workaround is to run 'sync && echo 2 >
/proc/sys/vm/drop_caches'. But, that evicts all unused inodes in the
system rather than just the inodes associated with the key being
removed, causing severe performance problems. Moreover, it requires
root privileges, so regular users can't "lock" their encrypted files.
Another workaround, used in Chromium OS kernels, is to add a new
VFS-level ioctl FS_IOC_DROP_CACHE which is a more restricted version of
drop_caches that operates on a single super_block. It does:
shrink_dcache_sb(sb);
invalidate_inodes(sb, false);
But it's still a hack. Yet, the major users of filesystem encryption
want this feature badly enough that they are actually using these hacks.
To properly solve the problem, start maintaining a list of the inodes
which have been "unlocked" using each master key. Originally this
wasn't possible because the kernel didn't keep track of in-use master
keys at all. But, with the ->s_master_keys keyring it is now possible.
Then, add an ioctl FS_IOC_REMOVE_ENCRYPTION_KEY. It finds the specified
master key in ->s_master_keys, then wipes the secret key itself, which
prevents any additional inodes from being unlocked with the key. Then,
it syncs the filesystem and evicts the inodes in the key's list. The
normal inode eviction code will free and wipe the per-file keys (in
->i_crypt_info). Note that freeing ->i_crypt_info without evicting the
inodes was also considered, but would have been racy.
Some inodes may still be in use when a master key is removed, and we
can't simply revoke random file descriptors, mmap's, etc. Thus, the
ioctl simply skips in-use inodes, and returns -EBUSY to indicate that
some inodes weren't evicted. The master key *secret* is still removed,
but the fscrypt_master_key struct remains to keep track of the remaining
inodes. Userspace can then retry the ioctl to evict the remaining
inodes. Alternatively, if userspace adds the key again, the refreshed
secret will be associated with the existing list of inodes so they
remain correctly tracked for future key removals.
The ioctl doesn't wipe pagecache pages. Thus, we tolerate that after a
kernel compromise some portions of plaintext file contents may still be
recoverable from memory. This can be solved by enabling page poisoning
system-wide, which security conscious users may choose to do. But it's
very difficult to solve otherwise, e.g. note that plaintext file
contents may have been read in other places than pagecache pages.
Like FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY is
initially restricted to privileged users only. This is sufficient for
some use cases, but not all. A later patch will relax this restriction,
but it will require introducing key hashes, among other changes.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
key_put(master_key);
|
|
|
|
|
}
|
|
|
|
|
if (res == -ENOKEY)
|
|
|
|
|
res = 0;
|
|
|
|
|
put_crypt_info(crypt_info);
|
|
|
|
|
return res;
|
|
|
|
|
}
|
fscrypt: remove broken support for detecting keyring key revocation
Filesystem encryption ostensibly supported revoking a keyring key that
had been used to "unlock" encrypted files, causing those files to become
"locked" again. This was, however, buggy for several reasons, the most
severe of which was that when key revocation happened to be detected for
an inode, its fscrypt_info was immediately freed, even while other
threads could be using it for encryption or decryption concurrently.
This could be exploited to crash the kernel or worse.
This patch fixes the use-after-free by removing the code which detects
the keyring key having been revoked, invalidated, or expired. Instead,
an encrypted inode that is "unlocked" now simply remains unlocked until
it is evicted from memory. Note that this is no worse than the case for
block device-level encryption, e.g. dm-crypt, and it still remains
possible for a privileged user to evict unused pages, inodes, and
dentries by running 'sync; echo 3 > /proc/sys/vm/drop_caches', or by
simply unmounting the filesystem. In fact, one of those actions was
already needed anyway for key revocation to work even somewhat sanely.
This change is not expected to break any applications.
In the future I'd like to implement a real API for fscrypt key
revocation that interacts sanely with ongoing filesystem operations ---
waiting for existing operations to complete and blocking new operations,
and invalidating and sanitizing key material and plaintext from the VFS
caches. But this is a hard problem, and for now this bug must be fixed.
This bug affected almost all versions of ext4, f2fs, and ubifs
encryption, and it was potentially reachable in any kernel configured
with encryption support (CONFIG_EXT4_ENCRYPTION=y,
CONFIG_EXT4_FS_ENCRYPTION=y, CONFIG_F2FS_FS_ENCRYPTION=y, or
CONFIG_UBIFS_FS_ENCRYPTION=y). Note that older kernels did not use the
shared fs/crypto/ code, but due to the potential security implications
of this bug, it may still be worthwhile to backport this fix to them.
Fixes: b7236e21d55f ("ext4 crypto: reorganize how we store keys in the inode")
Cc: stable@vger.kernel.org # v4.2+
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Acked-by: Michael Halcrow <mhalcrow@google.com>
8 years ago
|
|
|
EXPORT_SYMBOL(fscrypt_get_encryption_info);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* fscrypt_put_encryption_info() - free most of an inode's fscrypt data
|
|
|
|
|
* @inode: an inode being evicted
|
|
|
|
|
*
|
|
|
|
|
* Free the inode's fscrypt_info. Filesystems must call this when the inode is
|
|
|
|
|
* being evicted. An RCU grace period need not have elapsed yet.
|
|
|
|
|
*/
|
|
|
|
|
void fscrypt_put_encryption_info(struct inode *inode)
|
|
|
|
|
{
|
|
|
|
|
#ifdef CONFIG_FSCRYPT_SDP
|
|
|
|
|
fscrypt_sdp_cache_remove_inode_num(inode);
|
|
|
|
|
#endif
|
|
|
|
|
put_crypt_info(inode->i_crypt_info);
|
|
|
|
|
inode->i_crypt_info = NULL;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL(fscrypt_put_encryption_info);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* fscrypt_free_inode() - free an inode's fscrypt data requiring RCU delay
|
|
|
|
|
* @inode: an inode being freed
|
|
|
|
|
*
|
|
|
|
|
* Free the inode's cached decrypted symlink target, if any. Filesystems must
|
|
|
|
|
* call this after an RCU grace period, just before they free the inode.
|
|
|
|
|
*/
|
|
|
|
|
void fscrypt_free_inode(struct inode *inode)
|
|
|
|
|
{
|
|
|
|
|
if (IS_ENCRYPTED(inode) && S_ISLNK(inode->i_mode)) {
|
|
|
|
|
kfree(inode->i_link);
|
|
|
|
|
inode->i_link = NULL;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL(fscrypt_free_inode);
|
fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl
Add a new fscrypt ioctl, FS_IOC_REMOVE_ENCRYPTION_KEY. This ioctl
removes an encryption key that was added by FS_IOC_ADD_ENCRYPTION_KEY.
It wipes the secret key itself, then "locks" the encrypted files and
directories that had been unlocked using that key -- implemented by
evicting the relevant dentries and inodes from the VFS caches.
The problem this solves is that many fscrypt users want the ability to
remove encryption keys, causing the corresponding encrypted directories
to appear "locked" (presented in ciphertext form) again. Moreover,
users want removing an encryption key to *really* remove it, in the
sense that the removed keys cannot be recovered even if kernel memory is
compromised, e.g. by the exploit of a kernel security vulnerability or
by a physical attack. This is desirable after a user logs out of the
system, for example. In many cases users even already assume this to be
the case and are surprised to hear when it's not.
It is not sufficient to simply unlink the master key from the keyring
(or to revoke or invalidate it), since the actual encryption transform
objects are still pinned in memory by their inodes. Therefore, to
really remove a key we must also evict the relevant inodes.
Currently one workaround is to run 'sync && echo 2 >
/proc/sys/vm/drop_caches'. But, that evicts all unused inodes in the
system rather than just the inodes associated with the key being
removed, causing severe performance problems. Moreover, it requires
root privileges, so regular users can't "lock" their encrypted files.
Another workaround, used in Chromium OS kernels, is to add a new
VFS-level ioctl FS_IOC_DROP_CACHE which is a more restricted version of
drop_caches that operates on a single super_block. It does:
shrink_dcache_sb(sb);
invalidate_inodes(sb, false);
But it's still a hack. Yet, the major users of filesystem encryption
want this feature badly enough that they are actually using these hacks.
To properly solve the problem, start maintaining a list of the inodes
which have been "unlocked" using each master key. Originally this
wasn't possible because the kernel didn't keep track of in-use master
keys at all. But, with the ->s_master_keys keyring it is now possible.
Then, add an ioctl FS_IOC_REMOVE_ENCRYPTION_KEY. It finds the specified
master key in ->s_master_keys, then wipes the secret key itself, which
prevents any additional inodes from being unlocked with the key. Then,
it syncs the filesystem and evicts the inodes in the key's list. The
normal inode eviction code will free and wipe the per-file keys (in
->i_crypt_info). Note that freeing ->i_crypt_info without evicting the
inodes was also considered, but would have been racy.
Some inodes may still be in use when a master key is removed, and we
can't simply revoke random file descriptors, mmap's, etc. Thus, the
ioctl simply skips in-use inodes, and returns -EBUSY to indicate that
some inodes weren't evicted. The master key *secret* is still removed,
but the fscrypt_master_key struct remains to keep track of the remaining
inodes. Userspace can then retry the ioctl to evict the remaining
inodes. Alternatively, if userspace adds the key again, the refreshed
secret will be associated with the existing list of inodes so they
remain correctly tracked for future key removals.
The ioctl doesn't wipe pagecache pages. Thus, we tolerate that after a
kernel compromise some portions of plaintext file contents may still be
recoverable from memory. This can be solved by enabling page poisoning
system-wide, which security conscious users may choose to do. But it's
very difficult to solve otherwise, e.g. note that plaintext file
contents may have been read in other places than pagecache pages.
Like FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY is
initially restricted to privileged users only. This is sufficient for
some use cases, but not all. A later patch will relax this restriction,
but it will require introducing key hashes, among other changes.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* fscrypt_drop_inode() - check whether the inode's master key has been removed
|
|
|
|
|
* @inode: an inode being considered for eviction
|
fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl
Add a new fscrypt ioctl, FS_IOC_REMOVE_ENCRYPTION_KEY. This ioctl
removes an encryption key that was added by FS_IOC_ADD_ENCRYPTION_KEY.
It wipes the secret key itself, then "locks" the encrypted files and
directories that had been unlocked using that key -- implemented by
evicting the relevant dentries and inodes from the VFS caches.
The problem this solves is that many fscrypt users want the ability to
remove encryption keys, causing the corresponding encrypted directories
to appear "locked" (presented in ciphertext form) again. Moreover,
users want removing an encryption key to *really* remove it, in the
sense that the removed keys cannot be recovered even if kernel memory is
compromised, e.g. by the exploit of a kernel security vulnerability or
by a physical attack. This is desirable after a user logs out of the
system, for example. In many cases users even already assume this to be
the case and are surprised to hear when it's not.
It is not sufficient to simply unlink the master key from the keyring
(or to revoke or invalidate it), since the actual encryption transform
objects are still pinned in memory by their inodes. Therefore, to
really remove a key we must also evict the relevant inodes.
Currently one workaround is to run 'sync && echo 2 >
/proc/sys/vm/drop_caches'. But, that evicts all unused inodes in the
system rather than just the inodes associated with the key being
removed, causing severe performance problems. Moreover, it requires
root privileges, so regular users can't "lock" their encrypted files.
Another workaround, used in Chromium OS kernels, is to add a new
VFS-level ioctl FS_IOC_DROP_CACHE which is a more restricted version of
drop_caches that operates on a single super_block. It does:
shrink_dcache_sb(sb);
invalidate_inodes(sb, false);
But it's still a hack. Yet, the major users of filesystem encryption
want this feature badly enough that they are actually using these hacks.
To properly solve the problem, start maintaining a list of the inodes
which have been "unlocked" using each master key. Originally this
wasn't possible because the kernel didn't keep track of in-use master
keys at all. But, with the ->s_master_keys keyring it is now possible.
Then, add an ioctl FS_IOC_REMOVE_ENCRYPTION_KEY. It finds the specified
master key in ->s_master_keys, then wipes the secret key itself, which
prevents any additional inodes from being unlocked with the key. Then,
it syncs the filesystem and evicts the inodes in the key's list. The
normal inode eviction code will free and wipe the per-file keys (in
->i_crypt_info). Note that freeing ->i_crypt_info without evicting the
inodes was also considered, but would have been racy.
Some inodes may still be in use when a master key is removed, and we
can't simply revoke random file descriptors, mmap's, etc. Thus, the
ioctl simply skips in-use inodes, and returns -EBUSY to indicate that
some inodes weren't evicted. The master key *secret* is still removed,
but the fscrypt_master_key struct remains to keep track of the remaining
inodes. Userspace can then retry the ioctl to evict the remaining
inodes. Alternatively, if userspace adds the key again, the refreshed
secret will be associated with the existing list of inodes so they
remain correctly tracked for future key removals.
The ioctl doesn't wipe pagecache pages. Thus, we tolerate that after a
kernel compromise some portions of plaintext file contents may still be
recoverable from memory. This can be solved by enabling page poisoning
system-wide, which security conscious users may choose to do. But it's
very difficult to solve otherwise, e.g. note that plaintext file
contents may have been read in other places than pagecache pages.
Like FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY is
initially restricted to privileged users only. This is sufficient for
some use cases, but not all. A later patch will relax this restriction,
but it will require introducing key hashes, among other changes.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
*
|
|
|
|
|
* Filesystems supporting fscrypt must call this from their ->drop_inode()
|
|
|
|
|
* method so that encrypted inodes are evicted as soon as they're no longer in
|
|
|
|
|
* use and their master key has been removed.
|
|
|
|
|
*
|
|
|
|
|
* Return: 1 if fscrypt wants the inode to be evicted now, otherwise 0
|
|
|
|
|
*/
|
|
|
|
|
int fscrypt_drop_inode(struct inode *inode)
|
|
|
|
|
{
|
|
|
|
|
const struct fscrypt_info *ci = READ_ONCE(inode->i_crypt_info);
|
|
|
|
|
const struct fscrypt_master_key *mk;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If ci is NULL, then the inode doesn't have an encryption key set up
|
|
|
|
|
* so it's irrelevant. If ci_master_key is NULL, then the master key
|
|
|
|
|
* was provided via the legacy mechanism of the process-subscribed
|
|
|
|
|
* keyrings, so we don't know whether it's been removed or not.
|
|
|
|
|
*/
|
|
|
|
|
if (!ci || !ci->ci_master_key)
|
|
|
|
|
return 0;
|
|
|
|
|
mk = ci->ci_master_key->payload.data[0];
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* With proper, non-racy use of FS_IOC_REMOVE_ENCRYPTION_KEY, all inodes
|
|
|
|
|
* protected by the key were cleaned by sync_filesystem(). But if
|
|
|
|
|
* userspace is still using the files, inodes can be dirtied between
|
|
|
|
|
* then and now. We mustn't lose any writes, so skip dirty inodes here.
|
|
|
|
|
*/
|
|
|
|
|
if (inode->i_state & I_DIRTY_ALL)
|
|
|
|
|
return 0;
|
|
|
|
|
|
fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl
Add a new fscrypt ioctl, FS_IOC_REMOVE_ENCRYPTION_KEY. This ioctl
removes an encryption key that was added by FS_IOC_ADD_ENCRYPTION_KEY.
It wipes the secret key itself, then "locks" the encrypted files and
directories that had been unlocked using that key -- implemented by
evicting the relevant dentries and inodes from the VFS caches.
The problem this solves is that many fscrypt users want the ability to
remove encryption keys, causing the corresponding encrypted directories
to appear "locked" (presented in ciphertext form) again. Moreover,
users want removing an encryption key to *really* remove it, in the
sense that the removed keys cannot be recovered even if kernel memory is
compromised, e.g. by the exploit of a kernel security vulnerability or
by a physical attack. This is desirable after a user logs out of the
system, for example. In many cases users even already assume this to be
the case and are surprised to hear when it's not.
It is not sufficient to simply unlink the master key from the keyring
(or to revoke or invalidate it), since the actual encryption transform
objects are still pinned in memory by their inodes. Therefore, to
really remove a key we must also evict the relevant inodes.
Currently one workaround is to run 'sync && echo 2 >
/proc/sys/vm/drop_caches'. But, that evicts all unused inodes in the
system rather than just the inodes associated with the key being
removed, causing severe performance problems. Moreover, it requires
root privileges, so regular users can't "lock" their encrypted files.
Another workaround, used in Chromium OS kernels, is to add a new
VFS-level ioctl FS_IOC_DROP_CACHE which is a more restricted version of
drop_caches that operates on a single super_block. It does:
shrink_dcache_sb(sb);
invalidate_inodes(sb, false);
But it's still a hack. Yet, the major users of filesystem encryption
want this feature badly enough that they are actually using these hacks.
To properly solve the problem, start maintaining a list of the inodes
which have been "unlocked" using each master key. Originally this
wasn't possible because the kernel didn't keep track of in-use master
keys at all. But, with the ->s_master_keys keyring it is now possible.
Then, add an ioctl FS_IOC_REMOVE_ENCRYPTION_KEY. It finds the specified
master key in ->s_master_keys, then wipes the secret key itself, which
prevents any additional inodes from being unlocked with the key. Then,
it syncs the filesystem and evicts the inodes in the key's list. The
normal inode eviction code will free and wipe the per-file keys (in
->i_crypt_info). Note that freeing ->i_crypt_info without evicting the
inodes was also considered, but would have been racy.
Some inodes may still be in use when a master key is removed, and we
can't simply revoke random file descriptors, mmap's, etc. Thus, the
ioctl simply skips in-use inodes, and returns -EBUSY to indicate that
some inodes weren't evicted. The master key *secret* is still removed,
but the fscrypt_master_key struct remains to keep track of the remaining
inodes. Userspace can then retry the ioctl to evict the remaining
inodes. Alternatively, if userspace adds the key again, the refreshed
secret will be associated with the existing list of inodes so they
remain correctly tracked for future key removals.
The ioctl doesn't wipe pagecache pages. Thus, we tolerate that after a
kernel compromise some portions of plaintext file contents may still be
recoverable from memory. This can be solved by enabling page poisoning
system-wide, which security conscious users may choose to do. But it's
very difficult to solve otherwise, e.g. note that plaintext file
contents may have been read in other places than pagecache pages.
Like FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY is
initially restricted to privileged users only. This is sufficient for
some use cases, but not all. A later patch will relax this restriction,
but it will require introducing key hashes, among other changes.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
/*
|
fscrypt: allow unprivileged users to add/remove keys for v2 policies
Allow the FS_IOC_ADD_ENCRYPTION_KEY and FS_IOC_REMOVE_ENCRYPTION_KEY
ioctls to be used by non-root users to add and remove encryption keys
from the filesystem-level crypto keyrings, subject to limitations.
Motivation: while privileged fscrypt key management is sufficient for
some users (e.g. Android and Chromium OS, where a privileged process
manages all keys), the old API by design also allows non-root users to
set up and use encrypted directories, and we don't want to regress on
that. Especially, we don't want to force users to continue using the
old API, running into the visibility mismatch between files and keyrings
and being unable to "lock" encrypted directories.
Intuitively, the ioctls have to be privileged since they manipulate
filesystem-level state. However, it's actually safe to make them
unprivileged if we very carefully enforce some specific limitations.
First, each key must be identified by a cryptographic hash so that a
user can't add the wrong key for another user's files. For v2
encryption policies, we use the key_identifier for this. v1 policies
don't have this, so managing keys for them remains privileged.
Second, each key a user adds is charged to their quota for the keyrings
service. Thus, a user can't exhaust memory by adding a huge number of
keys. By default each non-root user is allowed up to 200 keys; this can
be changed using the existing sysctl 'kernel.keys.maxkeys'.
Third, if multiple users add the same key, we keep track of those users
of the key (of which there remains a single copy), and won't really
remove the key, i.e. "lock" the encrypted files, until all those users
have removed it. This prevents denial of service attacks that would be
possible under simpler schemes, such allowing the first user who added a
key to remove it -- since that could be a malicious user who has
compromised the key. Of course, encryption keys should be kept secret,
but the idea is that using encryption should never be *less* secure than
not using encryption, even if your key was compromised.
We tolerate that a user will be unable to really remove a key, i.e.
unable to "lock" their encrypted files, if another user has added the
same key. But in a sense, this is actually a good thing because it will
avoid providing a false notion of security where a key appears to have
been removed when actually it's still in memory, available to any
attacker who compromises the operating system kernel.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
* Note: since we aren't holding ->mk_secret_sem, the result here can
|
fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl
Add a new fscrypt ioctl, FS_IOC_REMOVE_ENCRYPTION_KEY. This ioctl
removes an encryption key that was added by FS_IOC_ADD_ENCRYPTION_KEY.
It wipes the secret key itself, then "locks" the encrypted files and
directories that had been unlocked using that key -- implemented by
evicting the relevant dentries and inodes from the VFS caches.
The problem this solves is that many fscrypt users want the ability to
remove encryption keys, causing the corresponding encrypted directories
to appear "locked" (presented in ciphertext form) again. Moreover,
users want removing an encryption key to *really* remove it, in the
sense that the removed keys cannot be recovered even if kernel memory is
compromised, e.g. by the exploit of a kernel security vulnerability or
by a physical attack. This is desirable after a user logs out of the
system, for example. In many cases users even already assume this to be
the case and are surprised to hear when it's not.
It is not sufficient to simply unlink the master key from the keyring
(or to revoke or invalidate it), since the actual encryption transform
objects are still pinned in memory by their inodes. Therefore, to
really remove a key we must also evict the relevant inodes.
Currently one workaround is to run 'sync && echo 2 >
/proc/sys/vm/drop_caches'. But, that evicts all unused inodes in the
system rather than just the inodes associated with the key being
removed, causing severe performance problems. Moreover, it requires
root privileges, so regular users can't "lock" their encrypted files.
Another workaround, used in Chromium OS kernels, is to add a new
VFS-level ioctl FS_IOC_DROP_CACHE which is a more restricted version of
drop_caches that operates on a single super_block. It does:
shrink_dcache_sb(sb);
invalidate_inodes(sb, false);
But it's still a hack. Yet, the major users of filesystem encryption
want this feature badly enough that they are actually using these hacks.
To properly solve the problem, start maintaining a list of the inodes
which have been "unlocked" using each master key. Originally this
wasn't possible because the kernel didn't keep track of in-use master
keys at all. But, with the ->s_master_keys keyring it is now possible.
Then, add an ioctl FS_IOC_REMOVE_ENCRYPTION_KEY. It finds the specified
master key in ->s_master_keys, then wipes the secret key itself, which
prevents any additional inodes from being unlocked with the key. Then,
it syncs the filesystem and evicts the inodes in the key's list. The
normal inode eviction code will free and wipe the per-file keys (in
->i_crypt_info). Note that freeing ->i_crypt_info without evicting the
inodes was also considered, but would have been racy.
Some inodes may still be in use when a master key is removed, and we
can't simply revoke random file descriptors, mmap's, etc. Thus, the
ioctl simply skips in-use inodes, and returns -EBUSY to indicate that
some inodes weren't evicted. The master key *secret* is still removed,
but the fscrypt_master_key struct remains to keep track of the remaining
inodes. Userspace can then retry the ioctl to evict the remaining
inodes. Alternatively, if userspace adds the key again, the refreshed
secret will be associated with the existing list of inodes so they
remain correctly tracked for future key removals.
The ioctl doesn't wipe pagecache pages. Thus, we tolerate that after a
kernel compromise some portions of plaintext file contents may still be
recoverable from memory. This can be solved by enabling page poisoning
system-wide, which security conscious users may choose to do. But it's
very difficult to solve otherwise, e.g. note that plaintext file
contents may have been read in other places than pagecache pages.
Like FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY is
initially restricted to privileged users only. This is sufficient for
some use cases, but not all. A later patch will relax this restriction,
but it will require introducing key hashes, among other changes.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
5 years ago
|
|
|
* immediately become outdated. But there's no correctness problem with
|
|
|
|
|
* unnecessarily evicting. Nor is there a correctness problem with not
|
|
|
|
|
* evicting while iput() is racing with the key being removed, since
|
|
|
|
|
* then the thread removing the key will either evict the inode itself
|
|
|
|
|
* or will correctly detect that it wasn't evicted due to the race.
|
|
|
|
|
*/
|
|
|
|
|
return !is_master_key_secret_present(&mk->mk_secret);
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(fscrypt_drop_inode);
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_FSCRYPT_SDP
|
|
|
|
|
static inline int __find_and_derive_mode_key(
|
|
|
|
|
struct fscrypt_key *fskey,
|
|
|
|
|
struct fscrypt_info *ci,
|
|
|
|
|
struct fscrypt_master_key *mk,
|
|
|
|
|
u8 hkdf_context, bool include_fs_uuid)
|
|
|
|
|
{
|
|
|
|
|
const struct inode *inode = ci->ci_inode;
|
|
|
|
|
const struct super_block *sb = inode->i_sb;
|
|
|
|
|
struct fscrypt_mode *mode = ci->ci_mode;
|
|
|
|
|
const u8 mode_num = mode - fscrypt_modes;
|
|
|
|
|
u8 mode_key[FSCRYPT_MAX_KEY_SIZE];
|
|
|
|
|
u8 hkdf_info[sizeof(mode_num) + sizeof(sb->s_uuid)];
|
|
|
|
|
unsigned int hkdf_infolen = 0;
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
if (WARN_ON(mode_num > __FSCRYPT_MODE_MAX))
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
|
|
mutex_lock(&fscrypt_mode_key_setup_mutex);
|
|
|
|
|
|
|
|
|
|
if (mk->mk_secret.is_hw_wrapped && S_ISREG(inode->i_mode)) {
|
|
|
|
|
if (!fscrypt_using_inline_encryption(ci)) {
|
|
|
|
|
fscrypt_warn(ci->ci_inode,
|
|
|
|
|
"Hardware-wrapped keys require inline encryption (-o inlinecrypt)");
|
|
|
|
|
err = -EINVAL;
|
|
|
|
|
goto out_unlock;
|
|
|
|
|
}
|
|
|
|
|
err = -EOPNOTSUPP;
|
|
|
|
|
} else {
|
|
|
|
|
BUILD_BUG_ON(sizeof(mode_num) != 1);
|
|
|
|
|
BUILD_BUG_ON(sizeof(sb->s_uuid) != 16);
|
|
|
|
|
BUILD_BUG_ON(sizeof(hkdf_info) != 17);
|
|
|
|
|
hkdf_info[hkdf_infolen++] = mode_num;
|
|
|
|
|
if (include_fs_uuid) {
|
|
|
|
|
memcpy(&hkdf_info[hkdf_infolen], &sb->s_uuid,
|
|
|
|
|
sizeof(sb->s_uuid));
|
|
|
|
|
hkdf_infolen += sizeof(sb->s_uuid);
|
|
|
|
|
}
|
|
|
|
|
err = fscrypt_hkdf_expand(&mk->mk_secret.hkdf,
|
|
|
|
|
hkdf_context, hkdf_info, hkdf_infolen,
|
|
|
|
|
mode_key, mode->keysize);
|
|
|
|
|
if (err)
|
|
|
|
|
goto out_unlock;
|
|
|
|
|
|
|
|
|
|
memcpy(fskey->raw, mode_key, mode->keysize);
|
|
|
|
|
fskey->size = mode->keysize;
|
|
|
|
|
memzero_explicit(mode_key, mode->keysize);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
out_unlock:
|
|
|
|
|
mutex_unlock(&fscrypt_mode_key_setup_mutex);
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int __find_and_derive_fskey(
|
|
|
|
|
struct fscrypt_info *ci,
|
|
|
|
|
struct fscrypt_key *fskey)
|
|
|
|
|
{
|
|
|
|
|
struct key *key;
|
|
|
|
|
struct fscrypt_master_key *mk = NULL;
|
|
|
|
|
struct fscrypt_key_specifier mk_spec;
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
switch (ci->ci_policy.version) {
|
|
|
|
|
// case FSCRYPT_POLICY_V1:
|
|
|
|
|
// mk_spec.type = FSCRYPT_KEY_SPEC_TYPE_DESCRIPTOR;
|
|
|
|
|
// memcpy(mk_spec.u.descriptor,
|
|
|
|
|
// ci->ci_policy.v1.master_key_descriptor,
|
|
|
|
|
// FSCRYPT_KEY_DESCRIPTOR_SIZE);
|
|
|
|
|
// break;
|
|
|
|
|
case FSCRYPT_POLICY_V2:
|
|
|
|
|
mk_spec.type = FSCRYPT_KEY_SPEC_TYPE_IDENTIFIER;
|
|
|
|
|
memcpy(mk_spec.u.identifier,
|
|
|
|
|
ci->ci_policy.v2.master_key_identifier,
|
|
|
|
|
FSCRYPT_KEY_IDENTIFIER_SIZE);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
WARN_ON(1);
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
key = fscrypt_find_master_key(ci->ci_inode->i_sb, &mk_spec);
|
|
|
|
|
if (IS_ERR(key))
|
|
|
|
|
return PTR_ERR(key);
|
|
|
|
|
|
|
|
|
|
mk = key->payload.data[0];
|
|
|
|
|
down_read(&mk->mk_secret_sem);
|
|
|
|
|
|
|
|
|
|
/* Has the secret been removed (via FS_IOC_REMOVE_ENCRYPTION_KEY)? */
|
|
|
|
|
if (!is_master_key_secret_present(&mk->mk_secret)) {
|
|
|
|
|
err = -ENOKEY;
|
|
|
|
|
goto out_release_key;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Require that the master key be at least as long as the derived key.
|
|
|
|
|
* Otherwise, the derived key cannot possibly contain as much entropy as
|
|
|
|
|
* that required by the encryption mode it will be used for. For v1
|
|
|
|
|
* policies it's also required for the KDF to work at all.
|
|
|
|
|
*/
|
|
|
|
|
if (mk->mk_secret.size < ci->ci_mode->keysize) {
|
|
|
|
|
fscrypt_warn(NULL,
|
|
|
|
|
"key with %s %*phN is too short (got %u bytes, need %u+ bytes)",
|
|
|
|
|
master_key_spec_type(&mk_spec),
|
|
|
|
|
master_key_spec_len(&mk_spec), (u8 *)&mk_spec.u,
|
|
|
|
|
mk->mk_secret.size, ci->ci_mode->keysize);
|
|
|
|
|
err = -ENOKEY;
|
|
|
|
|
goto out_release_key;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
err = fscrypt_select_encryption_impl(ci, mk->mk_secret.is_hw_wrapped);
|
|
|
|
|
if (err)
|
|
|
|
|
goto out_release_key;
|
|
|
|
|
|
|
|
|
|
if (mk->mk_secret.is_hw_wrapped &&
|
|
|
|
|
!(ci->ci_policy.v2.flags & (FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64 |
|
|
|
|
|
FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32))) {
|
|
|
|
|
fscrypt_warn(ci->ci_inode,
|
|
|
|
|
"Hardware-wrapped keys are only supported with IV_INO_LBLK policies");
|
|
|
|
|
err = -EINVAL;
|
|
|
|
|
goto out_release_key;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (ci->ci_policy.v2.flags & FSCRYPT_POLICY_FLAG_DIRECT_KEY) {
|
|
|
|
|
err = __find_and_derive_mode_key(fskey, ci, mk,
|
|
|
|
|
HKDF_CONTEXT_DIRECT_KEY, false);
|
|
|
|
|
} else if (ci->ci_policy.v2.flags &
|
|
|
|
|
FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64) {
|
|
|
|
|
err = __find_and_derive_mode_key(fskey, ci, mk,
|
|
|
|
|
HKDF_CONTEXT_IV_INO_LBLK_64_KEY, true);
|
|
|
|
|
|
|
|
|
|
} else if (ci->ci_policy.v2.flags &
|
|
|
|
|
FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32) {
|
|
|
|
|
err = -EOPNOTSUPP;
|
|
|
|
|
} else {
|
|
|
|
|
err = fscrypt_hkdf_expand(&mk->mk_secret.hkdf,
|
|
|
|
|
HKDF_CONTEXT_PER_FILE_ENC_KEY,
|
|
|
|
|
ci->ci_nonce,
|
|
|
|
|
FS_KEY_DERIVATION_NONCE_SIZE,
|
|
|
|
|
fskey->raw, ci->ci_mode->keysize);
|
|
|
|
|
if (err == 0)
|
|
|
|
|
fskey->size = ci->ci_mode->keysize;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
out_release_key:
|
|
|
|
|
up_read(&mk->mk_secret_sem);
|
|
|
|
|
key_put(key);
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* The function is only for regular files */
|
|
|
|
|
static int derive_fek(struct inode *inode,
|
|
|
|
|
struct fscrypt_info *crypt_info,
|
|
|
|
|
u8 *fek, u32 fek_len)
|
|
|
|
|
{
|
|
|
|
|
int res = 0;
|
|
|
|
|
/*
|
|
|
|
|
* 1. [ Native / Uninitialized / To_sensitive ] --> Plain fek
|
|
|
|
|
* 2. [ Native / Uninitialized / Non_sensitive ] --> Plain fek
|
|
|
|
|
*/
|
|
|
|
|
if (fscrypt_sdp_is_uninitialized(crypt_info))
|
|
|
|
|
res = fscrypt_sdp_derive_uninitialized_dek(crypt_info, fek, fek_len);
|
|
|
|
|
/*
|
|
|
|
|
* 3. [ Native / Initialized / Sensitive ] --> { fek }_SDPK
|
|
|
|
|
* 4. [ Non_native / Initialized / Sensitive ] --> { fek }_SDPK
|
|
|
|
|
*/
|
|
|
|
|
else if (fscrypt_sdp_is_sensitive(crypt_info))
|
|
|
|
|
res = fscrypt_sdp_derive_dek(crypt_info, fek, fek_len);
|
|
|
|
|
/*
|
|
|
|
|
* 5. [ Native / Initialized / Non_sensitive ] --> { fek }_cekey
|
|
|
|
|
*/
|
|
|
|
|
else if (fscrypt_sdp_is_native(crypt_info))
|
|
|
|
|
res = fscrypt_sdp_derive_fek(inode, crypt_info, fek, fek_len);
|
|
|
|
|
/*
|
|
|
|
|
* else { N/A }
|
|
|
|
|
*
|
|
|
|
|
* Not classified file.
|
|
|
|
|
* 6. [ Non_native / Initialized / Non_sensitive ]
|
|
|
|
|
* 7. [ Non_native / Initialized / To_sensitive ]
|
|
|
|
|
*/
|
|
|
|
|
return res;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int derive_fek_v1(struct inode *inode,
|
|
|
|
|
struct fscrypt_info *crypt_info,
|
|
|
|
|
u8 *fek, u32 fek_len)
|
|
|
|
|
{
|
|
|
|
|
return derive_fek(inode, crypt_info, fek, fek_len);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int fscrypt_get_encryption_key(
|
|
|
|
|
struct fscrypt_info *crypt_info,
|
|
|
|
|
struct fscrypt_key *key)
|
|
|
|
|
{
|
|
|
|
|
struct fscrypt_key *kek = NULL;
|
|
|
|
|
int res;
|
|
|
|
|
|
|
|
|
|
if (!crypt_info)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
//Adding switch case to handle both v1 and v2
|
|
|
|
|
switch (crypt_info->ci_policy.version) {
|
|
|
|
|
case FSCRYPT_POLICY_V1:
|
|
|
|
|
kek = kzalloc(sizeof(struct fscrypt_key), GFP_NOFS);
|
|
|
|
|
if (!kek)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
|
|
res = fscrypt_get_encryption_kek(crypt_info, kek);
|
|
|
|
|
if (res){
|
|
|
|
|
kzfree(kek);
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
res = find_and_derive_v1_file_key(key, crypt_info, kek->raw);
|
|
|
|
|
kzfree(kek);
|
|
|
|
|
break;
|
|
|
|
|
case FSCRYPT_POLICY_V2:
|
|
|
|
|
if (!(kek = key))
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
|
|
res = fscrypt_get_encryption_kek(crypt_info, kek);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
WARN_ON(1);
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
out:
|
|
|
|
|
return res;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL(fscrypt_get_encryption_key);
|
|
|
|
|
|
|
|
|
|
// no change for v1 and v2
|
|
|
|
|
int fscrypt_get_encryption_key_classified(
|
|
|
|
|
struct fscrypt_info *crypt_info,
|
|
|
|
|
struct fscrypt_key *key)
|
|
|
|
|
{
|
|
|
|
|
u8 *derived_key;
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
if (!crypt_info)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
|
|
derived_key = kmalloc(crypt_info->ci_mode->keysize, GFP_NOFS);
|
|
|
|
|
if (!derived_key)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
|
|
err = derive_fek(crypt_info->ci_inode, crypt_info, derived_key, crypt_info->ci_mode->keysize);
|
|
|
|
|
if (err)
|
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
|
|
memcpy(key->raw, derived_key, crypt_info->ci_mode->keysize);
|
|
|
|
|
key->size = crypt_info->ci_mode->keysize;
|
|
|
|
|
|
|
|
|
|
out:
|
|
|
|
|
kzfree(derived_key);
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL(fscrypt_get_encryption_key_classified);
|
|
|
|
|
|
|
|
|
|
int fscrypt_get_encryption_kek(
|
|
|
|
|
struct fscrypt_info *crypt_info,
|
|
|
|
|
struct fscrypt_key *kek)
|
|
|
|
|
{
|
|
|
|
|
int res;
|
|
|
|
|
|
|
|
|
|
if (!crypt_info)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
//switch case for v1 and v2, for v1 call keysetup_v1 function
|
|
|
|
|
switch (crypt_info->ci_policy.version) {
|
|
|
|
|
case FSCRYPT_POLICY_V1:
|
|
|
|
|
res = find_and_derive_v1_fskey(crypt_info, kek);
|
|
|
|
|
break;
|
|
|
|
|
case FSCRYPT_POLICY_V2:
|
|
|
|
|
res = __find_and_derive_fskey(crypt_info, kek);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
WARN_ON(1);
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
return res;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL(fscrypt_get_encryption_kek);
|
|
|
|
|
#endif
|
