Message-ID: <20150516132403.GA2998@thunk.org>
Date:	Sat, 16 May 2015 09:24:03 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Dave Chinner <david@...morbit.com>
Cc:	Jaegeuk Kim <jaegeuk@...nel.org>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org,
	linux-f2fs-devel@...ts.sourceforge.net
Subject: Re: [PATCH 03/18] f2fs crypto: declare some definitions for f2fs
 encryption feature

On Thu, May 14, 2015 at 10:37:21AM +1000, Dave Chinner wrote:
> > 
> > AFAIK, Ted wants to push the codes as a crypto library into fs/ finally, so
> > I believe most part of crypto codes are common.
> 
> Can I suggest fs/crypto/ if there are going to be multiple files?

Yes, I think we definitely want to do this as fs/crypto; it makes
things a bit more straightforward on a number of fronts; not just from
a Makefile point of view, but also in setting up a separate tree to
push into linux-next.

> > But, in order to realize that quickly, Ted implemented the feature to finalize
> > on-disk and in-memory design in EXT4 as a first step.
> > Then, I've been catching up and validating its design by implementing it in
> > F2FS, which also intends to figure out what crypto codes can be exactly common.
> 
> Excellent. That will make it easier and less error prone for other
> filesystems to implement it, too!

Yeah, that's why I figured it would be easier to get it into ext4 and
f2fs first.  We can keep the functions in sync for a release or so,
and then we can start creating patches that gradually move each of
fs/{ext4,f2fs}/{crypto,crypo_fname,crypto_policy}.c, etc. into a
common fs/crypto directory.  I'm sure there will be a bit of
refactoring that will be necessary as we go along, but it will be a
lot easier to validate that we've gotten things once we have to file
systems both depending on the common code.

If Michael and I had tried to create fs/cryto up-front, I'm *sure* we
would have gotten a number of things wrong.  :-)

> > Meanwhile, surely I've been working on writing patches to push them into fs/;
> > currenlty, I did for cryto.c and will do for crypto_key.c and crypto_fname.c.
> > But, it needs to think about crypto_policy.c differently, since it may depend
> > on how each filesystem stores the policy information respectively; we cannot
> > push all the filesystems should use xattrs, right?
> 
> All filesystems likely to implement per-file crypto support xattrs,
> and this is exactly what xattrs are designed for. e.g. we already
> require xattrs for generic security labels, ACLs, etc. Hence
> per-file crypto information should also use a common, shared xattr
> format. That way it only needs to be implemented once in the generic
> code and there's very little (hopefully nothing!) each filesystem
> has to customise to store the crypto information for each file.

Yes, absolutely.  What's going to be more difficult in the long run is
when we want to support per-block data integrity, using (for example)
AES/GCM, which will require 32 bytes of per-block "authentication tag"
(think Message Authentication Code) that have to be committed
atomically with the data block write.

Quite frankly, this is going to be much easier for COW file systems
like f2fs and btrfs.  I have some ideas about how to do this for
update-in-place file systems (using either a compression hack and/or
storing two generations worth of authentication tag per block), but
it's not pretty.  (Or in the case of ext4 we could use
data=journalling mode, but that's even less pretty from a performance
standpoint.)

Cheers,

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

Powered by blists - more mailing lists