All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Satya Tangirala <satyat@google.com>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fscrypt@vger.kernel.org
Subject: Re: [PATCH 0/1] userspace support for F2FS metadata encryption
Date: Wed, 7 Oct 2020 14:39:40 -0700	[thread overview]
Message-ID: <20201007213940.GE1530638@gmail.com> (raw)
In-Reply-To: <20201005074133.1958633-1-satyat@google.com>

On Mon, Oct 05, 2020 at 07:41:32AM +0000, Satya Tangirala wrote:
> The kernel patches for F2FS metadata encryption are at:
> 
> https://lore.kernel.org/linux-fscrypt/20201005073606.1949772-4-satyat@google.com/
> 
> This patch implements the userspace changes required for metadata
> encryption support as implemented in the kernel changes above. All blocks
> in the filesystem are encrypted with the user provided metadata encryption
> key except for the superblock (and its redundant copy). The DUN for a block
> is its offset from the start of the filesystem.
> 
> This patch introduces two new options for the userspace tools: '-A' to
> specify the encryption algorithm, and '-M' to specify the encryption key.
> mkfs.f2fs will store the encryption algorithm used for metadata encryption
> in the superblock itself, so '-A' is only applicable to mkfs.f2fs. The rest
> of the tools only take the '-M' option, and will obtain the encryption
> algorithm from the superblock of the FS.

As I mentioned on the kernel patches, it might make sense to compute a
metadata_key_identifier and store it in the super_block so that it can be
automatically requested without needing to provide an option.

> 
> Limitations: 
> Metadata encryption with sparse storage has not been implemented yet in
> this patch.
> 
> This patch requires the metadata encryption key to be readable from
> userspace, and does not ensure that it is zeroed before the program exits
> for any reason.
> 
> Satya Tangirala (1):
>   f2fs-tools: Introduce metadata encryption support

A cover letter shouldn't be used for a 1-patch series.  Just include these
details in the patch instead.

- Eric

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Satya Tangirala <satyat@google.com>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>,
	linux-fscrypt@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH 0/1] userspace support for F2FS metadata encryption
Date: Wed, 7 Oct 2020 14:39:40 -0700	[thread overview]
Message-ID: <20201007213940.GE1530638@gmail.com> (raw)
In-Reply-To: <20201005074133.1958633-1-satyat@google.com>

On Mon, Oct 05, 2020 at 07:41:32AM +0000, Satya Tangirala wrote:
> The kernel patches for F2FS metadata encryption are at:
> 
> https://lore.kernel.org/linux-fscrypt/20201005073606.1949772-4-satyat@google.com/
> 
> This patch implements the userspace changes required for metadata
> encryption support as implemented in the kernel changes above. All blocks
> in the filesystem are encrypted with the user provided metadata encryption
> key except for the superblock (and its redundant copy). The DUN for a block
> is its offset from the start of the filesystem.
> 
> This patch introduces two new options for the userspace tools: '-A' to
> specify the encryption algorithm, and '-M' to specify the encryption key.
> mkfs.f2fs will store the encryption algorithm used for metadata encryption
> in the superblock itself, so '-A' is only applicable to mkfs.f2fs. The rest
> of the tools only take the '-M' option, and will obtain the encryption
> algorithm from the superblock of the FS.

As I mentioned on the kernel patches, it might make sense to compute a
metadata_key_identifier and store it in the super_block so that it can be
automatically requested without needing to provide an option.

> 
> Limitations: 
> Metadata encryption with sparse storage has not been implemented yet in
> this patch.
> 
> This patch requires the metadata encryption key to be readable from
> userspace, and does not ensure that it is zeroed before the program exits
> for any reason.
> 
> Satya Tangirala (1):
>   f2fs-tools: Introduce metadata encryption support

A cover letter shouldn't be used for a 1-patch series.  Just include these
details in the patch instead.

- Eric


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  parent reply	other threads:[~2020-10-07 21:39 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-05  7:41 [PATCH 0/1] userspace support for F2FS metadata encryption Satya Tangirala
2020-10-05  7:41 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-10-05  7:41 ` [PATCH 1/1] f2fs-tools: Introduce metadata encryption support Satya Tangirala
2020-10-05  7:41   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-10-07 19:42   ` jaegeuk
2020-10-07 19:42     ` [f2fs-dev] " jaegeuk
2020-12-17 16:04     ` Satya Tangirala
2020-12-17 16:04       ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-10-07 21:52   ` Eric Biggers
2020-10-07 21:52     ` [f2fs-dev] " Eric Biggers
2020-10-07 21:39 ` Eric Biggers [this message]
2020-10-07 21:39   ` [f2fs-dev] [PATCH 0/1] userspace support for F2FS metadata encryption Eric Biggers
2020-12-17 16:23 ` Jaegeuk Kim
2020-12-17 16:23   ` [f2fs-dev] " Jaegeuk Kim
2020-12-18  6:41   ` Satya Tangirala
2020-12-18  6:41     ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-12-18 16:19     ` Jaegeuk Kim
2020-12-18 16:19       ` [f2fs-dev] " Jaegeuk Kim

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=20201007213940.GE1530638@gmail.com \
    --to=ebiggers@kernel.org \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=satyat@google.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: 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.