Date:   Fri, 7 Oct 2016 09:23:51 +1100
From:   Dave Chinner <david@...morbit.com>
To:     Theodore Ts'o <tytso@....edu>
Cc:     Richard Weinberger <richard@....at>,
        Michael Halcrow <mhalcrow@...gle.com>,
        David Gstir <david@...ma-star.at>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net,
        jaegeuk@...nel.org, Eric Biggers <ebiggers@...gle.com>,
        Anand Jain <anand.jain@...cle.com>,
        Tyler Hicks <tyhicks@...onical.com>
Subject: Re: [PATCH] fscrypto: make XTS tweak initialization
 endian-independent

On Wed, Oct 05, 2016 at 10:16:25PM -0400, Theodore Ts'o wrote:
> On Thu, Oct 06, 2016 at 12:17:15PM +1100, Dave Chinner wrote:
> > This is the sanest approach, because encrypting filesystem internal
> > metadata may have some unintended consequences. e.g being unable to
> > perform forensic analysis of corruption or data loss events, or an
> > inability for tools like fsck to work without also implementing all
> > the encryption code in userspace and being provided with all the
> > keys needed to decrypt the metadata.
> 
> Absolutely. 
> 
> > i.e. it's not just the kernel code we have to consider here when
> > discussing this level of encryption in filesystems - the impact
> > on the entire support ecosystem needs to be considered. A weakness
> > in a fsck tool will be just as serious as a weakness in the kernel
> > code, and there's a much larger amount of widely dispersed code that
> > would need to be encryption enabled by going down this path.
> 
> An approach that works fairly well, which doesn't require any
> userspace changes, is one where if you are using a hardware
> accelerated, in-line crypto engine, and where you are sending the key
> identifier to be used down through the block layer in the bio request,
> is to define a particular key as the "default" key to be used if a key
> is not specified in the bio request.
> 
> So if the file system doesn't send down an explicit key identifier for
> its metadata reads/write requests, the block device essentially acts
> like a dm-crypt device --- except the hardware is doing the encryption
> so it's nice and fast.

At which point, I have to ask, why not just use dm-crypt and
implement a simple "use device key on bio contents if none has been
specified by higher layer" mechanism to direct the encryption?  It's
simple, you can still offload the crypto to your hardware, requires
minimal extra plumbing, and no userspace tooling changes. This
allows the user data on a dm-crypt to be encrypted with a user
specified key so even is the device key is compromised their data is
not (and vice versa).

As for non-block device filesystems like UBIFS, I'd suggest that
their "storage layer" that the filesytem sits on top of could do the
same thing - any request that doesn't have a key supplied gets
encrypted using the device key. i.e. the filesystem layers use the
same implementation, but the underlying storage device implements
the encryption interface according to the requirements of the
subsystem.

i.e. I don't think we should be trying to implement a single layer
that supports both block and non-block filesystems here. However, we
can still architect a solution where the filesystem level code is
independent of the underlying storage encryption implementation.  In
this sort of architecture, the filesystem only does key management
and deals with unencrypted data and metadata, whilst the underlying
storage layer implements the (hardware accelerated) encryption as
the data passes through...

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
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

Powered by blists - more mailing lists