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] [day] [month] [year] [list]

Date: Fri, 16 Feb 2024 16:51:17 +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 16/02/2024 16:38, Pablo Neira Ayuso wrote:
> Hi,
> 
> Sorry for taking a while.
> 
> On Wed, Feb 07, 2024 at 12:33:44PM +0100, Matthieu Baerts wrote:
>> 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)?
> 
> We have kselftests, but nftables/tests/shell probe for kernel
> capabilities then it runs tests according to what the kernel
> supports, this includes packet and control plane path tests. For
> iptables, there are iptables-tests.py for the control plane path.

That's great! It is good to support all the different kernels.

>>>> 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.
> 
> I don't think so, iptables-nft supports the same features as
> iptables-legacy.

We were probably unlucky and hit a kernel/userspace bug that has been
fixed in between, sorry for the noise!

>>>> 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!
> 
> Thanks. If you experience any issue, report back to netfilter-devel@

Will do, thank you!

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