Message-ID: <20161006021625.pothakzxpbztwuwb@thunk.org>
Date:   Wed, 5 Oct 2016 22:16:25 -0400
From:   Theodore Ts'o <tytso@....edu>
To:     Dave Chinner <david@...morbit.com>
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 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.

This approach means that no changes are needed in the file system for
encrypting and decrypting the metadata blocks, and it also means that
no changes are needed in any of the e2fsprogs userspace utiliies
(which except for debugfs and fuse2fs, only read metadata blocks).
Well, resize2fs wouldn't work since it would try to move data blocks
around, but eMMC memory is generally not resizeable, so it all works
out at least for mobile devices, and if we really want to support this
for resizeable devices, we could teach resize2fs a way to signal to
the block device which blocks are data blocks and so the ICE layer
should be passed during a file system shrink operation.

So if we move to a model where we move the actual block
encryption/decryption into a dm-crypt like layer (instead of doing it
in fs/ext4/page_io.c as we currently do for ext4's fs crypto support),
we minimize the changes needed in the file systems --- since all we
need to do is to pass the key identifier into the bio layer, and key
identifier management can be done in the fs/crypto layer, and so on
top of the other benefits, we get the ability to support generalized
hardware ICE acceleration and metadata encryption for a relatively
tiny investment of effort.

Yes, this won't work for ubifs, but ubifs is a bit of an outlier, and
unless we think we want to support any other MTD file systems, we may
just simply need make things flexible enough so that ubifs can do its
own thing as far as hardware acceleration is concerned.

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

Powered by blists - more mailing lists