linux-kernel - Re: [PATCH] crypto: testmgr: Allow different compression results

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20180419115840.GA14706@hc>
Date:   Thu, 19 Apr 2018 13:58:40 +0200
From:   Jan Glauber <jan.glauber@...iumnetworks.com>
To:     Herbert Xu <herbert@...dor.apana.org.au>
Cc:     "David S . Miller" <davem@...emloft.net>,
        linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
        Mahipal Challa <mchalla@...ium.com>,
        Balakrishna Bhamidipati <bbhamidipati@...ium.com>
Subject: Re: [PATCH] crypto: testmgr: Allow different compression results

On Thu, Apr 19, 2018 at 11:42:11AM +0800, Herbert Xu wrote:
> On Wed, Apr 11, 2018 at 08:28:32PM +0200, Jan Glauber wrote:
> >
> > @@ -1362,7 +1373,17 @@ static int test_comp(struct crypto_comp *tfm,
> >  			goto out;
> >  		}
> >  
> > -		if (dlen != ctemplate[i].outlen) {
> > +		ilen = dlen;
> > +		dlen = COMP_BUF_SIZE;
> > +		ret = crypto_comp_decompress(tfm, output,
> > +					     ilen, decomp_output, &dlen);
> > +		if (ret) {
> > +			pr_err("alg: comp: compression failed: decompress: on test %d for %s failed: ret=%d\n",
> > +			       i + 1, algo, -ret);
> > +			goto out;
> > +		}
> > +
> > +		if (dlen != ctemplate[i].inlen) {
> >  			printk(KERN_ERR "alg: comp: Compression test %d "
> >  			       "failed for %s: output len = %d\n", i + 1, algo,
> >  			       dlen);
> 
> Your patch is fine as it is.
> 
> But I just thought I'd mention that if anyone wants to we should
> really change this to use a different tfm, e.g., always use the
> generic algorithm to perform the decompression.  This way if there
> were multiple implementations we can at least test them against
> the generic one.
> 
> Otherwise you could end up with a buggy implementation that works
> against itself but still generates incorrect output.

Nice idea. Would a crypto_alloc_cipher("deflate", ...) pick the generic
implementation or how can we select it?

--Jan