x/net: Add a BPF package #14982
Comments
|
CL https://golang.org/cl/21212 mentions this issue. |
…rograms. The package currently implements the operations defined by https://www.kernel.org/doc/Documentation/networking/filter.txt , which comprises the base BPF virtual machine plus the Linux kernel's extension opcodes. Updates golang/go#14982 Change-Id: Iafb43d80e067040e60465a9bfb7d5f2ca90cc2ae Reviewed-on: https://go-review.googlesource.com/21212 Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
|
Initial implementation done for BPF, working on eBPF. |
|
Much appreciated. One thing: Perhaps it might be better to drop LoadIPv4HeaderLen for avoiding confusion because that's a Linux-specific extension not included in LoadExtension. |
|
Hmm, AFAICT LoadIPv4HeaderLen is part of standard BPF, it's mentioned in the original paper (http://www.tcpdump.org/papers/bpf-usenix93.pdf). It was a compromise to the "purity" of the VM because looking at L4 headers is very common, and it requires some annoying math to calculate the IPv4 header length - so the designers put it in as a standalone opcode. I'll check the BPF source code for freebsd/netbsd and see if it's implemented there. |
|
Well, I mean, I suppose that the classic BPF_MSH (stands for BSD's memory buffer shift?) simply reads 4 bits from the given offset whatever the frame is. But I may be wrong. |
|
Oh, yeah, LoadIPv4HeaderLen is just a BPF_MSH under the hood, there's nothing that explicitly checks for IPv4-ness. In practice, the operation "read the lower nibble of a byte, multiply by 4, and load into the indirection register" is only ever used to calculate the IPv4 header length to skip past it, so I gave it an IPv4-specific name. Do you think we should use a more generic name? |
Or drop it. I'm fine either way. |
|
Reducing the scope of this issue to just BPF, not eBPF - that VM is quite a bit more complex, so I'd like to track it separately. Given that, this bug is done. |
|
CL https://golang.org/cl/23122 mentions this issue. |
Updates #14982. Change-Id: Id12b1e61456832d2b2ffbdbe8cf0a1db4444b1e4 Reviewed-on: https://go-review.googlesource.com/23122 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
From #14974, @mikioh suggested adding a BPF/eBPF package to x/net to handle compiling BPF/eBPF programs. Filing this bug to track that proposal and work.
I have a BPF package in progress, which I'll send out for an API review shortly. Looking at the spec for eBPF, while the VMs have similar names the ISA is different enough that I think we should have two separate packages, and have a FromBPF() helper in the ebpf package to translate Classic BPF into the extended form.
The text was updated successfully, but these errors were encountered: