Hacker News Reader

Comment by the_only_law | Hacker News Reader

I admittedly have only an extremely cursory knowledge of these sort of technologies, but how does eBPF compare to NDIS filters and WFP filters? Biggest reason I could imagine for this is easier portability of existing eBPF applications.

View on HN

You can do a lot more in NDIS and probably more in WFP than you can in eBPF, if only because eBPF has strict limits on the kinds of loops you can express (they have to be verifiably bounded). Packet-processing BPF programs are tightly bound to Linux kernel APIs, many of which won't be ported here, so I think write-once-run-anywhere is unlikely to be an attribute of this.

Importantly: eBPF has at this point not much to do with packets; it's a generic kernel and userland instrumentation layer. Most new BPF code is written to monitor local program runtimes, not to look at packets.

If Windows adopts XDP, we might get to a point where

The packet-processing BPF programs are less tightly bound to Linux kernel APIs than you might think. Even in Linux, there has been motivation to make the APIs more generic to support different kernel hooks for packets, in particular XDP which doesn't operate on the standard internal packet buffer representation (skbuff).

Microsoft doesn't support XDP, do they?(And you can only use XDP on Linux in certain circumstances). The clsbpf stuff is all pretty heavily tied to skbs.

Also, even in an XDP program, you're still likely to use a bunch of perf stuff, which is again pretty Linux-specific.

…where?

That's exactly what I thought. Because WFP are powerful, NDIS is bonkers (it's what what used by Internet Download Manager and Kaspersky for their features), so the only use case is maybe YARA-style eBPF rulesets.

Reply on news.ycombinator.com