netdev - Re: WARN: multiple IDs found for 'nf_conn': 92168, 117897

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:   Thu, 13 Oct 2022 23:55:41 +0200
From:   Jiri Olsa <olsajiri@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     Jiri Olsa <olsajiri@...il.com>,
        Martin KaFai Lau <martin.lau@...nel.org>,
        bpf@...r.kernel.org,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: WARN: multiple IDs found for 'nf_conn': 92168, 117897 - using
 92168

On Thu, Oct 13, 2022 at 08:05:17AM -0700, Jakub Kicinski wrote:
> On Wed, 5 Oct 2022 22:07:57 +0200 Jiri Olsa wrote:
> > > Yeah, it's there on linux-next, too.
> > > 
> > > Let me grab a fresh VM and try there. Maybe it's my system. Somehow.  
> > 
> > ok, I will look around what's the way to install that centos 8 thing
> 
> Any luck?

yea, sorry for delay, I reproduced that.. first objtool warnings ;-)


[jolsa@...tos8 linux-next]$ make
  UPD     include/generated/compile.h
  CALL    scripts/checksyscalls.sh
  DESCEND objtool
  DESCEND bpf/resolve_btfids
  CC      init/version.o
  AR      init/built-in.a
  AR      built-in.a
  AR      vmlinux.a
  LD      vmlinux.o
vmlinux.o: warning: objtool: relocate_restore_code+0x3c: relocation to !ENDBR: next_arg+0x8
vmlinux.o: warning: objtool: ___ksymtab+bpf_dispatcher_xdp_func+0x0: data relocation to !ENDBR: bpf_dispatcher_xdp_func+0x0
vmlinux.o: warning: objtool: bpf_dispatcher_xdp+0x20: data relocation to !ENDBR: bpf_dispatcher_xdp_func+0x0
  ...



Peter,
as for objtool warnings, looks like with gcc we'll get
endbr64 instruction generated after nops

with centos gcc 8.5:

	ffffffff818d2e20 <bpf_dispatcher_xdp_func>:
	ffffffff818d2e20:       90                      nop
	ffffffff818d2e21:       90                      nop
	ffffffff818d2e22:       90                      nop
	ffffffff818d2e23:       90                      nop
	ffffffff818d2e24:       90                      nop
	ffffffff818d2e25:       f3 0f 1e fa             endbr64
	ffffffff818d2e29:       e9 92 eb 52 00          jmpq   ffffffff81e019c0 <__x86_indirect_thunk_rdx>
	ffffffff818d2e2e:       66 90                   xchg   %ax,%ax

while latest gcc 12 will put it after:

	ffffffff82736900 <bpf_dispatcher_xdp_func>:     
	ffffffff82736900:       f3 0f 1e fa             endbr64 
	ffffffff82736904:       90                      nop    
	ffffffff82736905:       90                      nop    
	ffffffff82736906:       90                      nop
	ffffffff82736907:       90                      nop
	ffffffff82736908:       90                      nop    
	ffffffff82736909:       41 54                   push   %r12
	ffffffff8273690b:       49 89 f4                mov    %rsi,%r12
	ffffffff8273690e:       55                      push   %rbp
	ffffffff8273690f:       48 89 fd                mov    %rdi,%rbp
	ffffffff82736912:       53                      push   %rbx
	ffffffff82736913:       48 89 d3                mov    %rdx,%rbx
	ffffffff82736916:       e8 65 f6 cf fe          call   ffffffff81435f80 <__sanitizer_cov_trace_pc>
	ffffffff8273691b:       4c 89 e6                mov    %r12,%rsi
	ffffffff8273691e:       48 89 ef                mov    %rbp,%rdi
	ffffffff82736921:       48 89 d8                mov    %rbx,%rax
	ffffffff82736924:       5b                      pop    %rbx
	ffffffff82736925:       5d                      pop    %rbp
	ffffffff82736926:       41 5c                   pop    %r12
	ffffffff82736928:       e9 b3 b6 8c 00          jmp    ffffffff83001fe0 <__x86_indirect_thunk_array>

any idea where's the problem? bad backport? ;-)

in any case (unrelated), I'll check the bpf dispatcher code,
I'm not sure the nop update code is aware of the endbr64 instruction

jirka