| Message ID | bc34486c30d3d0bfd5404358f7bd566d802748be.1662420176.git.sweettea-kernel@dorminy.me (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | btrfs: add fscrypt integration | expand |
On Mon, Sep 05, 2022 at 08:35:19PM -0400, Sweet Tea Dorminy wrote: > With the introduction of extent-based file content encryption, filenames > and file contents might no longer use the same IV generation scheme, and > so should not upass the same logical block number to > fscrypt_generate_iv(). In preparation, start passing U64_MAX as the > block number for filename IV generation, and make fscrypt_generate_iv() > translate this to 0 if extent-based encryption is not being used. > > Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me> I had to go look at how you used this, because it seemed superflous to me, but it's because later you put the IV generation stuff above this particular bit of code. You say that we set it to 0 if extent-based encryption is not being used, but looking at this in vimdiff I don't know where that's going to be. So perhaps something like I will be adding code to generate IV's for extent-based encryption before falling through to the other policy types, and I will check for U64_MAX to skip the extent-based generation. At this point we'll want to switch back to 0 for filenames. Or some other such description. Thanks, Josef
diff --git a/fs/crypto/crypto.c b/fs/crypto/crypto.c index e78be66bbf01..7fe5979fbea2 100644 --- a/fs/crypto/crypto.c +++ b/fs/crypto/crypto.c @@ -71,7 +71,7 @@ EXPORT_SYMBOL(fscrypt_free_bounce_page); /* * Generate the IV for the given logical block number within the given file. - * For filenames encryption, lblk_num == 0. + * For filenames encryption, lblk_num == U64_MAX. * * Keep this in sync with fscrypt_limit_io_blocks(). fscrypt_limit_io_blocks() * needs to know about any IV generation methods where the low bits of IV don't @@ -84,6 +84,13 @@ void fscrypt_generate_iv(union fscrypt_iv *iv, u64 lblk_num, memset(iv, 0, ci->ci_mode->ivsize); + /* + * Filename encryption. For inode-based policies, filenames are + * encrypted as though they are lblk 0. + */ + if (lblk_num == U64_MAX) + lblk_num = 0; + if (flags & FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64) { WARN_ON_ONCE(lblk_num > U32_MAX); WARN_ON_ONCE(ci->ci_inode->i_ino > U32_MAX); diff --git a/fs/crypto/fname.c b/fs/crypto/fname.c index 3bdece33e14d..16b64e0589e4 100644 --- a/fs/crypto/fname.c +++ b/fs/crypto/fname.c @@ -79,7 +79,7 @@ int fscrypt_fname_encrypt(const struct inode *inode, const struct qstr *iname, memset(out + iname->len, 0, olen - iname->len); /* Initialize the IV */ - fscrypt_generate_iv(&iv, 0, ci); + fscrypt_generate_iv(&iv, U64_MAX, ci); /* Set up the encryption request */ req = skcipher_request_alloc(tfm, GFP_NOFS); @@ -134,7 +134,7 @@ static int fname_decrypt(const struct inode *inode, crypto_req_done, &wait); /* Initialize IV */ - fscrypt_generate_iv(&iv, 0, ci); + fscrypt_generate_iv(&iv, U64_MAX, ci); /* Create decryption request */ sg_init_one(&src_sg, iname->name, iname->len);
With the introduction of extent-based file content encryption, filenames and file contents might no longer use the same IV generation scheme, and so should not upass the same logical block number to fscrypt_generate_iv(). In preparation, start passing U64_MAX as the block number for filename IV generation, and make fscrypt_generate_iv() translate this to 0 if extent-based encryption is not being used. Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me> --- fs/crypto/crypto.c | 9 ++++++++- fs/crypto/fname.c | 4 ++-- 2 files changed, 10 insertions(+), 3 deletions(-)