An eBPF Loophole: Using XDP for Egress Traffic

Re:An eBPF Loophole: Using XDP for Egress Traffic by drewg123 on Wednesday November 05, 2025 @11:22AM (#45824716)

Yes, I (with a few others) did a similar optimization for FreeBSD's firewall, with similar results but much greater simplicity using what we call "pfil memory pointer hooks" We wrote a paper about it in 2020 for a conference that was cancelled due to Covid, so its fairly unknown.

On what's now almost 10 year old hardware, we could drop 44Mpps of a volumetric DOS attack and still serve our nominal workload with no impact. See PFILCTL(8) and PFIL(9), focus on ethernet (link layer) packets.

It relies on the same principal -- NIC passes the RX buffer directly to the firewall (ipfw, pf, or ipfilter). If the firewall says the packet is OK, rx processing happens as normal. If it says to drop, then dropping is very fast because it can simply re-use the buffer without re-allocation, re-doing DMA mapping, etc.

[ Parent | on HN ]

Re:An eBPF Loophole: Using XDP for Egress Traffic by toprerules on Wednesday November 05, 2025 @11:37AM (#45824915)

This is an essential use case for XDP - this is how FB's firewall works, and above that their LB uses the same technology.

The beauty of XDP is that it's all eBPF. Completely customizable by injecting policy where it's needed and native to the kernel.

[ Parent | on HN ]

Re:An eBPF Loophole: Using XDP for Egress Traffic by TuxPowered on Friday November 07, 2025 @01:12PM (#45849160)

> On what's now almost 10 year old hardware, we could drop 44Mpps of a volumetric DOS attack and still serve our nominal workload with no impact.

Was filtering done with pf, ipfw or some custom firewall?

[ Parent | on HN ]