From: Vincent Li <vincent.mc.li@gmail.com>
To: development@lists.ipfire.org
Subject: Re: Enable eBPF XDP/TC kernel feature for IPFire
Date: Wed, 10 Apr 2024 07:11:36 -0700 [thread overview]
Message-ID: <CAK3+h2xzX7bz=X4JXKFjXH_C0CvQs3+zpk2bpSQApN4E=Z3oow@mail.gmail.com> (raw)
In-Reply-To: <96b4035d-8ae5-418d-98df-08cecbb58e9d@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 2424 bytes --]
Hi Adolf,
Please see my reply inline
On Wed, Apr 10, 2024 at 2:04 AM Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>
> Hi Vincent,
>
> I am not very familiar at all with this type of stuff but one thing that I noticed is that in the image you provided a link to, the XDP section has a line labelled XDP_TX which completely bypasses the whole Netfilter section which doesn't seem to be a good idea to me.
>
XDP_TX is to redirect the packet out after processing the packet at
XDP stage, yes, netfilter will not see these packets.
for example for DDoS SYN flood attack scenario, when the SYN packet
is received, XDP program can generate SYN+ACK with syncookie and send
the SYN+ACK out, netfilter/Linux tcp stack knows nothing about it,
which actually saves host CPU cycles to process the SYN in
netfilter/TCP stack, which is actually good thing.
Also, XDP_DROP, XDP_PASS, XDP_TX action is depending on the XDP
program attached to the network interface, so it is the XDP program
author decide what to do with the packet, if no XDP program attached
to the network interface, everything works as usual, no interference
from XDP.
> I don't understand what the difference is between XDP_PASS and XDP_TX but I would expect that nothing should be allowed to bypass the netfilter section unless it is being dropped or rejected already by the XDP process.
>
XDP_PASS is to pass the packet to netfilter/TCP stack as usual after
XDP program packet processing, XDP_TX is to redirect the packet back
out through the same network interface after XDP program packet
processing.
> Regards,
>
> Adolf.
>
> On 09/04/2024 19:36, Vincent Li wrote:
> > Hi,
> >
> > I have been working on enabling eBPF XDP/TC kernel feature for IPFire,
> > please refer to
> > https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg
> > for where XDP fit in Linux network datapath, XDP will not interfere
> > with existing IPFire firewall rules. XDP is especially good at DDoS
> > packet filtering at high speed, see
> > https://netdevconf.info/0x15/slides/30/Netdev%200x15%20Accelerating%20synproxy%20with%20XDP.pdf
> >
> > I think we only need to enable XDP/TC network filtering capability
> > without eBPF tracing capability which some users are concerned about
> > potential host security information leaks.
> >
> > Please let me know what you think, thanks!
> >
> > Vincent
next prev parent reply other threads:[~2024-04-10 14:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-09 17:36 Vincent Li
2024-04-10 9:04 ` Adolf Belka
2024-04-10 14:11 ` Vincent Li [this message]
2024-04-10 15:17 ` Peter Müller
2024-04-10 18:01 ` Vincent Li
2024-04-17 16:07 ` Michael Tremer
2024-04-17 22:36 ` Vincent Li
2024-04-17 22:41 ` Vincent Li
2024-04-18 8:57 ` Michael Tremer
2024-04-18 15:21 ` Vincent Li
2024-04-18 21:13 ` Michael Tremer
2024-04-19 0:17 ` Vincent Li
2024-04-24 15:28 ` Michael Tremer
[not found] <CAK3+h2x_Qx3DtbKGPEexfjfEeoEJVnNhOxZGJMkSMYJZW=qhMg@mail.gmail.com>
2024-04-25 10:08 ` Michael Tremer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAK3+h2xzX7bz=X4JXKFjXH_C0CvQs3+zpk2bpSQApN4E=Z3oow@mail.gmail.com' \
--to=vincent.mc.li@gmail.com \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox