linux-kernel - Re: 2.6.37-rc7: Regression: b43: crashes in hwrng

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]

Date:	Wed, 5 Jan 2011 04:52:22 +0100
From:	"Mario 'BitKoenig' Holbe" <Mario.Holbe@...Ilmenau.DE>
To:	Herbert Xu <herbert@...dor.hengli.com.au>
Cc:	Larry Finger <Larry.Finger@...inger.net>,
	Matt Mackall <mpm@...enic.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
	Harald Welte <HaraldWelte@...tech.com>,
	Michal Ludvig <michal@...ix.cz>
Subject: Re: 2.6.37-rc7: Regression: b43: crashes in hwrng_register()

On Wed, Jan 05, 2011 at 11:30:20AM +1100, Herbert Xu wrote:
> OK, so xstore really is producing crap.  Can you try this path
> (also against vanilla) to print out some extra info?

All right, here is what happens...

On top of your 3rd patch:

--- linux-source-2.6.37-rc7/drivers/char/hw_random/via-rng.c.hxu3	2011-01-05 04:13:09.452322117 +0100
+++ linux-source-2.6.37-rc7/drivers/char/hw_random/via-rng.c	2011-01-05 03:59:33.169316276 +0100
@@ -97,6 +97,10 @@ static int via_rng_data_present(struct h
 	u32 bytes_out;
 	int i;
 
+	printk(KERN_DEBUG "buf=%p + %zu, via_rng_datum=%p\n",
+			buf, sizeof(buf), via_rng_datum);
+
+
 	/* We choose the recommended 1-byte-per-instruction RNG rate,
 	 * for greater randomness at the expense of speed.  Larger
 	 * values 2, 4, or 8 bytes-per-instruction yield greater

gives:

[  103.276337] buf=f6e23f28 + 28, via_rng_datum=f6e23f30
[  103.276351] f6e23f38 0x0 0x8
[  103.276371] buf=f6e23f28 + 28, via_rng_datum=f6e23f30
[  103.276380] f6e23f38 0xffffffff 0x8
...

According to the VIA PadLock Programming Guide, XSTORE increments EDI by
the number of bytes stored.
This did obviously not matter as long as the buffer was "sufficiently
distant", but now you have the buffer close on the stack and I believe,
the optimizer crops up, hence the EDI increment begins to matter.

IMHO EDI (and EDX - for completeness :)) should be put on the asm
clobber-list, but if I try to do it, I always get:
error: can't find a register in class 'DIREG' while reloading 'asm'
error: 'asm' operand has impossible constraints

So... I have the reason - solution is up to you :)

Btw: the 8 bytes increment (as well as the 8 in EAX 4:0) proves that
XSTOR indeed writes more than 32bit :)


g'nite
   Mario
-- 
The only thing to be scared of, son, is tomorrow.
I don't live for tomorrow. Never saw the fun in it.
                       -- Denny Crane, Boston Legal

Download attachment "signature.asc" of type "application/pgp-signature" (483 bytes)