Re: [PATCH v2] fscrypt: Factor out bio specific functions
On Sat, Jan 07, 2017 at 11:40:15PM +0100, Richard Weinberger wrote: > Kconfig is tricky. We face a build error with CONFIG_BLOCK=n with > UBIFS_FS_ENCRYPTION enabled. > UBIFS file encryption does "select FS_ENCRYPTION" just like ext4 and f2fs. > This will enable ENCRYPTION even when no block support is available. It's the good old select vs depends mess once again. > I can make UBIFS depend on BLOCK as intermediate fix. > But the real fix is this patch. And despite the diffstat it's simple and trivial as it just moves code. There is no good reason not to take it for 4.10.
Re: [PATCH v2] fscrypt: Factor out bio specific functions
Ted, Am 07.01.2017 um 20:24 schrieb Theodore Ts'o: > On Wed, Jan 04, 2017 at 12:10:43PM -0800, Eric Biggers wrote: >> >> I thought you're supposed to be able to build the kernel no matter how it's >> configured. If this patch is really too large for 4.10 then perhaps we >> should >> make FS_ENCRYPTION select CONFIG_BLOCK instead? > > We already have FS_ENCRYPTIOn depending on BLOCK, so this is *not* > fixing a build break. Kconfig is tricky. We face a build error with CONFIG_BLOCK=n with UBIFS_FS_ENCRYPTION enabled. UBIFS file encryption does "select FS_ENCRYPTION" just like ext4 and f2fs. This will enable ENCRYPTION even when no block support is available. I can make UBIFS depend on BLOCK as intermediate fix. But the real fix is this patch. Thanks, //richard
Re: [PATCH v2] fscrypt: Factor out bio specific functions
On Wed, Jan 04, 2017 at 12:10:43PM -0800, Eric Biggers wrote: > > I thought you're supposed to be able to build the kernel no matter how it's > configured. If this patch is really too large for 4.10 then perhaps we should > make FS_ENCRYPTION select CONFIG_BLOCK instead? We already have FS_ENCRYPTIOn depending on BLOCK, so this is *not* fixing a build break. Given that, it's a bit harder to claim this is a must-have bug fix for the stable branch? - Ted
Re: [PATCH v2] fscrypt: Factor out bio specific functions
Am 04.01.2017 um 21:10 schrieb Eric Biggers:
> On Tue, Jan 03, 2017 at 09:28:36AM -0500, Theodore Ts'o wrote:
>> On Tue, Jan 03, 2017 at 10:49:26AM +0100, Richard Weinberger wrote:
>>> Ted,
>>>
>>> Am 01.01.2017 um 22:47 schrieb Theodore Ts'o:
On Mon, Dec 19, 2016 at 12:25:32PM +0100, Richard Weinberger wrote:
> That way we can get rid of the direct dependency on CONFIG_BLOCK.
>
> Reported-by: Arnd Bergmann
> Reported-by: Randy Dunlap
> Suggested-by: Christoph Hellwig
> Fixes: d475a507457b ("ubifs: Add skeleton for fscrypto")
> Signed-off-by: Richard Weinberger
Applied, thanks.
>>>
>>> Just to make sure, this fixes a build error and should
>>> go into Linus' tree ASAP.
>>
>> I didn't consider this a build error since it could be fixed via a
>> config change. And it is a pretty big patch, even if it is mostly
>> moving (not that git recognized it as such)...
>>
>
> I thought you're supposed to be able to build the kernel no matter how it's
> configured. If this patch is really too large for 4.10 then perhaps we should
> make FS_ENCRYPTION select CONFIG_BLOCK instead?
My initial plan was a config fix but hch asked to fix the root cause right now.
https://lkml.org/lkml/2016/12/16/118
Thanks,
//richard
Re: [PATCH v2] fscrypt: Factor out bio specific functions
On Tue, Jan 03, 2017 at 09:28:36AM -0500, Theodore Ts'o wrote:
> On Tue, Jan 03, 2017 at 10:49:26AM +0100, Richard Weinberger wrote:
> > Ted,
> >
> > Am 01.01.2017 um 22:47 schrieb Theodore Ts'o:
> > > On Mon, Dec 19, 2016 at 12:25:32PM +0100, Richard Weinberger wrote:
> > >> That way we can get rid of the direct dependency on CONFIG_BLOCK.
> > >>
> > >> Reported-by: Arnd Bergmann
> > >> Reported-by: Randy Dunlap
> > >> Suggested-by: Christoph Hellwig
> > >> Fixes: d475a507457b ("ubifs: Add skeleton for fscrypto")
> > >> Signed-off-by: Richard Weinberger
> > >
> > > Applied, thanks.
> >
> > Just to make sure, this fixes a build error and should
> > go into Linus' tree ASAP.
>
> I didn't consider this a build error since it could be fixed via a
> config change. And it is a pretty big patch, even if it is mostly
> moving (not that git recognized it as such)...
>
I thought you're supposed to be able to build the kernel no matter how it's
configured. If this patch is really too large for 4.10 then perhaps we should
make FS_ENCRYPTION select CONFIG_BLOCK instead?
Eric
Re: [PATCH v2] fscrypt: Factor out bio specific functions
On Tue, Jan 03, 2017 at 10:49:26AM +0100, Richard Weinberger wrote:
> Ted,
>
> Am 01.01.2017 um 22:47 schrieb Theodore Ts'o:
> > On Mon, Dec 19, 2016 at 12:25:32PM +0100, Richard Weinberger wrote:
> >> That way we can get rid of the direct dependency on CONFIG_BLOCK.
> >>
> >> Reported-by: Arnd Bergmann
> >> Reported-by: Randy Dunlap
> >> Suggested-by: Christoph Hellwig
> >> Fixes: d475a507457b ("ubifs: Add skeleton for fscrypto")
> >> Signed-off-by: Richard Weinberger
> >
> > Applied, thanks.
>
> Just to make sure, this fixes a build error and should
> go into Linus' tree ASAP.
I didn't consider this a build error since it could be fixed via a
config change. And it is a pretty big patch, even if it is mostly
moving (not that git recognized it as such)...
git show --stat -M 58ae74683ae2c07cd717a91799edb50231061938
commit 58ae74683ae2c07cd717a91799edb50231061938
Author: Richard Weinberger
Date: Mon Dec 19 12:25:32 2016 +0100
fscrypt: factor out bio specific functions
That way we can get rid of the direct dependency on CONFIG_BLOCK.
Fixes: d475a507457b ("ubifs: Add skeleton for fscrypto")
Reported-by: Arnd Bergmann
Reported-by: Randy Dunlap
Reviewed-by: Eric Biggers
Reviewed-by: Christoph Hellwig
Reviewed-by: David Gstir
Signed-off-by: Richard Weinberger
Signed-off-by: Theodore Ts'o
fs/crypto/Kconfig | 1 -
fs/crypto/Makefile | 1 +
fs/crypto/bio.c | 145
++
fs/crypto/crypto.c | 157
+
fs/crypto/fscrypt_private.h | 16 -
include/linux/fscrypto.h| 11 +++---
6 files changed, 184 insertions(+), 147 deletions(-)
- Ted
Re: [PATCH v2] fscrypt: Factor out bio specific functions
Ted,
Am 01.01.2017 um 22:47 schrieb Theodore Ts'o:
> On Mon, Dec 19, 2016 at 12:25:32PM +0100, Richard Weinberger wrote:
>> That way we can get rid of the direct dependency on CONFIG_BLOCK.
>>
>> Reported-by: Arnd Bergmann
>> Reported-by: Randy Dunlap
>> Suggested-by: Christoph Hellwig
>> Fixes: d475a507457b ("ubifs: Add skeleton for fscrypto")
>> Signed-off-by: Richard Weinberger
>
> Applied, thanks.
Just to make sure, this fixes a build error and should
go into Linus' tree ASAP.
Thanks,
//richard
Re: [PATCH v2] fscrypt: Factor out bio specific functions
On Mon, Dec 19, 2016 at 12:25:32PM +0100, Richard Weinberger wrote:
> That way we can get rid of the direct dependency on CONFIG_BLOCK.
>
> Reported-by: Arnd Bergmann
> Reported-by: Randy Dunlap
> Suggested-by: Christoph Hellwig
> Fixes: d475a507457b ("ubifs: Add skeleton for fscrypto")
> Signed-off-by: Richard Weinberger
Applied, thanks.
- Ted
Re: [PATCH v2] fscrypt: Factor out bio specific functions
Hi,
> On 19.12.2016, at 12:25, Richard Weinberger wrote:
>
> That way we can get rid of the direct dependency on CONFIG_BLOCK.
>
> Reported-by: Arnd Bergmann
> Reported-by: Randy Dunlap
> Suggested-by: Christoph Hellwig
> Fixes: d475a507457b ("ubifs: Add skeleton for fscrypto")
> Signed-off-by: Richard Weinberger
> ---
> Changes since v1:
> - Moved fscrypt_zeroout_range() also to bio.c
Looks good to me.
Reviewed-by: David Gstir
- David
Re: [PATCH v2] fscrypt: Factor out bio specific functions
Looks fine, Reviewed-by: Christoph Hellwig
Re: [PATCH v2] fscrypt: Factor out bio specific functions
On Mon, Dec 19, 2016 at 12:25:32PM +0100, Richard Weinberger wrote:
> That way we can get rid of the direct dependency on CONFIG_BLOCK.
>
> Reported-by: Arnd Bergmann
> Reported-by: Randy Dunlap
> Suggested-by: Christoph Hellwig
> Fixes: d475a507457b ("ubifs: Add skeleton for fscrypto")
> Signed-off-by: Richard Weinberger
> ---
> Changes since v1:
> - Moved fscrypt_zeroout_range() also to bio.c
Reviewed-by: Eric Biggers
Thanks,
Eric
[PATCH v2] fscrypt: Factor out bio specific functions
That way we can get rid of the direct dependency on CONFIG_BLOCK.
Reported-by: Arnd Bergmann
Reported-by: Randy Dunlap
Suggested-by: Christoph Hellwig
Fixes: d475a507457b ("ubifs: Add skeleton for fscrypto")
Signed-off-by: Richard Weinberger
---
Changes since v1:
- Moved fscrypt_zeroout_range() also to bio.c
---
fs/crypto/Kconfig | 1 -
fs/crypto/Makefile | 1 +
fs/crypto/bio.c | 145
fs/crypto/crypto.c | 157 +---
fs/crypto/fscrypt_private.h | 16 -
include/linux/fscrypto.h| 11 ++--
6 files changed, 184 insertions(+), 147 deletions(-)
create mode 100644 fs/crypto/bio.c
diff --git a/fs/crypto/Kconfig b/fs/crypto/Kconfig
index f514978f6688..08b46e6e3995 100644
--- a/fs/crypto/Kconfig
+++ b/fs/crypto/Kconfig
@@ -1,6 +1,5 @@
config FS_ENCRYPTION
tristate "FS Encryption (Per-file encryption)"
- depends on BLOCK
select CRYPTO
select CRYPTO_AES
select CRYPTO_CBC
diff --git a/fs/crypto/Makefile b/fs/crypto/Makefile
index f17684c48739..9f6607f17b53 100644
--- a/fs/crypto/Makefile
+++ b/fs/crypto/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_FS_ENCRYPTION)+= fscrypto.o
fscrypto-y := crypto.o fname.o policy.o keyinfo.o
+fscrypto-$(CONFIG_BLOCK) += bio.o
diff --git a/fs/crypto/bio.c b/fs/crypto/bio.c
new file mode 100644
index ..a409a84f1bca
--- /dev/null
+++ b/fs/crypto/bio.c
@@ -0,0 +1,145 @@
+/*
+ * This contains encryption functions for per-file encryption.
+ *
+ * Copyright (C) 2015, Google, Inc.
+ * Copyright (C) 2015, Motorola Mobility
+ *
+ * Written by Michael Halcrow, 2014.
+ *
+ * Filename encryption additions
+ * Uday Savagaonkar, 2014
+ * Encryption policy handling additions
+ * Ildar Muslukhov, 2014
+ * Add fscrypt_pullback_bio_page()
+ * Jaegeuk Kim, 2015.
+ *
+ * This has not yet undergone a rigorous security audit.
+ *
+ * The usage of AES-XTS should conform to recommendations in NIST
+ * Special Publication 800-38E and IEEE P1619/D16.
+ */
+
+#include
+#include
+#include
+#include
+#include "fscrypt_private.h"
+
+/*
+ * Call fscrypt_decrypt_page on every single page, reusing the encryption
+ * context.
+ */
+static void completion_pages(struct work_struct *work)
+{
+ struct fscrypt_ctx *ctx =
+ container_of(work, struct fscrypt_ctx, r.work);
+ struct bio *bio = ctx->r.bio;
+ struct bio_vec *bv;
+ int i;
+
+ bio_for_each_segment_all(bv, bio, i) {
+ struct page *page = bv->bv_page;
+ int ret = fscrypt_decrypt_page(page->mapping->host, page,
+ PAGE_SIZE, 0, page->index);
+
+ if (ret) {
+ WARN_ON_ONCE(1);
+ SetPageError(page);
+ } else {
+ SetPageUptodate(page);
+ }
+ unlock_page(page);
+ }
+ fscrypt_release_ctx(ctx);
+ bio_put(bio);
+}
+
+void fscrypt_decrypt_bio_pages(struct fscrypt_ctx *ctx, struct bio *bio)
+{
+ INIT_WORK(&ctx->r.work, completion_pages);
+ ctx->r.bio = bio;
+ queue_work(fscrypt_read_workqueue, &ctx->r.work);
+}
+EXPORT_SYMBOL(fscrypt_decrypt_bio_pages);
+
+void fscrypt_pullback_bio_page(struct page **page, bool restore)
+{
+ struct fscrypt_ctx *ctx;
+ struct page *bounce_page;
+
+ /* The bounce data pages are unmapped. */
+ if ((*page)->mapping)
+ return;
+
+ /* The bounce data page is unmapped. */
+ bounce_page = *page;
+ ctx = (struct fscrypt_ctx *)page_private(bounce_page);
+
+ /* restore control page */
+ *page = ctx->w.control_page;
+
+ if (restore)
+ fscrypt_restore_control_page(bounce_page);
+}
+EXPORT_SYMBOL(fscrypt_pullback_bio_page);
+
+int fscrypt_zeroout_range(const struct inode *inode, pgoff_t lblk,
+ sector_t pblk, unsigned int len)
+{
+ struct fscrypt_ctx *ctx;
+ struct page *ciphertext_page = NULL;
+ struct bio *bio;
+ int ret, err = 0;
+
+ BUG_ON(inode->i_sb->s_blocksize != PAGE_SIZE);
+
+ ctx = fscrypt_get_ctx(inode, GFP_NOFS);
+ if (IS_ERR(ctx))
+ return PTR_ERR(ctx);
+
+ ciphertext_page = fscrypt_alloc_bounce_page(ctx, GFP_NOWAIT);
+ if (IS_ERR(ciphertext_page)) {
+ err = PTR_ERR(ciphertext_page);
+ goto errout;
+ }
+
+ while (len--) {
+ err = fscrypt_do_page_crypto(inode, FS_ENCRYPT, lblk,
+ZERO_PAGE(0), ciphertext_page,
+PAGE_SIZE, 0, GFP_NOFS);
+ if (err)
+ goto errout;
+
+ bio = bio_alloc(GFP_NOWAIT, 1);
+ if (!bio) {
+ err = -ENOMEM;
+ goto errout;
+ }
