diff mbox series

[v3,10/15] crypto/mlx5: add keytag device argument

Message ID 20210504210857.3398397-11-matan@nvidia.com (mailing list archive)
State Changes Requested, archived
Delegated to: akhil goyal
Headers show
Series drivers: introduce mlx5 crypto PMD | expand

Checks

Context Check Description
ci/checkpatch success coding style OK

Commit Message

Matan Azrad May 4, 2021, 9:08 p.m. UTC
From: Suanming Mou <suanmingm@nvidia.com>

A keytag is a piece of data encrypted together with a DEK.

When a DEK is referenced by an MKEY.bsf through its index, the keytag is
also supplied in the BSF as plaintext. The HW will decrypt the DEK (and
the attached keytag) and will fail the operation if the keytags don't
match.

This commit adds the configuration of the keytag with devargs.

Signed-off-by: Suanming Mou <suanmingm@nvidia.com>
Signed-off-by: Matan Azrad <matan@nvidia.com>
---
 drivers/crypto/mlx5/mlx5_crypto.c | 50 +++++++++++++++++--------------
 drivers/crypto/mlx5/mlx5_crypto.h |  3 +-
 2 files changed, 30 insertions(+), 23 deletions(-)

Comments

Akhil Goyal May 8, 2021, 12:31 p.m. UTC | #1
> From: Suanming Mou <suanmingm@nvidia.com>
> 
> A keytag is a piece of data encrypted together with a DEK.
> 
> When a DEK is referenced by an MKEY.bsf through its index, the keytag is
> also supplied in the BSF as plaintext. The HW will decrypt the DEK (and
> the attached keytag) and will fail the operation if the keytags don't
> match.
> 
> This commit adds the configuration of the keytag with devargs.
> 
> Signed-off-by: Suanming Mou <suanmingm@nvidia.com>
> Signed-off-by: Matan Azrad <matan@nvidia.com>
> ---
Documentation for devargs should be part of this patch.
Please split the last patch accordingly.

Title can be shortened to
Crypto/mlx5: add keytag devarg

Fix other patches of devargs accordingly.
Matan Azrad May 9, 2021, 8:31 a.m. UTC | #2
From: Akhil Goyal
> > From: Suanming Mou <suanmingm@nvidia.com>
> >
> > A keytag is a piece of data encrypted together with a DEK.
> >
> > When a DEK is referenced by an MKEY.bsf through its index, the keytag
> > is also supplied in the BSF as plaintext. The HW will decrypt the DEK
> > (and the attached keytag) and will fail the operation if the keytags
> > don't match.
> >
> > This commit adds the configuration of the keytag with devargs.
> >
> > Signed-off-by: Suanming Mou <suanmingm@nvidia.com>
> > Signed-off-by: Matan Azrad <matan@nvidia.com>
> > ---
> Documentation for devargs should be part of this patch.
> Please split the last patch accordingly.
> 
> Title can be shortened to
> Crypto/mlx5: add keytag devarg
> 
> Fix other patches of devargs accordingly.

As I said before, no devargs is really active before adding datapath patches.
The option to add all the supported features \ documentations in the patch which actually adds the support is correct.

The last patch adds the capabilities and docs when all of them are really supported.

Ok for title.
Thomas Monjalon May 9, 2021, 8:56 a.m. UTC | #3
09/05/2021 10:31, Matan Azrad:
> 
> From: Akhil Goyal
> > > From: Suanming Mou <suanmingm@nvidia.com>
> > >
> > > A keytag is a piece of data encrypted together with a DEK.
> > >
> > > When a DEK is referenced by an MKEY.bsf through its index, the keytag
> > > is also supplied in the BSF as plaintext. The HW will decrypt the DEK
> > > (and the attached keytag) and will fail the operation if the keytags
> > > don't match.
> > >
> > > This commit adds the configuration of the keytag with devargs.
> > >
> > > Signed-off-by: Suanming Mou <suanmingm@nvidia.com>
> > > Signed-off-by: Matan Azrad <matan@nvidia.com>
> > > ---
> > Documentation for devargs should be part of this patch.
> > Please split the last patch accordingly.
> > 
> > Title can be shortened to
> > Crypto/mlx5: add keytag devarg
> > 
> > Fix other patches of devargs accordingly.
> 
> As I said before, no devargs is really active before adding datapath patches.
> The option to add all the supported features \ documentations in the patch which actually adds the support is correct.
> 
> The last patch adds the capabilities and docs when all of them are really supported.

I think it is better for git history (blame, etc) to have doc
added at the same time of the code, even if the datapath is not active.
I agree with Akhil.
Akhil Goyal May 9, 2021, 9:17 a.m. UTC | #4
> From: Akhil Goyal
> > > From: Suanming Mou <suanmingm@nvidia.com>
> > >
> > > A keytag is a piece of data encrypted together with a DEK.
> > >
> > > When a DEK is referenced by an MKEY.bsf through its index, the keytag
> > > is also supplied in the BSF as plaintext. The HW will decrypt the DEK
> > > (and the attached keytag) and will fail the operation if the keytags
> > > don't match.
> > >
> > > This commit adds the configuration of the keytag with devargs.
> > >
> > > Signed-off-by: Suanming Mou <suanmingm@nvidia.com>
> > > Signed-off-by: Matan Azrad <matan@nvidia.com>
> > > ---
> > Documentation for devargs should be part of this patch.
> > Please split the last patch accordingly.
> >
> > Title can be shortened to
> > Crypto/mlx5: add keytag devarg
> >
> > Fix other patches of devargs accordingly.
> 
> As I said before, no devargs is really active before adding datapath patches.
> The option to add all the supported features \ documentations in the patch
> which actually adds the support is correct.
> 
> The last patch adds the capabilities and docs when all of them are really
> supported.
> 
In that case split the patches in such a manner that data path is added
Before devargs patch with some dummy values and add the devargs with
Appropriate documentation update in a later patch.
Matan Azrad May 9, 2021, 2:23 p.m. UTC | #5
From: Akhil Goyal
> > From: Akhil Goyal
> > > > From: Suanming Mou <suanmingm@nvidia.com>
> > > >
> > > > A keytag is a piece of data encrypted together with a DEK.
> > > >
> > > > When a DEK is referenced by an MKEY.bsf through its index, the
> > > > keytag is also supplied in the BSF as plaintext. The HW will
> > > > decrypt the DEK (and the attached keytag) and will fail the
> > > > operation if the keytags don't match.
> > > >
> > > > This commit adds the configuration of the keytag with devargs.
> > > >
> > > > Signed-off-by: Suanming Mou <suanmingm@nvidia.com>
> > > > Signed-off-by: Matan Azrad <matan@nvidia.com>
> > > > ---
> > > Documentation for devargs should be part of this patch.
> > > Please split the last patch accordingly.
> > >
> > > Title can be shortened to
> > > Crypto/mlx5: add keytag devarg
> > >
> > > Fix other patches of devargs accordingly.
> >
> > As I said before, no devargs is really active before adding datapath patches.
> > The option to add all the supported features \ documentations in the
> > patch which actually adds the support is correct.
> >
> > The last patch adds the capabilities and docs when all of them are
> > really supported.
> >
> In that case split the patches in such a manner that data path is added Before
> devargs patch with some dummy values and add the devargs with
> Appropriate documentation update in a later patch.


No, data-path must know all the devargs in advance, it cannot work well without them.
Matan Azrad May 9, 2021, 3:41 p.m. UTC | #6
From: Thomas Monjalon
> 09/05/2021 10:31, Matan Azrad:
> >
> > From: Akhil Goyal
> > > > From: Suanming Mou <suanmingm@nvidia.com>
> > > >
> > > > A keytag is a piece of data encrypted together with a DEK.
> > > >
> > > > When a DEK is referenced by an MKEY.bsf through its index, the
> > > > keytag is also supplied in the BSF as plaintext. The HW will
> > > > decrypt the DEK (and the attached keytag) and will fail the
> > > > operation if the keytags don't match.
> > > >
> > > > This commit adds the configuration of the keytag with devargs.
> > > >
> > > > Signed-off-by: Suanming Mou <suanmingm@nvidia.com>
> > > > Signed-off-by: Matan Azrad <matan@nvidia.com>
> > > > ---
> > > Documentation for devargs should be part of this patch.
> > > Please split the last patch accordingly.
> > >
> > > Title can be shortened to
> > > Crypto/mlx5: add keytag devarg
> > >
> > > Fix other patches of devargs accordingly.
> >
> > As I said before, no devargs is really active before adding datapath patches.
> > The option to add all the supported features \ documentations in the patch
> which actually adds the support is correct.
> >
> > The last patch adds the capabilities and docs when all of them are really
> supported.
> 
> I think it is better for git history (blame, etc) to have doc added at the same
> time of the code, even if the datapath is not active.
> I agree with Akhil.

User can read the commit log which explain things enough for blame case. 

I don't agree, here the devargs has no any usage, just saved in the pmd mem.
The devargs is actually active in the last datapath patch, we can squash the doc to datapath patch if you realy insist...
Akhil Goyal May 11, 2021, 5:38 p.m. UTC | #7
> 
> From: Akhil Goyal
> > > From: Akhil Goyal
> > > > > From: Suanming Mou <suanmingm@nvidia.com>
> > > > >
> > > > > A keytag is a piece of data encrypted together with a DEK.
> > > > >
> > > > > When a DEK is referenced by an MKEY.bsf through its index, the
> > > > > keytag is also supplied in the BSF as plaintext. The HW will
> > > > > decrypt the DEK (and the attached keytag) and will fail the
> > > > > operation if the keytags don't match.
> > > > >
> > > > > This commit adds the configuration of the keytag with devargs.
> > > > >
> > > > > Signed-off-by: Suanming Mou <suanmingm@nvidia.com>
> > > > > Signed-off-by: Matan Azrad <matan@nvidia.com>
> > > > > ---
> > > > Documentation for devargs should be part of this patch.
> > > > Please split the last patch accordingly.
> > > >
> > > > Title can be shortened to
> > > > Crypto/mlx5: add keytag devarg
> > > >
> > > > Fix other patches of devargs accordingly.
> > >
> > > As I said before, no devargs is really active before adding datapath
> patches.
> > > The option to add all the supported features \ documentations in the
> > > patch which actually adds the support is correct.
> > >
> > > The last patch adds the capabilities and docs when all of them are
> > > really supported.
> > >
> > In that case split the patches in such a manner that data path is added
> Before
> > devargs patch with some dummy values and add the devargs with
> > Appropriate documentation update in a later patch.
> 
> 
> No, data-path must know all the devargs in advance, it cannot work well
> without them.

The suggestion is to have a sequence like this
Crypto/mlx5: add datapath -- (with some dummy values of devargs.)
Crypto/mlx5: add keytag devarg  -- (replace the dummy values from previous patch
				       with correct one. Add documentation )
Crypto/mx5: add xyz devarg  -- (same as keytag)

Regards,
Akhil
Matan Azrad May 12, 2021, 5:57 a.m. UTC | #8
From: Akhil Goyal 
> > From: Akhil Goyal
> > > > From: Akhil Goyal
> > > > > > From: Suanming Mou <suanmingm@nvidia.com>
> > > > > >
> > > > > > A keytag is a piece of data encrypted together with a DEK.
> > > > > >
> > > > > > When a DEK is referenced by an MKEY.bsf through its index, the
> > > > > > keytag is also supplied in the BSF as plaintext. The HW will
> > > > > > decrypt the DEK (and the attached keytag) and will fail the
> > > > > > operation if the keytags don't match.
> > > > > >
> > > > > > This commit adds the configuration of the keytag with devargs.
> > > > > >
> > > > > > Signed-off-by: Suanming Mou <suanmingm@nvidia.com>
> > > > > > Signed-off-by: Matan Azrad <matan@nvidia.com>
> > > > > > ---
> > > > > Documentation for devargs should be part of this patch.
> > > > > Please split the last patch accordingly.
> > > > >
> > > > > Title can be shortened to
> > > > > Crypto/mlx5: add keytag devarg
> > > > >
> > > > > Fix other patches of devargs accordingly.
> > > >
> > > > As I said before, no devargs is really active before adding
> > > > datapath
> > patches.
> > > > The option to add all the supported features \ documentations in
> > > > the patch which actually adds the support is correct.
> > > >
> > > > The last patch adds the capabilities and docs when all of them are
> > > > really supported.
> > > >
> > > In that case split the patches in such a manner that data path is
> > > added
> > Before
> > > devargs patch with some dummy values and add the devargs with
> > > Appropriate documentation update in a later patch.
> >
> >
> > No, data-path must know all the devargs in advance, it cannot work
> > well without them.
> 
> The suggestion is to have a sequence like this
> Crypto/mlx5: add datapath -- (with some dummy values of devargs.)
> Crypto/mlx5: add keytag devarg  -- (replace the dummy values from previous
> patch
>                                        with correct one. Add documentation )
> Crypto/mx5: add xyz devarg  -- (same as keytag)

Yes, it can be another option.
But I don't see it critical.
If you insist we can do it.
 

> Regards,
> Akhil
diff mbox series

Patch

diff --git a/drivers/crypto/mlx5/mlx5_crypto.c b/drivers/crypto/mlx5/mlx5_crypto.c
index 8cc29ced21..73cca8136b 100644
--- a/drivers/crypto/mlx5/mlx5_crypto.c
+++ b/drivers/crypto/mlx5/mlx5_crypto.c
@@ -468,56 +468,52 @@  mlx5_crypto_args_check_handler(const char *key, const char *val, void *opaque)
 		attr->session_import_kek_ptr = (uint32_t)tmp;
 	else if (strcmp(key, "credential_id") == 0)
 		attr->credential_pointer = (uint32_t)tmp;
+	else if (strcmp(key, "keytag") == 0)
+		devarg_prms->keytag = tmp;
 	else
 		DRV_LOG(WARNING, "Invalid key %s.", key);
 	return 0;
 }
 
-static struct mlx5_devx_obj *
-mlx5_crypto_config_login(struct rte_devargs *devargs,
-			 struct ibv_context *ctx)
+static int
+mlx5_crypto_parse_devargs(struct rte_devargs *devargs,
+			  struct mlx5_crypto_devarg_params *devarg_prms)
 {
-	/*
-	 * Set credential pointer and session import KEK pointer to a default
-	 * value of 0.
-	 */
-	struct mlx5_crypto_devarg_params login = {
-			.login_devarg = false,
-			.login_attr = {
-					.credential_pointer = 0,
-					.session_import_kek_ptr = 0,
-			}
-	};
+	struct mlx5_devx_crypto_login_attr *attr = &devarg_prms->login_attr;
 	struct rte_kvargs *kvlist;
 
+	/* Default values. */
+	attr->credential_pointer = 0;
+	attr->session_import_kek_ptr = 0;
+	devarg_prms->keytag = 0;
 	if (devargs == NULL) {
 		DRV_LOG(ERR,
 	"No login devargs in order to enable crypto operations in the device.");
 		rte_errno = EINVAL;
-		return NULL;
+		return -1;
 	}
 	kvlist = rte_kvargs_parse(devargs->args, NULL);
 	if (kvlist == NULL) {
 		DRV_LOG(ERR, "Failed to parse devargs.");
 		rte_errno = EINVAL;
-		return NULL;
+		return -1;
 	}
 	if (rte_kvargs_process(kvlist, NULL, mlx5_crypto_args_check_handler,
-			   &login) != 0) {
+			   devarg_prms) != 0) {
 		DRV_LOG(ERR, "Devargs handler function Failed.");
 		rte_kvargs_free(kvlist);
 		rte_errno = EINVAL;
-		return NULL;
+		return -1;
 	}
 	rte_kvargs_free(kvlist);
-	if (login.login_devarg == false) {
+	if (devarg_prms->login_devarg == false) {
 		DRV_LOG(ERR,
 	"No login credential devarg in order to enable crypto operations "
 	"in the device.");
 		rte_errno = EINVAL;
-		return NULL;
+		return -1;
 	}
-	return mlx5_devx_cmd_create_crypto_login_obj(ctx, &login.login_attr);
+	return 0;
 }
 
 /**
@@ -543,6 +539,7 @@  mlx5_crypto_pci_probe(struct rte_pci_driver *pci_drv,
 	struct ibv_context *ctx;
 	struct mlx5_devx_obj *login;
 	struct mlx5_crypto_priv *priv;
+	struct mlx5_crypto_devarg_params devarg_prms = { 0 };
 	struct mlx5_hca_attr attr = { 0 };
 	struct rte_cryptodev_pmd_init_params init_params = {
 		.name = "",
@@ -551,6 +548,8 @@  mlx5_crypto_pci_probe(struct rte_pci_driver *pci_drv,
 		.max_nb_queue_pairs =
 				RTE_CRYPTODEV_PMD_DEFAULT_MAX_NB_QUEUE_PAIRS,
 	};
+	int ret;
+
 	RTE_SET_USED(pci_drv);
 	if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
 		DRV_LOG(ERR, "Non-primary process type is not supported.");
@@ -580,7 +579,13 @@  mlx5_crypto_pci_probe(struct rte_pci_driver *pci_drv,
 		rte_errno = ENOTSUP;
 		return -ENOTSUP;
 	}
-	login = mlx5_crypto_config_login(pci_dev->device.devargs, ctx);
+	ret = mlx5_crypto_parse_devargs(pci_dev->device.devargs, &devarg_prms);
+	if (ret) {
+		DRV_LOG(ERR, "Failed to parse devargs.");
+		return -rte_errno;
+	}
+	login = mlx5_devx_cmd_create_crypto_login_obj(ctx,
+						      &devarg_prms.login_attr);
 	if (login == NULL) {
 		DRV_LOG(ERR, "Failed to configure login.");
 		return -rte_errno;
@@ -620,6 +625,7 @@  mlx5_crypto_pci_probe(struct rte_pci_driver *pci_drv,
 	}
 	priv->mr_scache.reg_mr_cb = mlx5_common_verbs_reg_mr;
 	priv->mr_scache.dereg_mr_cb = mlx5_common_verbs_dereg_mr;
+	priv->keytag = rte_cpu_to_be_64(devarg_prms.keytag);
 	pthread_mutex_lock(&priv_list_lock);
 	TAILQ_INSERT_TAIL(&mlx5_crypto_priv_list, priv, next);
 	pthread_mutex_unlock(&priv_list_lock);
diff --git a/drivers/crypto/mlx5/mlx5_crypto.h b/drivers/crypto/mlx5/mlx5_crypto.h
index 0aef804b92..34c65f9a24 100644
--- a/drivers/crypto/mlx5/mlx5_crypto.h
+++ b/drivers/crypto/mlx5/mlx5_crypto.h
@@ -30,6 +30,7 @@  struct mlx5_crypto_priv {
 	struct rte_cryptodev_config dev_config;
 	struct mlx5_mr_share_cache mr_scache; /* Global shared MR cache. */
 	struct mlx5_devx_obj *login_obj;
+	uint64_t keytag;
 };
 
 struct mlx5_crypto_qp {
@@ -49,10 +50,10 @@  struct mlx5_crypto_dek {
 	bool size_is_48; /* Whether the key\data size is 48 bytes or not. */
 };
 
-
 struct mlx5_crypto_devarg_params {
 	bool login_devarg;
 	struct mlx5_devx_crypto_login_attr login_attr;
+	uint64_t keytag;
 };
 
 int