All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Satya Tangirala <satyat@google.com>
Cc: linux-block@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	Barani Muthukumaran <bmuthuku@qti.qualcomm.com>,
	Kuohong Wang <kuohong.wang@mediatek.com>,
	Kim Boojin <boojin.kim@samsung.com>
Subject: Re: [PATCH v6 1/9] block: Keyslot Manager for Inline Encryption
Date: Fri, 17 Jan 2020 01:10:02 -0800	[thread overview]
Message-ID: <20200117091002.GA15396@infradead.org> (raw)
In-Reply-To: <20191218145136.172774-2-satyat@google.com>

> +struct keyslot_manager {
> +	unsigned int num_slots;
> +	struct keyslot_mgmt_ll_ops ksm_ll_ops;
> +	unsigned int crypto_mode_supported[BLK_ENCRYPTION_MODE_MAX];
> +	void *ll_priv_data;
> +
> +	/* Protects programming and evicting keys from the device */
> +	struct rw_semaphore lock;
> +
> +	/* List of idle slots, with least recently used slot at front */
> +	wait_queue_head_t idle_slots_wait_queue;
> +	struct list_head idle_slots;
> +	spinlock_t idle_slots_lock;
> +
> +	/*
> +	 * Hash table which maps key hashes to keyslots, so that we can find a
> +	 * key's keyslot in O(1) time rather than O(num_slots).  Protected by
> +	 * 'lock'.  A cryptographic hash function is used so that timing attacks
> +	 * can't leak information about the raw keys.
> +	 */
> +	struct hlist_head *slot_hashtable;
> +	unsigned int slot_hashtable_size;
> +
> +	/* Per-keyslot data */
> +	struct keyslot slots[];
> +};

Is there a rationale for making this structure private?  If it was
exposed we could embedd it into the containing structure (although
the slots would need a dynamic allocation), and instead of the
keyslot_manager_private helper, the caller could simply use
container_of.

> +struct keyslot_manager *keyslot_manager_create(unsigned int num_slots,
> +	const struct keyslot_mgmt_ll_ops *ksm_ll_ops,
> +	const unsigned int crypto_mode_supported[BLK_ENCRYPTION_MODE_MAX],
> +	void *ll_priv_data)

.. and then the caller could simply set the ops and the supported modes
array directly in the structure, simplifying the interface even further.

> +static int find_keyslot(struct keyslot_manager *ksm,
> +			const struct blk_crypto_key *key)
> +{
> +	const struct hlist_head *head = hash_bucket_for_key(ksm, key);
> +	const struct keyslot *slotp;
> +
> +	hlist_for_each_entry(slotp, head, hash_node) {
> +		if (slotp->key.hash == key->hash &&
> +		    slotp->key.crypto_mode == key->crypto_mode &&
> +		    slotp->key.data_unit_size == key->data_unit_size &&
> +		    !crypto_memneq(slotp->key.raw, key->raw, key->size))
> +			return slotp - ksm->slots;
> +	}
> +	return -ENOKEY;
> +}

I'd return the actual slot pointer here, as that seems the more natural
fit.  Then factor the pointer arithmetics into a little helper to make
it obvious for those few places that need the actual slot number.

Also can you add proper subsystem prefix to the various symbol names?

> +void keyslot_manager_get_slot(struct keyslot_manager *ksm, unsigned int slot)
> +{
> +	if (WARN_ON(slot >= ksm->num_slots))
> +		return;
> +
> +	WARN_ON(atomic_inc_return(&ksm->slots[slot].slot_refs) < 2);
> +}
> +
> +/**
> + * keyslot_manager_put_slot() - Release a reference to a slot
> + * @ksm: The keyslot manager to release the reference from.
> + * @slot: The slot to release the reference from.
> + *
> + * Context: Any context.
> + */
> +void keyslot_manager_put_slot(struct keyslot_manager *ksm, unsigned int slot)
> +{
> +	unsigned long flags;
> +
> +	if (WARN_ON(slot >= ksm->num_slots))
> +		return;
> +
> +	if (atomic_dec_and_lock_irqsave(&ksm->slots[slot].slot_refs,
> +					&ksm->idle_slots_lock, flags)) {
> +		list_add_tail(&ksm->slots[slot].idle_slot_node,
> +			      &ksm->idle_slots);
> +		spin_unlock_irqrestore(&ksm->idle_slots_lock, flags);
> +		wake_up(&ksm->idle_slots_wait_queue);
> +	}
> +}

How about passing the bio_crypt_ctx structure instead of the not very
nicely typed slot index?  Also if we merge the files both these helpers
should probably just go away and me merged into the 1 or 2 callers that
exist.

> +#ifdef CONFIG_BLK_INLINE_ENCRYPTION
> +
> +#define BLK_CRYPTO_MAX_KEY_SIZE		64
> +
> +/**
> + * struct blk_crypto_key - an inline encryption key
> + * @crypto_mode: encryption algorithm this key is for
> + * @data_unit_size: the data unit size for all encryption/decryptions with this
> + *	key.  This is the size in bytes of each individual plaintext and
> + *	ciphertext.  This is always a power of 2.  It might be e.g. the
> + *	filesystem block size or the disk sector size.
> + * @data_unit_size_bits: log2 of data_unit_size
> + * @size: size of this key in bytes (determined by @crypto_mode)
> + * @hash: hash of this key, for keyslot manager use only
> + * @raw: the raw bytes of this key.  Only the first @size bytes are used.
> + *
> + * A blk_crypto_key is immutable once created, and many bios can reference it at
> + * the same time.  It must not be freed until all bios using it have completed.
> + */
> +struct blk_crypto_key {
> +	enum blk_crypto_mode_num crypto_mode;
> +	unsigned int data_unit_size;
> +	unsigned int data_unit_size_bits;
> +	unsigned int size;
> +	unsigned int hash;
> +	u8 raw[BLK_CRYPTO_MAX_KEY_SIZE];
> +};
> +
> +#endif /* CONFIG_BLK_INLINE_ENCRYPTION */
> +#endif /* CONFIG_BLOCK */

I don't think we need any ifdefs around these declarations.

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.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
Subject: Re: [f2fs-dev] [PATCH v6 1/9] block: Keyslot Manager for Inline Encryption
Date: Fri, 17 Jan 2020 01:10:02 -0800	[thread overview]
Message-ID: <20200117091002.GA15396@infradead.org> (raw)
In-Reply-To: <20191218145136.172774-2-satyat@google.com>

> +struct keyslot_manager {
> +	unsigned int num_slots;
> +	struct keyslot_mgmt_ll_ops ksm_ll_ops;
> +	unsigned int crypto_mode_supported[BLK_ENCRYPTION_MODE_MAX];
> +	void *ll_priv_data;
> +
> +	/* Protects programming and evicting keys from the device */
> +	struct rw_semaphore lock;
> +
> +	/* List of idle slots, with least recently used slot at front */
> +	wait_queue_head_t idle_slots_wait_queue;
> +	struct list_head idle_slots;
> +	spinlock_t idle_slots_lock;
> +
> +	/*
> +	 * Hash table which maps key hashes to keyslots, so that we can find a
> +	 * key's keyslot in O(1) time rather than O(num_slots).  Protected by
> +	 * 'lock'.  A cryptographic hash function is used so that timing attacks
> +	 * can't leak information about the raw keys.
> +	 */
> +	struct hlist_head *slot_hashtable;
> +	unsigned int slot_hashtable_size;
> +
> +	/* Per-keyslot data */
> +	struct keyslot slots[];
> +};

Is there a rationale for making this structure private?  If it was
exposed we could embedd it into the containing structure (although
the slots would need a dynamic allocation), and instead of the
keyslot_manager_private helper, the caller could simply use
container_of.

> +struct keyslot_manager *keyslot_manager_create(unsigned int num_slots,
> +	const struct keyslot_mgmt_ll_ops *ksm_ll_ops,
> +	const unsigned int crypto_mode_supported[BLK_ENCRYPTION_MODE_MAX],
> +	void *ll_priv_data)

.. and then the caller could simply set the ops and the supported modes
array directly in the structure, simplifying the interface even further.

> +static int find_keyslot(struct keyslot_manager *ksm,
> +			const struct blk_crypto_key *key)
> +{
> +	const struct hlist_head *head = hash_bucket_for_key(ksm, key);
> +	const struct keyslot *slotp;
> +
> +	hlist_for_each_entry(slotp, head, hash_node) {
> +		if (slotp->key.hash == key->hash &&
> +		    slotp->key.crypto_mode == key->crypto_mode &&
> +		    slotp->key.data_unit_size == key->data_unit_size &&
> +		    !crypto_memneq(slotp->key.raw, key->raw, key->size))
> +			return slotp - ksm->slots;
> +	}
> +	return -ENOKEY;
> +}

I'd return the actual slot pointer here, as that seems the more natural
fit.  Then factor the pointer arithmetics into a little helper to make
it obvious for those few places that need the actual slot number.

Also can you add proper subsystem prefix to the various symbol names?

> +void keyslot_manager_get_slot(struct keyslot_manager *ksm, unsigned int slot)
> +{
> +	if (WARN_ON(slot >= ksm->num_slots))
> +		return;
> +
> +	WARN_ON(atomic_inc_return(&ksm->slots[slot].slot_refs) < 2);
> +}
> +
> +/**
> + * keyslot_manager_put_slot() - Release a reference to a slot
> + * @ksm: The keyslot manager to release the reference from.
> + * @slot: The slot to release the reference from.
> + *
> + * Context: Any context.
> + */
> +void keyslot_manager_put_slot(struct keyslot_manager *ksm, unsigned int slot)
> +{
> +	unsigned long flags;
> +
> +	if (WARN_ON(slot >= ksm->num_slots))
> +		return;
> +
> +	if (atomic_dec_and_lock_irqsave(&ksm->slots[slot].slot_refs,
> +					&ksm->idle_slots_lock, flags)) {
> +		list_add_tail(&ksm->slots[slot].idle_slot_node,
> +			      &ksm->idle_slots);
> +		spin_unlock_irqrestore(&ksm->idle_slots_lock, flags);
> +		wake_up(&ksm->idle_slots_wait_queue);
> +	}
> +}

How about passing the bio_crypt_ctx structure instead of the not very
nicely typed slot index?  Also if we merge the files both these helpers
should probably just go away and me merged into the 1 or 2 callers that
exist.

> +#ifdef CONFIG_BLK_INLINE_ENCRYPTION
> +
> +#define BLK_CRYPTO_MAX_KEY_SIZE		64
> +
> +/**
> + * struct blk_crypto_key - an inline encryption key
> + * @crypto_mode: encryption algorithm this key is for
> + * @data_unit_size: the data unit size for all encryption/decryptions with this
> + *	key.  This is the size in bytes of each individual plaintext and
> + *	ciphertext.  This is always a power of 2.  It might be e.g. the
> + *	filesystem block size or the disk sector size.
> + * @data_unit_size_bits: log2 of data_unit_size
> + * @size: size of this key in bytes (determined by @crypto_mode)
> + * @hash: hash of this key, for keyslot manager use only
> + * @raw: the raw bytes of this key.  Only the first @size bytes are used.
> + *
> + * A blk_crypto_key is immutable once created, and many bios can reference it at
> + * the same time.  It must not be freed until all bios using it have completed.
> + */
> +struct blk_crypto_key {
> +	enum blk_crypto_mode_num crypto_mode;
> +	unsigned int data_unit_size;
> +	unsigned int data_unit_size_bits;
> +	unsigned int size;
> +	unsigned int hash;
> +	u8 raw[BLK_CRYPTO_MAX_KEY_SIZE];
> +};
> +
> +#endif /* CONFIG_BLK_INLINE_ENCRYPTION */
> +#endif /* CONFIG_BLOCK */

I don't think we need any ifdefs around these declarations.


_______________________________________________
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-01-17  9:10 UTC|newest]

Thread overview: 112+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-18 14:51 [PATCH v6 0/9] Inline Encryption Support Satya Tangirala
2019-12-18 14:51 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2019-12-18 14:51 ` [PATCH v6 1/9] block: Keyslot Manager for Inline Encryption Satya Tangirala
2019-12-18 14:51   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2019-12-18 20:13   ` Eric Biggers
2019-12-18 20:13     ` [f2fs-dev] " Eric Biggers
2020-01-17  9:10   ` Christoph Hellwig [this message]
2020-01-17  9:10     ` Christoph Hellwig
2019-12-18 14:51 ` [PATCH v6 2/9] block: Add encryption context to struct bio Satya Tangirala
2019-12-18 14:51   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2019-12-18 21:10   ` Eric Biggers
2019-12-18 21:10     ` [f2fs-dev] " Eric Biggers
2019-12-18 21:21   ` Darrick J. Wong
2019-12-18 21:21     ` [f2fs-dev] " Darrick J. Wong
2019-12-18 21:25     ` Martin K. Petersen
2019-12-18 21:25       ` [f2fs-dev] " Martin K. Petersen
2019-12-18 22:27       ` Eric Biggers
2019-12-18 22:27         ` [f2fs-dev] " Eric Biggers
2019-12-19  0:47         ` Martin K. Petersen
2019-12-19  0:47           ` [f2fs-dev] " Martin K. Petersen
2019-12-20  3:52           ` Eric Biggers
2019-12-20  3:52             ` [f2fs-dev] " Eric Biggers
2020-01-07  4:35             ` Martin K. Petersen
2020-01-07  4:35               ` [f2fs-dev] " Martin K. Petersen
2020-01-08 14:07           ` Christoph Hellwig
2020-01-08 14:07             ` [f2fs-dev] " Christoph Hellwig
2020-01-08 17:26             ` Eric Biggers
2020-01-08 17:26               ` [f2fs-dev] " Eric Biggers
2020-01-17  8:32               ` Christoph Hellwig
2020-01-17  8:32                 ` [f2fs-dev] " Christoph Hellwig
2020-01-18  5:11                 ` Eric Biggers
2020-01-18  5:11                   ` [f2fs-dev] " Eric Biggers
2020-01-21 22:05                   ` Satya Tangirala
2020-01-21 22:05                     ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-01-09  3:40             ` Martin K. Petersen
2020-01-09  3:40               ` [f2fs-dev] " Martin K. Petersen
2020-01-14 21:24   ` Eric Biggers
2020-01-14 21:24     ` [f2fs-dev] " Eric Biggers
2019-12-18 14:51 ` [PATCH v6 3/9] block: blk-crypto for Inline Encryption Satya Tangirala
2019-12-18 14:51   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2019-12-20  3:14   ` Eric Biggers
2019-12-20  3:14     ` [f2fs-dev] " Eric Biggers
2019-12-20  5:10   ` Eric Biggers
2019-12-20  5:10     ` [f2fs-dev] " Eric Biggers
2020-01-14 21:22   ` Eric Biggers
2020-01-14 21:22     ` [f2fs-dev] " Eric Biggers
2019-12-18 14:51 ` [PATCH v6 4/9] scsi: ufs: UFS driver v2.1 spec crypto additions Satya Tangirala
2019-12-18 14:51   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-01-17 12:31   ` Christoph Hellwig
2020-01-17 12:31     ` [f2fs-dev] " Christoph Hellwig
2019-12-18 14:51 ` [PATCH v6 5/9] scsi: ufs: UFS crypto API Satya Tangirala
2019-12-18 14:51   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2019-12-20  4:48   ` Eric Biggers
2019-12-20  4:48     ` [f2fs-dev] " Eric Biggers
2020-01-14 21:16     ` Eric Biggers
2020-01-14 21:16       ` [f2fs-dev] " Eric Biggers
2020-01-17 13:51   ` Christoph Hellwig
2020-01-17 13:51     ` [f2fs-dev] " Christoph Hellwig
2019-12-18 14:51 ` [PATCH v6 6/9] scsi: ufs: Add inline encryption support to UFS Satya Tangirala
2019-12-18 14:51   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2019-12-20  5:44   ` Eric Biggers
2019-12-20  5:44     ` [f2fs-dev] " Eric Biggers
2020-01-17 13:58   ` Christoph Hellwig
2020-01-17 13:58     ` [f2fs-dev] " Christoph Hellwig
2020-01-18  5:27     ` Eric Biggers
2020-01-18  5:27       ` [f2fs-dev] " Eric Biggers
2020-02-05 18:07       ` Christoph Hellwig
2020-02-05 18:07         ` [f2fs-dev] " Christoph Hellwig
2020-01-18  3:58   ` Eric Biggers
2020-01-18  3:58     ` [f2fs-dev] " Eric Biggers
2020-02-05 20:47   ` Eric Biggers
2020-02-05 20:47     ` [f2fs-dev] " Eric Biggers
2019-12-18 14:51 ` [PATCH v6 7/9] fscrypt: add inline encryption support Satya Tangirala
2019-12-18 14:51   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-01-14 21:12   ` Eric Biggers
2020-01-14 21:12     ` [f2fs-dev] " Eric Biggers
2019-12-18 14:51 ` [PATCH v6 8/9] f2fs: " Satya Tangirala
2019-12-18 14:51   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2019-12-20  4:23   ` Eric Biggers
2019-12-20  4:23     ` [f2fs-dev] " Eric Biggers
2019-12-18 14:51 ` [PATCH v6 9/9] ext4: " Satya Tangirala
2019-12-18 14:51   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2019-12-19  0:12   ` Eric Biggers
2019-12-19  0:12     ` [f2fs-dev] " Eric Biggers
2019-12-19  0:31     ` Satya Tangirala
2019-12-19  0:31       ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2019-12-22  0:16   ` Eric Biggers
2019-12-22  0:16     ` [f2fs-dev] " Eric Biggers
2020-01-08 14:05 ` [PATCH v6 0/9] Inline Encryption Support Christoph Hellwig
2020-01-08 14:05   ` [f2fs-dev] " Christoph Hellwig
2020-01-08 18:43   ` Satya Tangirala
2020-01-08 18:43     ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-01-17  8:52     ` Christoph Hellwig
2020-01-17  8:52       ` [f2fs-dev] " Christoph Hellwig
2020-02-01  0:53       ` Satya Tangirala
2020-02-01  0:53         ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-02-03  9:15         ` Christoph Hellwig
2020-02-03  9:15           ` [f2fs-dev] " Christoph Hellwig
2020-02-04  3:39           ` Satya Tangirala
2020-02-04  3:39             ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-02-04 14:58             ` Christoph Hellwig
2020-02-04 14:58               ` [f2fs-dev] " Christoph Hellwig
2020-02-04 21:21               ` Eric Biggers
2020-02-04 21:21                 ` [f2fs-dev] " Eric Biggers
2020-02-05  7:36                 ` Eric Biggers
2020-02-05  7:36                   ` [f2fs-dev] " Eric Biggers
2020-02-05 18:05                   ` Christoph Hellwig
2020-02-05 18:05                     ` [f2fs-dev] " Christoph Hellwig
2020-02-21 12:30                     ` Satya Tangirala
2020-02-21 12:30                       ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-02-21 14:20                       ` Christoph Hellwig
2020-02-21 14:20                         ` [f2fs-dev] " Christoph Hellwig

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=20200117091002.GA15396@infradead.org \
    --to=hch@infradead.org \
    --cc=bmuthuku@qti.qualcomm.com \
    --cc=boojin.kim@samsung.com \
    --cc=kuohong.wang@mediatek.com \
    --cc=linux-block@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
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.