linux-f2fs-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net, mhalcrow@google.com
Subject: Re: [PATCH] f2fs crypto: use inode number for xts_tweak
Date: Tue, 12 May 2015 19:35:57 -0400	[thread overview]
Message-ID: <20150512233557.GA2969@thunk.org> (raw)
In-Reply-To: <1431402663-24809-1-git-send-email-jaegeuk@kernel.org>

On Mon, May 11, 2015 at 08:51:03PM -0700, Jaegeuk Kim wrote:
> Previoulsy when making xts_tweak, page->index was used.
> But, when it supports fcollapse, the block address was moved, so that we can
> lose the original page->index, which causes decrytion failure.
> 
> In order to avoid that, let's use the inode->i_ino for xfs_tweak hint.

I'm afraid that's a really bad idea.  We need to have a different xts
tweak for each block, and if we use the inode number, then every
single block will have the same XTS tweak, which is a cryptographic
disaster.

Basically, we currently can't support either collapse range or insert
range for encrypted files.  In ext4 we explicitly return EOPNOTSUPP if
there is an attempt to call collapse range on an encrypted file.
Personally, I don't think this is a major restriction, so I haven't
lost any sleep over this.

Eventually, Michael and I hope to add support for Galois Counter Mode,
but that requires the file system to be able to store per-block
cryptrographic information, which can be used for the GCM
authentication tag as well as a per-block IV.  The per-block IV being
stored in a separate data structure would also allow insert
range/collapse range to work, at the cost of needing to do a lookup to
fetch the per-block cryptographic information.  (And to set the
per-block cryptographic information when writing the information, in a
way where we can atomically write the data block as well as the
per-block authenticaiton tag, which gets a bit tricky....)

In any case, I believe support for data integrity is a far more
compelling reason for adding pre-block crypto information, and
supporting collapse/insert range is at best a fortunate side effect.

Cheers,

						- Ted

  reply	other threads:[~2015-05-12 23:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-12  3:51 [PATCH] f2fs crypto: use inode number for xts_tweak Jaegeuk Kim
2015-05-12 23:35 ` Theodore Ts'o [this message]
2015-05-13  0:20   ` Jaegeuk Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150512233557.GA2969@thunk.org \
    --to=tytso@mit.edu \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhalcrow@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).