From: Eric Biggers <ebiggers3@gmail.com>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: Gwendal Grignou <gwendal@chromium.org>,
hashimoto@chromium.org, ebiggers@google.com,
linux-f2fs-devel@lists.sourceforge.net,
linux-fscrypt@vger.kernel.org, linux-mtd@lists.infradead.org,
tytso@mit.edu, linux-ext4@vger.kernel.org, kinaba@chromium.org
Subject: Re: [f2fs-dev] [PATCH] fscrypt: use 32 bytes of encrypted filename
Date: Fri, 21 Apr 2017 12:26:25 -0700 [thread overview]
Message-ID: <20170421192625.GD12755@gmail.com> (raw)
In-Reply-To: <20170421173503.GA1228@jaegeuk.local>
Hi Jaegeuk,
On Fri, Apr 21, 2017 at 10:35:03AM -0700, Jaegeuk Kim wrote:
>
> > In any case, I guess that unless there are other ideas we can do these patches:
> >
> > 1.) f2fs patch to start checking the name, as above
> > 2.) patch to start encoding last 32 bytes of the name (or second-to-last CTS
> > block, I haven't decided yet) rather than last 16 bytes, changing
> > fs/crypto/, fs/ext4/, and fs/f2fs/
> > 3.) cleanup patches to introduce helper function and switch ext4 and f2fs to it
>
> IMO, it'd better to do 3.) followed by 2.), since 2.) already needs to change
> fs/crypto which does not give much backporting effort.
>
That would be ideal, but unfortunately the main users of filesystem encryption
are using old kernel versions which don't have fs/crypto/, usually 4.4 at
latest. So it would be nice for it to be easier to backport the "use different
bytes from the encrypted filename" change to 4.4-stable, as I've been doing for
some of the other filesystem encryption fixes. And people do need it, it seems,
as it causes real problems like undeletable files; Gwendal is even already
trying to merge a fix into some Chrome OS kernel.
>
> I found one issue in my patch and modified it in f2fs tree [1]. Given next merge
> window probable starting next week, let me upstream this modified one first
> through f2fs. Then, you can see it in 4.12-rc1 two weeks later, so fscrypt
> patches can be easily integrated after then. If you have any concern, I'm also
> okay to push this patch through fscrypt. Let me know.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git/commit/?h=dev-test&id=1585cfbbb269be6a112e0629a52123c0f9eaf4fa
>
I think the series through fscrypt makes more sense, though if I don't have it
ready soon please go ahead and take the f2fs portion through the f2fs tree.
Thanks!
- Eric
next prev parent reply other threads:[~2017-04-21 19:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20170418210642.6039-1-gwendal@chromium.org>
2017-04-18 23:01 ` [PATCH] fscrypt: use 32 bytes of encrypted filename Eric Biggers
2017-04-19 0:10 ` Eric Biggers
2017-04-19 1:42 ` [f2fs-dev] " Jaegeuk Kim
2017-04-19 4:01 ` Eric Biggers
2017-04-19 20:44 ` Jaegeuk Kim
2017-04-21 7:44 ` Eric Biggers
2017-04-21 17:21 ` Gwendal Grignou
2017-04-21 18:53 ` [f2fs-dev] " Eric Biggers
2017-04-21 17:35 ` Jaegeuk Kim
2017-04-21 19:26 ` Eric Biggers [this message]
2017-04-19 20:31 ` Gwendal Grignou
2017-04-19 13:40 ` Richard Weinberger
2017-04-19 17:16 ` Eric Biggers
2017-04-19 17:21 ` Richard Weinberger
2017-04-24 21:19 ` Richard Weinberger
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=20170421192625.GD12755@gmail.com \
--to=ebiggers3@gmail.com \
--cc=ebiggers@google.com \
--cc=gwendal@chromium.org \
--cc=hashimoto@chromium.org \
--cc=jaegeuk@kernel.org \
--cc=kinaba@chromium.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=tytso@mit.edu \
/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).