Linux-f2fs-devel Archive on lore.kernel.org
 help / color / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Satya Tangirala <satyat@google.com>
Cc: linux-scsi@vger.kernel.org, Kim Boojin <boojin.kim@samsung.com>,
	Kuohong Wang <kuohong.wang@mediatek.com>,
	Barani Muthukumaran <bmuthuku@qti.qualcomm.com>,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-block@vger.kernel.org, linux-fscrypt@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: [f2fs-dev] [PATCH v13 10/12] fscrypt: add inline encryption support
Date: Thu, 28 May 2020 14:54:30 -0700
Message-ID: <20200528215430.GA143195@gmail.com> (raw)
In-Reply-To: <20200514003727.69001-11-satyat@google.com>

A few minor things to clean up when you resend this after v5.8-rc1:

(You'll have to resolve the conflicts with
 https://lore.kernel.org/r/20200515204141.251098-1-ebiggers@kernel.org
 too, but it shouldn't be too hard.  Note that I made setup_per_mode_enc_key()
 use a mutex, like this patch does.)

On Thu, May 14, 2020 at 12:37:25AM +0000, Satya Tangirala wrote:
> Add support for inline encryption to fs/crypto/.  With "inline
> encryption", the block layer handles the decryption/encryption as part
> of the bio, instead of the filesystem doing the crypto itself via
> Linux's crypto API.  This model is needed in order to take advantage of
> the inline encryption hardware present on most modern mobile SoCs.
> 
> To use inline encryption, the filesystem needs to be mounted with
> '-o inlinecrypt'.  The contents of any encrypted files will then be
> encrypted using blk-crypto, instead of using the traditional
> filesystem-layer crypto. Fscrypt still provides the key and IV to use,
> and the actual ciphertext on-disk is still the same; therefore it's
> testable using the existing fscrypt ciphertext verification tests.
> 
> Note that since blk-crypto has a fallack to Linux's crypto API, and

"fallack" => "fallback"

>  struct fscrypt_info {
>  
> -	/* The actual crypto transform used for encryption and decryption */
> -	struct crypto_skcipher *ci_ctfm;
> +	/* The key in a form prepared for actual encryption/decryption */
> +	struct fscrypt_prepared_key	ci_key;
>  

It would be clearer to call this field 'ci_enc_key' instead of 'ci_key'.
Since there are several types of fscrypt keys, including the recently added
ci_dirhash_key, I've been trying to clarify what type of key is meant when it's
ambiguous.  E.g. see https://git.kernel.org/torvalds/c/f592efe735a29c76

>  	/* True if the key should be freed when this fscrypt_info is freed */

If taking the above suggestion, this would need "the key" => "ci_enc_key"

>  	/*
>  	 * If non-NULL, then encryption is done using the master key directly
> -	 * and ci_ctfm will equal ci_direct_key->dk_ctfm.
> +	 * and ci_key will equal ci_direct_key->dk_key.
>  	 */

If taking the above suggestion, this would need "ci_key" => "ci_enc_key"

> +/* inline_crypt.c */
> +#ifdef CONFIG_FS_ENCRYPTION_INLINE_CRYPT
> +extern void fscrypt_select_encryption_impl(struct fscrypt_info *ci);

I'm now trying to consistently not use 'extern' on function declarations.  So,
can you remove it from the new declarations here and include/linux/fscrypt.h?

> +/**
> + * fscrypt_set_bio_crypt_ctx - prepare a file contents bio for inline encryption

I'm also now trying to consistently include the parentheses in the function
names in kerneldoc comments.  So:

 * fscrypt_set_bio_crypt_ctx() - prepare a file data bio for inline crypto

 * fscrypt_set_bio_crypt_ctx_bh() - prepare a file data bio for inline crypto

(similarly for the other new kerneldoc comments)

Make sure to also run

	scripts/kernel-doc -v -none fs/crypto/*.{c,h} include/linux/fscrypt.h

to check for new kerneldoc warnings.  In fscrypt.git#master I've gotten rid of
all the existing ones.

Thanks!

- Eric


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

  reply index

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-14  0:37 [f2fs-dev] [PATCH v13 00/12] Inline Encryption Support Satya Tangirala via Linux-f2fs-devel
2020-05-14  0:37 ` [f2fs-dev] [PATCH v13 01/12] Documentation: Document the blk-crypto framework Satya Tangirala via Linux-f2fs-devel
2020-05-14  0:37 ` [f2fs-dev] [PATCH v13 02/12] block: Keyslot Manager for Inline Encryption Satya Tangirala via Linux-f2fs-devel
2020-05-14  0:37 ` [f2fs-dev] [PATCH v13 03/12] block: Inline encryption support for blk-mq Satya Tangirala via Linux-f2fs-devel
2020-05-14  0:37 ` [f2fs-dev] [PATCH v13 04/12] block: Make blk-integrity preclude hardware inline encryption Satya Tangirala via Linux-f2fs-devel
2020-05-14  0:37 ` [f2fs-dev] [PATCH v13 05/12] block: blk-crypto-fallback for Inline Encryption Satya Tangirala via Linux-f2fs-devel
2020-05-14  0:37 ` [f2fs-dev] [PATCH v13 06/12] scsi: ufs: UFS driver v2.1 spec crypto additions Satya Tangirala via Linux-f2fs-devel
2020-05-15  3:55   ` Stanley Chu
2020-05-14  0:37 ` [f2fs-dev] [PATCH v13 07/12] scsi: ufs: UFS crypto API Satya Tangirala via Linux-f2fs-devel
2020-05-15  6:35   ` Stanley Chu
2020-05-14  0:37 ` [f2fs-dev] [PATCH v13 08/12] scsi: ufs: Add inline encryption support to UFS Satya Tangirala via Linux-f2fs-devel
2020-05-14  5:12   ` Eric Biggers
2020-05-15  7:37   ` Stanley Chu
2020-05-14  0:37 ` [f2fs-dev] [PATCH v13 09/12] fs: introduce SB_INLINECRYPT Satya Tangirala via Linux-f2fs-devel
2020-05-14  0:37 ` [f2fs-dev] [PATCH v13 10/12] fscrypt: add inline encryption support Satya Tangirala via Linux-f2fs-devel
2020-05-28 21:54   ` Eric Biggers [this message]
2020-06-03  2:07   ` Eric Biggers
2020-05-14  0:37 ` [f2fs-dev] [PATCH v13 11/12] f2fs: " Satya Tangirala via Linux-f2fs-devel
2020-05-14  0:37 ` [f2fs-dev] [PATCH v13 12/12] ext4: " Satya Tangirala via Linux-f2fs-devel
2020-05-14  5:10 ` [f2fs-dev] [PATCH v13 00/12] Inline Encryption Support Eric Biggers
2020-05-14 15:48   ` Jens Axboe
2020-05-15  7:41     ` Christoph Hellwig
2020-05-15 12:25       ` Satya Tangirala via Linux-f2fs-devel
2020-05-15 14:42         ` Christoph Hellwig
2020-05-15 17:00           ` Eric Biggers
2020-05-18 16:50             ` Christoph Hellwig
2020-05-15  1:04   ` Martin K. Petersen

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=20200528215430.GA143195@gmail.com \
    --to=ebiggers@kernel.org \
    --cc=bmuthuku@qti.qualcomm.com \
    --cc=boojin.kim@samsung.com \
    --cc=kuohong.wang@mediatek.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-scsi@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

Linux-f2fs-devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-f2fs-devel/0 linux-f2fs-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-f2fs-devel linux-f2fs-devel/ https://lore.kernel.org/linux-f2fs-devel \
		linux-f2fs-devel@lists.sourceforge.net
	public-inbox-index linux-f2fs-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/net.sourceforge.lists.linux-f2fs-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git