All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chao Yu <yuchao0@huawei.com>
To: Satya Tangirala <satyat@google.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: Tue, 22 Dec 2020 19:47:45 +0800	[thread overview]
Message-ID: <c08aadef-47a7-f6fc-c2fa-11393ca938e8@huawei.com> (raw)
In-Reply-To: <X9yYVuuLt3/hL17J@google.com>

On 2020/12/18 19:53, Satya Tangirala wrote:
> On Fri, Dec 18, 2020 at 05:02:23PM +0800, Chao Yu wrote:
>> On 2020/12/17 23:44, Satya Tangirala wrote:
>>> On Sat, Oct 10, 2020 at 05:53:06PM +0800, Chao Yu wrote:
>>>> 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
>>
>> Correct, considering performance of in batch node flush, it will be better to
>> use pba as IV value.
>>
>> 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?

And why not supporting hardware encryption for metadata in blk-crypto? then
both f2fs and ext4 can use inline-encryption based blk-crypto?

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: Chao Yu <yuchao0@huawei.com>
To: Satya Tangirala <satyat@google.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: Tue, 22 Dec 2020 19:47:45 +0800	[thread overview]
Message-ID: <c08aadef-47a7-f6fc-c2fa-11393ca938e8@huawei.com> (raw)
In-Reply-To: <X9yYVuuLt3/hL17J@google.com>

On 2020/12/18 19:53, Satya Tangirala wrote:
> On Fri, Dec 18, 2020 at 05:02:23PM +0800, Chao Yu wrote:
>> On 2020/12/17 23:44, Satya Tangirala wrote:
>>> On Sat, Oct 10, 2020 at 05:53:06PM +0800, Chao Yu wrote:
>>>> 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
>>
>> Correct, considering performance of in batch node flush, it will be better to
>> use pba as IV value.
>>
>> 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?

And why not supporting hardware encryption for metadata in blk-crypto? then
both f2fs and ext4 can use inline-encryption based blk-crypto?

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

  reply	other threads:[~2020-12-22 11:48 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 [this message]
2020-12-22 11:47           ` 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=c08aadef-47a7-f6fc-c2fa-11393ca938e8@huawei.com \
    --to=yuchao0@huawei.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=satyat@google.com \
    --cc=tytso@mit.edu \
    /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: link
Be 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.