From: Satya Tangirala <satyat@google.com> To: Chao Yu <yuchao0@huawei.com> Cc: "Theodore Y . Ts'o" <tytso@mit.edu>, Jaegeuk Kim <jaegeuk@kernel.org>, Eric Biggers <ebiggers@kernel.org>, Chao Yu <chao@kernel.org>, linux-kernel@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net Subject: Re: [PATCH 0/3] add support for metadata encryption to F2FS Date: Thu, 17 Dec 2020 15:44:11 +0000 [thread overview] Message-ID: <X9t8y3rElyAPCLoD@google.com> (raw) In-Reply-To: <471e0eb7-b035-03da-3ee3-35d5880a6748@huawei.com> On Sat, Oct 10, 2020 at 05:53:06PM +0800, Chao Yu wrote: > On 2020/10/5 15:36, Satya Tangirala wrote: > > This patch series adds support for metadata encryption to F2FS using > > blk-crypto. > > It looks this implementation is based on hardware crypto engine, could you > please add this info into f2fs.rst as well like inlinecrypt... > To be precise, the implementation requires either a hardware crypto engine *or* blk-crypto-fallback. I tried to clarify this a little better in the commit messages and in fscrypt.rst, but thinking about it again now, I think I should add a section about metadata encryption at the end of f2fs.rst. I'll do that when I send out v3 of this patch series (I just sent out v2). > > > > Patch 3 wires up F2FS with the functions introduced in Patch 2. F2FS > > will encrypt every block (that's not being encrypted by some other > > encryption key, e.g. a per-file key) with the metadata encryption key > > except the superblock (and the redundant copy of the superblock). The DUN > > of a block is the offset of the block from the start of the F2FS > > filesystem. > > Why not using nid as DUN, then GC could migrate encrypted node block directly via > meta inode's address space like we do for encrypted data block, rather than > decrypting node block to node page and then encrypting node page with DUN of new > blkaddr it migrates to. > The issue is, the bi_crypt_context in a bio holds a single DUN value, which is the DUN for the first data unit in the bio. blk-crypto assumes that the DUN of each subsequent data unit can be computed by simply incrementing the DUN. So physically contiguous data units can only be put into the same bio if they also have contiguous DUNs. I don't know much about nids, but if the nid is invariant w.r.t the physical block location, then there might be more fragmentation of bios in regular read/writes (because physical contiguity may have no relation to DUN contiguity). So I think we should continue using the fsblk number as the DUN.
WARNING: multiple messages have this Message-ID (diff)
From: Satya Tangirala via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net> To: Chao Yu <yuchao0@huawei.com> Cc: "Theodore Y . Ts'o" <tytso@mit.edu>, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, Eric Biggers <ebiggers@kernel.org>, linux-fscrypt@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org> Subject: Re: [f2fs-dev] [PATCH 0/3] add support for metadata encryption to F2FS Date: Thu, 17 Dec 2020 15:44:11 +0000 [thread overview] Message-ID: <X9t8y3rElyAPCLoD@google.com> (raw) In-Reply-To: <471e0eb7-b035-03da-3ee3-35d5880a6748@huawei.com> On Sat, Oct 10, 2020 at 05:53:06PM +0800, Chao Yu wrote: > On 2020/10/5 15:36, Satya Tangirala wrote: > > This patch series adds support for metadata encryption to F2FS using > > blk-crypto. > > It looks this implementation is based on hardware crypto engine, could you > please add this info into f2fs.rst as well like inlinecrypt... > To be precise, the implementation requires either a hardware crypto engine *or* blk-crypto-fallback. I tried to clarify this a little better in the commit messages and in fscrypt.rst, but thinking about it again now, I think I should add a section about metadata encryption at the end of f2fs.rst. I'll do that when I send out v3 of this patch series (I just sent out v2). > > > > Patch 3 wires up F2FS with the functions introduced in Patch 2. F2FS > > will encrypt every block (that's not being encrypted by some other > > encryption key, e.g. a per-file key) with the metadata encryption key > > except the superblock (and the redundant copy of the superblock). The DUN > > of a block is the offset of the block from the start of the F2FS > > filesystem. > > Why not using nid as DUN, then GC could migrate encrypted node block directly via > meta inode's address space like we do for encrypted data block, rather than > decrypting node block to node page and then encrypting node page with DUN of new > blkaddr it migrates to. > The issue is, the bi_crypt_context in a bio holds a single DUN value, which is the DUN for the first data unit in the bio. blk-crypto assumes that the DUN of each subsequent data unit can be computed by simply incrementing the DUN. So physically contiguous data units can only be put into the same bio if they also have contiguous DUNs. I don't know much about nids, but if the nid is invariant w.r.t the physical block location, then there might be more fragmentation of bios in regular read/writes (because physical contiguity may have no relation to DUN contiguity). So I think we should continue using the fsblk number as the DUN. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2020-12-17 15:45 UTC|newest] Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-05 7:36 [PATCH 0/3] add support for metadata encryption to F2FS Satya Tangirala 2020-10-05 7:36 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2020-10-05 7:36 ` [PATCH 1/3] fscrypt, f2fs: replace fscrypt_get_devices with fscrypt_get_device Satya Tangirala 2020-10-05 7:36 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2020-10-05 7:36 ` [PATCH 2/3] fscrypt: Add metadata encryption support Satya Tangirala 2020-10-05 7:36 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2020-10-07 20:52 ` Eric Biggers 2020-10-07 20:52 ` [f2fs-dev] " Eric Biggers 2020-10-07 23:28 ` Satya Tangirala 2020-10-07 23:28 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2020-10-08 17:05 ` Eric Biggers 2020-10-08 17:05 ` [f2fs-dev] " Eric Biggers 2020-10-05 7:36 ` [PATCH 3/3] f2fs: " Satya Tangirala 2020-10-05 7:36 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2020-10-05 10:19 ` kernel test robot 2020-10-05 10:19 ` kernel test robot 2020-10-07 21:20 ` Eric Biggers 2020-10-07 21:20 ` [f2fs-dev] " Eric Biggers 2020-10-08 0:31 ` Satya Tangirala 2020-10-08 0:31 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2020-10-05 7:43 ` [PATCH 0/3] add support for metadata encryption to F2FS Satya Tangirala 2020-10-05 7:43 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2020-10-07 21:00 ` Eric Biggers 2020-10-07 21:00 ` [f2fs-dev] " Eric Biggers 2020-10-07 22:05 ` Satya Tangirala 2020-10-07 22:05 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2020-10-08 17:01 ` Eric Biggers 2020-10-08 17:01 ` [f2fs-dev] " Eric Biggers 2020-10-10 9:53 ` Chao Yu 2020-10-10 9:53 ` [f2fs-dev] " Chao Yu 2020-12-17 15:44 ` Satya Tangirala [this message] 2020-12-17 15:44 ` Satya Tangirala via Linux-f2fs-devel 2020-12-18 9:02 ` Chao Yu 2020-12-18 9:02 ` [f2fs-dev] " Chao Yu 2020-12-18 11:53 ` Satya Tangirala 2020-12-18 11:53 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2020-12-22 11:47 ` Chao Yu 2020-12-22 11:47 ` [f2fs-dev] " Chao Yu 2020-12-24 10:13 ` Satya Tangirala 2020-12-24 10:13 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2020-12-25 9:31 ` Chao Yu 2020-12-25 9:31 ` [f2fs-dev] " Chao Yu
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=X9t8y3rElyAPCLoD@google.com \ --to=satyat@google.com \ --cc=chao@kernel.org \ --cc=ebiggers@kernel.org \ --cc=jaegeuk@kernel.org \ --cc=linux-f2fs-devel@lists.sourceforge.net \ --cc=linux-fscrypt@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=tytso@mit.edu \ --cc=yuchao0@huawei.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: linkBe 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.