netdev - Re: [netfilter-core] [ANN] net-next is OPEN

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: <51bdbaab-a611-4f4d-aa8c-e004102220f3@kernel.org>
Date: Wed, 7 Feb 2024 12:33:44 +0100
From: Matthieu Baerts <matttbe@...nel.org>
To: Pablo Neira Ayuso <pablo@...filter.org>
Cc: Jakub Kicinski <kuba@...nel.org>,
 Willem de Bruijn <willemdebruijn.kernel@...il.com>, netdev@...r.kernel.org,
 David Ahern <dsahern@...nel.org>, coreteam@...filter.org,
 netdev-driver-reviewers@...r.kernel.org, Hangbin Liu <liuhangbin@...il.com>,
 netfilter-devel@...r.kernel.org
Subject: Re: [netfilter-core] [ANN] net-next is OPEN

Hi Pablo,

Thank you for your reply!

On 07/02/2024 10:49, Pablo Neira Ayuso wrote:
> Hi Matthieu,
> 
> On Tue, Feb 06, 2024 at 07:31:44PM +0100, Matthieu Baerts wrote:
> [...]
>> Good point, I understand it sounds better to use 'iptables-nft' in new
>> kselftests. I should have added a bit of background and not just a link
>> to this commit: at that time (around ~v6.4), we didn't need to force
>> using 'iptables-legacy' on -net or net-next tree. But we needed that
>> when testing kernels <= v5.15.
>>
>> When validating (old) stable kernels, the recommended practice is
>> apparently [1] to use the kselftests from the last stable version, e.g.
>> using the kselftests from v6.7.4 when validating kernel v5.15.148. The
>> kselftests are then supposed to support older kernels, e.g. by skipping
>> some parts if a feature is not available. I didn't know about that
>> before, and I don't know if all kselftests devs know about that.
> 
> We are sending backports to stable kernels, if one stable kernel
> fails, then we have to fix it.

Do you validate stable kernels by running the kselftests from the same
version (e.g. both from v5.15.x) or by using the kselftests from the
last stable one (e.g. kernel v5.15.148 validated using the kselftests
from v6.7.4)?

>> I don't think that's easy to support old kernels, especially in the
>> networking area, where some features/behaviours are not directly exposed
>> to the userspace. Some MPTCP kselftests have to look at /proc/kallsyms
>> or use other (ugly?) workarounds [2] to predict what we are supposed to
>> have, depending on the kernel that is being used. But something has to
>> be done, not to have big kselftests, with many different subtests,
>> always marked as "failed" when validating new stable releases.
> 
> iptables-nft is supported in all of the existing stable kernels.

OK, then we should not have had the bug we had. I thought we were using
features that were not supported in v5.15.

>> Back to the modification to use 'iptables-legacy', maybe a kernel config
>> was missing, but the same kselftest, with the same list of kconfig to
>> add, was not working with the v5.15 kernel, while everything was OK with
>> a v6.4 one. With 'iptables-legacy', the test was running fine on both. I
>> will check if maybe an old kconfig option was not missing.
> 
> I suspect this is most likely kernel config missing, as it happened to Jakub.

Probably, yes. I just retried by testing a v5.15.148 kernel using the
kselftests from the net-next tree and forcing iptables-nft: I no longer
have the issue I had one year ago. Not sure why, we already had
NFT_COMPAT=m back then. Maybe because we recently added IP_NF_FILTER and
similar, because we noticed some CI didn't have them?
Anyway, I will then switch back to iptables-nft. Thanks for the suggestion!

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.