[v3,10/15] crypto/mlx5: add keytag device argument
Checks
Commit Message
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
> 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.
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.
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.
> 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.
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.
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...
>
> 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
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
@@ -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);
@@ -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