linux-ext4 - Re: [RFC PATCH v2 7/8] fscrypt: wire up fscrypt to use blk-crypto

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 13 Jun 2019 15:30:13 -0600
From:   Andreas Dilger <adilger@...ger.ca>
To:     Eric Biggers <ebiggers@...nel.org>
Cc:     linux-ext4 <linux-ext4@...r.kernel.org>,
        Sebastien Buisson <sbuisson@....com>
Subject: Re: [RFC PATCH v2 7/8] fscrypt: wire up fscrypt to use blk-crypto

[reduced CC list, since I don't think this is interesting outside ext4]

On Jun 13, 2019, at 12:55 PM, Eric Biggers <ebiggers@...nel.org> wrote:
> 
> What it really enables is a cryptosystem and on-disk format change where, for
> the purpose of working better with inline encryption, file contents are
> encrypted with the master key directly (or for v2 encryption policies it will be
> a per-mode derived key as it really should be, once we can actually get the v2
> encryption policy support reviewed and merged), and the inode numbers are added
> to the IVs.  As we know, when ext4 support is added, this will also preclude the
> filesystem from being resized.

Just as an aside, I thought that the inode number would *not* be added to the IV,
exactly so that ext4 filesystem resize would work?

I guess it shouldn't *strictly* preventing filesystem resizing, only the case of
shrinking the filesystem and having to relocate encrypted inodes.  Expanding the
filesystem shouldn't have that problem at all, nor should shrinking if there isn't
a need to relocate the encrypted inodes.  Moving encrypted blocks should be OK,
since the logical block numbers (and hence derived block IV) would stay the same.

Something like https://patchwork.ozlabs.org/patch/960766/ "Add block_high_watermark
sysfs tunable" would allow pre-migrating encrypted files in userspace via data copy
(read/decrypt+write/encrypt) before doing the resize, if necessary, so that files
do not use inode numbers that will be cut off the end of the filesystem.

Cheers, Andreas

Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)