All of lore.kernel.org
 help / color / mirror / Atom feed
From: Corentin Labbe <clabbe.montjoie@gmail.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: kernel test robot <lkp@intel.com>,
	kbuild-all@lists.01.org, linux-kernel@vger.kernel.org,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: Re: [PATCH] crypto: sun4i-ss - Fix SHA1 hash on A33-variant with BE CPU
Date: Mon, 7 Sep 2020 18:00:29 +0200	[thread overview]
Message-ID: <20200907160029.GC11894@Red> (raw)
In-Reply-To: <20200907062400.GA15841@gondor.apana.org.au>

On Mon, Sep 07, 2020 at 04:24:00PM +1000, Herbert Xu wrote:
> On Sun, Sep 06, 2020 at 04:52:24PM +0800, kernel test robot wrote:
> >
> > >> drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c:483:35: sparse: sparse: incorrect type in assignment (different base types) @@     expected unsigned int [assigned] [usertype] v @@     got restricted __le32 [usertype] @@
> >    drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c:483:35: sparse:     expected unsigned int [assigned] [usertype] v
> >    drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c:483:35: sparse:     got restricted __le32 [usertype]
> >    drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c:485:35: sparse: sparse: incorrect type in assignment (different base types) @@     expected unsigned int [assigned] [usertype] v @@     got restricted __be32 [usertype] @@
> >    drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c:485:35: sparse:     expected unsigned int [assigned] [usertype] v
> >    drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c:485:35: sparse:     got restricted __be32 [usertype]
> >    drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c:490:27: sparse: sparse: incorrect type in assignment (different base types) @@     expected unsigned int [addressable] [assigned] [usertype] v @@     got restricted __le32 [usertype] @@
> >    drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c:490:27: sparse:     expected unsigned int [addressable] [assigned] [usertype] v
> >    drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c:490:27: sparse:     got restricted __le32 [usertype]
> 
> This appears to be a genuine bug, on big-endian CPUs at least.
> 
> ---8<---
> When the hash is written out on the A33 variant, it is incorrectly
> swabbed on big-endian CPUs, when it should simply be written out as
> is because it's already in the right format.  This was caught by
> sparse warnings.
> 
> Instead of using cpu_to_Xe32 followed by a memcpy, this patch
> converts the final hash write to use put_unaligned instead.  This
> simplifies the code and makes the A33 variant handling a lot clearer.
> 
> This patch also fixes the incorrect endianness marking on wb,
> although this should have no effect in the genereated code.
> 
> Fixes: 1e02e6fbdadb ("crypto: sun4i-ss - add the A33 variant of SS")
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> 
> diff --git a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c
> index dc35edd90034..84f7921de577 100644
> --- a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c
> +++ b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c
> @@ -9,6 +9,7 @@
>   * You could find the datasheet in Documentation/arm/sunxi.rst
>   */
>  #include "sun4i-ss.h"
> +#include <asm/unaligned.h>
>  #include <linux/scatterlist.h>
>  
>  /* This is a totally arbitrary value */
> @@ -196,7 +197,7 @@ static int sun4i_hash(struct ahash_request *areq)
>  	struct sg_mapping_iter mi;
>  	int in_r, err = 0;
>  	size_t copied = 0;
> -	__le32 wb = 0;
> +	u32 wb = 0;
>  
>  	dev_dbg(ss->dev, "%s %s bc=%llu len=%u mode=%x wl=%u h0=%0x",
>  		__func__, crypto_tfm_alg_name(areq->base.tfm),
> @@ -408,7 +409,7 @@ static int sun4i_hash(struct ahash_request *areq)
>  
>  		nbw = op->len - 4 * nwait;
>  		if (nbw) {
> -			wb = cpu_to_le32(*(u32 *)(op->buf + nwait * 4));
> +			wb = le32_to_cpup((__le32 *)(op->buf + nwait * 4));
>  			wb &= GENMASK((nbw * 8) - 1, 0);
>  
>  			op->byte_count += nbw;
> @@ -417,7 +418,7 @@ static int sun4i_hash(struct ahash_request *areq)
>  
>  	/* write the remaining bytes of the nbw buffer */
>  	wb |= ((1 << 7) << (nbw * 8));
> -	bf[j++] = le32_to_cpu(wb);
> +	((__le32 *)bf)[j++] = cpu_to_le32(wb);
>  
>  	/*
>  	 * number of space to pad to obtain 64o minus 8(size) minus 4 (final 1)
> @@ -479,16 +480,16 @@ static int sun4i_hash(struct ahash_request *areq)
>  	/* Get the hash from the device */
>  	if (op->mode == SS_OP_SHA1) {
>  		for (i = 0; i < 5; i++) {
> +			v = readl(ss->base + SS_MD0 + i * 4);
>  			if (ss->variant->sha1_in_be)
> -				v = cpu_to_le32(readl(ss->base + SS_MD0 + i * 4));
> +				put_unaligned(v, areq->result + i * 4);

The put_unaligned should be _le32.

This fix the modprobe tcrypt fail.


WARNING: multiple messages have this Message-ID (diff)
From: Corentin Labbe <clabbe.montjoie@gmail.com>
To: kbuild-all@lists.01.org
Subject: Re: [PATCH] crypto: sun4i-ss - Fix SHA1 hash on A33-variant with BE CPU
Date: Mon, 07 Sep 2020 18:00:29 +0200	[thread overview]
Message-ID: <20200907160029.GC11894@Red> (raw)
In-Reply-To: <20200907062400.GA15841@gondor.apana.org.au>

[-- Attachment #1: Type: text/plain, Size: 4334 bytes --]

On Mon, Sep 07, 2020 at 04:24:00PM +1000, Herbert Xu wrote:
> On Sun, Sep 06, 2020 at 04:52:24PM +0800, kernel test robot wrote:
> >
> > >> drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c:483:35: sparse: sparse: incorrect type in assignment (different base types) @@     expected unsigned int [assigned] [usertype] v @@     got restricted __le32 [usertype] @@
> >    drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c:483:35: sparse:     expected unsigned int [assigned] [usertype] v
> >    drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c:483:35: sparse:     got restricted __le32 [usertype]
> >    drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c:485:35: sparse: sparse: incorrect type in assignment (different base types) @@     expected unsigned int [assigned] [usertype] v @@     got restricted __be32 [usertype] @@
> >    drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c:485:35: sparse:     expected unsigned int [assigned] [usertype] v
> >    drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c:485:35: sparse:     got restricted __be32 [usertype]
> >    drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c:490:27: sparse: sparse: incorrect type in assignment (different base types) @@     expected unsigned int [addressable] [assigned] [usertype] v @@     got restricted __le32 [usertype] @@
> >    drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c:490:27: sparse:     expected unsigned int [addressable] [assigned] [usertype] v
> >    drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c:490:27: sparse:     got restricted __le32 [usertype]
> 
> This appears to be a genuine bug, on big-endian CPUs at least.
> 
> ---8<---
> When the hash is written out on the A33 variant, it is incorrectly
> swabbed on big-endian CPUs, when it should simply be written out as
> is because it's already in the right format.  This was caught by
> sparse warnings.
> 
> Instead of using cpu_to_Xe32 followed by a memcpy, this patch
> converts the final hash write to use put_unaligned instead.  This
> simplifies the code and makes the A33 variant handling a lot clearer.
> 
> This patch also fixes the incorrect endianness marking on wb,
> although this should have no effect in the genereated code.
> 
> Fixes: 1e02e6fbdadb ("crypto: sun4i-ss - add the A33 variant of SS")
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> 
> diff --git a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c
> index dc35edd90034..84f7921de577 100644
> --- a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c
> +++ b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c
> @@ -9,6 +9,7 @@
>   * You could find the datasheet in Documentation/arm/sunxi.rst
>   */
>  #include "sun4i-ss.h"
> +#include <asm/unaligned.h>
>  #include <linux/scatterlist.h>
>  
>  /* This is a totally arbitrary value */
> @@ -196,7 +197,7 @@ static int sun4i_hash(struct ahash_request *areq)
>  	struct sg_mapping_iter mi;
>  	int in_r, err = 0;
>  	size_t copied = 0;
> -	__le32 wb = 0;
> +	u32 wb = 0;
>  
>  	dev_dbg(ss->dev, "%s %s bc=%llu len=%u mode=%x wl=%u h0=%0x",
>  		__func__, crypto_tfm_alg_name(areq->base.tfm),
> @@ -408,7 +409,7 @@ static int sun4i_hash(struct ahash_request *areq)
>  
>  		nbw = op->len - 4 * nwait;
>  		if (nbw) {
> -			wb = cpu_to_le32(*(u32 *)(op->buf + nwait * 4));
> +			wb = le32_to_cpup((__le32 *)(op->buf + nwait * 4));
>  			wb &= GENMASK((nbw * 8) - 1, 0);
>  
>  			op->byte_count += nbw;
> @@ -417,7 +418,7 @@ static int sun4i_hash(struct ahash_request *areq)
>  
>  	/* write the remaining bytes of the nbw buffer */
>  	wb |= ((1 << 7) << (nbw * 8));
> -	bf[j++] = le32_to_cpu(wb);
> +	((__le32 *)bf)[j++] = cpu_to_le32(wb);
>  
>  	/*
>  	 * number of space to pad to obtain 64o minus 8(size) minus 4 (final 1)
> @@ -479,16 +480,16 @@ static int sun4i_hash(struct ahash_request *areq)
>  	/* Get the hash from the device */
>  	if (op->mode == SS_OP_SHA1) {
>  		for (i = 0; i < 5; i++) {
> +			v = readl(ss->base + SS_MD0 + i * 4);
>  			if (ss->variant->sha1_in_be)
> -				v = cpu_to_le32(readl(ss->base + SS_MD0 + i * 4));
> +				put_unaligned(v, areq->result + i * 4);

The put_unaligned should be _le32.

This fix the modprobe tcrypt fail.

  parent reply	other threads:[~2020-09-07 16:01 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-06  8:52 drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c:483:35: sparse: sparse: incorrect type in assignment (different base types) kernel test robot
2020-09-06  8:52 ` kernel test robot
2020-09-07  6:24 ` [PATCH] crypto: sun4i-ss - Fix SHA1 hash on A33-variant with BE CPU Herbert Xu
2020-09-07  6:24   ` Herbert Xu
2020-09-07 14:55   ` Corentin Labbe
2020-09-07 14:55     ` Corentin Labbe
2020-09-07 16:00   ` Corentin Labbe [this message]
2020-09-07 16:00     ` Corentin Labbe
2020-09-08  5:00     ` [v2 PATCH] crypto: sun4i-ss - Fix sparse endianness markers Herbert Xu
2020-09-08  5:00       ` Herbert Xu
2020-09-10 12:22       ` Corentin Labbe
2020-09-10 12:22         ` Corentin Labbe
2020-09-11  4:13         ` Herbert Xu
2020-09-11  4:13           ` Herbert Xu
2020-09-14  7:45           ` Corentin Labbe
2020-09-14  7:45             ` Corentin Labbe
2020-09-14 10:40           ` Corentin Labbe
2020-09-14 10:40             ` Corentin Labbe
2020-09-24  3:08             ` Herbert Xu
2020-09-24  3:08               ` Herbert Xu
2020-09-24 13:27               ` Corentin Labbe
2020-09-24 13:27                 ` Corentin Labbe
2020-10-08  5:52                 ` Herbert Xu
2020-10-08  5:52                   ` Herbert Xu
2020-10-08  6:36                   ` Corentin Labbe
2020-10-08  6:36                     ` Corentin Labbe
2020-10-08 23:35                     ` Eric Biggers
2020-10-08 23:35                       ` Eric Biggers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200907160029.GC11894@Red \
    --to=clabbe.montjoie@gmail.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=kbuild-all@lists.01.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.