linux-kernel - Re: [PATCH 2/5] crypto: crypto_user_stat: convert all stats from u32 to u64

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: <20181107185840.GC5133@Red>
Date:   Wed, 7 Nov 2018 19:58:40 +0100
From:   LABBE Corentin <clabbe@...libre.com>
To:     Eric Biggers <ebiggers@...nel.org>
Cc:     davem@...emloft.net, herbert@...dor.apana.org.au,
        linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/5] crypto: crypto_user_stat: convert all stats from u32
 to u64

On Mon, Nov 05, 2018 at 05:42:42PM -0800, Eric Biggers wrote:
> Hi Corentin,
> 
> On Mon, Nov 05, 2018 at 12:51:11PM +0000, Corentin Labbe wrote:
> > All the 32-bit fields need to be 64-bit.  In some cases, UINT32_MAX crypto
> > operations can be done in seconds.
> > 
> > Reported-by: Eric Biggers <ebiggers@...nel.org>
> > Signed-off-by: Corentin Labbe <clabbe@...libre.com>
> > ---
> >  crypto/algapi.c                 |  10 +--
> >  crypto/crypto_user_stat.c       | 114 +++++++++++++++-----------------
> >  include/crypto/acompress.h      |   8 +--
> >  include/crypto/aead.h           |   8 +--
> >  include/crypto/akcipher.h       |  16 ++---
> >  include/crypto/hash.h           |   6 +-
> >  include/crypto/kpp.h            |  12 ++--
> >  include/crypto/rng.h            |   8 +--
> >  include/crypto/skcipher.h       |   8 +--
> >  include/linux/crypto.h          |  46 ++++++-------
> >  include/uapi/linux/cryptouser.h |  38 +++++------
> >  11 files changed, 133 insertions(+), 141 deletions(-)
> > 
> > diff --git a/crypto/algapi.c b/crypto/algapi.c
> > index f5396c88e8cd..42fe316f80ee 100644
> > --- a/crypto/algapi.c
> > +++ b/crypto/algapi.c
> > @@ -259,13 +259,13 @@ static struct crypto_larval *__crypto_register_alg(struct crypto_alg *alg)
> >  	list_add(&larval->alg.cra_list, &crypto_alg_list);
> >  
> >  #ifdef CONFIG_CRYPTO_STATS
> > -	atomic_set(&alg->encrypt_cnt, 0);
> > -	atomic_set(&alg->decrypt_cnt, 0);
> > +	atomic64_set(&alg->encrypt_cnt, 0);
> > +	atomic64_set(&alg->decrypt_cnt, 0);
> >  	atomic64_set(&alg->encrypt_tlen, 0);
> >  	atomic64_set(&alg->decrypt_tlen, 0);
> > -	atomic_set(&alg->verify_cnt, 0);
> > -	atomic_set(&alg->cipher_err_cnt, 0);
> > -	atomic_set(&alg->sign_cnt, 0);
> > +	atomic64_set(&alg->verify_cnt, 0);
> > +	atomic64_set(&alg->cipher_err_cnt, 0);
> > +	atomic64_set(&alg->sign_cnt, 0);
> >  #endif
> >  
> >  out:
> > diff --git a/crypto/crypto_user_stat.c b/crypto/crypto_user_stat.c
> > index a6fb2e6f618d..352569f378a0 100644
> > --- a/crypto/crypto_user_stat.c
> > +++ b/crypto/crypto_user_stat.c
> > @@ -35,22 +35,21 @@ static int crypto_report_aead(struct sk_buff *skb, struct crypto_alg *alg)
> >  {
> >  	struct crypto_stat raead;
> >  	u64 v64;
> > -	u32 v32;
> >  
> >  	memset(&raead, 0, sizeof(raead));
> >  
> >  	strscpy(raead.type, "aead", sizeof(raead.type));
> >  
> > -	v32 = atomic_read(&alg->encrypt_cnt);
> > -	raead.stat_encrypt_cnt = v32;
> > +	v64 = atomic64_read(&alg->encrypt_cnt);
> > +	raead.stat_encrypt_cnt = v64;
> >  	v64 = atomic64_read(&alg->encrypt_tlen);
> >  	raead.stat_encrypt_tlen = v64;
> > -	v32 = atomic_read(&alg->decrypt_cnt);
> > -	raead.stat_decrypt_cnt = v32;
> > +	v64 = atomic64_read(&alg->decrypt_cnt);
> > +	raead.stat_decrypt_cnt = v64;
> >  	v64 = atomic64_read(&alg->decrypt_tlen);
> >  	raead.stat_decrypt_tlen = v64;
> > -	v32 = atomic_read(&alg->aead_err_cnt);
> > -	raead.stat_aead_err_cnt = v32;
> > +	v64 = atomic64_read(&alg->aead_err_cnt);
> > +	raead.stat_aead_err_cnt = v64;
> >  
> >  	return nla_put(skb, CRYPTOCFGA_STAT_AEAD, sizeof(raead), &raead);
> >  }
> 
> Why not assign the result of atomic64_read() directly?
> I don't see the point of the 'v64' variable.
> 

Yes it will be more compact and easier to read

Thanks