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] [day] [month] [year] [list]
Message-ID: <95c18689-6a98-4d5c-9b38-200270696662@linuxfoundation.org>
Date: Tue, 26 Mar 2024 13:39:19 -0600
From: Shuah Khan <skhan@...uxfoundation.org>
To: Mark Brown <broonie@...nel.org>, Kees Cook <keescook@...omium.org>,
 Andy Lutomirski <luto@...capital.net>, Will Drewry <wad@...omium.org>,
 Shuah Khan <shuah@...nel.org>
Cc: linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org,
 Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH v2] selftests/seccomp: Try to fit runtime of benchmark
 into timeout

On 3/25/24 10:57, Mark Brown wrote:
> The seccomp benchmark runs five scenarios, one calibration run with no
> seccomp filters enabled then four further runs each adding a filter. The
> calibration run times itself for 15s and then each additional run executes
> for the same number of times.
> 
> Currently the seccomp tests, including the benchmark, run with an extended
> 120s timeout but this is not sufficient to robustly run the tests on a lot
> of platforms. Sample timings from some recent runs:
> 
>     Platform          Run 1  Run 2  Run 3  Run 4
>     ---------         -----  -----  -----  -----
>     PowerEdge R200    16.6s  16.6s  31.6s  37.4s
>     BBB (arm)         20.4s  20.4s  54.5s
>     Synquacer (arm64) 20.7s  23.7s  40.3s
> 
> The x86 runs from the PowerEdge are quite marginal and routinely fail, for
> the successful run reported here the timed portions of the run are at
> 117.2s leaving less than 3s of margin which is frequently breached. The
> added overhead of adding filters on the other platforms is such that there
> is no prospect of their runs fitting into the 120s timeout, especially
> on 32 bit arm where there is no BPF JIT.
> 
> While we could lower the time we calibrate for I'm also already seeing the
> currently completing runs reporting issues with the per filter overheads
> not matching expectations:
> 
> Let's instead raise the timeout to 180s which is only a 50% increase on the
> current timeout which is itself not *too* large given that there's only two
> tests in this suite.
> 
> Signed-off-by: Mark Brown <broonie@...nel.org>
> ---
> Changes in v2:
> - Rebase onto v6.9-rc1.
> - Link to v1: https://lore.kernel.org/r/20231219-b4-kselftest-seccomp-benchmark-timeout-v1-1-8515c73015b9@kernel.org

Applied to linux-kselftest fixes for next rc.

thanks,
-- Shuah


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ