Received-SPF: pass (google.com: domain of linux-kernel+bounces-37620-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Message-ID: <3fe0cb4a-9dbe-409a-b856-9b32824583fe@arista.com>
Date: Wed, 24 Jan 2024 19:59:32 +0000
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/3] selftests/net: A couple of typos fixes in
 key-management test
Content-Language: en-US
To: Jakub Kicinski <kuba@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>,
 Eric Dumazet <edumazet@google.com>, Paolo Abeni <pabeni@redhat.com>,
 Shuah Khan <shuah@kernel.org>, Dmitry Safonov <0x7f454c46@gmail.com>,
 Mohammad Nassiri <mnassiri@ciena.com>, netdev@vger.kernel.org,
 linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20240118-tcp-ao-test-key-mgmt-v1-0-3583ca147113@arista.com>
 <20240118085129.6313054b@kernel.org>
 <358faa27-3ea3-4e63-a76f-7b5deeed756d@arista.com>
 <20240118091327.173f3cb0@kernel.org>
 <a9a5378d-c908-4a83-a63d-3e9928733a3d@arista.com>
 <20240124071229.6a7262cc@kernel.org>
 <1ad64e3d-5252-4aaf-82be-5162edd1e781@arista.com>
 <20240124110431.3c3eba9a@kernel.org>
From: Dmitry Safonov <dima@arista.com>
In-Reply-To: <20240124110431.3c3eba9a@kernel.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 1/24/24 19:04, Jakub Kicinski wrote:
> On Wed, 24 Jan 2024 17:46:10 +0000 Dmitry Safonov wrote:
>>>> Thanks!
>>>>
>>>> I'll send a patch for it in version 2 (as I anyway need to address
>>>> Simon's feedback).  
>>>
>>> Hi Dmitry!
>>>
>>> I put TCP_AO and VETH in the config and the tests seem to fail with  
>>
>> Thanks for wiring it up and for https://netdev.bots.linux.dev/status.html!
>>
>>> selftests: net/tcp_ao: rst_ipv4
>>> not ok 1 # error 834[lib/kconfig.c:143] Failed to initialize kconfig 2: No such file or directory
>>> # Planned tests != run tests (0 != 1)
>>> # Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:1  
>>
>> Hehe, yeah I wanted to detect kernels with !CONFIG_TCP_AO, to SKIP the
>> test, rather than FAIL it, which this lib/kconfig.c does.
>> But from a glance, I think it's failing in your run because there are
>> checks with and without TCP_AO, but I didn't think of checking for
>> the hashing algorithms support.
>>
>> I think what happens is has_tcp_ao():
>> : strcpy(tmp.alg_name, "hmac(sha1)");
>> ...
>> : if (setsockopt(sk, IPPROTO_TCP, TCP_AO_ADD_KEY, &tmp, sizeof(tmp)) < 0)
>>
>> Could you check that what I suppose is failing, is actually failing?
>> [dima@Mindolluin linux-master]$ grep -e '\<CONFIG_CRYPTO_SHA1\>' -e
>> '\<CONFIG_CRYPTO_HMAC\>' .config
>> CONFIG_CRYPTO_HMAC=y
>> CONFIG_CRYPTO_SHA1=y
> 
> FWIW the config used is uploaded with the results. If you click on 
> the remote it should take you to a location like this:
> 
> https://netdev-2.bots.linux.dev/vmksft-tcp-ao/results/435369/
> 
> and there should be a config file in there. 
> 
>> If that's the case, I'll  add the detection for hashing algorithms to
>> lib/kconfig.c (together with a patch for
>> tools/testing/selftests/net/config).
>> And also heads up for key-management.c - that tries a bunch of hashing
>> algorithms to check that the work and that the key rotation between
>> different algorithms works:
>>
>> : const char *test_algos[] = {
>> : 	"cmac(aes128)",
>> : 	"hmac(sha1)", "hmac(sha512)", "hmac(sha384)", "hmac(sha256)",
>> : 	"hmac(sha224)", "hmac(sha3-512)",
>> : 	/* only if !CONFIG_FIPS */
>> : #define TEST_NON_FIPS_ALGOS	2
>> : 	"hmac(rmd160)", "hmac(md5)"
>> : };
> 
> I was stuck in a meeting and I started playing around with the options 
> for TCP-AO :)

Haha, the same: 3 hour-long meetings for today :-/

> I added these options now:
> 
> CONFIG_CRYPTO_HMAC=y
> CONFIG_CRYPTO_SHA1=y
> CONFIG_CRYPTO_RMD160=y
> CONFIG_IPV6=y
> CONFIG_TCP_AO=y
> CONFIG_TCP_MD5SIG=y
> CONFIG_VETH=m
> 
> And it looks much better! There are still some failures:
> 
> https://netdev.bots.linux.dev/contest.html?branch=net-next-2024-01-24--18-00&executor=vmksft-tcp-ao

Wow! Nice, thank you!

> 
> I added VRF so that should hopefully take care of the MD5 skips
> on the next run. But the failures of the rst-ip* tests don't look 
> like an obvious config problem.

Yep, I'll look into this this week.

Thanks,
            Dmitry