linux-kernel - Re: [PATCH v2] DRBG: fix maximum value checks on 32 bit systems

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: <2035043.6AURNB1mku@myon.chronox.de>
Date:	Thu, 28 Aug 2014 09:13:36 +0200
From:	Stephan Mueller <smueller@...onox.de>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] DRBG: fix maximum value checks on 32 bit systems

Am Mittwoch, 27. August 2014, 21:35:28 schrieb Herbert Xu:

Hi Herbert,

> On Tue, Aug 26, 2014 at 11:36:54AM +0200, Stephan Mueller wrote:
> > The max_addtllen and max_req are defined in drbg_cores[] in crypto/drbg.c
> > for each DRBG type. As size_t on a 32 bit system is 32 bit the bit shifts
> > would not work either.
> > 
> > Thus, I am wondering whether the just applied patch would need to go to
> > Linus
> > tree too? I would think that the following patch would be in order:
> Have you actually tested this on a 32-bit box? If so and it
> actually works then I'd be happy to push it.

I tested the current cryptodev-2.6:

- on x86_64 and on i386

- in FIPS mode and without FIPS mode on both arches

- executing the CAVS testing in FIPS mode and non-FIPS mode on both arches

- executing stress tests (obtain random values at a size randomly selected 
between 1 through 1 million bytes) in both modes on both arches

- adding some debug printks to check for the drbg_max_addtl() on both arches

- adding some debug printks to check for the drbg_max_requests() on both 
arches

I found a bug that was introduced with 
bc034ef5573ef4d81daa666c02a3df1ad28e24a7 when booting in FIPS mode, i.e. it is 
not in Linus' tree. The patch will be on your desk shortly.

Thus, the fix in b9347aff91ce4789619168539f08202d8d6a1177 works. However, this 
patch is based on 05c81ccd9087d238c10b234eadb55632742e5518. So, if we want to 
fix Linus' tree with minimal impact, either these two patches are pushed to 
Linus or I have to port b9347aff91ce4789619168539f08202d8d6a1177 to the 
current Linus tree.
> 
> Cheers,


-- 
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/