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] [day] [month] [year] [list]

Message-ID: <20161229010149.GA12683@zzz>
Date:   Wed, 28 Dec 2016 19:01:49 -0600
From:   Eric Biggers <ebiggers3@...il.com>
To:     Theodore Ts'o <tytso@....edu>
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 07:45:26PM -0500, Theodore Ts'o wrote:
> 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.
> 

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
--
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