netdev - Re: [PATCH bpf-next v4 2/3] selftests/bpf: Add connmark read test

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]

Date:   Wed, 12 Oct 2022 15:20:01 -0700
From:   Martin KaFai Lau <martin.lau@...ux.dev>
To:     Daniel Xu <dxu@...uu.xyz>
Cc:     pablo@...filter.org, fw@...len.de, netfilter-devel@...r.kernel.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        andrii@...nel.org, daniel@...earbox.net, ast@...nel.org,
        bpf@...r.kernel.org, memxor@...il.com
Subject: Re: [PATCH bpf-next v4 2/3] selftests/bpf: Add connmark read test

On 10/12/22 3:09 PM, Daniel Xu wrote:
> Hi Martin,
> 
> On Tue, Oct 11, 2022 at 10:49:32PM -0700, Martin KaFai Lau wrote:
>> On 8/11/22 2:55 PM, Daniel Xu wrote:
>>> Test that the prog can read from the connection mark. This test is nice
>>> because it ensures progs can interact with netfilter subsystem
>>> correctly.
>>>
>>> Signed-off-by: Daniel Xu <dxu@...uu.xyz>
>>> Acked-by: Kumar Kartikeya Dwivedi <memxor@...il.com>
>>> ---
>>>    tools/testing/selftests/bpf/prog_tests/bpf_nf.c | 3 ++-
>>>    tools/testing/selftests/bpf/progs/test_bpf_nf.c | 3 +++
>>>    2 files changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/tools/testing/selftests/bpf/prog_tests/bpf_nf.c b/tools/testing/selftests/bpf/prog_tests/bpf_nf.c
>>> index 88a2c0bdefec..544bf90ac2a7 100644
>>> --- a/tools/testing/selftests/bpf/prog_tests/bpf_nf.c
>>> +++ b/tools/testing/selftests/bpf/prog_tests/bpf_nf.c
>>> @@ -44,7 +44,7 @@ static int connect_to_server(int srv_fd)
>>>    static void test_bpf_nf_ct(int mode)
>>>    {
>>> -	const char *iptables = "iptables -t raw %s PREROUTING -j CT";
>>> +	const char *iptables = "iptables -t raw %s PREROUTING -j CONNMARK --set-mark 42/0";
>> Hi Daniel Xu, this test starts failing recently in CI [0]:
>>
>> Warning: Extension CONNMARK revision 0 not supported, missing kernel module?
>>    iptables v1.8.8 (nf_tables): Could not fetch rule set generation id:
>> Invalid argument
>>
>>    Warning: Extension CONNMARK revision 0 not supported, missing kernel module?
>>    iptables v1.8.8 (nf_tables): Could not fetch rule set generation id:
>> Invalid argument
>>
>>    Warning: Extension CONNMARK revision 0 not supported, missing kernel module?
>>    iptables v1.8.8 (nf_tables): Could not fetch rule set generation id:
>> Invalid argument
>>
>>    Warning: Extension CONNMARK revision 0 not supported, missing kernel module?
>>    iptables v1.8.8 (nf_tables): Could not fetch rule set generation id:
>> Invalid argument
>>
>>    test_bpf_nf_ct:PASS:test_bpf_nf__open_and_load 0 nsec
>>    test_bpf_nf_ct:FAIL:iptables unexpected error: 1024 (errno 0)
>>
>> Could you help to take a look? Thanks.
>>
>> [0]: https://github.com/kernel-patches/bpf/actions/runs/3231598391/jobs/5291529292
> 
> [...]
> 
> Thanks for letting me know. I took a quick look and it seems that
> synproxy selftest is also failing:
> 
>      2022-10-12T03:14:20.2007627Z test_synproxy:FAIL:iptables -t raw -I PREROUTING      -i tmp1 -p tcp -m tcp --syn --dport 8080 -j CT --notrack unexpected error: 1024 (errno 2)
> 
> Googling the "Could not fetch rule set generation id" yields a lot of
> hits. Most of the links are from downstream projects recommending user
> downgrade iptables (nftables) to iptables-legacy.

Thanks for looking into it!  We have been debugging a bit today also.  I also 
think iptables-legacy is the one to use.  I posted a patch [0].  Let see how the 
CI goes.

The rules that the selftest used is not a lot.  I wonder what it takes to remove 
the iptables command usage from the selftest?

[0]: https://lore.kernel.org/bpf/20221012221235.3529719-1-martin.lau@linux.dev/

> 
> So perhaps iptables/nftables suffered a regression somewhere. I'll take
> a closer look tonight / tomorrow morning.
> 
> Thanks,
> Daniel