linux-kernel - Re: [PATCH 2/2] [v2] crypto: hisilicon

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]

Message-ID: <f801a4c1-8fa6-8c14-120c-49c24ec84449@huawei.com>
Date:   Fri, 20 Sep 2019 09:33:33 +0100
From:   John Garry <john.garry@...wei.com>
To:     Arnd Bergmann <arnd@...db.de>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        Zhou Wang <wangzhou1@...ilicon.com>
CC:     Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        Kenneth Lee <liguozhu@...ilicon.com>,
        Mao Wenan <maowenan@...wei.com>,
        Hao Fang <fanghao11@...wei.com>,
        Shiju Jose <shiju.jose@...wei.com>,
        <linux-crypto@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] [v2] crypto: hisilicon - allow compile-testing on x86

On 19/09/2019 15:09, Arnd Bergmann wrote:
> To avoid missing arm64 specific warnings that get introduced
> in this driver, allow compile-testing on all 64-bit architectures.
>
> The only actual arm64 specific code in this driver is an open-
> coded 128 bit MMIO write. On non-arm64 the same can be done
> using memcpy_toio. What I also noticed is that the mmio store
> (either one) is not endian-safe, this will only work on little-
> endian configurations, so I also add a Kconfig dependency on
> that, regardless of the architecture.
> Finally, a depenndecy on CONFIG_64BIT is needed because of the

nit: spelling mistake

> writeq().
>
> Signed-off-by: Arnd Bergmann <arnd@...db.de>
> ---
> v2: actually add !CPU_BIG_ENDIAN dependency as described in the
> changelog
> ---
>  drivers/crypto/hisilicon/Kconfig | 9 ++++++---
>  drivers/crypto/hisilicon/qm.c    | 6 ++++++
>  2 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/crypto/hisilicon/Kconfig b/drivers/crypto/hisilicon/Kconfig
> index ebaf91e0146d..7bfcaa7674fd 100644
> --- a/drivers/crypto/hisilicon/Kconfig
> +++ b/drivers/crypto/hisilicon/Kconfig
> @@ -16,14 +16,15 @@ config CRYPTO_DEV_HISI_SEC
>
>  config CRYPTO_DEV_HISI_QM
>  	tristate
> -	depends on ARM64 && PCI && PCI_MSI
> +	depends on ARM64 || COMPILE_TEST
> +	depends on PCI && PCI_MSI
>  	help
>  	  HiSilicon accelerator engines use a common queue management
>  	  interface. Specific engine driver may use this module.
>
>  config CRYPTO_HISI_SGL
>  	tristate
> -	depends on ARM64
> +	depends on ARM64 || COMPILE_TEST
>  	help
>  	  HiSilicon accelerator engines use a common hardware scatterlist
>  	  interface for data format. Specific engine driver may use this
> @@ -31,7 +32,9 @@ config CRYPTO_HISI_SGL
>
>  config CRYPTO_DEV_HISI_ZIP
>  	tristate "Support for HiSilicon ZIP accelerator"
> -	depends on ARM64 && PCI && PCI_MSI
> +	depends on PCI && PCI_MSI
> +	depends on ARM64 || (COMPILE_TEST && 64BIT)
> +	depends on !CPU_BIG_ENDIAN || COMPILE_TEST
>  	select CRYPTO_DEV_HISI_QM
>  	select CRYPTO_HISI_SGL
>  	select SG_SPLIT
> diff --git a/drivers/crypto/hisilicon/qm.c b/drivers/crypto/hisilicon/qm.c
> index f975c393a603..a8ed699081b7 100644
> --- a/drivers/crypto/hisilicon/qm.c
> +++ b/drivers/crypto/hisilicon/qm.c
> @@ -331,6 +331,12 @@ static void qm_mb_write(struct hisi_qm *qm, const void *src)
>  	void __iomem *fun_base = qm->io_base + QM_MB_CMD_SEND_BASE;
>  	unsigned long tmp0 = 0, tmp1 = 0;
>

Hi Arnd,

> +	if (!IS_ENABLED(CONFIG_ARM64)) {
> +		memcpy_toio(fun_base, src, 16);
> +		wmb();
> +		return;
> +	}
> +
>  	asm volatile("ldp %0, %1, %3\n"
>  		     "stp %0, %1, %2\n"
>  		     "dsb sy\n"
>

As I understand, this operation needs to be done atomically. So - even 
though your change is just for compile testing - the memcpy_to_io() may 
not do the same thing on other archs, right?

I just wonder if it's right to make that change, or at least warn the 
imaginary user of possible malfunction for !arm64.

Thanks,
John