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
next prev 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: 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.