On Wed, Dec 28, 2016 at 07:45:26PM -0500, Theodore Ts'o wrote:

On Wed, Dec 28, 2016 at 03:27:59PM -0600, Eric Biggers wrote:

quoted

This problem would also be fixed by my patch to make the test_dummy_encryption
encryption keys go through the regular keyring lookup and key derivation paths,
which IMO is a better solution long-term:

	fscrypt / ext4: make test_dummy_encryption require a keyring key

and corresponding xfstests-bld patch:

	xfstests-bld: populate keyring with default key for test_dummy_encryption

My problem with this patch is that it breaks backwards compatibility
with older kernels --- such as the 3.10 and 3.18 kernels currently
shipping today in Android handsets.  So I don't want to make changes
to xfstests-bld that require specific kernel patches which aren't
necesarily available on existing kernels which are in use in
production today.

And it won't necessarily be simple to get your fscrypt/ext4 change
into all of the various Android device kernels, the android-common
kernels, the unreleased device kernels in use at various handset
manufactuers, etc.

Actually the patched xfstests-bld can still test both old and new kernels.
Therefore there would be no need to backport the kernel patch.  The xfstests-bld
patch just adds a key to the keyring, which new kernels will use but old kernels
won't (since when test_dummy_encryption is enabled, old kernels don't look at
the keyring at all).

Granted, there is breakage in the other direction --- the kernel change breaks
the current xfstests-bld --- but that's not really an issue since we can just
update xfstests-bld.

Eric