netdev - Re: Persistent problem with handshake unit tests

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: <bd9fa2f7-ffc5-44f6-a301-ea9be91285ab@roeck-us.net>
Date: Fri, 2 Feb 2024 19:54:17 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Chuck Lever III <chuck.lever@...cle.com>
Cc: Jakub Kicinski <kuba@...nel.org>,
 kernel-tls-handshake <kernel-tls-handshake@...ts.linux.dev>,
 "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: Persistent problem with handshake unit tests

On 2/2/24 19:46, Chuck Lever III wrote:
> 
> 
>> On Feb 2, 2024, at 3:51 PM, Guenter Roeck <linux@...ck-us.net> wrote:
>>
>> On 2/2/24 12:49, Guenter Roeck wrote:
>>> On 2/2/24 11:22, Jakub Kicinski wrote:
>>>> On Fri, 2 Feb 2024 09:21:22 -0800 Guenter Roeck wrote:
>>>>> when running handshake kunit tests in qemu, I always get the following
>>>>> failure.
>>>>
>>>> Sorry for sidetracking - how do you run kunit to get all the tests?
>>>> We run:
>>>>
>>>>      ./tools/testing/kunit/kunit.py run --alltests
>>>>
>>>> but more and more I feel like the --alltests is a cruel joke.
>>> I have CONFIG_NET_HANDSHAKE_KUNIT_TEST=y enabled in my configuration.
>>> The tests run during boot, so no additional work is needed. I don't run all
>>> tests because many take too long to execute in qemu.
>>
>> Follow-up: If this test isn't supposed to run during boot, please
>> let me know and I'll drop it.
> 
> These are pretty simple tests that should run quickly. I don't see
> a reason to exclude them. Generally the memory environment in the
> Kunit test harness is significantly different than the one at boot,
> so problems like this do crop up for qemu vs. boot time on occasion.
> 
> Question is, has this test started to fail only recently, or has it
> been broken since it was merged?
> 

I am wuite sure that it has been broken since it was merged. I only recently
started actually checking test results, so I missed the problem for a while.
Also, I am not sure if anyone besides me is actually running those tests ;-)

Guenter