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>] [day] [month] [year] [list]
Message-ID: <CAKKD2Pow_4GOB4qr9Ms4yiXaMjGX7NeGOKay+x6ohTurQGfLcw@mail.gmail.com>
Date: Sun, 30 Mar 2025 07:55:46 +0800
From: Xinyong Wang <wang.xy.chn@...il.com>
To: bpf@...r.kernel.org
Cc: netdev@...r.kernel.org
Subject: [BPF] Question about per-CPU metadata_dst in bpf helper
 bpf_skb_set_tunnel_key implementation

Hi all,

I am an eBPF newbie and still learning the internals. when studying
the implementation of the bpf_skb_set_tunnel_key helper, I have a
question regarding its handling of race conditions.

>From what I understand, bpf_skb_set_tunnel_key uses a per-CPU variable
metadata_dst to set tunnel information for a packet. However, it
appears that the function directly references this per-CPU variable
md_dst without copying the tunnel information to the skb, just
refcounted. This may raise a concern about whether the tunnel
information could be overwritten by another packet before the original
packet is finally sent.

For example:

1. When packet A  tx, it calls bpf_skb_set_tunnel_key, and the tunnel
information is stored in the per-CPU variable md_dst.
2. Packet A is queued into qdisc for transmission
3. Before packet A is sent, packet B arrives at the same CPU and calls
bpf_skb_set_tunnel_key, modifying tunnel info of the same per-CPU
variable md_dst.
4. When packet A is finally sent, it might use the tunnel information
set by packet B, leading to incorrect behavior.

Could someone clarify how the bpf_skb_set_tunnel_key ensures that the
tunnel information is not overwritten in such cases?  why does the
example case above not occur?

Thank you for your time and expertise!

Best regards,
Xinyong

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ