[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YCMZSjgUDtxaVem3@mit.edu>
Date: Tue, 9 Feb 2021 18:22:50 -0500
From: "Theodore Ts'o" <tytso@....edu>
To: Andreas Dilger <adilger@...ger.ca>
Cc: Daniel Rosenberg <drosen@...gle.com>,
Eric Biggers <ebiggers@...nel.org>,
Andreas Dilger <adilger.kernel@...ger.ca>,
linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org,
Gabriel Krisman Bertazi <krisman@...labora.com>,
kernel-team@...roid.com, Paul Lawrence <paullawrence@...gle.com>
Subject: Re: [PATCH 1/2] ext4: Handle casefolding with encryption
On Wed, Feb 03, 2021 at 11:31:28AM -0500, Theodore Ts'o wrote:
> On Wed, Feb 03, 2021 at 03:55:06AM -0700, Andreas Dilger wrote:
> >
> > It looks like this change will break the dirdata feature, which is similarly
> > storing a data field beyond the end of the dirent. However, that feature also
> > provides for flags stored in the high bits of the type field to indicate
> > which of the fields are in use there.
> > The first byte of each field stores
> > the length, so it can be skipped even if the content is not understood.
>
> Daniel, for context, the dirdata field is an out-of-tree feature which
> is used by Lustre, and so has fairly large deployed base. So if there
> is a way that we can accomodate not breaking dirdata, that would be
> good.
>
> Did the ext4 casefold+encryption implementation escape out to any
> Android handsets?
So from an OOB chat with Daniel, it appears that the ext4
casefold+encryption implementation did in fact escape out to Android
handsets. So I think what we will need to do, ultiumately, is support
one way of supporting the casefold IV in the case where "encryption &&
casefold", and another way when "encryption && casefold && dirdata".
That's going to be a bit sucky, but I don't think it should be that
complex. Daniel, Andreas, does that make sense to you?
- Ted
Powered by blists - more mailing lists