linux-kernel - Re: [PATCH REPOST for 2.6.25] Use an own random generator for pageattr-test.c

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]

Date:	Tue, 11 Mar 2008 22:49:26 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Andi Kleen <andi@...stfloor.org>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org, akpm@...l.org
Subject: Re: [PATCH REPOST for 2.6.25] Use an own random generator for pageattr-test.c

On Tue, Mar 11, 2008 at 10:08:07PM +0100, Thomas Gleixner wrote:
> On Tue, 11 Mar 2008, Andi Kleen wrote:
> > > > > > Use an own random generator for pageattr-test.c
> > > > > > 
> > > > > > [Repost. Please ack/nack. This is a bug fix and imho a .25 late merge 
> > > > > > candidate because it fixes a subtle bug]
> > > > > 
> > > > > Care to point out which "subtle bug" is fixed ? 
> > > > > 
> > > > > You replace a random generator by another to get repeateable
> > > > > sequences. The non repeatability of the cpa test patterns is hardly a
> > > > > "subtle bug".
> > > > 
> > > > The subtle bug(s) are first that it is not repeatable (it really should),
> > > 
> > > As I said before. It's hardly a bug. In fact it is questionable
> > > whether fully reproducible test patterns are desired.
> > 
> > Ok then you won't be able to repeat the test ever.
> > 
> > I consider this bad practice in test code because it makes it impossible
> > to stabilize bugs
> 
> Test code with constant test patterns tend to miss the corner case
> bugs, while random pattern test cases hit them assumed that there is a
> broad enough tester base. 

The original idea was that there is enough variability in memory
maps that you still get the various scenarios tested, but that
a boot on a single machine stays deterministic in its behaviour.

> 
> It's a question of how you write such test code to achieve
> reproducability. It's not rocket science to track the variables of a
> test run and print them along with the printk, when a wrong state is
> detected. 

If you wanted to do that you would need some variant of my patch too --
to do it with random32() you would first need to print all NR_CPUS
state (and implement "kernel less" first for NR_CPUS > 128 kernels :),
then keep track of all CPUs the test thread ran on and print that
out too and also disable the regular timer reseeder to avoid races.
Clearly doesn't make sense.

random32() in lib/ is simply unusable as a deterministic RND,
it's more like super weak strange /dev/random variant which
probably should be never put into lib/ anyways because it's unlikely
to be generally useful.

So for a random but repeatable sequence like you describe you could keep the 
patch, replace the static int next = 1; with static int next and add a 
get_random_bytes(&next, sizeof(next)); and then print out the next value

-andi

--
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/