linux-kernel - Re: [PATCH 2/2] selftests/x86/fsgsbase: Default to trying to run the test repeatedly

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:   Mon, 11 Feb 2019 12:47:38 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     Shuah Khan <shuah@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H . Peter Anvin" <hpa@...or.com>,
        Andy Lutomirski <luto@...capital.net>,
        linux-kernel@...r.kernel.org, x86@...nel.org,
        linux-kselftest@...r.kernel.org, Dan Rue <dan.rue@...aro.org>
Subject: Re: [PATCH 2/2] selftests/x86/fsgsbase: Default to trying to run the
 test repeatedly

On Mon, Feb 11, 2019 at 09:49:16AM +0100, Ingo Molnar wrote:

> So this isn't very user-friendly either, previously it would run a 
> testcase and immediately provide output.

> Now it's just starting and 'hanging':

>   galatea:~/linux/linux/tools/testing/selftests/x86> ./fsgsbase_64 

> I got bored and Ctrl-C-ed it after ~30 seconds.

> How long is this supposed to run, and why isn't the user informed?

On Intel systems I've got access to it's tended to only run for less
than 10 seconds for me with excursions up to ~30s at most, I'd have
projected it to be about a minute if the tests pass.  However retesting
with Debian's v4.19 kernel it seems to be running a lot more stably so
we're now seeing it run to completion reliably when just one copy of the
test is running.

AFAICT it's not terribly idiomatic to provide much output, and anything
that was per iteration would be *way* too spammy.

> Also, testcases should really be short, so I think a better approach 
> would be to thread the test-case and start an instance on every CPU. That 
> should also excercise SMP bugs, if any.

Well, a *better* approach would be for the underlying issue that the
test is finding to be fixed.

I didn't look at adding more threads as the test case is already
threaded, it does seem that running multiple copies simultaneously makes
things reproduce more quickly so it's definitely useful though it's
still taking multiple iterations.

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