Subject: [RFC PATCH 0/1] bpf: Add helper to mark xdp_buff->data as PTR_TO_PACKET for tracing

Subject: [RFC PATCH 0/1] bpf: Add helper to mark xdp_buff->data as PTR_TO_PACKET for tracing

[Vijay Nag]

Hi BPF maintainers,

This is an RFC to propose  new BPF helper that will enable tracing programs attached to XDP entry points, such as __xdp_dispatch, to safely parse packet headers using xdp_buff->data with native pointer semantics.

Currently, the verifier treats xdp_buff->data and xdp_buff->data_end as generic PTR_TO_MEM. Consequently, even with proper bounds checks, attempts to access header fields using pointer arithmetic (e.g., eth+1) fail verification. This forces users to revert to bpf_probe_read_kernel() even when the packet data is safely readable in memory.

## Motivation

There are several valid scenarios where tracing or instrumentation tools (e.g., xdpdump, latency profilers) need to inspect packet headers at XDP hook points without writing or maintaining full XDP programs. These scenarios include:

- Conditional flow capture based on IP/TCP header fields
- Per-packet metadata collection (e.g., timestamp, RSS queue, etc.)
- Passive flow observation from fentry to existing XDP functions

In these cases, users often write tracing programs that receive a struct xdp_buff * context and want to treat xdp->data as the start of the packet, similar to how XDP programs can with xdp_md->data.

## Proposal

I propose introducing a new BPF helper:

void *bpf_pkt_ptr_from_xdp_buff(struct xdp_buff *xdp);

This helper would:

- Return xdp->data
- Mark the pointer as PTR_TO_PACKET in verifier metadata
- Allow safe pointer arithmetic and field access (e.g., eth+1, iph->saddr)
- Maintain strict bounds checking via xdp->data_end

This approach allows safe, verifier-friendly packet parsing logic in fentry/kprobe programs that work on struct xdp_buff *.

## Example Usage

SEC("fentry/__xdp_dispatch")
int BPF_PROG(trace_xdp_entry, struct xdp_buff *xdp)
{
    void *data = bpf_pkt_ptr_from_xdp_buff(xdp);
    void *data_end = xdp->data_end;
    struct ethhdr *eth = data;
    if ((void *)(eth + 1) > data_end)
        return 0;
    if (eth->h_proto == bpf_htons(ETH_P_IP))
        bpf_printk("Captured IPv4 packet\n");
    return 0;
}

## Alternatives Considered

- Using bpf_probe_read_kernel() for each header:
  - Works, but incurs copy overhead
  - Prevents natural packet pointer-based idioms
  - Not ideal for frequent filtered tracing

- Teaching the verifier to infer packet provenance on raw PTR_TO_MEM:
  - Complex, error-prone, and hard to generalize

## Security Considerations

- The helper is read-only and does not modify xdp_buff or data
- The returned pointer would follow the same bounds logic as xdp_md->data
- Maintains safety via verifier checks against data_end
- Pattern is similar to existing helpers like bpf_xdp_load_bytes()

## Open Questions

- Would this helper be preferred over modifying verifier logic?
- Is this useful for skb- or tc_buff-based tracing too?
- Should there be constraints on program type or attachment points?

I am eagerly looking forward to your feedback. If the idea is acceptable, I would be happy to submit a working implementation and documentation update.

Thanks,
Vijay Nag

Re: Subject: [RFC PATCH 0/1] bpf: Add helper to mark xdp_buff->data as PTR_TO_PACKET for tracing

[Yonghong Song]

On 7/15/25 11:34 PM, Vijay Nag wrote:
> Hi BPF maintainers,
>
> This is an RFC to propose  new BPF helper that will enable tracing programs attached to XDP entry points, such as __xdp_dispatch, to safely parse packet headers using xdp_buff->data with native pointer semantics.
>
> Currently, the verifier treats xdp_buff->data and xdp_buff->data_end as generic PTR_TO_MEM. Consequently, even with proper bounds checks, attempts to access header fields using pointer arithmetic (e.g., eth+1) fail verification. This forces users to revert to bpf_probe_read_kernel() even when the packet data is safely readable in memory.
>
> ## Motivation
>
> There are several valid scenarios where tracing or instrumentation tools (e.g., xdpdump, latency profilers) need to inspect packet headers at XDP hook points without writing or maintaining full XDP programs. These scenarios include:
>
> - Conditional flow capture based on IP/TCP header fields
> - Per-packet metadata collection (e.g., timestamp, RSS queue, etc.)
> - Passive flow observation from fentry to existing XDP functions
>
> In these cases, users often write tracing programs that receive a struct xdp_buff * context and want to treat xdp->data as the start of the packet, similar to how XDP programs can with xdp_md->data.
>
> ## Proposal
>
> I propose introducing a new BPF helper:
>
> void *bpf_pkt_ptr_from_xdp_buff(struct xdp_buff *xdp);

You cannot introduce bpf helper any more. If really necessary, kfunc is the
only option now.

>
> This helper would:
>
> - Return xdp->data
> - Mark the pointer as PTR_TO_PACKET in verifier metadata
> - Allow safe pointer arithmetic and field access (e.g., eth+1, iph->saddr)
> - Maintain strict bounds checking via xdp->data_end
>
> This approach allows safe, verifier-friendly packet parsing logic in fentry/kprobe programs that work on struct xdp_buff *.
>
> ## Example Usage
>
> SEC("fentry/__xdp_dispatch")
> int BPF_PROG(trace_xdp_entry, struct xdp_buff *xdp)
> {
>      void *data = bpf_pkt_ptr_from_xdp_buff(xdp);
>      void *data_end = xdp->data_end;
>      struct ethhdr *eth = data;
>      if ((void *)(eth + 1) > data_end)
>          return 0;
>      if (eth->h_proto == bpf_htons(ETH_P_IP))
>          bpf_printk("Captured IPv4 packet\n");
>      return 0;
> }

In the above, do not use helper and direct use
   void *data = xdp->data;

With latest bpf-next, your code will succeed with
verification due to the following recent verifier change:
   https://lore.kernel.org/all/20250704230354.1323244-1-eddyz87@gmail.com/

Previously, 'data/data_end' will become a scalar after xdp->{data,data_end}.
But with the above patch set, 'data/data_end' will become
rdonly_untrusted_mem, which allows further dereference.

>
> ## Alternatives Considered
>
> - Using bpf_probe_read_kernel() for each header:
>    - Works, but incurs copy overhead
>    - Prevents natural packet pointer-based idioms
>    - Not ideal for frequent filtered tracing
>
> - Teaching the verifier to infer packet provenance on raw PTR_TO_MEM:
>    - Complex, error-prone, and hard to generalize
>
> ## Security Considerations
>
> - The helper is read-only and does not modify xdp_buff or data
> - The returned pointer would follow the same bounds logic as xdp_md->data
> - Maintains safety via verifier checks against data_end
> - Pattern is similar to existing helpers like bpf_xdp_load_bytes()
>
> ## Open Questions
>
> - Would this helper be preferred over modifying verifier logic?
> - Is this useful for skb- or tc_buff-based tracing too?
> - Should there be constraints on program type or attachment points?
>
> I am eagerly looking forward to your feedback. If the idea is acceptable, I would be happy to submit a working implementation and documentation update.
>
> Thanks,
> Vijay Nag
>
>