From: Theodore Ts'o <tytso@mit.edu>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Anssi Hannula <anssi.hannula@iki.fi>,
Andreas Dilger <adilger.kernel@dilger.ca>,
linux-ext4@vger.kernel.org, Michael Halcrow <mhalcrow@google.com>
Subject: Re: ext4 crypto: Do not select from EXT4_FS_ENCRYPTION
Date: Sun, 3 May 2015 21:37:24 -0400 [thread overview]
Message-ID: <20150504013724.GM10014@thunk.org> (raw)
In-Reply-To: <20150504010016.GA23560@gondor.apana.org.au>
On Mon, May 04, 2015 at 09:00:16AM +0800, Herbert Xu wrote:
>
> Sorry for the confusion. Please just revert my patch.
>
> I was trying to figure out what was causing various crypto modules
> to be built-in in my test config and this was the latest change that
> *looked* as if it might have caused my problem. Obviously I didn't
> test it properly after making that change.
>
> It should just be reverted because if ext4 was built-in then you
> do want to have the crypto stuff built-in just in case the root fs
> was encrypted.
Whoops, I _just_ sent a pull request to Linus. The patch as it stands
actually allows both behaviors, depending on whether you answer 'y' or
'm' to EXT4_ENCRYPTION question. Given that one of the main purposes
of per-filesystem encryption is that we only have to encrypt the user
files, so the system files can remain unencrypted for performance
reasons[1], I can imagine scenarios where it's conceivable that
someone might want to keep the crypto as modules. My main unhappiness
with the Kconfig option is that it's a bit user unfriendly/confusing
what it means for CONFIG_EXT4_ENCRYPTION to be 'y' versus 'm'.
So I may end up reverting it, but since I've already sent the pull
request to Linus, I'm going to sleep on this for a bit.
Cheers,
- Ted
[1] Though not for Intel chips; Intel acceleration of AES is so fast
there you might as well encrypt everything; and for single-user
laptops I still recommend dm-crypt. Unfortunately, there are some ARM
chips which either do not have hardware accelerated AES, or where
their hardware accleration is decidedly poor....
prev parent reply other threads:[~2015-05-04 1:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-01 0:18 ext4 crypto: Do not select from EXT4_FS_ENCRYPTION Herbert Xu
2015-05-02 13:40 ` Theodore Ts'o
2015-05-03 12:34 ` Anssi Hannula
2015-05-03 17:53 ` Theodore Ts'o
2015-05-03 18:29 ` Anssi Hannula
2015-05-03 21:11 ` Theodore Ts'o
2015-05-04 1:00 ` Herbert Xu
2015-05-04 1:37 ` Theodore Ts'o [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=20150504013724.GM10014@thunk.org \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=anssi.hannula@iki.fi \
--cc=herbert@gondor.apana.org.au \
--cc=linux-ext4@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.