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  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:   Fri, 7 Jan 2022 18:44:05 -0800
From:   Alexei Starovoitov <>
To:     Toke Høiland-Jørgensen <>
Cc:     Alexei Starovoitov <>,
        Daniel Borkmann <>,
        Andrii Nakryiko <>,
        Martin KaFai Lau <>,
        Song Liu <>, Yonghong Song <>,
        John Fastabend <>,
        KP Singh <>,
        "David S. Miller" <>,
        Jakub Kicinski <>,
        Jesper Dangaard Brouer <>,
        Network Development <>,
        bpf <>
Subject: Re: [PATCH bpf-next v7 1/3] bpf: Add "live packet" mode for XDP in bpf_prog_run()

On Fri, Jan 7, 2022 at 1:54 PM Toke Høiland-Jørgensen <> wrote:
> Because the data pages are recycled by the page pool, and the test runner
> doesn't re-initialise them for each run, subsequent invocations of the XDP
> program will see the packet data in the state it was after the last time it
> ran on that particular page. This means that an XDP program that modifies
> the packet before redirecting it has to be careful about which assumptions
> it makes about the packet content, but that is only an issue for the most
> naively written programs.

This is too vague and partially incorrect.
The bpf program can do bpf_xdp_adjust_meta() and otherwise change
packet boundaries. These effects will be seen by subsequent
XDP_PASS/TX/REDIRECT, but on the next iteration the boundaries
will get reset to the original values.
So the test runner actually re-initializes some parts of the data,
but not the contents of the packet.
At least that's my understanding of the patch.
The users shouldn't need to dig into implementation to discover this.
Please document it.
The more I think about it the more I believe that it warrants
a little blurb in Documentation/bpf/ that describes what one can
do with this "xdp live mode".

Another question comes to mind:
What happens when a program modifies the packet?
Does it mean that the 2nd frame will see the modified data?
It will not, right?
It's the page pool size of packets that will be inited the same way
at the beginning. Which is NAPI_POLL_WEIGHT * 2 == 128 packets.
Why this number?
Should it be configurable?
Then the user can say: init N packets with this one pattern
and the program will know that exactly N invocation will be
with the same data, but N+1 it will see the 1st packet again
that potentially was modified by the program.
Is it accurate?

Powered by blists - more mailing lists