summaryrefslogtreecommitdiffstats
path: root/tools/net/bpf_exp.l
Commit message (Collapse)AuthorAgeFilesLines
* tools, bpf_asm: simplify parser rule for BPF extensionsRay Bellis2016-02-221-16/+68
| | | | | | | | | | We can already use yylval in the lexer for encoding the BPF extension number, so that the parser rules can be further reduced to a single one for each B/H/W case. Signed-off-by: Ray Bellis <ray@isc.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* tools: bpf_asm: cleanup vlan extension related tokenDaniel Borkmann2015-03-241-4/+4
| | | | | | | | We now have K_VLANT, K_VLANP and K_VLANTPID. Clean them up into more descriptive token, namely K_VLAN_TCI, K_VLAN_AVAIL and K_VLAN_TPID. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* filter: introduce SKF_AD_VLAN_TPID BPF extensionMichal Sekletar2015-03-241-0/+2
| | | | | | | | | | | | | | | | | | | | | If vlan offloading takes place then vlan header is removed from frame and its contents, both vlan_tci and vlan_proto, is available to user space via TPACKET interface. However, only vlan_tci can be used in BPF filters. This commit introduces a new BPF extension. It makes possible to load the value of vlan_proto (vlan TPID) to register A. Support for classic BPF and eBPF is being added, analogous to skb->protocol. Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Alexei Starovoitov <ast@plumgrid.com> Cc: Jiri Pirko <jpirko@redhat.com> Signed-off-by: Michal Sekletar <msekleta@redhat.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Alexei Starovoitov <ast@plumgrid.com> Reviewed-by: Jiri Pirko <jiri@resnulli.us> Signed-off-by: David S. Miller <davem@davemloft.net>
* filter: added BPF random opcodeChema Gonzalez2014-04-221-0/+1
| | | | | | | | | | | | | | | Added a new ancillary load (bpf call in eBPF parlance) that produces a 32-bit random number. We are implementing it as an ancillary load (instead of an ISA opcode) because (a) it is simpler, (b) allows easy JITing, and (c) seems more in line with generic ISAs that do not have "get a random number" as a instruction, but as an OS call. The main use for this ancillary load is to perform random packet sampling. Signed-off-by: Chema Gonzalez <chema@google.com> Acked-by: Alexei Starovoitov <ast@plumgrid.com> Acked-by: Daniel Borkmann <dborkman@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* filter: bpf_asm: add minimal bpf asm toolDaniel Borkmann2013-12-111-0/+143
There are a couple of valid use cases for a minimal low-level bpf asm like tool, for example, using/linking to libpcap is not an option, the required BPF filters use Linux extensions that are not supported by libpcap's compiler, a filter might be more complex and not cleanly implementable with libpcap's compiler, particular filter codes should be optimized differently than libpcap's internal BPF compiler does, or for security audits of emitted BPF JIT code for prepared set of BPF instructions resp. BPF JIT compiler development in general. Then, in such cases writing such a filter in low-level syntax can be an good alternative, for example, xt_bpf and cls_bpf users might have requirements that could result in more complex filter code, or one that cannot be expressed with libpcap (e.g. different return codes in cls_bpf for flowids on various BPF code paths). Moreover, BPF JIT implementors may wish to manually write test cases in order to verify the resulting JIT image, and thus need low-level access to BPF code generation as well. Therefore, complete the available toolchain for BPF with this small bpf_asm helper tool for the tools/net/ directory. These 3 complementary minimal helper tools round up and facilitate BPF development. Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>