fscrypt updates for 4.18
Theodore Y. Ts'o
maintainerThe following changes since commit 75bc37fefc4471e718ba8e651aa74673d4e0a9eb:
Linux 4.17-rc4 (2018-05-06 16:57:38 -1000)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/fscrypt.git tags/fscrypt_for_linus
for you to fetch changes up to 4f2f76f751433908364ccff82f437a57d0e6e9b7:
ext4: fix fencepost error in check for inode count overflow during resize (2018-05-25 12:51:25 -0400)
----------------------------------------------------------------
Add bunch of cleanups, and add support for the Speck128/256 algorithms. Yes, Speck is contrversial, but the intention is to use them only for the lowest end Android devices, where the alternative *really* is no encryption at all for data stored at rest.
----------------------------------------------------------------
Amir Goldstein (3):
vfs: add the sb_start_intwrite_trylock() helper
ext4: factor out helper ext4_sample_last_mounted()
ext4: do not update s_last_mounted of a frozen fs
Eryu Guan (2):
ext4: use XATTR_CREATE in ext4_initxattrs()
ext4: use raw i_version value for ea_inode
Jaegeuk Kim (1):
ext4: handle errors on ext4_commit_super
Jan Kara (2):
ext4: fix hole length detection in ext4_ind_map_blocks()
ext4: fix fencepost error in check for inode count overflow during resize
Konstantin Khlebnikov (1):
ext4: report delalloc reserve as non-free in statfs for project quota
Luis R. Rodriguez (1):
ext4: add verifier check for symlink with append/immutable flags
Lukas Czerner (1):
ext4: update mtime in ext4_punch_hole even if no blocks are released
Mathieu Malaterre (1):
ext4: make function ‘ext4_getfsmap_find_fixed_metadata’ static
Sean Fu (1):
ext4: remove NULL check before calling kmem_cache_destroy()
Souptick Joarder (1):
fs: ext4: add new return type vm_fault_t
Theodore Ts'o (3):
ext4: do not allow external inodes for inline data
ext4: bubble errors from ext4_find_inline_data_nolock() up to ext4_iget()
ext4: correctly handle a zero-length xattr with a non-zero e_value_offs
Wang Long (1):
jbd2: remove NULL check before calling kmem_cache_destroy()
Wang Shilong (5):
ext4: fix wrong return value in ext4_read_inode_bitmap()
ext4: add new ext4_mark_group_bitmap_corrupted() helper
ext4: mark inode bitmap corrupted when found
ext4: mark block bitmap corrupted when found
jbd2: remove bunch of empty lines with jbd2 debug
fs/ext4/balloc.c | 33 +++++++------------- fs/ext4/ext4.h | 7 +++++ fs/ext4/extents_status.c | 3 +- fs/ext4/file.c | 93 ++++++++++++++++++++++++++++++++----------------------- fs/ext4/fsmap.c | 4 +-- fs/ext4/ialloc.c | 35 +++++++++------------ fs/ext4/indirect.c | 14 ++++++--- fs/ext4/inline.c | 6 ++++ fs/ext4/inode.c | 77 +++++++++++++++++++++++++++++++-------------- fs/ext4/mballoc.c | 23 +++++++------- fs/ext4/resize.c | 2 +- fs/ext4/super.c | 68 +++++++++++++++++++++++++++++++--------- fs/ext4/xattr.c | 2 +- fs/ext4/xattr_security.c | 2 +- fs/jbd2/journal.c | 20 +++++------- fs/jbd2/revoke.c | 12 +++---- fs/jbd2/transaction.c | 6 ++-- include/linux/fs.h | 5 +++ 18 files changed, 245 insertions(+), 167 deletions(-)
Ted,
Quoted 10 lines · Theodore Y. Ts'o
The following changes since commit
75bc37fefc4471e718ba8e651aa74673d4e0a9eb:Linux 4.17-rc4 (2018-05-06 16:57:38 -1000)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/fscrypt.gittags/fscrypt_for_linusfor you to fetch changes up to
4f2f76f751433908364ccff82f437a57d0e6e9b7:
Quoted 7 lines
ext4: fix fencepost error in check for inode count overflow during resize (2018-05-25 12:51:25 -0400)
----------------------------------------------------------------
Add bunch of cleanups, and add support for the Speck128/256 algorithms. Yes, Speck is contrversial, but the intention is to use them only for the lowest end Android devices, where the alternative *really* is no encryption at all for data stored at rest.
Will Android tell me that Speck is being used?
Signature · 2 lines
Thanks, //richard
Theodore Y. Ts'o
maintainerQuoted 6 lines · Richard Weinberger
Quoted 4 lines
Add bunch of cleanups, and add support for the Speck128/256 algorithms. Yes, Speck is contrversial, but the intention is to use them only for the lowest end Android devices, where the alternative *really* is no encryption at all for data stored at rest.
Will Android tell me that Speck is being used?
Well, today Android doesn't tell you, "Your files aren't being encrypted" in some big dialog box. :-)
Whether a phone is using no encryption or not, and what encryption algorithm, is fundamentally a property of the phone. It's used to encrypt data at rest on the phone, so this isn't a data interchange issue. I'm sure there will be some way of finding out --- by looking at the source code for that phone, if nothing else.
But I suspect that if you are buying a phone in a first world country, you're never going to see a phone with Speck on it --- unless you build your own AOSP build and deliberately enable it for yourself, anyway. :-)
This is really intended for "The Next Billion Users"; phones like Android Go that was disclosed at the 2017 Google I/O conference, where the unsubsidized price is well under $100 USD (so cheaper than the original OLPC target).
- Ted
Am Dienstag, 5. Juni 2018, 17:35:01 CEST schrieb Theodore Y. Ts'o:
Quoted 17 lines · Richard Weinberger
Quoted 6 lines
Quoted 4 lines
Add bunch of cleanups, and add support for the Speck128/256 algorithms. Yes, Speck is contrversial, but the intention is to use them only for the lowest end Android devices, where the alternative *really* is no encryption at all for data stored at rest.
Will Android tell me that Speck is being used?
Well, today Android doesn't tell you, "Your files aren't being encrypted" in some big dialog box. :-)
Whether a phone is using no encryption or not, and what encryption algorithm, is fundamentally a property of the phone. It's used to encrypt data at rest on the phone, so this isn't a data interchange issue. I'm sure there will be some way of finding out --- by looking at the source code for that phone, if nothing else.
Quoted 4 lines
But I suspect that if you are buying a phone in a first world country, you're never going to see a phone with Speck on it --- unless you build your own AOSP build and deliberately enable it for yourself, anyway. :-)
That's the question. I understand the use case, but I fear attack scenarios where someone manages to downgrade the crypto of my phone.
This is why I was asking whether Android tells me whether Speck is used or not. "it does encryption" is clearly not enough.
Thanks,
//richard
P.s. Sorry for hijacking this PR. :-)
Signature · 2 lines
sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria ATU66964118 - FN 374287y
Theodore Y. Ts'o
maintainerQuoted 4 lines · Richard Weinberger
That's the question. I understand the use case, but I fear attack scenarios where someone manages to downgrade the crypto of my phone.
This is why I was asking whether Android tells me whether Speck is used or not. "it does encryption" is clearly not enough.
An attack scenario where someone manages to downgrade the crypto of your phone would require replacing your kernel and your /system partition --- at which point, you've got other problems. :-)
- Ted
Am Dienstag, 5. Juni 2018, 19:02:08 CEST schrieb Theodore Y. Ts'o:
Quoted 9 lines · Richard Weinberger
Quoted 4 lines
That's the question. I understand the use case, but I fear attack scenarios where someone manages to downgrade the crypto of my phone.
This is why I was asking whether Android tells me whether Speck is used or not. "it does encryption" is clearly not enough.An attack scenario where someone manages to downgrade the crypto of your phone would require replacing your kernel and your /system partition --- at which point, you've got other problems. :-)
This means Speck is never enabled at kernel level on non-cheap phones?
Thanks,
//richard
Signature · 2 lines
sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria ATU66964118 - FN 374287y
Quoted 2 lines · Theodore Y. Ts'o
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/fscrypt.gittags/fscrypt_for_linus
That tag actually points to the same commit as the 'ext4_for_linus' tag pointed to.
You have the tag *message* for fscrypt, but then the commit it points to has nothing to do with fscrypt.
I think you tagged the wrong branch.
(This can also be seen in the diffstat and the shortlog - they are describing the ext4 changes).
Linus
Theodore Y. Ts'o
maintainerQuoted 5 lines · Richard Weinberger
Quoted 3 lines
An attack scenario where someone manages to downgrade the crypto of your phone would require replacing your kernel and your /system partition --- at which point, you've got other problems. :-)
This means Speck is never enabled at kernel level on non-cheap phones?
No. And even if it were, the /system partition is going to request that the kernel encrypt files using one and only encryption algorithm:
namely, AES.
Things aren't as configurable on an Android phone as you might be used to on a laptop. Some manufacturers use ext4; some manufacturers decide they want to use f2fs. They make that decision not you, and only the file system utilities for that one file system are compiled into the system.
Similarly, you don't get to choose what crypto algorithm you use; that's decided for you by the manufacturer. Which is good; it's one less thing that hte attacker can spoof, and one less thing for users to potentially get wrong.
- Ted
Theodore Y. Ts'o
maintainerQuoted 5 lines · Linus Torvalds
You have the tag *message* for fscrypt, but then the commit it points to has nothing to do with fscrypt.
I think you tagged the wrong branch.
Yeah, sorry. I used git shortlog when I was examining the branch to compose the tag message, and then I have a semi-automated script which generates the pull request. And I failed to check the arguments to
the script, as well as the output of the script. :-(
Trying again, here you go.....
The following changes since commit 75bc37fefc4471e718ba8e651aa74673d4e0a9eb:
Linux 4.17-rc4 (2018-05-06 16:57:38 -1000)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/fscrypt.git tags/fscrypt_for_linus
for you to fetch changes up to e1cc40e5d42acb1d99652babb17e6a5ee4247409:
fscrypt: log the crypto algorithm implementations (2018-05-20 16:36:00 -0400)
----------------------------------------------------------------
Add bunch of cleanups, and add support for the Speck128/256 algorithms. Yes, Speck is contrversial, but the intention is to use them only for the lowest end Android devices, where the alternative *really* is no encryption at all for data stored at rest.
----------------------------------------------------------------
Eric Biggers (18):
fscrypt: use unbound workqueue for decryption
fs, fscrypt: only define ->s_cop when FS_ENCRYPTION is enabled
fscrypt: clean up after fscrypt_prepare_lookup() conversions
fscrypt: remove unnecessary NULL check when allocating skcipher
fscrypt: remove error messages for skcipher_request_alloc() failure
fscrypt: remove stale comment from fscrypt_d_revalidate()
fscrypt: don't clear flags on crypto transform
fscrypt: don't special-case EOPNOTSUPP from fscrypt_get_encryption_info()
fscrypt: drop max_namelen check from fname_decrypt()
fscrypt: drop empty name check from fname_decrypt()
fscrypt: make fscrypt_operations.max_namelen an integer
fscrypt: remove unnecessary check for non-logon key type
fscrypt: remove internal key size constants
fscrypt: use a common logging function
fscrypt: separate key lookup from key derivation
fscrypt: only derive the needed portion of the key
fscrypt: add Speck128/256 support
fscrypt: log the crypto algorithm implementations
Documentation/filesystems/fscrypt.rst | 10 ++ fs/crypto/crypto.c | 47 +++++-- fs/crypto/fname.c | 32 ++--- fs/crypto/fscrypt_private.h | 23 ++-- fs/crypto/hooks.c | 5 +- fs/crypto/keyinfo.c | 286 ++++++++++++++++++++++++----------------- fs/ext4/super.c | 8 +- fs/f2fs/super.c | 8 +- fs/ubifs/crypto.c | 10 +- include/linux/fs.h | 4 +- include/linux/fscrypt_notsupp.h | 10 -- include/linux/fscrypt_supp.h | 16 +-- include/uapi/linux/fs.h | 2 + 13 files changed, 248 insertions(+), 213 deletions(-)