On Nov 12, 2025, at 4:07 AM, David Gwynne <[email protected]> wrote:
> On Tue, Nov 11, 2025 at 11:42:24AM -0800, Guy Harris wrote: >>> Synopsis: The in-kernel BPF interpreter doesn't support BPF_XOR and BPF_MOD >>> Category: kernel >>> Environment: >> System : OpenBSD 7.8 >> Details : OpenBSD 7.8 (GENERIC.MP) #54: Sun Oct 12 12:58:11 MDT 2025 >> [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP >> >> Architecture: OpenBSD.amd64 >> Machine : amd64 >>> Description: >> Linux introduced two new BPF instructions - BPF_XOR, doing a exclusive-or, >> and BPF_MOD, doing a C-style modulo operation. > > wonder what they needed these ops for. I'm not a Linux historian, I'm just poking at kernel commit logs, but: XOR appears to have been introduced as a hack, rather than a BPF operation, in commit ffe06c17afbbbd4d73cdc339419be232847d667a Author: Jiri Pirko <[email protected]> Date: Sat Mar 31 11:01:20 2012 +0000 filter: add XOR operation Add XOR instruction fo BPF machine. Needed for computing packet hashes. This predates the introduction of eBPF into the Linux kernel, but the eBPF Wikipedia article says, in January 2012, "The first non-networking use case of the classic Berkeley Packet Filter, seccomp-bpf,[15] appeared; it allows filtering of system calls using a configurable policy implemented through BPF instructions." Reference 15 is https://lwn.net/Articles/475043/. So this wasn't done for use in libpcap packet filters, it was done for a proto-eBPF, using the "classic" BPF interpreter for purposes other than just filtering packets when capturing. The hack was part of a Linux mechanism by which loads from specialized packet offsets are used to fetch packet metadata. (It's too bad that the "load packet length" instruction in the original BPF wasn't made a "load packet metadata" instruction, with the k field used to indicate which particular metadata value is to be loaded.) In commit b6069a95706ca5738be3f5d90fd286cbd13ac695 Author: Eric Dumazet <[email protected]> Date: Fri Sep 7 22:03:35 2012 +0000 filter: add MOD operation Add a new ALU opcode, to compute a modulus. Commit ffe06c17afbbb used an ancillary to implement XOR_X, but here we reserve one of the available ALU opcode to implement both MOD_X and MOD_K they added MOD as a regular instruction, and the next commit was commit 9e49e88958feb41ec701fa34b44723dabadbc28c Author: Daniel Borkmann <[email protected]> Date: Mon Sep 24 02:23:59 2012 +0000 filter: add XOR instruction for use with X/K SKF_AD_ALU_XOR_X has been added a while ago, but as an 'ancillary' operation that is invoked through a negative offset in K within BPF load operations. Since BPF_MOD has recently been added, BPF_XOR should also be part of the common ALU operations. Removing SKF_AD_ALU_XOR_X might not be an option since this is exposed to user space. they made XOR a regular instruction, which is a cleaner way to do it. There may have been discussion in Linux mailing lists such as linux-netdev on this. I added them to libpcap's user-mode BPF interpreter, and added % and ^ operators in filter expressions, in commit da45f5a83f828aa5e8692834d580dc5e3eaacd1a Author: Guy Harris <[email protected]> Date: Sun May 18 11:16:55 2014 -0700 Support mod and XOR operators. Same opcodes as on Linux. We support them in BPF filters, but warn, in the man page, that using them on anything other than Linux 3.7 or later will cause the filter to run in userland and thus require more resources and perhaps cause more packets to be dropped. (The filter will presumably be rejected by the kernel-mode code if it doesn't support BPF_MOD or BPF_XOR, and libpcap will fall back on running the filter in userland.) probably to 1) keep those opcodes in sync with Linux and 2) expose them in filters, in case anybody has a use for them. NetBSD picked them up in revision 1.68 date: 2014-11-19 19:35:21 +0000; author: christos; state: Exp; lines: +22 -2; branches: 1.68.2; Add BPF_MOD/BPF_XOR, sync DLT entries and document unused bpf instructions. From libpcap-1.6.2 I don't know whether I suggested this to them or they decided to do it on their own. > i'll put the ops in when i get a chance in the next few days. Thanks!
