linux-kernel - Re: [PATCH V3 4/4] crypto: Add Xilinx AES driver

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 15 Nov 2019 13:45:17 +0100
From:   Corentin Labbe <clabbe.montjoie@...il.com>
To:     Kalyani Akula <kalyani.akula@...inx.com>
Cc:     linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
        Kalyani Akula <kalyania@...inx.com>,
        Harsh Jain <harshj@...inx.com>,
        Sarat Chand Savitala <saratcha@...inx.com>,
        Mohan Marutirao Dhanawade <mohan.dhanawade@...inx.com>
Subject: Re: [PATCH V3 4/4] crypto: Add Xilinx AES driver

On Wed, Nov 06, 2019 at 05:10:35PM +0530, Kalyani Akula wrote:
> This patch adds AES driver support for the Xilinx ZynqMP SoC.
> 
> Signed-off-by: Kalyani Akula <kalyani.akula@...inx.com>
> ---
>  drivers/crypto/Kconfig                 |  11 +
>  drivers/crypto/Makefile                |   2 +
>  drivers/crypto/xilinx/Makefile         |   3 +
>  drivers/crypto/xilinx/zynqmp-aes-gcm.c | 457 +++++++++++++++++++++++++++++++++
>  4 files changed, 473 insertions(+)
>  create mode 100644 drivers/crypto/xilinx/Makefile
>  create mode 100644 drivers/crypto/xilinx/zynqmp-aes-gcm.c
> 
> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> index 1fb622f..8e7d3a9 100644
> --- a/drivers/crypto/Kconfig
> +++ b/drivers/crypto/Kconfig
> @@ -696,6 +696,17 @@ config CRYPTO_DEV_ROCKCHIP
>  	help
>  	  This driver interfaces with the hardware crypto accelerator.
>  	  Supporting cbc/ecb chainmode, and aes/des/des3_ede cipher mode.
> +config CRYPTO_DEV_ZYNQMP_AES
> +	tristate "Support for Xilinx ZynqMP AES hw accelerator"
> +	depends on ARCH_ZYNQMP || COMPILE_TEST
> +	select CRYPTO_AES
> +	select CRYPTO_ENGINE
> +	select CRYPTO_AEAD
> +	help
> +	  Xilinx ZynqMP has AES-GCM engine used for symmetric key
> +	  encryption and decryption. This driver interfaces with AES hw
> +	  accelerator. Select this if you want to use the ZynqMP module
> +	  for AES algorithms.
>  
>  config CRYPTO_DEV_MEDIATEK
>  	tristate "MediaTek's EIP97 Cryptographic Engine driver"
> diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
> index afc4753..b6124b8 100644
> --- a/drivers/crypto/Makefile
> +++ b/drivers/crypto/Makefile
> @@ -47,4 +47,6 @@ obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
>  obj-$(CONFIG_CRYPTO_DEV_BCM_SPU) += bcm/
>  obj-$(CONFIG_CRYPTO_DEV_SAFEXCEL) += inside-secure/
>  obj-$(CONFIG_CRYPTO_DEV_ARTPEC6) += axis/
> +obj-$(CONFIG_CRYPTO_DEV_ZYNQMP_AES) += xilinx/
> +

Hello

you insert a useless newline

[...]
> +static int zynqmp_handle_aes_req(struct crypto_engine *engine,
> +				 void *req)
> +{
> +	struct aead_request *areq =
> +				container_of(req, struct aead_request, base);
> +	struct crypto_aead *aead = crypto_aead_reqtfm(req);
> +	struct zynqmp_aead_tfm_ctx *tfm_ctx = crypto_aead_ctx(aead);
> +	struct zynqmp_aead_req_ctx *rq_ctx = aead_request_ctx(areq);
> +	struct aead_request *subreq;
> +	int need_fallback;
> +	int err;
> +
> +	need_fallback = zynqmp_fallback_check(tfm_ctx, areq);
> +
> +	if (need_fallback) {
> +		subreq = aead_request_alloc(tfm_ctx->fbk_cipher, GFP_KERNEL);
> +		if (!subreq)
> +			return -ENOMEM;
> +
> +		aead_request_set_callback(subreq, areq->base.flags,
> +					  NULL, NULL);
> +		aead_request_set_crypt(subreq, areq->src, areq->dst,
> +				       areq->cryptlen, areq->iv);
> +		aead_request_set_ad(subreq, areq->assoclen);
> +		if (rq_ctx->op == ZYNQMP_AES_ENCRYPT)
> +			err = crypto_aead_encrypt(subreq);
> +		else
> +			err = crypto_aead_decrypt(subreq);
> +		aead_request_free(subreq);

Every other crypto driver which use async fallback does not use aead_request_free() (and do not allocate a new request).
I am puzzled that you can free an async request without waiting for its completion.
Perhaps I am wrong, but since no other driver do like that...

[...]
> +static int zynqmp_aes_aead_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	int err = -1;
> +
> +	if (!pdev->dev.of_node)
> +		return -ENODEV;
> +
> +	aes_drv_ctx.dev = dev;

You should test if dev is not already set.
And add a comment like "this driver support only one instance".

> +	aes_drv_ctx.eemi_ops = zynqmp_pm_get_eemi_ops();
> +	if (IS_ERR(aes_drv_ctx.eemi_ops)) {
> +		dev_err(dev, "Failed to get ZynqMP EEMI interface\n");
> +		return PTR_ERR(aes_drv_ctx.eemi_ops);
> +	}
> +
> +	err = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(ZYNQMP_DMA_BIT_MASK));
> +	if (err < 0) {
> +		dev_err(dev, "No usable DMA configuration\n");
> +		return err;
> +	}
> +
> +	aes_drv_ctx.engine = crypto_engine_alloc_init(dev, 1);
> +	if (!aes_drv_ctx.engine) {
> +		dev_err(dev, "Cannot alloc AES engine\n");
> +		return err;
> +	}
> +
> +	err = crypto_engine_start(aes_drv_ctx.engine);
> +	if (err) {
> +		dev_err(dev, "Cannot start AES engine\n");
> +		return err;
> +	}
> +
> +	err = crypto_register_aead(&aes_drv_ctx.alg.aead);
> +	if (err < 0)
> +		dev_err(dev, "Failed to register AEAD alg.\n");

In case of error you didnt crypto_engine_exit()

Regards