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: <6bbbb89b-1339-e5a1-b127-09270327b6c8@intel.com>
Date:   Tue, 1 Nov 2022 00:04:53 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Alexey Dobriyan <adobriyan@...il.com>
Cc:     "H. Peter Anvin" <hpa@...or.com>, tglx@...utronix.de,
        mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com,
        linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCH v2] selftests/x86: add "ffff8" -- kernel memory scanner

On 10/31/22 23:45, Alexey Dobriyan wrote:
> On Mon, Oct 31, 2022 at 02:37:43PM -0700, Dave Hansen wrote:
>> On 10/29/22 10:25, Alexey Dobriyan wrote:
>>> 	$ ./ffff8_64 -h
>>> 	usage: ./ffff8_64 [-f] [-r] [-n N] [-s S]
>>> 	        -f: sequential scan
>>> 	        -r: random scan (default)
>>> 	        -n: use N threads (default: $(nproc))
>>> 	        -s: lowest address shift (default: 47)
>>> 	        -t: time to run (default: 256 seconds)
>> Does this mean that if someone is just running all kernel selftests,
>> they need to wait for 256 seconds for this to finish?
> Yes. But low time will cover negligible amount of address space.
> 
> Is there some kind of policy to not do this? LTP surely has similar
> tests for races.

There's no written policy that I know of.  But, right now, the entirety
of the x86 selftests will run in a second or two.  It's actually
something I run in a loop to stress the entry/exit paths when I'm
messing with them.  Something silly like this:

	for i in *_32 *_64; do ./$i; done

Just picking a number out of thin air, I'd say that running for a couple
of seconds, like 2 is fine by default for any one tests.  Longer than
that, and it'll be out of whack with all the other x86 selftests.  If
it's 256 seconds, it just won't get run.

Yes, a single run will not have as much coverage, but a lot of people
run those tests (think 0day) and some folks run them a *lot*, like how I
run them in a loop.

The MPX selftest that was in there was in a similar situation.  It
*could* run for a long, long time and that helped because address
randomization would eventually help find some of the nastier corner
cases.  But, it was limited to a few seconds.

I really think we should stick to just a few seconds at most for any
individual test.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ