LinuxLists.cc - [PATCH 0/5] ext4: RFC: Encryption

2014-07-23 23:02:00

by Michael Halcrow

[permalink] [raw]

Subject: Re: [PATCH 0/5] ext4: RFC: Encryption

(Reposting in plain text; the previous cut-and-paste resulted in LKML-hostile
message format.)

On Wed, Jul 23, 2014 at 3:39 PM, Andreas Dilger <[email protected]> wrote:
> On Jul 23, 2014, at 3:23 PM, Michael Halcrow <[email protected]> wrote:
>> This patchset proposes a method for encrypting in EXT4 data read and
>> write paths. It's a proof-of-concept/prototype only right now.
>
> Maybe it is worthwhile to take a step back and explain what your overall
> goal is? What is the benefit of implementing crypto at the filesystem
> level over at the block device level? Are you targeting per-user crypto
> keys? Fast secure deletion of files by having per-inode keys that are
> encrypted by the filesystem/user key and then clobbered at deletion time?
>
> What is the threat model? Without knowing that, there isn't any point
> in designing or implementing anything.

My apologies for leaving those details sparse. I have a fairly large
design document that I need to prune for publication, but I can
copy-and-paste the adversarial models section here. The current
patchset targets Phase 1. The primary use case at the moment
is the Chromium OS user cache.

I don't want to get bogged down in the details around the later phases
at the moment though, because there is related work with IMA that
needs to be taken into consideration.

===
Adversarial Models

The EXT4 encryption effort will have multiple phases and development
with various features. The first version will focus exclusively on
attacks against file content (not metadata) confidentiality under a
single point-in-time permanent offline compromise of the block device
content. Later features will add resiliency in the face of an
adversary who is able to manipulate the offline block device content
prior to the authorized user later performing EXT4 file system I/O on
said content.

We are not currently planning on attempting any mitigations against
timing attacks. We recognize that these are important to address, but
we consider that to be primarily a Linux kernel Crypto API
issue. Addressing timing attacks against users of the Crypto API is
out of scope for this document.

Phase 1 Model

With the initial set of features, we will target the narrowly-scoped
threat of a single point-in-time permanent offline compromise of the
block device content, where loss of confidentiality of file metadata,
including the file sizes, names, and permissions, is tolerable.

An example scenario is the Chromium OS user cache, where the file
names can be tokenized at the application layer.

Phase 2 Model

We will additionally protect the confidentiality of file sizes, names,
permissions, etc. in the face of a single point-in-time permanent
offline compromise of the block device content. A mount-wide protector
will be shared among all users of the file system, and so one user on
a system will be able to manipulate the metadata of other users’
files.

This behavior is necessary for the Chromium OS user cache scenario,
where one user must be able to delete cache content for another user.

Phase 3 Model

We will add per-block authentication tags to the data pages to protect
file content integrity. At this point, the threat scope increases to
include occasional temporary offline compromise of the block device
content. "Occasional" means that an observer will be able to read
and/or manipulate the offline ciphertext and/or authentication tags on
the order of dozens of times in the lifetime of the file system. File
metadata will still be subject to undetected corruption, particularly
by other users on the system who gain access to the block device
content. However, some types of metadata manipulation, such as file
size or block mapping corruption, can be detected when validating the
integrity of the file contents.

Phase 4 Model

We will add in-place cryptographic context conversion to facilitate
transparent live encryption and key rotation. This will address the
threat of a key being compromised due over-exposure (e.g., amount of
data encrypted with the same key, age of key, amount of time the key
has been resident in memory under various run-time circumstances,
etc.).

Phase 5 Model

We will add TPM protectors to require boot sequence integrity to
release the encryption keys. This will address the threat of an
attacker replacing measurable components in the boot sequence up to
and including the kernel.

Phase 6 Model

We will add versioning support to mitigate rollback attacks. This will
address the threat of an attacker snapshotting a previous portion of
the block device content and restoring that portion at a later time.
===

>
> Hopefully you are already aware of the ext4 metadata checksum feature that
> is in newer kernels? That might be useful for storing your strong crypto
> integrity hashes for filesystem metadata.

I'm aware of that work and am evaluating it as a potential vehicle for
storing the
metadata.

> We've also previously discussed storing file-data checksums in some form.
> One of the leading candidates being either a per-block table of checksums
> that are statically mapped either for every block in the filesystem, or
> only to the "data" blocks of the filesystem (i.e. those that don't contain
> fixed metadata that already has its own checksums such as inode tables,
> bitmaps, and backup group descriptors/superblocks). The other possibility
> is storing checksums with each extent, with the option to make the extents
> as small or large as needed. See thread starting at:
> http://www.spinics.net/lists/linux-ext4/msg42620.html
>
> Once we understand what the actual security goals and threat model are,
> then it will be easier to determine the best way to implement this.
>
> Cheers, Andreas
>
>> Outstanding issues:
>>
>> * While it seems to work well with complex tasks like a parallel
>> kernel build, fsx is pretty good at reliably breaking it in its
>> current form. I think it's trying to decrypt a page of all zeros
>> when doing a mmap'd write after an falloc. I want to get feedback
>> on the overall approach before I spend too much time bug-hunting.
>>
>> * It has not undergone a security audit/review. It isn't IND-CCA2
>> secure, and that's the goal. We need a way to store (at least)
>> page-granular metadata.
>>
>> * Only the file data is encrypted. I'd like to look into also
>> encrypting the file system metadata with a mount-wide key. That's
>> for another phase of development.
>>
>> * The key management isn't fleshed out. I've hacked in some eCryptfs
>> stuff because it was the fastest way for me to stand up the
>> prototype with real crypto keys. Use ecryptfs-add-passphrase to add
>> a key to the keyring, and then pass the hex sig as the
>> encrypt_key_sig mount option:
>>
>> # apt-get install ecryptfs-utils
>> # echo -n "hunter2" | ecryptfs-add-passphrase
>> Passphrase:
>> Inserted auth tok with sig [4cb927ea0c564410] into the user session keyring
>> # mount -o encrypt_key_sig=4cb927ea0c564410 /dev/sdb1 /mnt/ext4crypt
>>
>> * The EXT4 block size must be the same as the page size. I'm not yet
>> sure whether I will want to try to support block-granular
>> encryption or page-granular encryption. There are implications with
>> respect to how much the integrity data occupies in relation to the
>> encrypted data.
>>
>> Mimi, maybe an approach like this one will work out for IMA. We've
>> just got to figure out where to store the block- or page-granular
>> integrity data.
>>
>> I've broken up the patches so that not only can each one build after
>> application, but discrete steps of functionality can be tested one
>> patch at a time.
>>
>> A couple of other thoughts:
>>
>> * Maybe the write submit path can complete on the encryption
>> callback. Not sure what that might buy us.
>>
>> * Maybe a key with a specific descriptor in each user's keyring
>> (e.g. "EXT4_DEFAULT_KEY") can be used when creating new files so
>> that each user can use his own key in a common EXT4 mount. Or maybe
>> we can specify an encryption context in the parent directory xattr.
>>
>> Michael Halcrow (5):
>> ext4: Adds callback support for bio read completion
>> ext4: Adds EXT4 encryption facilities
>> ext4: Implements the EXT4 encryption write path
>> ext4: Adds EXT4 encryption read callback support
>> ext4: Implements real encryption in the EXT4 write and read paths
>>
>> fs/buffer.c | 46 +++-
>> fs/ext4/Makefile | 9 +-
>> fs/ext4/crypto.c | 629 ++++++++++++++++++++++++++++++++++++++++++++
>> fs/ext4/ext4.h | 50 ++++
>> fs/ext4/file.c | 9 +-
>> fs/ext4/inode.c | 196 +++++++++++++-
>> fs/ext4/namei.c | 3 +
>> fs/ext4/page-io.c | 182 ++++++++++---
>> fs/ext4/super.c | 34 ++-
>> fs/ext4/xattr.h | 1 +
>> include/linux/bio.h | 3 +
>> include/linux/blk_types.h | 4 +
>> include/linux/buffer_head.h | 8 +
>> 13 files changed, 1118 insertions(+), 56 deletions(-)
>> create mode 100644 fs/ext4/crypto.c
>>
>> --
>> 2.0.0.526.g5318336
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> Cheers, Andreas
>
>
>
>
>

2014-07-24 12:27:21

by Theodore Ts'o

[permalink] [raw]

Subject: Re: [PATCH 0/5] ext4: RFC: Encryption

On Wed, Jul 23, 2014 at 04:39:43PM -0600, Andreas Dilger wrote:
>
> Maybe it is worthwhile to take a step back and explain what your overall
> goal is? What is the benefit of implementing crypto at the filesystem
> level over at the block device level? Are you targeting per-user crypto
> keys? Fast secure deletion of files by having per-inode keys that are
> encrypted by the filesystem/user key and then clobbered at deletion time?

One particular use case would involve per-user crypto keys, and where
space for things like (for example), browser cache files, can be
efficiently shared across multiple users, and where a root or some
privileged user can selectively delete cache files belonging to
another user in order to free up space, although without access to the
keys, root wouldn't be able to gain access to the data files.

The thinking was that each file would be encrypted using a per-file
key, and then the per-file key could be encrypted by one or more user
keys, and stored in the extended attributes.

(Hence, it's important for this design that the file metadata remains
unencrypted; that way it's possible to delete an encrypted file
without having access to the keys, and so e2fsck can check a file
system without having access to the keys. The flip side to this is
that we are potentially leaking more information due to the metadata
being encrypted. So for many use cases, using a block device dm-crypt
is going to be the better choice. But in this particular case, we do
need some of the attributes of ecryptfs, but we want something which
is more efficient and more stable/less bug-prone that ecryptfs.
Michael acknowledged all of this in his presentation at the ext4
workshop in February, and apologized for inflicting ecryptfs on the
world; you can think of this as atonement, by coming up with something
better as a replacement. :-)

Anyway, the question of the how to drive the policy of deciding which
key or keys should be used to encrypt the per-file key is something
for which we can add additional flexibility and power later; none of
this is in the patch series.

So the main thing that's up for review is the changes to the read and
write paths. One of the things that I'm especially looking for input
is the changes to fs/buffer.c. We've tried to keep the changes
minimal, and general, but something that I've considered is to simply
stop using fs/mpage.c and fs/buffer.c for the read path, and extending
fs/ext4/page_io.c so it is used for ext4's read and write path.

There are some advantages to doing this, in that it would reduce CPU
overhead on the read path (since right now we end up calling
ext4_get_block, and hence ext4_map_blocks for every single block), and
would allow us to avoid needing to attach buffer heads to pages except
for the data=journal mode. So this is something I'll want to do at
some point.

But, it would be simpler for review purposes to keep the modification
of ext4 to use page_io.c for reads separate from the encryption
changes, and other file systems that are still using fs/buffer.c and
fs/mpage.c might find these changes to be useful. So there are
arguments both ways.

> We've also previously discussed storing file-data checksums in some form.
> One of the leading candidates being either a per-block table of checksums
> that are statically mapped either for every block in the filesystem, or
> only to the "data" blocks of the filesystem (i.e. those that don't contain
> fixed metadata that already has its own checksums such as inode tables,
> bitmaps, and backup group descriptors/superblocks). The other possibility
> is storing checksums with each extent, with the option to make the extents
> as small or large as needed. See thread starting at:
> http://www.spinics.net/lists/linux-ext4/msg42620.html

Yes, this was discussed at the ext4 workshop in February, when Michael
presented his initial plans. The hope was that we could reuse the
infrastructure file-data checksums for the data integrity checksums.
The other potential thoguht was that some of infrastructure Ming ming
has been thinking about for reflink support could also be used for
both normal checksums and data integrity checksums. We'll have to see
what Lukas and Mingming come up with....

Cheers,

- Ted

2014-08-05 23:06:57

by Mimi Zohar

[permalink] [raw]

Subject: Re: [PATCH 4/5] ext4: Adds EXT4 encryption read callback support

On Wed, 2014-07-23 at 14:23 -0700, Michael Halcrow wrote:
> Adds EXT4 encryption read callback support.
>
> Copies block_read_full_page() to ext4_read_full_page() and adds some
> callback stuff near the end. I couldn't think of an elegant way to
> modify block_read_full_page() to accept the callback context without
> unnecessarily repeatedly allocating it and immediately deallocating it
> for sparse pages.
>
> Mimi, for IMA, maybe you'll want to do something like what's happening
> in ext4_completion_work().
>
> Signed-off-by: Michael Halcrow <[email protected]>
> ---
> fs/ext4/crypto.c | 30 +++++++--
> fs/ext4/ext4.h | 1 +
> fs/ext4/file.c | 9 ++-
> fs/ext4/inode.c | 184 ++++++++++++++++++++++++++++++++++++++++++++++++++--
> include/linux/bio.h | 3 +
> 5 files changed, 215 insertions(+), 12 deletions(-)
>
> diff --git a/fs/ext4/crypto.c b/fs/ext4/crypto.c
> index 3c9e9f4..435f33f 100644
> --- a/fs/ext4/crypto.c
> +++ b/fs/ext4/crypto.c
> @@ -58,6 +58,7 @@ atomic_t ext4_dbg_ctxs = ATOMIC_INIT(0);
> void ext4_release_crypto_ctx(ext4_crypto_ctx_t *ctx)
> {
> unsigned long flags;
> + atomic_dec(&ctx->dbg_refcnt);
> if (ctx->bounce_page) {
> if (ctx->flags & EXT4_BOUNCE_PAGE_REQUIRES_FREE_ENCRYPT_FL) {
> __free_page(ctx->bounce_page);
> @@ -67,6 +68,7 @@ void ext4_release_crypto_ctx(ext4_crypto_ctx_t *ctx)
> }
> ctx->bounce_page = NULL;
> }
> + ctx->control_page = NULL;
> if (ctx->flags & EXT4_CTX_REQUIRES_FREE_ENCRYPT_FL) {
> if (ctx->tfm)
> crypto_free_ablkcipher(ctx->tfm);
> @@ -136,6 +138,7 @@ ext4_crypto_ctx_t *ext4_get_crypto_ctx(
> } else {
> ctx->flags &= ~EXT4_CTX_REQUIRES_FREE_ENCRYPT_FL;
> }
> + atomic_set(&ctx->dbg_refcnt, 0);
>
> /* Allocate a new Crypto API context if we don't already have
> * one. */
> @@ -417,13 +420,28 @@ int ext4_decrypt(ext4_crypto_ctx_t *ctx, struct page* page)
> sg_set_page(&src, page, PAGE_CACHE_SIZE, 0);
> ablkcipher_request_set_crypt(req, &src, &dst, PAGE_CACHE_SIZE,
> xts_tweak);
> - res = crypto_ablkcipher_decrypt(req);
> - if (res == -EINPROGRESS || res == -EBUSY) {
> - BUG_ON(req->base.data != &ecr);
> - wait_for_completion(&ecr.completion);
> - res = ecr.res;
> - reinit_completion(&ecr.completion);
> +/* =======
> + * TODO(mhalcrow): Removed real crypto so intermediate patch for read
> + * path is still fully functional. For now just doing something that
> + * might expose a race condition. */
> + {
> + char *page_virt;
> + char tmp;
> + int i;
> + page_virt = kmap(page);
> + for (i = 0; i < PAGE_CACHE_SIZE / 2; ++i) {
> + tmp = page_virt[i];
> + page_virt[i] = page_virt[PAGE_CACHE_SIZE - i - 1];
> + page_virt[PAGE_CACHE_SIZE - i - 1] = tmp;
> + }
> + for (i = 0; i < PAGE_CACHE_SIZE / 2; ++i) {
> + tmp = page_virt[i];
> + page_virt[i] = page_virt[PAGE_CACHE_SIZE - i - 1];
> + page_virt[PAGE_CACHE_SIZE - i - 1] = tmp;
> + }
> + kunmap(page);
> }
> +/* ======= */
> ablkcipher_request_free(req);
> out:
> if (res)
> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index 7508261..1118bb0 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
> @@ -2821,6 +2821,7 @@ typedef struct ext4_crypto_ctx {
> struct work_struct work; /* Work queue for read complete path */
> struct list_head free_list; /* Free list */
> int flags; /* Flags */
> + atomic_t dbg_refcnt; /* TODO(mhalcrow): Remove for release */
> } ext4_crypto_ctx_t;
> extern struct workqueue_struct *mpage_read_workqueue;
> int ext4_allocate_crypto(size_t num_crypto_pages, size_t num_crypto_ctxs);
> diff --git a/fs/ext4/file.c b/fs/ext4/file.c
> index aca7b24..9b8478c 100644
> --- a/fs/ext4/file.c
> +++ b/fs/ext4/file.c
> @@ -202,6 +202,7 @@ static int ext4_file_mmap(struct file *file, struct vm_area_struct *vma)
> {
> file_accessed(file);
> vma->vm_ops = &ext4_file_vm_ops;
> + ext4_get_crypto_key(file->f_mapping->host);
> return 0;
> }
>
> @@ -212,6 +213,7 @@ static int ext4_file_open(struct inode * inode, struct file * filp)
> struct vfsmount *mnt = filp->f_path.mnt;
> struct path path;
> char buf[64], *cp;
> + int ret;
>
> if (unlikely(!(sbi->s_mount_flags & EXT4_MF_MNTDIR_SAMPLED) &&
> !(sb->s_flags & MS_RDONLY))) {
> @@ -250,11 +252,14 @@ static int ext4_file_open(struct inode * inode, struct file * filp)
> * writing and the journal is present
> */
> if (filp->f_mode & FMODE_WRITE) {
> - int ret = ext4_inode_attach_jinode(inode);
> + ret = ext4_inode_attach_jinode(inode);
> if (ret < 0)
> return ret;
> }
> - return dquot_file_open(inode, filp);
> + ret = dquot_file_open(inode, filp);
> + if (!ret)
> + ext4_get_crypto_key(inode);
> + return ret;
> }
>
> /*
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 4d37a12..6bf57d3 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -800,6 +800,8 @@ struct buffer_head *ext4_bread(handle_t *handle, struct inode *inode,
> ext4_lblk_t block, int create, int *err)
> {
> struct buffer_head *bh;
> + struct ext4_inode_info *ei = EXT4_I(inode);
> + ext4_crypto_ctx_t *ctx;
>
> bh = ext4_getblk(handle, inode, block, create, err);
> if (!bh)
> @@ -808,8 +810,16 @@ struct buffer_head *ext4_bread(handle_t *handle, struct inode *inode,
> return bh;
> ll_rw_block(READ | REQ_META | REQ_PRIO, 1, &bh);
> wait_on_buffer(bh);
> - if (buffer_uptodate(bh))
> + if (buffer_uptodate(bh)) {
> + if (ei->i_encrypt) {
> + BUG_ON(!bh->b_page);
> + BUG_ON(bh->b_size != PAGE_CACHE_SIZE);
> + ctx = ext4_get_crypto_ctx(false, ei->i_crypto_key);
> + WARN_ON_ONCE(ext4_decrypt(ctx, bh->b_page));
> + ext4_release_crypto_ctx(ctx);
> + }
> return bh;
> + }
> put_bh(bh);
> *err = -EIO;
> return NULL;
> @@ -2833,20 +2843,151 @@ static sector_t ext4_bmap(struct address_space *mapping, sector_t block)
> return generic_block_bmap(mapping, block, ext4_get_block);
> }
>
> +static void ext4_completion_work(struct work_struct *work)
> +{
> + ext4_crypto_ctx_t *ctx = container_of(work, ext4_crypto_ctx_t, work);
> + struct page *page = ctx->control_page;
> + WARN_ON_ONCE(ext4_decrypt(ctx, page));
> + ext4_release_crypto_ctx(ctx);
> + SetPageUptodate(page);
> + unlock_page(page);
> +}
> +

This completion work is on a per block/page basis, not file basis. How
is this going to help?

Mimi

> +static int ext4_complete_cb(struct bio *bio, int res)
> +{
> + ext4_crypto_ctx_t *ctx = bio->bi_cb_ctx;
> + struct page *page = ctx->control_page;
> + BUG_ON(atomic_read(&ctx->dbg_refcnt) != 1);
> + if (res) {
> + ext4_release_crypto_ctx(ctx);
> + unlock_page(page);
> + return res;
> + }
> + INIT_WORK(&ctx->work, ext4_completion_work);
> + queue_work(mpage_read_workqueue, &ctx->work);
> + return 0;
> +}
> +
> +static int ext4_read_full_page(struct page *page)
> +{
> + struct inode *inode = page->mapping->host;
> + sector_t iblock, lblock;
> + struct buffer_head *bh, *head, *arr[MAX_BUF_PER_PAGE];
> + unsigned int blocksize, bbits;
> + int nr, i;
> + int fully_mapped = 1;
> +
> + head = create_page_buffers(page, inode, 0);
> + blocksize = head->b_size;
> + bbits = ilog2(blocksize);
> +
> + iblock = (sector_t)page->index << (PAGE_CACHE_SHIFT - bbits);
> + lblock = (i_size_read(inode)+blocksize-1) >> bbits;
> + bh = head;
> + nr = 0;
> + i = 0;
> +
> + do {
> + if (buffer_uptodate(bh))
> + continue;
> +
> + if (!buffer_mapped(bh)) {
> + int err = 0;
> +
> + fully_mapped = 0;
> + if (iblock < lblock) {
> + WARN_ON(bh->b_size != blocksize);
> + err = ext4_get_block(inode, iblock, bh, 0);
> + if (err)
> + SetPageError(page);
> + }
> + if (!buffer_mapped(bh)) {
> + zero_user(page, i * blocksize, blocksize);
> + if (!err)
> + set_buffer_uptodate(bh);
> + continue;
> + }
> + /*
> + * get_block() might have updated the buffer
> + * synchronously
> + */
> + if (buffer_uptodate(bh))
> + continue;
> + }
> + arr[nr++] = bh;
> + } while (i++, iblock++, (bh = bh->b_this_page) != head);
> +
> + if (fully_mapped)
> + SetPageMappedToDisk(page);
> +
> + if (!nr) {
> + /*
> + * All buffers are uptodate - we can set the page uptodate
> + * as well. But not if get_block() returned an error.
> + */
> + if (!PageError(page))
> + SetPageUptodate(page);
> + unlock_page(page);
> + return 0;
> + }
> +
> + /* TODO(mhalcrow): For the development phase, encryption
> + * requires that the block size be equal to the page size. To
> + * make this the case for release (if we go that route), we'll
> + * need a super.c change to verify. */
> + BUG_ON(nr != 1);
> +
> + /* Stage two: lock the buffers */
> + for (i = 0; i < nr; i++) {
> + bh = arr[i];
> + lock_buffer(bh);
> + mark_buffer_async_read(bh);
> + }
> +
> + /*
> + * Stage 3: start the IO. Check for uptodateness
> + * inside the buffer lock in case another process reading
> + * the underlying blockdev brought it uptodate (the sct fix).
> + */
> + for (i = 0; i < nr; i++) {
> + bh = arr[i];
> + if (buffer_uptodate(bh))
> + end_buffer_async_read(bh, 1);
> + else {
> + struct ext4_inode_info *ei = EXT4_I(inode);
> + ext4_crypto_ctx_t *ctx = ext4_get_crypto_ctx(
> + false, ei->i_crypto_key);
> + BUG_ON(atomic_read(&ctx->dbg_refcnt) != 0);
> + atomic_inc(&ctx->dbg_refcnt);
> + BUG_ON(ctx->control_page);
> + ctx->control_page = page;
> + BUG_ON(atomic_read(&ctx->dbg_refcnt) != 1);
> + if (submit_bh_cb(READ, bh, ext4_complete_cb, ctx))
> + ext4_release_crypto_ctx(ctx);
> + }
> + }
> + return 0;
> +}
> +
> static int ext4_readpage(struct file *file, struct page *page)
> {
> int ret = -EAGAIN;
> struct inode *inode = page->mapping->host;
> + struct ext4_inode_info *ei = EXT4_I(inode);
>
> trace_ext4_readpage(page);
>
> if (ext4_has_inline_data(inode))
> ret = ext4_readpage_inline(inode, page);
>
> - if (ret == -EAGAIN)
> + if (ei->i_encrypt) {
> + BUG_ON(ret != -EAGAIN);
> + ext4_read_full_page(page);
> + } else if (ret == -EAGAIN) {
> return mpage_readpage(page, ext4_get_block);
> + }
>
> - return ret;
> + return 0;
> }
>
> static int
> @@ -2854,12 +2995,35 @@ ext4_readpages(struct file *file, struct address_space *mapping,
> struct list_head *pages, unsigned nr_pages)
> {
> struct inode *inode = mapping->host;
> + struct ext4_inode_info *ei = EXT4_I(inode);
> + struct page *page = NULL;
> + unsigned page_idx;
>
> /* If the file has inline data, no need to do readpages. */
> if (ext4_has_inline_data(inode))
> return 0;
>
> - return mpage_readpages(mapping, pages, nr_pages, ext4_get_block);
> + if (ei->i_encrypt) {
> + for (page_idx = 0; page_idx < nr_pages; page_idx++) {
> + page = list_entry(pages->prev, struct page, lru);
> + prefetchw(&page->flags);
> + list_del(&page->lru);
> + if (!add_to_page_cache_lru(page, mapping, page->index,
> + GFP_KERNEL)) {
> + if (!PageUptodate(page)) {
> + ext4_read_full_page(page);
> + } else {
> + unlock_page(page);
> + }
> + }
> + page_cache_release(page);
> + }
> + BUG_ON(!list_empty(pages));
> + return 0;
> + } else {
> + return mpage_readpages(mapping, pages, nr_pages,
> + ext4_get_block);
> + }
> }
>
> static void ext4_invalidatepage(struct page *page, unsigned int offset,
> @@ -3118,9 +3282,13 @@ static ssize_t ext4_direct_IO(int rw, struct kiocb *iocb,
> {
> struct file *file = iocb->ki_filp;
> struct inode *inode = file->f_mapping->host;
> + struct ext4_inode_info *ei = EXT4_I(inode);
> size_t count = iov_iter_count(iter);
> ssize_t ret;
>
> + if (ei->i_encrypt)
> + return 0;
> +
> /*
> * If we are doing data journalling we don't support O_DIRECT
> */
> @@ -3243,8 +3411,10 @@ static int ext4_block_zero_page_range(handle_t *handle,
> unsigned blocksize, max, pos;
> ext4_lblk_t iblock;
> struct inode *inode = mapping->host;
> + struct ext4_inode_info *ei = EXT4_I(inode);
> struct buffer_head *bh;
> struct page *page;
> + ext4_crypto_ctx_t *ctx;
> int err = 0;
>
> page = find_or_create_page(mapping, from >> PAGE_CACHE_SHIFT,
> @@ -3300,6 +3470,12 @@ static int ext4_block_zero_page_range(handle_t *handle,
> /* Uhhuh. Read error. Complain and punt. */
> if (!buffer_uptodate(bh))
> goto unlock;
> + if (ei->i_encrypt) {
> + BUG_ON(blocksize != PAGE_CACHE_SIZE);
> + ctx = ext4_get_crypto_ctx(false, ei->i_crypto_key);
> + WARN_ON_ONCE(ext4_decrypt(ctx, page));
> + ext4_release_crypto_ctx(ctx);
> + }
> }
> if (ext4_should_journal_data(inode)) {
> BUFFER_TRACE(bh, "get write access");
> diff --git a/include/linux/bio.h b/include/linux/bio.h
> index d2633ee..6ec3bee 100644
> --- a/include/linux/bio.h
> +++ b/include/linux/bio.h
> @@ -375,6 +375,9 @@ static inline struct bio *bio_clone_kmalloc(struct bio *bio, gfp_t gfp_mask)
>
> }
>
> +/* TODO(mhalcrow): Only here for test; remove before release */
> +extern atomic_t global_bio_count;
> +
> extern void bio_endio(struct bio *, int);
> extern void bio_endio_nodec(struct bio *, int);
> struct request_queue;