linux-kernel - Re: [PATCH v2 14/14] selftests/nolibc: tinyconfig: add support for 32/64-bit powerpc

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: <20230722131728.GM17311@1wt.eu>
Date:   Sat, 22 Jul 2023 15:17:28 +0200
From:   Willy Tarreau <w@....eu>
To:     Zhangjin Wu <falcon@...ylab.org>
Cc:     thomas@...ch.de, arnd@...db.de, linux-kernel@...r.kernel.org,
        linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v2 14/14] selftests/nolibc: tinyconfig: add support for
 32/64-bit powerpc

On Wed, Jul 19, 2023 at 09:32:46PM +0800, Zhangjin Wu wrote:
> Firstly, add extra config files for powerpc, powerpc64le and powerpc64.
> 
> Second, QEMU_TIMEOUT is configured as 60 seconds for powerpc to allow
> quit qemu-system-ppc even if poweroff fails. In normal host machine, ~20
> seconds may be enough for boot+test+poweroff, but 60 seconds is used
> here to gurantee it at least finish even in a very slow host machine or
> the host machine is too busy. Both powerpc64le and powerpc64 can
> poweroff normally, no need to configure QEMU_TIMEOUT for them.

Hmmm call me annoying, but this started with tinyconfig "in order to
save build time" and now it's enforcing a 1-minute timeout on a single
test. When I run the tests, they hardly last more than a few seconds
and sometimes even just about one second. If some tests last too long
doing nothing, we should adjust their config (e.g. useless probe of a
driver). If they can't power off due to a config option we need to fix
that option. If it can't power off due to the architecture, we can also
try the reboot (qemu is started with --no-reboot to stop instead of
rebooting), and as a last resort we should rely on the timeout in case
everything else fails. But then this timeout should be quite short
because we'll then have guaranteed from the choice of config options
that it boots and executes fast by default.

Finally, if we need to implement a timeout enforcement for at least
one arch because we do not control every failure case, then there's no
reason for considering that certain archs are safe against this and
others not. This means that we can (should?) implement the timeout by
default for every arch, and make sure that the timeout is never hit by
default, unless there's really absolutely no way to fix the arch that
cannot power down nor reboot, in which case the timeout should remain
short enough.

What's your opinion ?

Willy