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, 24 Dec 2020 10:13:59 +0000 [thread overview] Message-ID: <X+Rp579fp5sMDvSP@google.com> (raw) In-Reply-To: <c08aadef-47a7-f6fc-c2fa-11393ca938e8@huawei.com> On Tue, Dec 22, 2020 at 07:47:45PM +0800, Chao Yu wrote: > On 2020/12/18 19:53, Satya Tangirala wrote: > > On Fri, Dec 18, 2020 at 05:02:23PM +0800, Chao Yu wrote: > > > But, what's the plan about supporting software encryption for metadata? Current > > > f2fs write flow will handle all operations which may encounter failure before > > > allocating block address for node, if we do allocation first, and then use pba > > > as IV to encrypt node block, it will be a little complicated to revert allocation > > > if we fail to encrypt node block. > > > > > Software encryption for metadata is supported through the blk-crypto > > blk-crypto will encrypt all data in filesystem, if FBE is enabled, data may > be encrypted twice? blk-crypto will only encrypt bios as directed to do so by the encryption context set on the bio. That encryption context is constructed by the submitter of the bio - in our case, the submitter is the filesystem. So the filesystem decides which bio gets encrypted with which key/algorithm/etc (and in the current implementation, each bio only supports a single bi_crypt_context, so *only one* layer of encryption is possible with blk-crypto anyway). So no, data won't be encrypted twice, because F2FS/fscrypt ensure that it does not (and the filesystem knows exactly which blocks need metadata encryption, and which blocks need FBE). > > And why not supporting hardware encryption for metadata in blk-crypto? then > both f2fs and ext4 can use inline-encryption based blk-crypto? > I may be misunderstanding what you're asking, but I think you're asking why not make blk-crypto do metadata encryption (without explicit involvement from filesystems)? Or more generally, why not do metadata encryption below the filesystem layer? As mentioned above, the filesystem is what knows which blocks need to be metadata encrypted and which blocks need to be FBE encrypted (or even just read without any encryption at all) - the block layer doesn't have this information, and so can't effectively decide which blocks to use the metadata encryption key on. Fwiw, Android does take a somewhat similar approach to what you're suggesting here (I explain more in detail in the cover letter for v2 of this patch series at https://lore.kernel.org/linux-fscrypt/20201217150435.1505269-1-satyat@google.com/ ). In Android, we have a new DM target (called dm-default-key) that adds an encryption context to any bio that doesn't already have an encryption context - so the assumption in general is that if the filesystem wants to use an FBE key, it would have already set the encryption context on the bio, so if a bio reaches dm-default-key without an encryption context, it must mean that it needs metadata encryption. However, that assumption doesn't always hold because F2FS sometimes needs to read the ciphertext of FBE files without having the file's FBE key available - in those situations, F2FS will send a bio without any encryption context, but will also tell dm-default-key to *not* add the metadata encryption context. That's a layering violation, which is why I'm not using that approach here. Does that answer your question? Or am I misunderstanding what you're asking? > Thanks, > > > framework - so encryption will happen in the block layer, not the > > filesystem layer. So there's nothing extra/special we need to do if > > there's an encryption failure - an encryption failure is no different > > from a read/write failure in a lower layer from f2fs' perspective. > > . > >
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, 24 Dec 2020 10:13:59 +0000 [thread overview] Message-ID: <X+Rp579fp5sMDvSP@google.com> (raw) In-Reply-To: <c08aadef-47a7-f6fc-c2fa-11393ca938e8@huawei.com> On Tue, Dec 22, 2020 at 07:47:45PM +0800, Chao Yu wrote: > On 2020/12/18 19:53, Satya Tangirala wrote: > > On Fri, Dec 18, 2020 at 05:02:23PM +0800, Chao Yu wrote: > > > But, what's the plan about supporting software encryption for metadata? Current > > > f2fs write flow will handle all operations which may encounter failure before > > > allocating block address for node, if we do allocation first, and then use pba > > > as IV to encrypt node block, it will be a little complicated to revert allocation > > > if we fail to encrypt node block. > > > > > Software encryption for metadata is supported through the blk-crypto > > blk-crypto will encrypt all data in filesystem, if FBE is enabled, data may > be encrypted twice? blk-crypto will only encrypt bios as directed to do so by the encryption context set on the bio. That encryption context is constructed by the submitter of the bio - in our case, the submitter is the filesystem. So the filesystem decides which bio gets encrypted with which key/algorithm/etc (and in the current implementation, each bio only supports a single bi_crypt_context, so *only one* layer of encryption is possible with blk-crypto anyway). So no, data won't be encrypted twice, because F2FS/fscrypt ensure that it does not (and the filesystem knows exactly which blocks need metadata encryption, and which blocks need FBE). > > And why not supporting hardware encryption for metadata in blk-crypto? then > both f2fs and ext4 can use inline-encryption based blk-crypto? > I may be misunderstanding what you're asking, but I think you're asking why not make blk-crypto do metadata encryption (without explicit involvement from filesystems)? Or more generally, why not do metadata encryption below the filesystem layer? As mentioned above, the filesystem is what knows which blocks need to be metadata encrypted and which blocks need to be FBE encrypted (or even just read without any encryption at all) - the block layer doesn't have this information, and so can't effectively decide which blocks to use the metadata encryption key on. Fwiw, Android does take a somewhat similar approach to what you're suggesting here (I explain more in detail in the cover letter for v2 of this patch series at https://lore.kernel.org/linux-fscrypt/20201217150435.1505269-1-satyat@google.com/ ). In Android, we have a new DM target (called dm-default-key) that adds an encryption context to any bio that doesn't already have an encryption context - so the assumption in general is that if the filesystem wants to use an FBE key, it would have already set the encryption context on the bio, so if a bio reaches dm-default-key without an encryption context, it must mean that it needs metadata encryption. However, that assumption doesn't always hold because F2FS sometimes needs to read the ciphertext of FBE files without having the file's FBE key available - in those situations, F2FS will send a bio without any encryption context, but will also tell dm-default-key to *not* add the metadata encryption context. That's a layering violation, which is why I'm not using that approach here. Does that answer your question? Or am I misunderstanding what you're asking? > Thanks, > > > framework - so encryption will happen in the block layer, not the > > filesystem layer. So there's nothing extra/special we need to do if > > there's an encryption failure - an encryption failure is no different > > from a read/write failure in a lower layer from f2fs' perspective. > > . > > _______________________________________________ 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-24 10:15 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 2020-12-17 15:44 ` [f2fs-dev] " 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 [this message] 2020-12-24 10:13 ` 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=X+Rp579fp5sMDvSP@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.