linux-ext4 - Re: [PATCH] fscrypt: fix the test_dummy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 28 Dec 2016 19:45:26 -0500
From:   Theodore Ts'o <tytso@....edu>
To:     Eric Biggers <ebiggers3@...il.com>
Cc:     Linux Filesystem Development List <linux-fsdevel@...r.kernel.org>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        stable@...r.kernel.org
Subject: Re: [PATCH] fscrypt: fix the test_dummy_encryption mount option

On Wed, Dec 28, 2016 at 03:27:59PM -0600, Eric Biggers wrote:
> 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.

I don't know if there are going to be a lot of device handset
manufacturers outside of Google that will be trying to make
xfstests-bld work on Android, or by compiling a device kernel on x86
and then running kvm-xfstests or gce-xfstests as the only easy way to
test an Android kernel --- but if someone from some handset
manufacturer comes up to me and asks me for help debugging ext4
encryption, I'd much rather be able to point them at the standard
kvm-xfstests image and tell them it will work with their device kernel
which was based off of the 3.10 or 3.18 android-common git tree.

Cheers,

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html