| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <BN7PR02MB5124F96B9291015478AC8F85AF8B0@BN7PR02MB5124.namprd02.prod.outlook.com>
Date: Wed, 9 Jan 2019 08:53:00 +0000
From: Kalyani Akula <kalyania@...inx.com>
To: Corentin Labbe <clabbe.montjoie@...il.com>
CC: "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
"davem@...emloft.net" <davem@...emloft.net>,
"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Sarat Chand Savitala <saratcha@...inx.com>
Subject: RE: [RFC PATCH 2/3] crypto: Add Xilinx SHA3 driver
Hi Corentin,
Thanks for the review,
Please find my response inline.
> -----Original Message-----
> From: Corentin Labbe [mailto:clabbe.montjoie@...il.com]
> Sent: Monday, January 7, 2019 3:43 PM
> To: Kalyani Akula <kalyania@...inx.com>
> Cc: herbert@...dor.apana.org.au; davem@...emloft.net; linux-
> crypto@...r.kernel.org; linux-kernel@...r.kernel.org; Kalyani Akula
> <kalyania@...inx.com>; Sarat Chand Savitala <saratcha@...inx.com>
> Subject: Re: [RFC PATCH 2/3] crypto: Add Xilinx SHA3 driver
>
> On Mon, Jan 07, 2019 at 02:32:55PM +0530, Kalyani Akula wrote:
> > This patch adds SHA3 driver suuport for the Xilinx ZynqMP SoC.
> >
> > Signed-off-by: Kalyani Akula <kalyani.akula@...inx.com>
>
> Hello
>
> I have some comment below
>
> > +static int zynqmp_sha_init(struct ahash_request *req) {
> > + const struct zynqmp_eemi_ops *eemi_ops =
> zynqmp_pm_get_eemi_ops();
> > + struct zynqmp_sha_reqctx *ctx = ahash_request_ctx(req);
> > + struct crypto_ahash *tfm = crypto_ahash_reqtfm(req);
> > + struct zynqmp_sha_ctx *tctx = crypto_ahash_ctx(tfm);
> > + struct zynqmp_sha_dev *dd = NULL;
> > + struct zynqmp_sha_dev *tmp;
> > + int ret;
> > +
> > + if (!eemi_ops || !eemi_ops->sha_hash)
> > + return -ENOTSUPP;
> > +
>
> Where can I find sha_hash() ?
> It seems that your serie miss some patchs.
This API should go into drivers/firmware/xilinx/zynqmp.c file. Will send fix and send next version.
I was in assumption that the above driver is not in main-line as it was sent as drivers/firmware/Xilinx/zynqmp/firmware.c initially and renamed later to zynqmp.c.
>
> > + spin_lock_bh(&zynqmp_sha.lock);
> > + if (!tctx->dd) {
> > + list_for_each_entry(tmp, &zynqmp_sha.dev_list, list) {
> > + dd = tmp;
> > + break;
> > + }
> > + tctx->dd = dd;
> > + } else {
> > + dd = tctx->dd;
> > + }
> > + spin_unlock_bh(&zynqmp_sha.lock);
> > +
> > + ctx->dd = dd;
> > + dev_dbg(dd->dev, "init: digest size: %d\n",
> > + crypto_ahash_digestsize(tfm));
> > +
> > + ret = eemi_ops->sha_hash(0, 0, ZYNQMP_SHA3_INIT);
> > +
> > + return ret;
> > +}
> > +
> > +static int zynqmp_sha_update(struct ahash_request *req) {
> > + const struct zynqmp_eemi_ops *eemi_ops =
> zynqmp_pm_get_eemi_ops();
> > + struct zynqmp_sha_ctx *tctx = crypto_tfm_ctx(req->base.tfm);
> > + struct zynqmp_sha_dev *dd = tctx->dd;
> > + size_t dma_size = req->nbytes;
> > + dma_addr_t dma_addr;
> > + char *kbuf;
> > + int ret;
> > +
> > + if (!req->nbytes)
> > + return 0;
> > +
> > + if (!eemi_ops || !eemi_ops->sha_hash)
> > + return -ENOTSUPP;
> > +
> > + kbuf = dma_alloc_coherent(dd->dev, dma_size, &dma_addr,
> GFP_KERNEL);
> > + if (!kbuf)
> > + return -ENOMEM;
> > +
> > + scatterwalk_map_and_copy(kbuf, req->src, 0, req->nbytes, 0);
> > + __flush_cache_user_range((unsigned long)kbuf,
> > + (unsigned long)kbuf + dma_size);
> > + ret = eemi_ops->sha_hash(dma_addr, req->nbytes,
> ZYNQMP_SHA3_UPDATE);
>
> Even with the sha_hash prototype missing, I think your driver have a
> problem:
> You support having more than one device, but sha_hash lacks any reference
> on the device doing the request.
Actually this is taken care using PM API id's by which the request is identified in the firmware (platform management unit (PMU-FW)) and sent to specific HW engine.
The ID specific to SHA3 engine will be added include/linux/firmware/xlnx-zynqmp.h in the next version.
>
> > +static int zynqmp_sha_final(struct ahash_request *req) {
> > + const struct zynqmp_eemi_ops *eemi_ops =
> zynqmp_pm_get_eemi_ops();
> > + struct zynqmp_sha_ctx *tctx = crypto_tfm_ctx(req->base.tfm);
> > + struct zynqmp_sha_dev *dd = tctx->dd;
> > + size_t dma_size = SHA384_DIGEST_SIZE;
> > + dma_addr_t dma_addr;
> > + char *kbuf;
> > + int ret;
> > +
> > + if (!eemi_ops || !eemi_ops->sha_hash)
> > + return -ENOTSUPP;
> > +
> > + kbuf = dma_alloc_coherent(dd->dev, dma_size, &dma_addr,
> GFP_KERNEL);
> > + if (!kbuf)
> > + return -ENOMEM;
> > +
> > + ret = eemi_ops->sha_hash(dma_addr, dma_size,
> ZYNQMP_SHA3_FINAL);
> > + memcpy(req->result, kbuf, 48);
>
> It is better to use SHA384_DIGEST_SIZE instead of 48
Will fix in the next version.
>
> [...]
> > +static int zynqmp_sha_probe(struct platform_device *pdev) {
> > + struct zynqmp_sha_dev *sha_dd;
> > + struct device *dev = &pdev->dev;
> > + int err;
> > +
> > + sha_dd = devm_kzalloc(&pdev->dev, sizeof(*sha_dd),
> GFP_KERNEL);
> > + if (!sha_dd)
> > + return -ENOMEM;
> > +
> > + sha_dd->dev = dev;
> > + platform_set_drvdata(pdev, sha_dd);
> > + INIT_LIST_HEAD(&sha_dd->list);
> > + spin_lock_init(&sha_dd->lock);
> > + crypto_init_queue(&sha_dd->queue,
> ZYNQMP_SHA_QUEUE_LENGTH);
>
> You create a queue, but you didnt use it.
>
> [...]
> > + spin_lock(&zynqmp_sha.lock);
> > + list_add_tail(&sha_dd->list, &zynqmp_sha.dev_list);
> > + spin_unlock(&zynqmp_sha.lock);
> > +
> > + err = dma_set_mask_and_coherent(&pdev->dev,
> DMA_BIT_MASK(44));
> > + if (err < 0)
> > + dev_err(dev, "no usable DMA configuration");
>
> It is an error that you ignore, you miss some goto errxxx.
>
Will fix it in the next version.
Regards,
kalyani
> Regards
Powered by blists - more mailing lists