[GIT PULL] fscrypt updates for 4.18

[GIT PULL] fscrypt updates for 4.18

[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.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(-)

Re: [GIT PULL] fscrypt updates for 4.18

[Richard Weinberger]

Ted,

On Tue, Jun 5, 2018 at 5:07 PM, Theodore Y. Ts'o <tytso@mit.edu> wrote:
> 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 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.

Will Android tell me that Speck is being used?

-- 
Thanks,
//richard

Re: [GIT PULL] fscrypt updates for 4.18

[Theodore Y. Ts'o]

On Tue, Jun 05, 2018 at 05:13:35PM +0200, Richard Weinberger wrote:
> > 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

Re: [GIT PULL] fscrypt updates for 4.18

[Richard Weinberger]

Am Dienstag, 5. Juni 2018, 17:35:01 CEST schrieb Theodore Y. Ts'o:
> On Tue, Jun 05, 2018 at 05:13:35PM +0200, Richard Weinberger wrote:
> > > 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.  :-)

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. :-)

-- 
sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria
ATU66964118 - FN 374287y

Re: [GIT PULL] fscrypt updates for 4.18

[Theodore Y. Ts'o]

On Tue, Jun 05, 2018 at 06:10:24PM +0200, Richard Weinberger wrote:
> 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

Re: [GIT PULL] fscrypt updates for 4.18

[Richard Weinberger]

Am Dienstag, 5. Juni 2018, 19:02:08 CEST schrieb Theodore Y. Ts'o:
> On Tue, Jun 05, 2018 at 06:10:24PM +0200, Richard Weinberger wrote:
> > 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

-- 
sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria
ATU66964118 - FN 374287y

Re: [GIT PULL] fscrypt updates for 4.18

[Linus Torvalds]

On Tue, Jun 5, 2018 at 8:07 AM Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/tytso/fscrypt.git tags/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

Re: [GIT PULL] fscrypt updates for 4.18

[Theodore Y. Ts'o]

On Tue, Jun 05, 2018 at 07:05:52PM +0200, Richard Weinberger wrote:
> > 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

Re: [GIT PULL] fscrypt updates for 4.18

[Theodore Y. Ts'o]

On Tue, Jun 05, 2018 at 01:22:41PM -0700, Linus Torvalds wrote:
> 
> 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(-)