From: Eric Biggers <ebiggers@kernel.org>
To: Jeff Layton <jlayton@kernel.org>
Cc: linux-fscrypt@vger.kernel.org
Subject: Re: fscrypt, i_blkbits and network filesystems
Date: Fri, 9 Oct 2020 14:50:05 -0700 [thread overview]
Message-ID: <20201009215005.GB839@sol.localdomain> (raw)
In-Reply-To: <5e3273e2a2c8d95b5dfd77c35e133767d4e32e29.camel@kernel.org>
On Fri, Oct 09, 2020 at 04:16:38PM -0400, Jeff Layton wrote:
> On Thu, 2020-10-08 at 10:46 -0700, Eric Biggers wrote:
> >
> > First, you should avoid using "PAGE_SIZE" as the crypto data unit size, since
> > PAGE_SIZE isn't the same everywhere. E.g. PAGE_SIZE is 4096 bytes on x86, but
> > usually 65536 bytes on PowerPC. If encrypted files are created on x86, they
> > should be readable on PowerPC too, and vice versa. That means the crypto data
> > unit size should be a specific value, generally 4096 bytes. But other
> > power-of-2 sizes could be allowed too.
> >
>
> Ok, good point.
>
> Pardon my lack of crypto knowledge, but I assume we have to ensure that
> we use the same crypto block size everywhere for the same inode as well?
> i.e., I can't encrypt a 4k block and then read in and decrypt a 16 byte
> chunk of it?
That's basically correct. As I mentioned earlier: For AES-XTS specifically,
*in principle* it's possible to encrypt/decrypt an individual 16-byte aligned
region. But Linux's crypto API doesn't currently support sub-message crypto,
and also fscrypt supports the AES-CBC and Adiantum encryption modes which have
stricter requirements.
> > Second, I'm not really understanding what the problem is with setting i_blkbits
> > for IS_ENCRYPTED() inodes to the log2 of the crypto data unit size. Wouldn't
> > that be the right thing to do? Even though it wouldn't have any meaning for the
> > server, it would have a meaning for the client -- it would be the granularity of
> > encryption (and decryption).
> >
>
> It's not a huge problem. I was thinking there might be an issue with
> some applications, but I don't think it really matters. The blocksize
> reported by stat is sort of a nebulous concept anyway when you get to a
> network filesystem.
>
> The only real problem we have is that an application might pass down an
> I/O that is smaller than 4k, but we haven't been granted the capability
> to do buffered I/O. In that situation, we'll need to read what's there
> now (if anything) and then dispatch a synchronous write op that is gated
> on that data not having changed.
>
> There's some benefit to dealing with as small a chunk of data as we can,
> but 4k is probably a reasonable chunk to work with in most cases if
> that's not possible.
Applications can do reads/writes of any length regardless of what they see in
stat::st_blksize. So you're going to have to support reads/writes with length
less than the data unit size (granularity of encryption) anyway.
You can choose whatever data unit size you want; it's a trade-off between the
fixed overhead of doing each encryption/decryption operation, and the
granularity of I/O that you want to support. I'd assume that 4096 bytes would
be a good compromise for ceph, like it is for the other filesystems. It also
matches PAGE_SIZE on most platforms. But it's possible that something else
would be better.
- Eric
prev parent reply other threads:[~2020-10-09 21:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-08 12:25 fscrypt, i_blkbits and network filesystems Jeff Layton
2020-10-08 17:46 ` Eric Biggers
2020-10-09 20:16 ` Jeff Layton
2020-10-09 21:50 ` Eric Biggers [this message]
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=20201009215005.GB839@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=jlayton@kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
/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).