2017-11-01 21:09:13 +07:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
|
2014-09-05 12:17:18 +07:00
|
|
|
/* Copyright (c) 2011-2014 PLUMgrid, http://plumgrid.com
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of version 2 of the GNU General Public
|
|
|
|
* License as published by the Free Software Foundation.
|
|
|
|
*/
|
|
|
|
#ifndef _UAPI__LINUX_BPF_H__
|
|
|
|
#define _UAPI__LINUX_BPF_H__
|
|
|
|
|
|
|
|
#include <linux/types.h>
|
2014-10-14 16:08:54 +07:00
|
|
|
#include <linux/bpf_common.h>
|
2014-09-05 12:17:18 +07:00
|
|
|
|
|
|
|
/* Extended instruction set based on top of classic BPF */
|
|
|
|
|
|
|
|
/* instruction classes */
|
|
|
|
#define BPF_ALU64 0x07 /* alu mode in double word width */
|
|
|
|
|
|
|
|
/* ld/ldx fields */
|
2018-01-17 18:05:36 +07:00
|
|
|
#define BPF_DW 0x18 /* double word (64-bit) */
|
2014-09-05 12:17:18 +07:00
|
|
|
#define BPF_XADD 0xc0 /* exclusive add */
|
|
|
|
|
|
|
|
/* alu/jmp fields */
|
|
|
|
#define BPF_MOV 0xb0 /* mov reg to reg */
|
|
|
|
#define BPF_ARSH 0xc0 /* sign extending arithmetic shift right */
|
|
|
|
|
|
|
|
/* change endianness of a register */
|
|
|
|
#define BPF_END 0xd0 /* flags for endianness conversion: */
|
|
|
|
#define BPF_TO_LE 0x00 /* convert to little-endian */
|
|
|
|
#define BPF_TO_BE 0x08 /* convert to big-endian */
|
|
|
|
#define BPF_FROM_LE BPF_TO_LE
|
|
|
|
#define BPF_FROM_BE BPF_TO_BE
|
|
|
|
|
bpf: add BPF_J{LT,LE,SLT,SLE} instructions
Currently, eBPF only understands BPF_JGT (>), BPF_JGE (>=),
BPF_JSGT (s>), BPF_JSGE (s>=) instructions, this means that
particularly *JLT/*JLE counterparts involving immediates need
to be rewritten from e.g. X < [IMM] by swapping arguments into
[IMM] > X, meaning the immediate first is required to be loaded
into a register Y := [IMM], such that then we can compare with
Y > X. Note that the destination operand is always required to
be a register.
This has the downside of having unnecessarily increased register
pressure, meaning complex program would need to spill other
registers temporarily to stack in order to obtain an unused
register for the [IMM]. Loading to registers will thus also
affect state pruning since we need to account for that register
use and potentially those registers that had to be spilled/filled
again. As a consequence slightly more stack space might have
been used due to spilling, and BPF programs are a bit longer
due to extra code involving the register load and potentially
required spill/fills.
Thus, add BPF_JLT (<), BPF_JLE (<=), BPF_JSLT (s<), BPF_JSLE (s<=)
counterparts to the eBPF instruction set. Modifying LLVM to
remove the NegateCC() workaround in a PoC patch at [1] and
allowing it to also emit the new instructions resulted in
cilium's BPF programs that are injected into the fast-path to
have a reduced program length in the range of 2-3% (e.g.
accumulated main and tail call sections from one of the object
file reduced from 4864 to 4729 insns), reduced complexity in
the range of 10-30% (e.g. accumulated sections reduced in one
of the cases from 116432 to 88428 insns), and reduced stack
usage in the range of 1-5% (e.g. accumulated sections from one
of the object files reduced from 824 to 784b).
The modification for LLVM will be incorporated in a backwards
compatible way. Plan is for LLVM to have i) a target specific
option to offer a possibility to explicitly enable the extension
by the user (as we have with -m target specific extensions today
for various CPU insns), and ii) have the kernel checked for
presence of the extensions and enable them transparently when
the user is selecting more aggressive options such as -march=native
in a bpf target context. (Other frontends generating BPF byte
code, e.g. ply can probe the kernel directly for its code
generation.)
[1] https://github.com/borkmann/llvm/tree/bpf-insns
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-08-10 06:39:55 +07:00
|
|
|
/* jmp encodings */
|
2014-09-05 12:17:18 +07:00
|
|
|
#define BPF_JNE 0x50 /* jump != */
|
bpf: add BPF_J{LT,LE,SLT,SLE} instructions
Currently, eBPF only understands BPF_JGT (>), BPF_JGE (>=),
BPF_JSGT (s>), BPF_JSGE (s>=) instructions, this means that
particularly *JLT/*JLE counterparts involving immediates need
to be rewritten from e.g. X < [IMM] by swapping arguments into
[IMM] > X, meaning the immediate first is required to be loaded
into a register Y := [IMM], such that then we can compare with
Y > X. Note that the destination operand is always required to
be a register.
This has the downside of having unnecessarily increased register
pressure, meaning complex program would need to spill other
registers temporarily to stack in order to obtain an unused
register for the [IMM]. Loading to registers will thus also
affect state pruning since we need to account for that register
use and potentially those registers that had to be spilled/filled
again. As a consequence slightly more stack space might have
been used due to spilling, and BPF programs are a bit longer
due to extra code involving the register load and potentially
required spill/fills.
Thus, add BPF_JLT (<), BPF_JLE (<=), BPF_JSLT (s<), BPF_JSLE (s<=)
counterparts to the eBPF instruction set. Modifying LLVM to
remove the NegateCC() workaround in a PoC patch at [1] and
allowing it to also emit the new instructions resulted in
cilium's BPF programs that are injected into the fast-path to
have a reduced program length in the range of 2-3% (e.g.
accumulated main and tail call sections from one of the object
file reduced from 4864 to 4729 insns), reduced complexity in
the range of 10-30% (e.g. accumulated sections reduced in one
of the cases from 116432 to 88428 insns), and reduced stack
usage in the range of 1-5% (e.g. accumulated sections from one
of the object files reduced from 824 to 784b).
The modification for LLVM will be incorporated in a backwards
compatible way. Plan is for LLVM to have i) a target specific
option to offer a possibility to explicitly enable the extension
by the user (as we have with -m target specific extensions today
for various CPU insns), and ii) have the kernel checked for
presence of the extensions and enable them transparently when
the user is selecting more aggressive options such as -march=native
in a bpf target context. (Other frontends generating BPF byte
code, e.g. ply can probe the kernel directly for its code
generation.)
[1] https://github.com/borkmann/llvm/tree/bpf-insns
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-08-10 06:39:55 +07:00
|
|
|
#define BPF_JLT 0xa0 /* LT is unsigned, '<' */
|
|
|
|
#define BPF_JLE 0xb0 /* LE is unsigned, '<=' */
|
2014-09-05 12:17:18 +07:00
|
|
|
#define BPF_JSGT 0x60 /* SGT is signed '>', GT in x86 */
|
|
|
|
#define BPF_JSGE 0x70 /* SGE is signed '>=', GE in x86 */
|
bpf: add BPF_J{LT,LE,SLT,SLE} instructions
Currently, eBPF only understands BPF_JGT (>), BPF_JGE (>=),
BPF_JSGT (s>), BPF_JSGE (s>=) instructions, this means that
particularly *JLT/*JLE counterparts involving immediates need
to be rewritten from e.g. X < [IMM] by swapping arguments into
[IMM] > X, meaning the immediate first is required to be loaded
into a register Y := [IMM], such that then we can compare with
Y > X. Note that the destination operand is always required to
be a register.
This has the downside of having unnecessarily increased register
pressure, meaning complex program would need to spill other
registers temporarily to stack in order to obtain an unused
register for the [IMM]. Loading to registers will thus also
affect state pruning since we need to account for that register
use and potentially those registers that had to be spilled/filled
again. As a consequence slightly more stack space might have
been used due to spilling, and BPF programs are a bit longer
due to extra code involving the register load and potentially
required spill/fills.
Thus, add BPF_JLT (<), BPF_JLE (<=), BPF_JSLT (s<), BPF_JSLE (s<=)
counterparts to the eBPF instruction set. Modifying LLVM to
remove the NegateCC() workaround in a PoC patch at [1] and
allowing it to also emit the new instructions resulted in
cilium's BPF programs that are injected into the fast-path to
have a reduced program length in the range of 2-3% (e.g.
accumulated main and tail call sections from one of the object
file reduced from 4864 to 4729 insns), reduced complexity in
the range of 10-30% (e.g. accumulated sections reduced in one
of the cases from 116432 to 88428 insns), and reduced stack
usage in the range of 1-5% (e.g. accumulated sections from one
of the object files reduced from 824 to 784b).
The modification for LLVM will be incorporated in a backwards
compatible way. Plan is for LLVM to have i) a target specific
option to offer a possibility to explicitly enable the extension
by the user (as we have with -m target specific extensions today
for various CPU insns), and ii) have the kernel checked for
presence of the extensions and enable them transparently when
the user is selecting more aggressive options such as -march=native
in a bpf target context. (Other frontends generating BPF byte
code, e.g. ply can probe the kernel directly for its code
generation.)
[1] https://github.com/borkmann/llvm/tree/bpf-insns
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-08-10 06:39:55 +07:00
|
|
|
#define BPF_JSLT 0xc0 /* SLT is signed, '<' */
|
|
|
|
#define BPF_JSLE 0xd0 /* SLE is signed, '<=' */
|
2014-09-05 12:17:18 +07:00
|
|
|
#define BPF_CALL 0x80 /* function call */
|
|
|
|
#define BPF_EXIT 0x90 /* function return */
|
|
|
|
|
|
|
|
/* Register numbers */
|
|
|
|
enum {
|
|
|
|
BPF_REG_0 = 0,
|
|
|
|
BPF_REG_1,
|
|
|
|
BPF_REG_2,
|
|
|
|
BPF_REG_3,
|
|
|
|
BPF_REG_4,
|
|
|
|
BPF_REG_5,
|
|
|
|
BPF_REG_6,
|
|
|
|
BPF_REG_7,
|
|
|
|
BPF_REG_8,
|
|
|
|
BPF_REG_9,
|
|
|
|
BPF_REG_10,
|
|
|
|
__MAX_BPF_REG,
|
|
|
|
};
|
|
|
|
|
|
|
|
/* BPF has 10 general purpose 64-bit registers and stack frame. */
|
|
|
|
#define MAX_BPF_REG __MAX_BPF_REG
|
|
|
|
|
|
|
|
struct bpf_insn {
|
|
|
|
__u8 code; /* opcode */
|
|
|
|
__u8 dst_reg:4; /* dest register */
|
|
|
|
__u8 src_reg:4; /* source register */
|
|
|
|
__s16 off; /* signed offset */
|
|
|
|
__s32 imm; /* signed immediate constant */
|
|
|
|
};
|
|
|
|
|
2017-01-21 23:26:11 +07:00
|
|
|
/* Key of an a BPF_MAP_TYPE_LPM_TRIE entry */
|
|
|
|
struct bpf_lpm_trie_key {
|
|
|
|
__u32 prefixlen; /* up to 32 for AF_INET, 128 for AF_INET6 */
|
|
|
|
__u8 data[0]; /* Arbitrary size */
|
|
|
|
};
|
|
|
|
|
2015-10-29 20:58:09 +07:00
|
|
|
/* BPF syscall commands, see bpf(2) man-page for details. */
|
2014-09-26 14:16:57 +07:00
|
|
|
enum bpf_cmd {
|
|
|
|
BPF_MAP_CREATE,
|
bpf: add lookup/update/delete/iterate methods to BPF maps
'maps' is a generic storage of different types for sharing data between kernel
and userspace.
The maps are accessed from user space via BPF syscall, which has commands:
- create a map with given type and attributes
fd = bpf(BPF_MAP_CREATE, union bpf_attr *attr, u32 size)
returns fd or negative error
- lookup key in a given map referenced by fd
err = bpf(BPF_MAP_LOOKUP_ELEM, union bpf_attr *attr, u32 size)
using attr->map_fd, attr->key, attr->value
returns zero and stores found elem into value or negative error
- create or update key/value pair in a given map
err = bpf(BPF_MAP_UPDATE_ELEM, union bpf_attr *attr, u32 size)
using attr->map_fd, attr->key, attr->value
returns zero or negative error
- find and delete element by key in a given map
err = bpf(BPF_MAP_DELETE_ELEM, union bpf_attr *attr, u32 size)
using attr->map_fd, attr->key
- iterate map elements (based on input key return next_key)
err = bpf(BPF_MAP_GET_NEXT_KEY, union bpf_attr *attr, u32 size)
using attr->map_fd, attr->key, attr->next_key
- close(fd) deletes the map
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-26 14:16:59 +07:00
|
|
|
BPF_MAP_LOOKUP_ELEM,
|
|
|
|
BPF_MAP_UPDATE_ELEM,
|
|
|
|
BPF_MAP_DELETE_ELEM,
|
|
|
|
BPF_MAP_GET_NEXT_KEY,
|
2014-09-26 14:17:00 +07:00
|
|
|
BPF_PROG_LOAD,
|
2015-10-29 20:58:09 +07:00
|
|
|
BPF_OBJ_PIN,
|
|
|
|
BPF_OBJ_GET,
|
bpf: add BPF_PROG_ATTACH and BPF_PROG_DETACH commands
Extend the bpf(2) syscall by two new commands, BPF_PROG_ATTACH and
BPF_PROG_DETACH which allow attaching and detaching eBPF programs
to a target.
On the API level, the target could be anything that has an fd in
userspace, hence the name of the field in union bpf_attr is called
'target_fd'.
When called with BPF_ATTACH_TYPE_CGROUP_INET_{E,IN}GRESS, the target is
expected to be a valid file descriptor of a cgroup v2 directory which
has the bpf controller enabled. These are the only use-cases
implemented by this patch at this point, but more can be added.
If a program of the given type already exists in the given cgroup,
the program is swapped automically, so userspace does not have to drop
an existing program first before installing a new one, which would
otherwise leave a gap in which no program is attached.
For more information on the propagation logic to subcgroups, please
refer to the bpf cgroup controller implementation.
The API is guarded by CAP_NET_ADMIN.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-23 22:52:27 +07:00
|
|
|
BPF_PROG_ATTACH,
|
|
|
|
BPF_PROG_DETACH,
|
2017-03-31 11:45:38 +07:00
|
|
|
BPF_PROG_TEST_RUN,
|
2017-06-06 02:15:48 +07:00
|
|
|
BPF_PROG_GET_NEXT_ID,
|
|
|
|
BPF_MAP_GET_NEXT_ID,
|
2017-06-06 02:15:49 +07:00
|
|
|
BPF_PROG_GET_FD_BY_ID,
|
2017-06-06 02:15:50 +07:00
|
|
|
BPF_MAP_GET_FD_BY_ID,
|
2017-06-06 02:15:52 +07:00
|
|
|
BPF_OBJ_GET_INFO_BY_FD,
|
2017-10-03 12:50:22 +07:00
|
|
|
BPF_PROG_QUERY,
|
2018-03-29 02:05:37 +07:00
|
|
|
BPF_RAW_TRACEPOINT_OPEN,
|
2018-04-19 05:56:01 +07:00
|
|
|
BPF_BTF_LOAD,
|
2014-09-26 14:16:57 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
enum bpf_map_type {
|
|
|
|
BPF_MAP_TYPE_UNSPEC,
|
2014-11-14 08:36:45 +07:00
|
|
|
BPF_MAP_TYPE_HASH,
|
2014-11-14 08:36:46 +07:00
|
|
|
BPF_MAP_TYPE_ARRAY,
|
bpf: allow bpf programs to tail-call other bpf programs
introduce bpf_tail_call(ctx, &jmp_table, index) helper function
which can be used from BPF programs like:
int bpf_prog(struct pt_regs *ctx)
{
...
bpf_tail_call(ctx, &jmp_table, index);
...
}
that is roughly equivalent to:
int bpf_prog(struct pt_regs *ctx)
{
...
if (jmp_table[index])
return (*jmp_table[index])(ctx);
...
}
The important detail that it's not a normal call, but a tail call.
The kernel stack is precious, so this helper reuses the current
stack frame and jumps into another BPF program without adding
extra call frame.
It's trivially done in interpreter and a bit trickier in JITs.
In case of x64 JIT the bigger part of generated assembler prologue
is common for all programs, so it is simply skipped while jumping.
Other JITs can do similar prologue-skipping optimization or
do stack unwind before jumping into the next program.
bpf_tail_call() arguments:
ctx - context pointer
jmp_table - one of BPF_MAP_TYPE_PROG_ARRAY maps used as the jump table
index - index in the jump table
Since all BPF programs are idenitified by file descriptor, user space
need to populate the jmp_table with FDs of other BPF programs.
If jmp_table[index] is empty the bpf_tail_call() doesn't jump anywhere
and program execution continues as normal.
New BPF_MAP_TYPE_PROG_ARRAY map type is introduced so that user space can
populate this jmp_table array with FDs of other bpf programs.
Programs can share the same jmp_table array or use multiple jmp_tables.
The chain of tail calls can form unpredictable dynamic loops therefore
tail_call_cnt is used to limit the number of calls and currently is set to 32.
Use cases:
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
==========
- simplify complex programs by splitting them into a sequence of small programs
- dispatch routine
For tracing and future seccomp the program may be triggered on all system
calls, but processing of syscall arguments will be different. It's more
efficient to implement them as:
int syscall_entry(struct seccomp_data *ctx)
{
bpf_tail_call(ctx, &syscall_jmp_table, ctx->nr /* syscall number */);
... default: process unknown syscall ...
}
int sys_write_event(struct seccomp_data *ctx) {...}
int sys_read_event(struct seccomp_data *ctx) {...}
syscall_jmp_table[__NR_write] = sys_write_event;
syscall_jmp_table[__NR_read] = sys_read_event;
For networking the program may call into different parsers depending on
packet format, like:
int packet_parser(struct __sk_buff *skb)
{
... parse L2, L3 here ...
__u8 ipproto = load_byte(skb, ... offsetof(struct iphdr, protocol));
bpf_tail_call(skb, &ipproto_jmp_table, ipproto);
... default: process unknown protocol ...
}
int parse_tcp(struct __sk_buff *skb) {...}
int parse_udp(struct __sk_buff *skb) {...}
ipproto_jmp_table[IPPROTO_TCP] = parse_tcp;
ipproto_jmp_table[IPPROTO_UDP] = parse_udp;
- for TC use case, bpf_tail_call() allows to implement reclassify-like logic
- bpf_map_update_elem/delete calls into BPF_MAP_TYPE_PROG_ARRAY jump table
are atomic, so user space can build chains of BPF programs on the fly
Implementation details:
=======================
- high performance of bpf_tail_call() is the goal.
It could have been implemented without JIT changes as a wrapper on top of
BPF_PROG_RUN() macro, but with two downsides:
. all programs would have to pay performance penalty for this feature and
tail call itself would be slower, since mandatory stack unwind, return,
stack allocate would be done for every tailcall.
. tailcall would be limited to programs running preempt_disabled, since
generic 'void *ctx' doesn't have room for 'tail_call_cnt' and it would
need to be either global per_cpu variable accessed by helper and by wrapper
or global variable protected by locks.
In this implementation x64 JIT bypasses stack unwind and jumps into the
callee program after prologue.
- bpf_prog_array_compatible() ensures that prog_type of callee and caller
are the same and JITed/non-JITed flag is the same, since calling JITed
program from non-JITed is invalid, since stack frames are different.
Similarly calling kprobe type program from socket type program is invalid.
- jump table is implemented as BPF_MAP_TYPE_PROG_ARRAY to reuse 'map'
abstraction, its user space API and all of verifier logic.
It's in the existing arraymap.c file, since several functions are
shared with regular array map.
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-05-20 06:59:03 +07:00
|
|
|
BPF_MAP_TYPE_PROG_ARRAY,
|
2015-08-06 14:02:34 +07:00
|
|
|
BPF_MAP_TYPE_PERF_EVENT_ARRAY,
|
2016-02-02 13:39:53 +07:00
|
|
|
BPF_MAP_TYPE_PERCPU_HASH,
|
2016-02-02 13:39:54 +07:00
|
|
|
BPF_MAP_TYPE_PERCPU_ARRAY,
|
2016-02-18 10:58:58 +07:00
|
|
|
BPF_MAP_TYPE_STACK_TRACE,
|
2016-07-01 00:28:43 +07:00
|
|
|
BPF_MAP_TYPE_CGROUP_ARRAY,
|
2016-11-12 01:55:09 +07:00
|
|
|
BPF_MAP_TYPE_LRU_HASH,
|
2016-11-12 01:55:10 +07:00
|
|
|
BPF_MAP_TYPE_LRU_PERCPU_HASH,
|
2017-01-21 23:26:11 +07:00
|
|
|
BPF_MAP_TYPE_LPM_TRIE,
|
2017-03-23 00:00:33 +07:00
|
|
|
BPF_MAP_TYPE_ARRAY_OF_MAPS,
|
2017-03-23 00:00:34 +07:00
|
|
|
BPF_MAP_TYPE_HASH_OF_MAPS,
|
2017-07-17 23:28:56 +07:00
|
|
|
BPF_MAP_TYPE_DEVMAP,
|
2017-08-16 12:32:47 +07:00
|
|
|
BPF_MAP_TYPE_SOCKMAP,
|
2017-10-16 17:19:28 +07:00
|
|
|
BPF_MAP_TYPE_CPUMAP,
|
2014-09-26 14:16:57 +07:00
|
|
|
};
|
|
|
|
|
2014-09-26 14:17:00 +07:00
|
|
|
enum bpf_prog_type {
|
|
|
|
BPF_PROG_TYPE_UNSPEC,
|
2014-12-02 06:06:34 +07:00
|
|
|
BPF_PROG_TYPE_SOCKET_FILTER,
|
tracing, perf: Implement BPF programs attached to kprobes
BPF programs, attached to kprobes, provide a safe way to execute
user-defined BPF byte-code programs without being able to crash or
hang the kernel in any way. The BPF engine makes sure that such
programs have a finite execution time and that they cannot break
out of their sandbox.
The user interface is to attach to a kprobe via the perf syscall:
struct perf_event_attr attr = {
.type = PERF_TYPE_TRACEPOINT,
.config = event_id,
...
};
event_fd = perf_event_open(&attr,...);
ioctl(event_fd, PERF_EVENT_IOC_SET_BPF, prog_fd);
'prog_fd' is a file descriptor associated with BPF program
previously loaded.
'event_id' is an ID of the kprobe created.
Closing 'event_fd':
close(event_fd);
... automatically detaches BPF program from it.
BPF programs can call in-kernel helper functions to:
- lookup/update/delete elements in maps
- probe_read - wraper of probe_kernel_read() used to access any
kernel data structures
BPF programs receive 'struct pt_regs *' as an input ('struct pt_regs' is
architecture dependent) and return 0 to ignore the event and 1 to store
kprobe event into the ring buffer.
Note, kprobes are a fundamentally _not_ a stable kernel ABI,
so BPF programs attached to kprobes must be recompiled for
every kernel version and user must supply correct LINUX_VERSION_CODE
in attr.kern_version during bpf_prog_load() call.
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Reviewed-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: David S. Miller <davem@davemloft.net>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1427312966-8434-4-git-send-email-ast@plumgrid.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-03-26 02:49:20 +07:00
|
|
|
BPF_PROG_TYPE_KPROBE,
|
ebpf: add sched_cls_type and map it to sk_filter's verifier ops
As discussed recently and at netconf/netdev01, we want to prevent making
bpf_verifier_ops registration available for modules, but have them at a
controlled place inside the kernel instead.
The reason for this is, that out-of-tree modules can go crazy and define
and register any verfifier ops they want, doing all sorts of crap, even
bypassing available GPLed eBPF helper functions. We don't want to offer
such a shiny playground, of course, but keep strict control to ourselves
inside the core kernel.
This also encourages us to design eBPF user helpers carefully and
generically, so they can be shared among various subsystems using eBPF.
For the eBPF traffic classifier (cls_bpf), it's a good start to share
the same helper facilities as we currently do in eBPF for socket filters.
That way, we have BPF_PROG_TYPE_SCHED_CLS look like it's own type, thus
one day if there's a good reason to diverge the set of helper functions
from the set available to socket filters, we keep ABI compatibility.
In future, we could place all bpf_prog_type_list at a central place,
perhaps.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-01 18:31:46 +07:00
|
|
|
BPF_PROG_TYPE_SCHED_CLS,
|
2015-03-20 21:11:11 +07:00
|
|
|
BPF_PROG_TYPE_SCHED_ACT,
|
2016-04-07 08:43:25 +07:00
|
|
|
BPF_PROG_TYPE_TRACEPOINT,
|
2016-07-20 02:16:47 +07:00
|
|
|
BPF_PROG_TYPE_XDP,
|
2016-09-02 08:37:22 +07:00
|
|
|
BPF_PROG_TYPE_PERF_EVENT,
|
2016-11-23 22:52:25 +07:00
|
|
|
BPF_PROG_TYPE_CGROUP_SKB,
|
2016-12-01 23:48:04 +07:00
|
|
|
BPF_PROG_TYPE_CGROUP_SOCK,
|
2016-11-30 23:10:10 +07:00
|
|
|
BPF_PROG_TYPE_LWT_IN,
|
|
|
|
BPF_PROG_TYPE_LWT_OUT,
|
|
|
|
BPF_PROG_TYPE_LWT_XMIT,
|
bpf: BPF support for sock_ops
Created a new BPF program type, BPF_PROG_TYPE_SOCK_OPS, and a corresponding
struct that allows BPF programs of this type to access some of the
socket's fields (such as IP addresses, ports, etc.). It uses the
existing bpf cgroups infrastructure so the programs can be attached per
cgroup with full inheritance support. The program will be called at
appropriate times to set relevant connections parameters such as buffer
sizes, SYN and SYN-ACK RTOs, etc., based on connection information such
as IP addresses, port numbers, etc.
Alghough there are already 3 mechanisms to set parameters (sysctls,
route metrics and setsockopts), this new mechanism provides some
distinct advantages. Unlike sysctls, it can set parameters per
connection. In contrast to route metrics, it can also use port numbers
and information provided by a user level program. In addition, it could
set parameters probabilistically for evaluation purposes (i.e. do
something different on 10% of the flows and compare results with the
other 90% of the flows). Also, in cases where IPv6 addresses contain
geographic information, the rules to make changes based on the distance
(or RTT) between the hosts are much easier than route metric rules and
can be global. Finally, unlike setsockopt, it oes not require
application changes and it can be updated easily at any time.
Although the bpf cgroup framework already contains a sock related
program type (BPF_PROG_TYPE_CGROUP_SOCK), I created the new type
(BPF_PROG_TYPE_SOCK_OPS) beccause the existing type expects to be called
only once during the connections's lifetime. In contrast, the new
program type will be called multiple times from different places in the
network stack code. For example, before sending SYN and SYN-ACKs to set
an appropriate timeout, when the connection is established to set
congestion control, etc. As a result it has "op" field to specify the
type of operation requested.
The purpose of this new program type is to simplify setting connection
parameters, such as buffer sizes, TCP's SYN RTO, etc. For example, it is
easy to use facebook's internal IPv6 addresses to determine if both hosts
of a connection are in the same datacenter. Therefore, it is easy to
write a BPF program to choose a small SYN RTO value when both hosts are
in the same datacenter.
This patch only contains the framework to support the new BPF program
type, following patches add the functionality to set various connection
parameters.
This patch defines a new BPF program type: BPF_PROG_TYPE_SOCKET_OPS
and a new bpf syscall command to load a new program of this type:
BPF_PROG_LOAD_SOCKET_OPS.
Two new corresponding structs (one for the kernel one for the user/BPF
program):
/* kernel version */
struct bpf_sock_ops_kern {
struct sock *sk;
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
};
/* user version
* Some fields are in network byte order reflecting the sock struct
* Use the bpf_ntohl helper macro in samples/bpf/bpf_endian.h to
* convert them to host byte order.
*/
struct bpf_sock_ops {
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
__u32 family;
__u32 remote_ip4; /* In network byte order */
__u32 local_ip4; /* In network byte order */
__u32 remote_ip6[4]; /* In network byte order */
__u32 local_ip6[4]; /* In network byte order */
__u32 remote_port; /* In network byte order */
__u32 local_port; /* In host byte horder */
};
Currently there are two types of ops. The first type expects the BPF
program to return a value which is then used by the caller (or a
negative value to indicate the operation is not supported). The second
type expects state changes to be done by the BPF program, for example
through a setsockopt BPF helper function, and they ignore the return
value.
The reply fields of the bpf_sockt_ops struct are there in case a bpf
program needs to return a value larger than an integer.
Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-01 10:02:40 +07:00
|
|
|
BPF_PROG_TYPE_SOCK_OPS,
|
2017-08-16 12:31:58 +07:00
|
|
|
BPF_PROG_TYPE_SK_SKB,
|
2017-11-05 20:15:32 +07:00
|
|
|
BPF_PROG_TYPE_CGROUP_DEVICE,
|
bpf: create tcp_bpf_ulp allowing BPF to monitor socket TX/RX data
This implements a BPF ULP layer to allow policy enforcement and
monitoring at the socket layer. In order to support this a new
program type BPF_PROG_TYPE_SK_MSG is used to run the policy at
the sendmsg/sendpage hook. To attach the policy to sockets a
sockmap is used with a new program attach type BPF_SK_MSG_VERDICT.
Similar to previous sockmap usages when a sock is added to a
sockmap, via a map update, if the map contains a BPF_SK_MSG_VERDICT
program type attached then the BPF ULP layer is created on the
socket and the attached BPF_PROG_TYPE_SK_MSG program is run for
every msg in sendmsg case and page/offset in sendpage case.
BPF_PROG_TYPE_SK_MSG Semantics/API:
BPF_PROG_TYPE_SK_MSG supports only two return codes SK_PASS and
SK_DROP. Returning SK_DROP free's the copied data in the sendmsg
case and in the sendpage case leaves the data untouched. Both cases
return -EACESS to the user. Returning SK_PASS will allow the msg to
be sent.
In the sendmsg case data is copied into kernel space buffers before
running the BPF program. The kernel space buffers are stored in a
scatterlist object where each element is a kernel memory buffer.
Some effort is made to coalesce data from the sendmsg call here.
For example a sendmsg call with many one byte iov entries will
likely be pushed into a single entry. The BPF program is run with
data pointers (start/end) pointing to the first sg element.
In the sendpage case data is not copied. We opt not to copy the
data by default here, because the BPF infrastructure does not
know what bytes will be needed nor when they will be needed. So
copying all bytes may be wasteful. Because of this the initial
start/end data pointers are (0,0). Meaning no data can be read or
written. This avoids reading data that may be modified by the
user. A new helper is added later in this series if reading and
writing the data is needed. The helper call will do a copy by
default so that the page is exclusively owned by the BPF call.
The verdict from the BPF_PROG_TYPE_SK_MSG applies to the entire msg
in the sendmsg() case and the entire page/offset in the sendpage case.
This avoids ambiguity on how to handle mixed return codes in the
sendmsg case. Again a helper is added later in the series if
a verdict needs to apply to multiple system calls and/or only
a subpart of the currently being processed message.
The helper msg_redirect_map() can be used to select the socket to
send the data on. This is used similar to existing redirect use
cases. This allows policy to redirect msgs.
Pseudo code simple example:
The basic logic to attach a program to a socket is as follows,
// load the programs
bpf_prog_load(SOCKMAP_TCP_MSG_PROG, BPF_PROG_TYPE_SK_MSG,
&obj, &msg_prog);
// lookup the sockmap
bpf_map_msg = bpf_object__find_map_by_name(obj, "my_sock_map");
// get fd for sockmap
map_fd_msg = bpf_map__fd(bpf_map_msg);
// attach program to sockmap
bpf_prog_attach(msg_prog, map_fd_msg, BPF_SK_MSG_VERDICT, 0);
Adding sockets to the map is done in the normal way,
// Add a socket 'fd' to sockmap at location 'i'
bpf_map_update_elem(map_fd_msg, &i, fd, BPF_ANY);
After the above any socket attached to "my_sock_map", in this case
'fd', will run the BPF msg verdict program (msg_prog) on every
sendmsg and sendpage system call.
For a complete example see BPF selftests or sockmap samples.
Implementation notes:
It seemed the simplest, to me at least, to use a refcnt to ensure
psock is not lost across the sendmsg copy into the sg, the bpf program
running on the data in sg_data, and the final pass to the TCP stack.
Some performance testing may show a better method to do this and avoid
the refcnt cost, but for now use the simpler method.
Another item that will come after basic support is in place is
supporting MSG_MORE flag. At the moment we call sendpages even if
the MSG_MORE flag is set. An enhancement would be to collect the
pages into a larger scatterlist and pass down the stack. Notice that
bpf_tcp_sendmsg() could support this with some additional state saved
across sendmsg calls. I built the code to support this without having
to do refactoring work. Other features TBD include ZEROCOPY and the
TCP_RECV_QUEUE/TCP_NO_QUEUE support. This will follow initial series
shortly.
Future work could improve size limits on the scatterlist rings used
here. Currently, we use MAX_SKB_FRAGS simply because this was being
used already in the TLS case. Future work could extend the kernel sk
APIs to tune this depending on workload. This is a trade-off
between memory usage and throughput performance.
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: David S. Miller <davem@davemloft.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-19 02:57:10 +07:00
|
|
|
BPF_PROG_TYPE_SK_MSG,
|
2018-03-29 02:05:37 +07:00
|
|
|
BPF_PROG_TYPE_RAW_TRACEPOINT,
|
2018-03-31 05:08:02 +07:00
|
|
|
BPF_PROG_TYPE_CGROUP_SOCK_ADDR,
|
2014-09-26 14:17:00 +07:00
|
|
|
};
|
|
|
|
|
2016-11-23 22:52:25 +07:00
|
|
|
enum bpf_attach_type {
|
|
|
|
BPF_CGROUP_INET_INGRESS,
|
|
|
|
BPF_CGROUP_INET_EGRESS,
|
2016-12-01 23:48:04 +07:00
|
|
|
BPF_CGROUP_INET_SOCK_CREATE,
|
bpf: BPF support for sock_ops
Created a new BPF program type, BPF_PROG_TYPE_SOCK_OPS, and a corresponding
struct that allows BPF programs of this type to access some of the
socket's fields (such as IP addresses, ports, etc.). It uses the
existing bpf cgroups infrastructure so the programs can be attached per
cgroup with full inheritance support. The program will be called at
appropriate times to set relevant connections parameters such as buffer
sizes, SYN and SYN-ACK RTOs, etc., based on connection information such
as IP addresses, port numbers, etc.
Alghough there are already 3 mechanisms to set parameters (sysctls,
route metrics and setsockopts), this new mechanism provides some
distinct advantages. Unlike sysctls, it can set parameters per
connection. In contrast to route metrics, it can also use port numbers
and information provided by a user level program. In addition, it could
set parameters probabilistically for evaluation purposes (i.e. do
something different on 10% of the flows and compare results with the
other 90% of the flows). Also, in cases where IPv6 addresses contain
geographic information, the rules to make changes based on the distance
(or RTT) between the hosts are much easier than route metric rules and
can be global. Finally, unlike setsockopt, it oes not require
application changes and it can be updated easily at any time.
Although the bpf cgroup framework already contains a sock related
program type (BPF_PROG_TYPE_CGROUP_SOCK), I created the new type
(BPF_PROG_TYPE_SOCK_OPS) beccause the existing type expects to be called
only once during the connections's lifetime. In contrast, the new
program type will be called multiple times from different places in the
network stack code. For example, before sending SYN and SYN-ACKs to set
an appropriate timeout, when the connection is established to set
congestion control, etc. As a result it has "op" field to specify the
type of operation requested.
The purpose of this new program type is to simplify setting connection
parameters, such as buffer sizes, TCP's SYN RTO, etc. For example, it is
easy to use facebook's internal IPv6 addresses to determine if both hosts
of a connection are in the same datacenter. Therefore, it is easy to
write a BPF program to choose a small SYN RTO value when both hosts are
in the same datacenter.
This patch only contains the framework to support the new BPF program
type, following patches add the functionality to set various connection
parameters.
This patch defines a new BPF program type: BPF_PROG_TYPE_SOCKET_OPS
and a new bpf syscall command to load a new program of this type:
BPF_PROG_LOAD_SOCKET_OPS.
Two new corresponding structs (one for the kernel one for the user/BPF
program):
/* kernel version */
struct bpf_sock_ops_kern {
struct sock *sk;
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
};
/* user version
* Some fields are in network byte order reflecting the sock struct
* Use the bpf_ntohl helper macro in samples/bpf/bpf_endian.h to
* convert them to host byte order.
*/
struct bpf_sock_ops {
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
__u32 family;
__u32 remote_ip4; /* In network byte order */
__u32 local_ip4; /* In network byte order */
__u32 remote_ip6[4]; /* In network byte order */
__u32 local_ip6[4]; /* In network byte order */
__u32 remote_port; /* In network byte order */
__u32 local_port; /* In host byte horder */
};
Currently there are two types of ops. The first type expects the BPF
program to return a value which is then used by the caller (or a
negative value to indicate the operation is not supported). The second
type expects state changes to be done by the BPF program, for example
through a setsockopt BPF helper function, and they ignore the return
value.
The reply fields of the bpf_sockt_ops struct are there in case a bpf
program needs to return a value larger than an integer.
Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-01 10:02:40 +07:00
|
|
|
BPF_CGROUP_SOCK_OPS,
|
2017-08-28 21:10:04 +07:00
|
|
|
BPF_SK_SKB_STREAM_PARSER,
|
|
|
|
BPF_SK_SKB_STREAM_VERDICT,
|
2017-11-05 20:15:32 +07:00
|
|
|
BPF_CGROUP_DEVICE,
|
bpf: create tcp_bpf_ulp allowing BPF to monitor socket TX/RX data
This implements a BPF ULP layer to allow policy enforcement and
monitoring at the socket layer. In order to support this a new
program type BPF_PROG_TYPE_SK_MSG is used to run the policy at
the sendmsg/sendpage hook. To attach the policy to sockets a
sockmap is used with a new program attach type BPF_SK_MSG_VERDICT.
Similar to previous sockmap usages when a sock is added to a
sockmap, via a map update, if the map contains a BPF_SK_MSG_VERDICT
program type attached then the BPF ULP layer is created on the
socket and the attached BPF_PROG_TYPE_SK_MSG program is run for
every msg in sendmsg case and page/offset in sendpage case.
BPF_PROG_TYPE_SK_MSG Semantics/API:
BPF_PROG_TYPE_SK_MSG supports only two return codes SK_PASS and
SK_DROP. Returning SK_DROP free's the copied data in the sendmsg
case and in the sendpage case leaves the data untouched. Both cases
return -EACESS to the user. Returning SK_PASS will allow the msg to
be sent.
In the sendmsg case data is copied into kernel space buffers before
running the BPF program. The kernel space buffers are stored in a
scatterlist object where each element is a kernel memory buffer.
Some effort is made to coalesce data from the sendmsg call here.
For example a sendmsg call with many one byte iov entries will
likely be pushed into a single entry. The BPF program is run with
data pointers (start/end) pointing to the first sg element.
In the sendpage case data is not copied. We opt not to copy the
data by default here, because the BPF infrastructure does not
know what bytes will be needed nor when they will be needed. So
copying all bytes may be wasteful. Because of this the initial
start/end data pointers are (0,0). Meaning no data can be read or
written. This avoids reading data that may be modified by the
user. A new helper is added later in this series if reading and
writing the data is needed. The helper call will do a copy by
default so that the page is exclusively owned by the BPF call.
The verdict from the BPF_PROG_TYPE_SK_MSG applies to the entire msg
in the sendmsg() case and the entire page/offset in the sendpage case.
This avoids ambiguity on how to handle mixed return codes in the
sendmsg case. Again a helper is added later in the series if
a verdict needs to apply to multiple system calls and/or only
a subpart of the currently being processed message.
The helper msg_redirect_map() can be used to select the socket to
send the data on. This is used similar to existing redirect use
cases. This allows policy to redirect msgs.
Pseudo code simple example:
The basic logic to attach a program to a socket is as follows,
// load the programs
bpf_prog_load(SOCKMAP_TCP_MSG_PROG, BPF_PROG_TYPE_SK_MSG,
&obj, &msg_prog);
// lookup the sockmap
bpf_map_msg = bpf_object__find_map_by_name(obj, "my_sock_map");
// get fd for sockmap
map_fd_msg = bpf_map__fd(bpf_map_msg);
// attach program to sockmap
bpf_prog_attach(msg_prog, map_fd_msg, BPF_SK_MSG_VERDICT, 0);
Adding sockets to the map is done in the normal way,
// Add a socket 'fd' to sockmap at location 'i'
bpf_map_update_elem(map_fd_msg, &i, fd, BPF_ANY);
After the above any socket attached to "my_sock_map", in this case
'fd', will run the BPF msg verdict program (msg_prog) on every
sendmsg and sendpage system call.
For a complete example see BPF selftests or sockmap samples.
Implementation notes:
It seemed the simplest, to me at least, to use a refcnt to ensure
psock is not lost across the sendmsg copy into the sg, the bpf program
running on the data in sg_data, and the final pass to the TCP stack.
Some performance testing may show a better method to do this and avoid
the refcnt cost, but for now use the simpler method.
Another item that will come after basic support is in place is
supporting MSG_MORE flag. At the moment we call sendpages even if
the MSG_MORE flag is set. An enhancement would be to collect the
pages into a larger scatterlist and pass down the stack. Notice that
bpf_tcp_sendmsg() could support this with some additional state saved
across sendmsg calls. I built the code to support this without having
to do refactoring work. Other features TBD include ZEROCOPY and the
TCP_RECV_QUEUE/TCP_NO_QUEUE support. This will follow initial series
shortly.
Future work could improve size limits on the scatterlist rings used
here. Currently, we use MAX_SKB_FRAGS simply because this was being
used already in the TLS case. Future work could extend the kernel sk
APIs to tune this depending on workload. This is a trade-off
between memory usage and throughput performance.
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: David S. Miller <davem@davemloft.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-19 02:57:10 +07:00
|
|
|
BPF_SK_MSG_VERDICT,
|
2018-03-31 05:08:02 +07:00
|
|
|
BPF_CGROUP_INET4_BIND,
|
|
|
|
BPF_CGROUP_INET6_BIND,
|
2018-03-31 05:08:05 +07:00
|
|
|
BPF_CGROUP_INET4_CONNECT,
|
|
|
|
BPF_CGROUP_INET6_CONNECT,
|
2018-03-31 05:08:07 +07:00
|
|
|
BPF_CGROUP_INET4_POST_BIND,
|
|
|
|
BPF_CGROUP_INET6_POST_BIND,
|
2016-11-23 22:52:25 +07:00
|
|
|
__MAX_BPF_ATTACH_TYPE
|
|
|
|
};
|
|
|
|
|
|
|
|
#define MAX_BPF_ATTACH_TYPE __MAX_BPF_ATTACH_TYPE
|
|
|
|
|
2017-10-03 12:50:21 +07:00
|
|
|
/* cgroup-bpf attach flags used in BPF_PROG_ATTACH command
|
|
|
|
*
|
|
|
|
* NONE(default): No further bpf programs allowed in the subtree.
|
|
|
|
*
|
|
|
|
* BPF_F_ALLOW_OVERRIDE: If a sub-cgroup installs some bpf program,
|
|
|
|
* the program in this cgroup yields to sub-cgroup program.
|
|
|
|
*
|
|
|
|
* BPF_F_ALLOW_MULTI: If a sub-cgroup installs some bpf program,
|
|
|
|
* that cgroup program gets run in addition to the program in this cgroup.
|
|
|
|
*
|
|
|
|
* Only one program is allowed to be attached to a cgroup with
|
|
|
|
* NONE or BPF_F_ALLOW_OVERRIDE flag.
|
|
|
|
* Attaching another program on top of NONE or BPF_F_ALLOW_OVERRIDE will
|
|
|
|
* release old program and attach the new one. Attach flags has to match.
|
|
|
|
*
|
|
|
|
* Multiple programs are allowed to be attached to a cgroup with
|
|
|
|
* BPF_F_ALLOW_MULTI flag. They are executed in FIFO order
|
|
|
|
* (those that were attached first, run first)
|
|
|
|
* The programs of sub-cgroup are executed first, then programs of
|
|
|
|
* this cgroup and then programs of parent cgroup.
|
|
|
|
* When children program makes decision (like picking TCP CA or sock bind)
|
|
|
|
* parent program has a chance to override it.
|
|
|
|
*
|
|
|
|
* A cgroup with MULTI or OVERRIDE flag allows any attach flags in sub-cgroups.
|
|
|
|
* A cgroup with NONE doesn't allow any programs in sub-cgroups.
|
|
|
|
* Ex1:
|
|
|
|
* cgrp1 (MULTI progs A, B) ->
|
|
|
|
* cgrp2 (OVERRIDE prog C) ->
|
|
|
|
* cgrp3 (MULTI prog D) ->
|
|
|
|
* cgrp4 (OVERRIDE prog E) ->
|
|
|
|
* cgrp5 (NONE prog F)
|
|
|
|
* the event in cgrp5 triggers execution of F,D,A,B in that order.
|
|
|
|
* if prog F is detached, the execution is E,D,A,B
|
|
|
|
* if prog F and D are detached, the execution is E,A,B
|
|
|
|
* if prog F, E and D are detached, the execution is C,A,B
|
|
|
|
*
|
|
|
|
* All eligible programs are executed regardless of return code from
|
|
|
|
* earlier programs.
|
2017-02-11 11:28:24 +07:00
|
|
|
*/
|
|
|
|
#define BPF_F_ALLOW_OVERRIDE (1U << 0)
|
2017-10-03 12:50:21 +07:00
|
|
|
#define BPF_F_ALLOW_MULTI (1U << 1)
|
2017-02-11 11:28:24 +07:00
|
|
|
|
2017-05-11 01:38:07 +07:00
|
|
|
/* If BPF_F_STRICT_ALIGNMENT is used in BPF_PROG_LOAD command, the
|
|
|
|
* verifier will perform strict alignment checking as if the kernel
|
|
|
|
* has been built with CONFIG_EFFICIENT_UNALIGNED_ACCESS not set,
|
|
|
|
* and NET_IP_ALIGN defined to 2.
|
|
|
|
*/
|
|
|
|
#define BPF_F_STRICT_ALIGNMENT (1U << 0)
|
|
|
|
|
2017-12-15 08:55:05 +07:00
|
|
|
/* when bpf_ldimm64->src_reg == BPF_PSEUDO_MAP_FD, bpf_ldimm64->imm == fd */
|
2015-03-01 18:31:43 +07:00
|
|
|
#define BPF_PSEUDO_MAP_FD 1
|
|
|
|
|
2017-12-15 08:55:05 +07:00
|
|
|
/* when bpf_call->src_reg == BPF_PSEUDO_CALL, bpf_call->imm == pc-relative
|
|
|
|
* offset to another bpf function
|
|
|
|
*/
|
|
|
|
#define BPF_PSEUDO_CALL 1
|
|
|
|
|
bpf: add 'flags' attribute to BPF_MAP_UPDATE_ELEM command
the current meaning of BPF_MAP_UPDATE_ELEM syscall command is:
either update existing map element or create a new one.
Initially the plan was to add a new command to handle the case of
'create new element if it didn't exist', but 'flags' style looks
cleaner and overall diff is much smaller (more code reused), so add 'flags'
attribute to BPF_MAP_UPDATE_ELEM command with the following meaning:
#define BPF_ANY 0 /* create new element or update existing */
#define BPF_NOEXIST 1 /* create new element if it didn't exist */
#define BPF_EXIST 2 /* update existing element */
bpf_update_elem(fd, key, value, BPF_NOEXIST) call can fail with EEXIST
if element already exists.
bpf_update_elem(fd, key, value, BPF_EXIST) can fail with ENOENT
if element doesn't exist.
Userspace will call it as:
int bpf_update_elem(int fd, void *key, void *value, __u64 flags)
{
union bpf_attr attr = {
.map_fd = fd,
.key = ptr_to_u64(key),
.value = ptr_to_u64(value),
.flags = flags;
};
return bpf(BPF_MAP_UPDATE_ELEM, &attr, sizeof(attr));
}
First two bits of 'flags' are used to encode style of bpf_update_elem() command.
Bits 2-63 are reserved for future use.
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-11-14 08:36:44 +07:00
|
|
|
/* flags for BPF_MAP_UPDATE_ELEM command */
|
|
|
|
#define BPF_ANY 0 /* create new element or update existing */
|
|
|
|
#define BPF_NOEXIST 1 /* create new element if it didn't exist */
|
|
|
|
#define BPF_EXIST 2 /* update existing element */
|
|
|
|
|
2017-08-19 01:28:00 +07:00
|
|
|
/* flags for BPF_MAP_CREATE command */
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 12:57:15 +07:00
|
|
|
#define BPF_F_NO_PREALLOC (1U << 0)
|
2016-11-12 01:55:09 +07:00
|
|
|
/* Instead of having one common LRU list in the
|
2016-11-12 01:55:10 +07:00
|
|
|
* BPF_MAP_TYPE_LRU_[PERCPU_]HASH map, use a percpu LRU list
|
2016-11-12 01:55:09 +07:00
|
|
|
* which can scale and perform better.
|
|
|
|
* Note, the LRU nodes (including free nodes) cannot be moved
|
|
|
|
* across different LRU lists.
|
|
|
|
*/
|
|
|
|
#define BPF_F_NO_COMMON_LRU (1U << 1)
|
2017-08-19 01:28:00 +07:00
|
|
|
/* Specify numa node during map creation */
|
|
|
|
#define BPF_F_NUMA_NODE (1U << 2)
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 12:57:15 +07:00
|
|
|
|
2017-10-03 12:50:22 +07:00
|
|
|
/* flags for BPF_PROG_QUERY */
|
|
|
|
#define BPF_F_QUERY_EFFECTIVE (1U << 0)
|
|
|
|
|
2017-09-28 04:37:52 +07:00
|
|
|
#define BPF_OBJ_NAME_LEN 16U
|
|
|
|
|
2017-10-19 03:00:22 +07:00
|
|
|
/* Flags for accessing BPF object */
|
|
|
|
#define BPF_F_RDONLY (1U << 3)
|
|
|
|
#define BPF_F_WRONLY (1U << 4)
|
|
|
|
|
bpf: extend stackmap to save binary_build_id+offset instead of address
Currently, bpf stackmap store address for each entry in the call trace.
To map these addresses to user space files, it is necessary to maintain
the mapping from these virtual address to symbols in the binary. Usually,
the user space profiler (such as perf) has to scan /proc/pid/maps at the
beginning of profiling, and monitor mmap2() calls afterwards. Given the
cost of maintaining the address map, this solution is not practical for
system wide profiling that is always on.
This patch tries to solve this problem with a variation of stackmap. This
variation is enabled by flag BPF_F_STACK_BUILD_ID. Instead of storing
addresses, the variation stores ELF file build_id + offset.
Build ID is a 20-byte unique identifier for ELF files. The following
command shows the Build ID of /bin/bash:
[user@]$ readelf -n /bin/bash
...
Build ID: XXXXXXXXXX
...
With BPF_F_STACK_BUILD_ID, bpf_get_stackid() tries to parse Build ID
for each entry in the call trace, and translate it into the following
struct:
struct bpf_stack_build_id_offset {
__s32 status;
unsigned char build_id[BPF_BUILD_ID_SIZE];
union {
__u64 offset;
__u64 ip;
};
};
The search of build_id is limited to the first page of the file, and this
page should be in page cache. Otherwise, we fallback to store ip for this
entry (ip field in struct bpf_stack_build_id_offset). This requires the
build_id to be stored in the first page. A quick survey of binary and
dynamic library files in a few different systems shows that almost all
binary and dynamic library files have build_id in the first page.
Build_id is only meaningful for user stack. If a kernel stack is added to
a stackmap with BPF_F_STACK_BUILD_ID, it will automatically fallback to
only store ip (status == BPF_STACK_BUILD_ID_IP). Similarly, if build_id
lookup failed for some reason, it will also fallback to store ip.
User space can access struct bpf_stack_build_id_offset with bpf
syscall BPF_MAP_LOOKUP_ELEM. It is necessary for user space to
maintain mapping from build id to binary files. This mostly static
mapping is much easier to maintain than per process address maps.
Note: Stackmap with build_id only works in non-nmi context at this time.
This is because we need to take mm->mmap_sem for find_vma(). If this
changes, we would like to allow build_id lookup in nmi context.
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-15 00:23:21 +07:00
|
|
|
/* Flag for stack_map, store build_id+offset instead of pointer */
|
|
|
|
#define BPF_F_STACK_BUILD_ID (1U << 5)
|
|
|
|
|
|
|
|
enum bpf_stack_build_id_status {
|
|
|
|
/* user space need an empty entry to identify end of a trace */
|
|
|
|
BPF_STACK_BUILD_ID_EMPTY = 0,
|
|
|
|
/* with valid build_id and offset */
|
|
|
|
BPF_STACK_BUILD_ID_VALID = 1,
|
|
|
|
/* couldn't get build_id, fallback to ip */
|
|
|
|
BPF_STACK_BUILD_ID_IP = 2,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define BPF_BUILD_ID_SIZE 20
|
|
|
|
struct bpf_stack_build_id {
|
|
|
|
__s32 status;
|
|
|
|
unsigned char build_id[BPF_BUILD_ID_SIZE];
|
|
|
|
union {
|
|
|
|
__u64 offset;
|
|
|
|
__u64 ip;
|
|
|
|
};
|
|
|
|
};
|
|
|
|
|
2014-09-26 14:16:57 +07:00
|
|
|
union bpf_attr {
|
|
|
|
struct { /* anonymous struct used by BPF_MAP_CREATE command */
|
|
|
|
__u32 map_type; /* one of enum bpf_map_type */
|
|
|
|
__u32 key_size; /* size of key in bytes */
|
|
|
|
__u32 value_size; /* size of value in bytes */
|
|
|
|
__u32 max_entries; /* max number of entries in a map */
|
2017-08-19 01:28:00 +07:00
|
|
|
__u32 map_flags; /* BPF_MAP_CREATE related
|
|
|
|
* flags defined above.
|
|
|
|
*/
|
2017-03-23 00:00:33 +07:00
|
|
|
__u32 inner_map_fd; /* fd pointing to the inner map */
|
2017-08-19 01:28:00 +07:00
|
|
|
__u32 numa_node; /* numa node (effective only if
|
|
|
|
* BPF_F_NUMA_NODE is set).
|
|
|
|
*/
|
2017-10-06 11:52:12 +07:00
|
|
|
char map_name[BPF_OBJ_NAME_LEN];
|
2018-01-12 11:29:09 +07:00
|
|
|
__u32 map_ifindex; /* ifindex of netdev to create on */
|
2018-04-19 05:56:03 +07:00
|
|
|
__u32 btf_fd; /* fd pointing to a BTF type data */
|
|
|
|
__u32 btf_key_id; /* BTF type_id of the key */
|
|
|
|
__u32 btf_value_id; /* BTF type_id of the value */
|
2014-09-26 14:16:57 +07:00
|
|
|
};
|
bpf: add lookup/update/delete/iterate methods to BPF maps
'maps' is a generic storage of different types for sharing data between kernel
and userspace.
The maps are accessed from user space via BPF syscall, which has commands:
- create a map with given type and attributes
fd = bpf(BPF_MAP_CREATE, union bpf_attr *attr, u32 size)
returns fd or negative error
- lookup key in a given map referenced by fd
err = bpf(BPF_MAP_LOOKUP_ELEM, union bpf_attr *attr, u32 size)
using attr->map_fd, attr->key, attr->value
returns zero and stores found elem into value or negative error
- create or update key/value pair in a given map
err = bpf(BPF_MAP_UPDATE_ELEM, union bpf_attr *attr, u32 size)
using attr->map_fd, attr->key, attr->value
returns zero or negative error
- find and delete element by key in a given map
err = bpf(BPF_MAP_DELETE_ELEM, union bpf_attr *attr, u32 size)
using attr->map_fd, attr->key
- iterate map elements (based on input key return next_key)
err = bpf(BPF_MAP_GET_NEXT_KEY, union bpf_attr *attr, u32 size)
using attr->map_fd, attr->key, attr->next_key
- close(fd) deletes the map
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-26 14:16:59 +07:00
|
|
|
|
|
|
|
struct { /* anonymous struct used by BPF_MAP_*_ELEM commands */
|
|
|
|
__u32 map_fd;
|
|
|
|
__aligned_u64 key;
|
|
|
|
union {
|
|
|
|
__aligned_u64 value;
|
|
|
|
__aligned_u64 next_key;
|
|
|
|
};
|
bpf: add 'flags' attribute to BPF_MAP_UPDATE_ELEM command
the current meaning of BPF_MAP_UPDATE_ELEM syscall command is:
either update existing map element or create a new one.
Initially the plan was to add a new command to handle the case of
'create new element if it didn't exist', but 'flags' style looks
cleaner and overall diff is much smaller (more code reused), so add 'flags'
attribute to BPF_MAP_UPDATE_ELEM command with the following meaning:
#define BPF_ANY 0 /* create new element or update existing */
#define BPF_NOEXIST 1 /* create new element if it didn't exist */
#define BPF_EXIST 2 /* update existing element */
bpf_update_elem(fd, key, value, BPF_NOEXIST) call can fail with EEXIST
if element already exists.
bpf_update_elem(fd, key, value, BPF_EXIST) can fail with ENOENT
if element doesn't exist.
Userspace will call it as:
int bpf_update_elem(int fd, void *key, void *value, __u64 flags)
{
union bpf_attr attr = {
.map_fd = fd,
.key = ptr_to_u64(key),
.value = ptr_to_u64(value),
.flags = flags;
};
return bpf(BPF_MAP_UPDATE_ELEM, &attr, sizeof(attr));
}
First two bits of 'flags' are used to encode style of bpf_update_elem() command.
Bits 2-63 are reserved for future use.
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-11-14 08:36:44 +07:00
|
|
|
__u64 flags;
|
bpf: add lookup/update/delete/iterate methods to BPF maps
'maps' is a generic storage of different types for sharing data between kernel
and userspace.
The maps are accessed from user space via BPF syscall, which has commands:
- create a map with given type and attributes
fd = bpf(BPF_MAP_CREATE, union bpf_attr *attr, u32 size)
returns fd or negative error
- lookup key in a given map referenced by fd
err = bpf(BPF_MAP_LOOKUP_ELEM, union bpf_attr *attr, u32 size)
using attr->map_fd, attr->key, attr->value
returns zero and stores found elem into value or negative error
- create or update key/value pair in a given map
err = bpf(BPF_MAP_UPDATE_ELEM, union bpf_attr *attr, u32 size)
using attr->map_fd, attr->key, attr->value
returns zero or negative error
- find and delete element by key in a given map
err = bpf(BPF_MAP_DELETE_ELEM, union bpf_attr *attr, u32 size)
using attr->map_fd, attr->key
- iterate map elements (based on input key return next_key)
err = bpf(BPF_MAP_GET_NEXT_KEY, union bpf_attr *attr, u32 size)
using attr->map_fd, attr->key, attr->next_key
- close(fd) deletes the map
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-26 14:16:59 +07:00
|
|
|
};
|
2014-09-26 14:17:00 +07:00
|
|
|
|
|
|
|
struct { /* anonymous struct used by BPF_PROG_LOAD command */
|
|
|
|
__u32 prog_type; /* one of enum bpf_prog_type */
|
|
|
|
__u32 insn_cnt;
|
|
|
|
__aligned_u64 insns;
|
|
|
|
__aligned_u64 license;
|
bpf: verifier (add ability to receive verification log)
add optional attributes for BPF_PROG_LOAD syscall:
union bpf_attr {
struct {
...
__u32 log_level; /* verbosity level of eBPF verifier */
__u32 log_size; /* size of user buffer */
__aligned_u64 log_buf; /* user supplied 'char *buffer' */
};
};
when log_level > 0 the verifier will return its verification log in the user
supplied buffer 'log_buf' which can be used by program author to analyze why
verifier rejected given program.
'Understanding eBPF verifier messages' section of Documentation/networking/filter.txt
provides several examples of these messages, like the program:
BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
BPF_LD_MAP_FD(BPF_REG_1, 0),
BPF_CALL_FUNC(BPF_FUNC_map_lookup_elem),
BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 1),
BPF_ST_MEM(BPF_DW, BPF_REG_0, 4, 0),
BPF_EXIT_INSN(),
will be rejected with the following multi-line message in log_buf:
0: (7a) *(u64 *)(r10 -8) = 0
1: (bf) r2 = r10
2: (07) r2 += -8
3: (b7) r1 = 0
4: (85) call 1
5: (15) if r0 == 0x0 goto pc+1
R0=map_ptr R10=fp
6: (7a) *(u64 *)(r0 +4) = 0
misaligned access off 4 size 8
The format of the output can change at any time as verifier evolves.
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-26 14:17:03 +07:00
|
|
|
__u32 log_level; /* verbosity level of verifier */
|
|
|
|
__u32 log_size; /* size of user buffer */
|
|
|
|
__aligned_u64 log_buf; /* user supplied buffer */
|
tracing, perf: Implement BPF programs attached to kprobes
BPF programs, attached to kprobes, provide a safe way to execute
user-defined BPF byte-code programs without being able to crash or
hang the kernel in any way. The BPF engine makes sure that such
programs have a finite execution time and that they cannot break
out of their sandbox.
The user interface is to attach to a kprobe via the perf syscall:
struct perf_event_attr attr = {
.type = PERF_TYPE_TRACEPOINT,
.config = event_id,
...
};
event_fd = perf_event_open(&attr,...);
ioctl(event_fd, PERF_EVENT_IOC_SET_BPF, prog_fd);
'prog_fd' is a file descriptor associated with BPF program
previously loaded.
'event_id' is an ID of the kprobe created.
Closing 'event_fd':
close(event_fd);
... automatically detaches BPF program from it.
BPF programs can call in-kernel helper functions to:
- lookup/update/delete elements in maps
- probe_read - wraper of probe_kernel_read() used to access any
kernel data structures
BPF programs receive 'struct pt_regs *' as an input ('struct pt_regs' is
architecture dependent) and return 0 to ignore the event and 1 to store
kprobe event into the ring buffer.
Note, kprobes are a fundamentally _not_ a stable kernel ABI,
so BPF programs attached to kprobes must be recompiled for
every kernel version and user must supply correct LINUX_VERSION_CODE
in attr.kern_version during bpf_prog_load() call.
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Reviewed-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: David S. Miller <davem@davemloft.net>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1427312966-8434-4-git-send-email-ast@plumgrid.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-03-26 02:49:20 +07:00
|
|
|
__u32 kern_version; /* checked when prog_type=kprobe */
|
2017-05-11 01:38:07 +07:00
|
|
|
__u32 prog_flags;
|
2017-10-06 11:52:12 +07:00
|
|
|
char prog_name[BPF_OBJ_NAME_LEN];
|
2017-11-21 06:21:53 +07:00
|
|
|
__u32 prog_ifindex; /* ifindex of netdev to prep for */
|
2018-03-31 05:08:00 +07:00
|
|
|
/* For some prog types expected attach type must be known at
|
|
|
|
* load time to verify attach type specific parts of prog
|
|
|
|
* (context accesses, allowed helpers, etc).
|
|
|
|
*/
|
|
|
|
__u32 expected_attach_type;
|
2014-09-26 14:17:00 +07:00
|
|
|
};
|
2015-10-29 20:58:09 +07:00
|
|
|
|
|
|
|
struct { /* anonymous struct used by BPF_OBJ_* commands */
|
|
|
|
__aligned_u64 pathname;
|
|
|
|
__u32 bpf_fd;
|
2017-10-19 03:00:22 +07:00
|
|
|
__u32 file_flags;
|
2015-10-29 20:58:09 +07:00
|
|
|
};
|
bpf: add BPF_PROG_ATTACH and BPF_PROG_DETACH commands
Extend the bpf(2) syscall by two new commands, BPF_PROG_ATTACH and
BPF_PROG_DETACH which allow attaching and detaching eBPF programs
to a target.
On the API level, the target could be anything that has an fd in
userspace, hence the name of the field in union bpf_attr is called
'target_fd'.
When called with BPF_ATTACH_TYPE_CGROUP_INET_{E,IN}GRESS, the target is
expected to be a valid file descriptor of a cgroup v2 directory which
has the bpf controller enabled. These are the only use-cases
implemented by this patch at this point, but more can be added.
If a program of the given type already exists in the given cgroup,
the program is swapped automically, so userspace does not have to drop
an existing program first before installing a new one, which would
otherwise leave a gap in which no program is attached.
For more information on the propagation logic to subcgroups, please
refer to the bpf cgroup controller implementation.
The API is guarded by CAP_NET_ADMIN.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-23 22:52:27 +07:00
|
|
|
|
|
|
|
struct { /* anonymous struct used by BPF_PROG_ATTACH/DETACH commands */
|
|
|
|
__u32 target_fd; /* container object to attach to */
|
|
|
|
__u32 attach_bpf_fd; /* eBPF program to attach */
|
|
|
|
__u32 attach_type;
|
2017-02-11 11:28:24 +07:00
|
|
|
__u32 attach_flags;
|
bpf: add BPF_PROG_ATTACH and BPF_PROG_DETACH commands
Extend the bpf(2) syscall by two new commands, BPF_PROG_ATTACH and
BPF_PROG_DETACH which allow attaching and detaching eBPF programs
to a target.
On the API level, the target could be anything that has an fd in
userspace, hence the name of the field in union bpf_attr is called
'target_fd'.
When called with BPF_ATTACH_TYPE_CGROUP_INET_{E,IN}GRESS, the target is
expected to be a valid file descriptor of a cgroup v2 directory which
has the bpf controller enabled. These are the only use-cases
implemented by this patch at this point, but more can be added.
If a program of the given type already exists in the given cgroup,
the program is swapped automically, so userspace does not have to drop
an existing program first before installing a new one, which would
otherwise leave a gap in which no program is attached.
For more information on the propagation logic to subcgroups, please
refer to the bpf cgroup controller implementation.
The API is guarded by CAP_NET_ADMIN.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-23 22:52:27 +07:00
|
|
|
};
|
2017-03-31 11:45:38 +07:00
|
|
|
|
|
|
|
struct { /* anonymous struct used by BPF_PROG_TEST_RUN command */
|
|
|
|
__u32 prog_fd;
|
|
|
|
__u32 retval;
|
|
|
|
__u32 data_size_in;
|
|
|
|
__u32 data_size_out;
|
|
|
|
__aligned_u64 data_in;
|
|
|
|
__aligned_u64 data_out;
|
|
|
|
__u32 repeat;
|
|
|
|
__u32 duration;
|
|
|
|
} test;
|
2017-06-06 02:15:48 +07:00
|
|
|
|
2017-06-06 02:15:49 +07:00
|
|
|
struct { /* anonymous struct used by BPF_*_GET_*_ID */
|
|
|
|
union {
|
|
|
|
__u32 start_id;
|
|
|
|
__u32 prog_id;
|
2017-06-06 02:15:50 +07:00
|
|
|
__u32 map_id;
|
2017-06-06 02:15:49 +07:00
|
|
|
};
|
2017-06-06 02:15:48 +07:00
|
|
|
__u32 next_id;
|
2017-10-19 03:00:22 +07:00
|
|
|
__u32 open_flags;
|
2017-06-06 02:15:48 +07:00
|
|
|
};
|
2017-06-06 02:15:52 +07:00
|
|
|
|
|
|
|
struct { /* anonymous struct used by BPF_OBJ_GET_INFO_BY_FD */
|
|
|
|
__u32 bpf_fd;
|
|
|
|
__u32 info_len;
|
|
|
|
__aligned_u64 info;
|
|
|
|
} info;
|
2017-10-03 12:50:22 +07:00
|
|
|
|
|
|
|
struct { /* anonymous struct used by BPF_PROG_QUERY command */
|
|
|
|
__u32 target_fd; /* container object to query */
|
|
|
|
__u32 attach_type;
|
|
|
|
__u32 query_flags;
|
|
|
|
__u32 attach_flags;
|
|
|
|
__aligned_u64 prog_ids;
|
|
|
|
__u32 prog_cnt;
|
|
|
|
} query;
|
2018-03-29 02:05:37 +07:00
|
|
|
|
|
|
|
struct {
|
|
|
|
__u64 name;
|
|
|
|
__u32 prog_fd;
|
|
|
|
} raw_tracepoint;
|
2018-04-19 05:56:01 +07:00
|
|
|
|
|
|
|
struct { /* anonymous struct for BPF_BTF_LOAD */
|
|
|
|
__aligned_u64 btf;
|
|
|
|
__aligned_u64 btf_log_buf;
|
|
|
|
__u32 btf_size;
|
|
|
|
__u32 btf_log_size;
|
|
|
|
__u32 btf_log_level;
|
|
|
|
};
|
2014-09-26 14:16:57 +07:00
|
|
|
} __attribute__((aligned(8)));
|
|
|
|
|
2018-04-26 00:16:52 +07:00
|
|
|
/* The description below is an attempt at providing documentation to eBPF
|
|
|
|
* developers about the multiple available eBPF helper functions. It can be
|
|
|
|
* parsed and used to produce a manual page. The workflow is the following,
|
|
|
|
* and requires the rst2man utility:
|
|
|
|
*
|
|
|
|
* $ ./scripts/bpf_helpers_doc.py \
|
|
|
|
* --filename include/uapi/linux/bpf.h > /tmp/bpf-helpers.rst
|
|
|
|
* $ rst2man /tmp/bpf-helpers.rst > /tmp/bpf-helpers.7
|
|
|
|
* $ man /tmp/bpf-helpers.7
|
|
|
|
*
|
|
|
|
* Note that in order to produce this external documentation, some RST
|
|
|
|
* formatting is used in the descriptions to get "bold" and "italics" in
|
|
|
|
* manual pages. Also note that the few trailing white spaces are
|
|
|
|
* intentional, removing them would break paragraphs for rst2man.
|
|
|
|
*
|
|
|
|
* Start of BPF helper function descriptions:
|
2018-04-26 00:16:53 +07:00
|
|
|
*
|
|
|
|
* void *bpf_map_lookup_elem(struct bpf_map *map, const void *key)
|
|
|
|
* Description
|
|
|
|
* Perform a lookup in *map* for an entry associated to *key*.
|
|
|
|
* Return
|
|
|
|
* Map value associated to *key*, or **NULL** if no entry was
|
|
|
|
* found.
|
|
|
|
*
|
|
|
|
* int bpf_map_update_elem(struct bpf_map *map, const void *key, const void *value, u64 flags)
|
|
|
|
* Description
|
|
|
|
* Add or update the value of the entry associated to *key* in
|
|
|
|
* *map* with *value*. *flags* is one of:
|
|
|
|
*
|
|
|
|
* **BPF_NOEXIST**
|
|
|
|
* The entry for *key* must not exist in the map.
|
|
|
|
* **BPF_EXIST**
|
|
|
|
* The entry for *key* must already exist in the map.
|
|
|
|
* **BPF_ANY**
|
|
|
|
* No condition on the existence of the entry for *key*.
|
|
|
|
*
|
|
|
|
* Flag value **BPF_NOEXIST** cannot be used for maps of types
|
|
|
|
* **BPF_MAP_TYPE_ARRAY** or **BPF_MAP_TYPE_PERCPU_ARRAY** (all
|
|
|
|
* elements always exist), the helper would return an error.
|
|
|
|
* Return
|
|
|
|
* 0 on success, or a negative error in case of failure.
|
|
|
|
*
|
|
|
|
* int bpf_map_delete_elem(struct bpf_map *map, const void *key)
|
|
|
|
* Description
|
|
|
|
* Delete entry with *key* from *map*.
|
|
|
|
* Return
|
|
|
|
* 0 on success, or a negative error in case of failure.
|
|
|
|
*
|
|
|
|
* int bpf_probe_read(void *dst, u32 size, const void *src)
|
|
|
|
* Description
|
|
|
|
* For tracing programs, safely attempt to read *size* bytes from
|
|
|
|
* address *src* and store the data in *dst*.
|
|
|
|
* Return
|
|
|
|
* 0 on success, or a negative error in case of failure.
|
|
|
|
*
|
|
|
|
* u64 bpf_ktime_get_ns(void)
|
|
|
|
* Description
|
|
|
|
* Return the time elapsed since system boot, in nanoseconds.
|
|
|
|
* Return
|
|
|
|
* Current *ktime*.
|
|
|
|
*
|
|
|
|
* int bpf_trace_printk(const char *fmt, u32 fmt_size, ...)
|
|
|
|
* Description
|
|
|
|
* This helper is a "printk()-like" facility for debugging. It
|
|
|
|
* prints a message defined by format *fmt* (of size *fmt_size*)
|
|
|
|
* to file *\/sys/kernel/debug/tracing/trace* from DebugFS, if
|
|
|
|
* available. It can take up to three additional **u64**
|
|
|
|
* arguments (as an eBPF helpers, the total number of arguments is
|
|
|
|
* limited to five).
|
|
|
|
*
|
|
|
|
* Each time the helper is called, it appends a line to the trace.
|
|
|
|
* The format of the trace is customizable, and the exact output
|
|
|
|
* one will get depends on the options set in
|
|
|
|
* *\/sys/kernel/debug/tracing/trace_options* (see also the
|
|
|
|
* *README* file under the same directory). However, it usually
|
|
|
|
* defaults to something like:
|
|
|
|
*
|
|
|
|
* ::
|
|
|
|
*
|
|
|
|
* telnet-470 [001] .N.. 419421.045894: 0x00000001: <formatted msg>
|
|
|
|
*
|
|
|
|
* In the above:
|
|
|
|
*
|
|
|
|
* * ``telnet`` is the name of the current task.
|
|
|
|
* * ``470`` is the PID of the current task.
|
|
|
|
* * ``001`` is the CPU number on which the task is
|
|
|
|
* running.
|
|
|
|
* * In ``.N..``, each character refers to a set of
|
|
|
|
* options (whether irqs are enabled, scheduling
|
|
|
|
* options, whether hard/softirqs are running, level of
|
|
|
|
* preempt_disabled respectively). **N** means that
|
|
|
|
* **TIF_NEED_RESCHED** and **PREEMPT_NEED_RESCHED**
|
|
|
|
* are set.
|
|
|
|
* * ``419421.045894`` is a timestamp.
|
|
|
|
* * ``0x00000001`` is a fake value used by BPF for the
|
|
|
|
* instruction pointer register.
|
|
|
|
* * ``<formatted msg>`` is the message formatted with
|
|
|
|
* *fmt*.
|
|
|
|
*
|
|
|
|
* The conversion specifiers supported by *fmt* are similar, but
|
|
|
|
* more limited than for printk(). They are **%d**, **%i**,
|
|
|
|
* **%u**, **%x**, **%ld**, **%li**, **%lu**, **%lx**, **%lld**,
|
|
|
|
* **%lli**, **%llu**, **%llx**, **%p**, **%s**. No modifier (size
|
|
|
|
* of field, padding with zeroes, etc.) is available, and the
|
|
|
|
* helper will return **-EINVAL** (but print nothing) if it
|
|
|
|
* encounters an unknown specifier.
|
|
|
|
*
|
|
|
|
* Also, note that **bpf_trace_printk**\ () is slow, and should
|
|
|
|
* only be used for debugging purposes. For this reason, a notice
|
|
|
|
* bloc (spanning several lines) is printed to kernel logs and
|
|
|
|
* states that the helper should not be used "for production use"
|
|
|
|
* the first time this helper is used (or more precisely, when
|
|
|
|
* **trace_printk**\ () buffers are allocated). For passing values
|
|
|
|
* to user space, perf events should be preferred.
|
|
|
|
* Return
|
|
|
|
* The number of bytes written to the buffer, or a negative error
|
|
|
|
* in case of failure.
|
|
|
|
*
|
2018-04-26 00:16:55 +07:00
|
|
|
* u32 bpf_get_prandom_u32(void)
|
|
|
|
* Description
|
|
|
|
* Get a pseudo-random number.
|
|
|
|
*
|
|
|
|
* From a security point of view, this helper uses its own
|
|
|
|
* pseudo-random internal state, and cannot be used to infer the
|
|
|
|
* seed of other random functions in the kernel. However, it is
|
|
|
|
* essential to note that the generator used by the helper is not
|
|
|
|
* cryptographically secure.
|
|
|
|
* Return
|
|
|
|
* A random 32-bit unsigned value.
|
|
|
|
*
|
|
|
|
* u32 bpf_get_smp_processor_id(void)
|
|
|
|
* Description
|
|
|
|
* Get the SMP (symmetric multiprocessing) processor id. Note that
|
|
|
|
* all programs run with preemption disabled, which means that the
|
|
|
|
* SMP processor id is stable during all the execution of the
|
|
|
|
* program.
|
|
|
|
* Return
|
|
|
|
* The SMP id of the processor running the program.
|
|
|
|
*
|
2018-04-26 00:16:53 +07:00
|
|
|
* int bpf_skb_store_bytes(struct sk_buff *skb, u32 offset, const void *from, u32 len, u64 flags)
|
|
|
|
* Description
|
|
|
|
* Store *len* bytes from address *from* into the packet
|
|
|
|
* associated to *skb*, at *offset*. *flags* are a combination of
|
|
|
|
* **BPF_F_RECOMPUTE_CSUM** (automatically recompute the
|
|
|
|
* checksum for the packet after storing the bytes) and
|
|
|
|
* **BPF_F_INVALIDATE_HASH** (set *skb*\ **->hash**, *skb*\
|
|
|
|
* **->swhash** and *skb*\ **->l4hash** to 0).
|
|
|
|
*
|
|
|
|
* A call to this helper is susceptible to change the underlaying
|
|
|
|
* packet buffer. Therefore, at load time, all checks on pointers
|
|
|
|
* previously done by the verifier are invalidated and must be
|
|
|
|
* performed again, if the helper is used in combination with
|
|
|
|
* direct packet access.
|
|
|
|
* Return
|
|
|
|
* 0 on success, or a negative error in case of failure.
|
|
|
|
*
|
|
|
|
* int bpf_l3_csum_replace(struct sk_buff *skb, u32 offset, u64 from, u64 to, u64 size)
|
|
|
|
* Description
|
|
|
|
* Recompute the layer 3 (e.g. IP) checksum for the packet
|
|
|
|
* associated to *skb*. Computation is incremental, so the helper
|
|
|
|
* must know the former value of the header field that was
|
|
|
|
* modified (*from*), the new value of this field (*to*), and the
|
|
|
|
* number of bytes (2 or 4) for this field, stored in *size*.
|
|
|
|
* Alternatively, it is possible to store the difference between
|
|
|
|
* the previous and the new values of the header field in *to*, by
|
|
|
|
* setting *from* and *size* to 0. For both methods, *offset*
|
|
|
|
* indicates the location of the IP checksum within the packet.
|
|
|
|
*
|
|
|
|
* This helper works in combination with **bpf_csum_diff**\ (),
|
|
|
|
* which does not update the checksum in-place, but offers more
|
|
|
|
* flexibility and can handle sizes larger than 2 or 4 for the
|
|
|
|
* checksum to update.
|
|
|
|
*
|
|
|
|
* A call to this helper is susceptible to change the underlaying
|
|
|
|
* packet buffer. Therefore, at load time, all checks on pointers
|
|
|
|
* previously done by the verifier are invalidated and must be
|
|
|
|
* performed again, if the helper is used in combination with
|
|
|
|
* direct packet access.
|
|
|
|
* Return
|
|
|
|
* 0 on success, or a negative error in case of failure.
|
|
|
|
*
|
|
|
|
* int bpf_l4_csum_replace(struct sk_buff *skb, u32 offset, u64 from, u64 to, u64 flags)
|
|
|
|
* Description
|
|
|
|
* Recompute the layer 4 (e.g. TCP, UDP or ICMP) checksum for the
|
|
|
|
* packet associated to *skb*. Computation is incremental, so the
|
|
|
|
* helper must know the former value of the header field that was
|
|
|
|
* modified (*from*), the new value of this field (*to*), and the
|
|
|
|
* number of bytes (2 or 4) for this field, stored on the lowest
|
|
|
|
* four bits of *flags*. Alternatively, it is possible to store
|
|
|
|
* the difference between the previous and the new values of the
|
|
|
|
* header field in *to*, by setting *from* and the four lowest
|
|
|
|
* bits of *flags* to 0. For both methods, *offset* indicates the
|
|
|
|
* location of the IP checksum within the packet. In addition to
|
|
|
|
* the size of the field, *flags* can be added (bitwise OR) actual
|
|
|
|
* flags. With **BPF_F_MARK_MANGLED_0**, a null checksum is left
|
|
|
|
* untouched (unless **BPF_F_MARK_ENFORCE** is added as well), and
|
|
|
|
* for updates resulting in a null checksum the value is set to
|
|
|
|
* **CSUM_MANGLED_0** instead. Flag **BPF_F_PSEUDO_HDR** indicates
|
|
|
|
* the checksum is to be computed against a pseudo-header.
|
|
|
|
*
|
|
|
|
* This helper works in combination with **bpf_csum_diff**\ (),
|
|
|
|
* which does not update the checksum in-place, but offers more
|
|
|
|
* flexibility and can handle sizes larger than 2 or 4 for the
|
|
|
|
* checksum to update.
|
|
|
|
*
|
|
|
|
* A call to this helper is susceptible to change the underlaying
|
|
|
|
* packet buffer. Therefore, at load time, all checks on pointers
|
|
|
|
* previously done by the verifier are invalidated and must be
|
|
|
|
* performed again, if the helper is used in combination with
|
|
|
|
* direct packet access.
|
|
|
|
* Return
|
|
|
|
* 0 on success, or a negative error in case of failure.
|
|
|
|
*
|
|
|
|
* int bpf_tail_call(void *ctx, struct bpf_map *prog_array_map, u32 index)
|
|
|
|
* Description
|
|
|
|
* This special helper is used to trigger a "tail call", or in
|
|
|
|
* other words, to jump into another eBPF program. The same stack
|
|
|
|
* frame is used (but values on stack and in registers for the
|
|
|
|
* caller are not accessible to the callee). This mechanism allows
|
|
|
|
* for program chaining, either for raising the maximum number of
|
|
|
|
* available eBPF instructions, or to execute given programs in
|
|
|
|
* conditional blocks. For security reasons, there is an upper
|
|
|
|
* limit to the number of successive tail calls that can be
|
|
|
|
* performed.
|
|
|
|
*
|
|
|
|
* Upon call of this helper, the program attempts to jump into a
|
|
|
|
* program referenced at index *index* in *prog_array_map*, a
|
|
|
|
* special map of type **BPF_MAP_TYPE_PROG_ARRAY**, and passes
|
|
|
|
* *ctx*, a pointer to the context.
|
|
|
|
*
|
|
|
|
* If the call succeeds, the kernel immediately runs the first
|
|
|
|
* instruction of the new program. This is not a function call,
|
|
|
|
* and it never returns to the previous program. If the call
|
|
|
|
* fails, then the helper has no effect, and the caller continues
|
|
|
|
* to run its subsequent instructions. A call can fail if the
|
|
|
|
* destination program for the jump does not exist (i.e. *index*
|
|
|
|
* is superior to the number of entries in *prog_array_map*), or
|
|
|
|
* if the maximum number of tail calls has been reached for this
|
|
|
|
* chain of programs. This limit is defined in the kernel by the
|
|
|
|
* macro **MAX_TAIL_CALL_CNT** (not accessible to user space),
|
|
|
|
* which is currently set to 32.
|
|
|
|
* Return
|
|
|
|
* 0 on success, or a negative error in case of failure.
|
|
|
|
*
|
|
|
|
* int bpf_clone_redirect(struct sk_buff *skb, u32 ifindex, u64 flags)
|
|
|
|
* Description
|
|
|
|
* Clone and redirect the packet associated to *skb* to another
|
|
|
|
* net device of index *ifindex*. Both ingress and egress
|
|
|
|
* interfaces can be used for redirection. The **BPF_F_INGRESS**
|
|
|
|
* value in *flags* is used to make the distinction (ingress path
|
|
|
|
* is selected if the flag is present, egress path otherwise).
|
|
|
|
* This is the only flag supported for now.
|
|
|
|
*
|
|
|
|
* In comparison with **bpf_redirect**\ () helper,
|
|
|
|
* **bpf_clone_redirect**\ () has the associated cost of
|
|
|
|
* duplicating the packet buffer, but this can be executed out of
|
|
|
|
* the eBPF program. Conversely, **bpf_redirect**\ () is more
|
|
|
|
* efficient, but it is handled through an action code where the
|
|
|
|
* redirection happens only after the eBPF program has returned.
|
|
|
|
*
|
|
|
|
* A call to this helper is susceptible to change the underlaying
|
|
|
|
* packet buffer. Therefore, at load time, all checks on pointers
|
|
|
|
* previously done by the verifier are invalidated and must be
|
|
|
|
* performed again, if the helper is used in combination with
|
|
|
|
* direct packet access.
|
|
|
|
* Return
|
|
|
|
* 0 on success, or a negative error in case of failure.
|
2018-04-26 00:16:54 +07:00
|
|
|
*
|
|
|
|
* u64 bpf_get_current_pid_tgid(void)
|
|
|
|
* Return
|
|
|
|
* A 64-bit integer containing the current tgid and pid, and
|
|
|
|
* created as such:
|
|
|
|
* *current_task*\ **->tgid << 32 \|**
|
|
|
|
* *current_task*\ **->pid**.
|
|
|
|
*
|
|
|
|
* u64 bpf_get_current_uid_gid(void)
|
|
|
|
* Return
|
|
|
|
* A 64-bit integer containing the current GID and UID, and
|
|
|
|
* created as such: *current_gid* **<< 32 \|** *current_uid*.
|
|
|
|
*
|
|
|
|
* int bpf_get_current_comm(char *buf, u32 size_of_buf)
|
|
|
|
* Description
|
|
|
|
* Copy the **comm** attribute of the current task into *buf* of
|
|
|
|
* *size_of_buf*. The **comm** attribute contains the name of
|
|
|
|
* the executable (excluding the path) for the current task. The
|
|
|
|
* *size_of_buf* must be strictly positive. On success, the
|
|
|
|
* helper makes sure that the *buf* is NUL-terminated. On failure,
|
|
|
|
* it is filled with zeroes.
|
|
|
|
* Return
|
|
|
|
* 0 on success, or a negative error in case of failure.
|
|
|
|
*
|
2018-04-26 00:16:55 +07:00
|
|
|
* u32 bpf_get_cgroup_classid(struct sk_buff *skb)
|
|
|
|
* Description
|
|
|
|
* Retrieve the classid for the current task, i.e. for the net_cls
|
|
|
|
* cgroup to which *skb* belongs.
|
|
|
|
*
|
|
|
|
* This helper can be used on TC egress path, but not on ingress.
|
|
|
|
*
|
|
|
|
* The net_cls cgroup provides an interface to tag network packets
|
|
|
|
* based on a user-provided identifier for all traffic coming from
|
|
|
|
* the tasks belonging to the related cgroup. See also the related
|
|
|
|
* kernel documentation, available from the Linux sources in file
|
|
|
|
* *Documentation/cgroup-v1/net_cls.txt*.
|
|
|
|
*
|
|
|
|
* The Linux kernel has two versions for cgroups: there are
|
|
|
|
* cgroups v1 and cgroups v2. Both are available to users, who can
|
|
|
|
* use a mixture of them, but note that the net_cls cgroup is for
|
|
|
|
* cgroup v1 only. This makes it incompatible with BPF programs
|
|
|
|
* run on cgroups, which is a cgroup-v2-only feature (a socket can
|
|
|
|
* only hold data for one version of cgroups at a time).
|
|
|
|
*
|
|
|
|
* This helper is only available is the kernel was compiled with
|
|
|
|
* the **CONFIG_CGROUP_NET_CLASSID** configuration option set to
|
|
|
|
* "**y**" or to "**m**".
|
|
|
|
* Return
|
|
|
|
* The classid, or 0 for the default unconfigured classid.
|
|
|
|
*
|
2018-04-26 00:16:54 +07:00
|
|
|
* int bpf_skb_vlan_push(struct sk_buff *skb, __be16 vlan_proto, u16 vlan_tci)
|
|
|
|
* Description
|
|
|
|
* Push a *vlan_tci* (VLAN tag control information) of protocol
|
|
|
|
* *vlan_proto* to the packet associated to *skb*, then update
|
|
|
|
* the checksum. Note that if *vlan_proto* is different from
|
|
|
|
* **ETH_P_8021Q** and **ETH_P_8021AD**, it is considered to
|
|
|
|
* be **ETH_P_8021Q**.
|
|
|
|
*
|
|
|
|
* A call to this helper is susceptible to change the underlaying
|
|
|
|
* packet buffer. Therefore, at load time, all checks on pointers
|
|
|
|
* previously done by the verifier are invalidated and must be
|
|
|
|
* performed again, if the helper is used in combination with
|
|
|
|
* direct packet access.
|
|
|
|
* Return
|
|
|
|
* 0 on success, or a negative error in case of failure.
|
|
|
|
*
|
|
|
|
* int bpf_skb_vlan_pop(struct sk_buff *skb)
|
|
|
|
* Description
|
|
|
|
* Pop a VLAN header from the packet associated to *skb*.
|
|
|
|
*
|
|
|
|
* A call to this helper is susceptible to change the underlaying
|
|
|
|
* packet buffer. Therefore, at load time, all checks on pointers
|
|
|
|
* previously done by the verifier are invalidated and must be
|
|
|
|
* performed again, if the helper is used in combination with
|
|
|
|
* direct packet access.
|
|
|
|
* Return
|
|
|
|
* 0 on success, or a negative error in case of failure.
|
|
|
|
*
|
|
|
|
* int bpf_skb_get_tunnel_key(struct sk_buff *skb, struct bpf_tunnel_key *key, u32 size, u64 flags)
|
|
|
|
* Description
|
|
|
|
* Get tunnel metadata. This helper takes a pointer *key* to an
|
|
|
|
* empty **struct bpf_tunnel_key** of **size**, that will be
|
|
|
|
* filled with tunnel metadata for the packet associated to *skb*.
|
|
|
|
* The *flags* can be set to **BPF_F_TUNINFO_IPV6**, which
|
|
|
|
* indicates that the tunnel is based on IPv6 protocol instead of
|
|
|
|
* IPv4.
|
|
|
|
*
|
|
|
|
* The **struct bpf_tunnel_key** is an object that generalizes the
|
|
|
|
* principal parameters used by various tunneling protocols into a
|
|
|
|
* single struct. This way, it can be used to easily make a
|
|
|
|
* decision based on the contents of the encapsulation header,
|
|
|
|
* "summarized" in this struct. In particular, it holds the IP
|
|
|
|
* address of the remote end (IPv4 or IPv6, depending on the case)
|
|
|
|
* in *key*\ **->remote_ipv4** or *key*\ **->remote_ipv6**. Also,
|
|
|
|
* this struct exposes the *key*\ **->tunnel_id**, which is
|
|
|
|
* generally mapped to a VNI (Virtual Network Identifier), making
|
|
|
|
* it programmable together with the **bpf_skb_set_tunnel_key**\
|
|
|
|
* () helper.
|
|
|
|
*
|
|
|
|
* Let's imagine that the following code is part of a program
|
|
|
|
* attached to the TC ingress interface, on one end of a GRE
|
|
|
|
* tunnel, and is supposed to filter out all messages coming from
|
|
|
|
* remote ends with IPv4 address other than 10.0.0.1:
|
|
|
|
*
|
|
|
|
* ::
|
|
|
|
*
|
|
|
|
* int ret;
|
|
|
|
* struct bpf_tunnel_key key = {};
|
|
|
|
*
|
|
|
|
* ret = bpf_skb_get_tunnel_key(skb, &key, sizeof(key), 0);
|
|
|
|
* if (ret < 0)
|
|
|
|
* return TC_ACT_SHOT; // drop packet
|
|
|
|
*
|
|
|
|
* if (key.remote_ipv4 != 0x0a000001)
|
|
|
|
* return TC_ACT_SHOT; // drop packet
|
|
|
|
*
|
|
|
|
* return TC_ACT_OK; // accept packet
|
|
|
|
*
|
|
|
|
* This interface can also be used with all encapsulation devices
|
|
|
|
* that can operate in "collect metadata" mode: instead of having
|
|
|
|
* one network device per specific configuration, the "collect
|
|
|
|
* metadata" mode only requires a single device where the
|
|
|
|
* configuration can be extracted from this helper.
|
|
|
|
*
|
|
|
|
* This can be used together with various tunnels such as VXLan,
|
|
|
|
* Geneve, GRE or IP in IP (IPIP).
|
|
|
|
* Return
|
|
|
|
* 0 on success, or a negative error in case of failure.
|
|
|
|
*
|
|
|
|
* int bpf_skb_set_tunnel_key(struct sk_buff *skb, struct bpf_tunnel_key *key, u32 size, u64 flags)
|
|
|
|
* Description
|
|
|
|
* Populate tunnel metadata for packet associated to *skb.* The
|
|
|
|
* tunnel metadata is set to the contents of *key*, of *size*. The
|
|
|
|
* *flags* can be set to a combination of the following values:
|
|
|
|
*
|
|
|
|
* **BPF_F_TUNINFO_IPV6**
|
|
|
|
* Indicate that the tunnel is based on IPv6 protocol
|
|
|
|
* instead of IPv4.
|
|
|
|
* **BPF_F_ZERO_CSUM_TX**
|
|
|
|
* For IPv4 packets, add a flag to tunnel metadata
|
|
|
|
* indicating that checksum computation should be skipped
|
|
|
|
* and checksum set to zeroes.
|
|
|
|
* **BPF_F_DONT_FRAGMENT**
|
|
|
|
* Add a flag to tunnel metadata indicating that the
|
|
|
|
* packet should not be fragmented.
|
|
|
|
* **BPF_F_SEQ_NUMBER**
|
|
|
|
* Add a flag to tunnel metadata indicating that a
|
|
|
|
* sequence number should be added to tunnel header before
|
|
|
|
* sending the packet. This flag was added for GRE
|
|
|
|
* encapsulation, but might be used with other protocols
|
|
|
|
* as well in the future.
|
|
|
|
*
|
|
|
|
* Here is a typical usage on the transmit path:
|
|
|
|
*
|
|
|
|
* ::
|
|
|
|
*
|
|
|
|
* struct bpf_tunnel_key key;
|
|
|
|
* populate key ...
|
|
|
|
* bpf_skb_set_tunnel_key(skb, &key, sizeof(key), 0);
|
|
|
|
* bpf_clone_redirect(skb, vxlan_dev_ifindex, 0);
|
|
|
|
*
|
|
|
|
* See also the description of the **bpf_skb_get_tunnel_key**\ ()
|
|
|
|
* helper for additional information.
|
|
|
|
* Return
|
|
|
|
* 0 on success, or a negative error in case of failure.
|
|
|
|
*
|
|
|
|
* int bpf_redirect(u32 ifindex, u64 flags)
|
|
|
|
* Description
|
|
|
|
* Redirect the packet to another net device of index *ifindex*.
|
|
|
|
* This helper is somewhat similar to **bpf_clone_redirect**\
|
|
|
|
* (), except that the packet is not cloned, which provides
|
|
|
|
* increased performance.
|
|
|
|
*
|
|
|
|
* Except for XDP, both ingress and egress interfaces can be used
|
|
|
|
* for redirection. The **BPF_F_INGRESS** value in *flags* is used
|
|
|
|
* to make the distinction (ingress path is selected if the flag
|
|
|
|
* is present, egress path otherwise). Currently, XDP only
|
|
|
|
* supports redirection to the egress interface, and accepts no
|
|
|
|
* flag at all.
|
|
|
|
*
|
|
|
|
* The same effect can be attained with the more generic
|
|
|
|
* **bpf_redirect_map**\ (), which requires specific maps to be
|
|
|
|
* used but offers better performance.
|
|
|
|
* Return
|
|
|
|
* For XDP, the helper returns **XDP_REDIRECT** on success or
|
|
|
|
* **XDP_ABORTED** on error. For other program types, the values
|
|
|
|
* are **TC_ACT_REDIRECT** on success or **TC_ACT_SHOT** on
|
|
|
|
* error.
|
|
|
|
*
|
2018-04-26 00:16:55 +07:00
|
|
|
* u32 bpf_get_route_realm(struct sk_buff *skb)
|
|
|
|
* Description
|
|
|
|
* Retrieve the realm or the route, that is to say the
|
|
|
|
* **tclassid** field of the destination for the *skb*. The
|
|
|
|
* indentifier retrieved is a user-provided tag, similar to the
|
|
|
|
* one used with the net_cls cgroup (see description for
|
|
|
|
* **bpf_get_cgroup_classid**\ () helper), but here this tag is
|
|
|
|
* held by a route (a destination entry), not by a task.
|
|
|
|
*
|
|
|
|
* Retrieving this identifier works with the clsact TC egress hook
|
|
|
|
* (see also **tc-bpf(8)**), or alternatively on conventional
|
|
|
|
* classful egress qdiscs, but not on TC ingress path. In case of
|
|
|
|
* clsact TC egress hook, this has the advantage that, internally,
|
|
|
|
* the destination entry has not been dropped yet in the transmit
|
|
|
|
* path. Therefore, the destination entry does not need to be
|
|
|
|
* artificially held via **netif_keep_dst**\ () for a classful
|
|
|
|
* qdisc until the *skb* is freed.
|
|
|
|
*
|
|
|
|
* This helper is available only if the kernel was compiled with
|
|
|
|
* **CONFIG_IP_ROUTE_CLASSID** configuration option.
|
|
|
|
* Return
|
|
|
|
* The realm of the route for the packet associated to *skb*, or 0
|
|
|
|
* if none was found.
|
|
|
|
*
|
2018-04-26 00:16:54 +07:00
|
|
|
* int bpf_perf_event_output(struct pt_reg *ctx, struct bpf_map *map, u64 flags, void *data, u64 size)
|
|
|
|
* Description
|
|
|
|
* Write raw *data* blob into a special BPF perf event held by
|
|
|
|
* *map* of type **BPF_MAP_TYPE_PERF_EVENT_ARRAY**. This perf
|
|
|
|
* event must have the following attributes: **PERF_SAMPLE_RAW**
|
|
|
|
* as **sample_type**, **PERF_TYPE_SOFTWARE** as **type**, and
|
|
|
|
* **PERF_COUNT_SW_BPF_OUTPUT** as **config**.
|
|
|
|
*
|
|
|
|
* The *flags* are used to indicate the index in *map* for which
|
|
|
|
* the value must be put, masked with **BPF_F_INDEX_MASK**.
|
|
|
|
* Alternatively, *flags* can be set to **BPF_F_CURRENT_CPU**
|
|
|
|
* to indicate that the index of the current CPU core should be
|
|
|
|
* used.
|
|
|
|
*
|
|
|
|
* The value to write, of *size*, is passed through eBPF stack and
|
|
|
|
* pointed by *data*.
|
|
|
|
*
|
|
|
|
* The context of the program *ctx* needs also be passed to the
|
|
|
|
* helper.
|
|
|
|
*
|
|
|
|
* On user space, a program willing to read the values needs to
|
|
|
|
* call **perf_event_open**\ () on the perf event (either for
|
|
|
|
* one or for all CPUs) and to store the file descriptor into the
|
|
|
|
* *map*. This must be done before the eBPF program can send data
|
|
|
|
* into it. An example is available in file
|
|
|
|
* *samples/bpf/trace_output_user.c* in the Linux kernel source
|
|
|
|
* tree (the eBPF program counterpart is in
|
|
|
|
* *samples/bpf/trace_output_kern.c*).
|
|
|
|
*
|
|
|
|
* **bpf_perf_event_output**\ () achieves better performance
|
|
|
|
* than **bpf_trace_printk**\ () for sharing data with user
|
|
|
|
* space, and is much better suitable for streaming data from eBPF
|
|
|
|
* programs.
|
|
|
|
*
|
|
|
|
* Note that this helper is not restricted to tracing use cases
|
|
|
|
* and can be used with programs attached to TC or XDP as well,
|
|
|
|
* where it allows for passing data to user space listeners. Data
|
|
|
|
* can be:
|
|
|
|
*
|
|
|
|
* * Only custom structs,
|
|
|
|
* * Only the packet payload, or
|
|
|
|
* * A combination of both.
|
|
|
|
* Return
|
|
|
|
* 0 on success, or a negative error in case of failure.
|
|
|
|
*
|
2018-04-26 00:16:55 +07:00
|
|
|
* int bpf_skb_load_bytes(const struct sk_buff *skb, u32 offset, void *to, u32 len)
|
|
|
|
* Description
|
|
|
|
* This helper was provided as an easy way to load data from a
|
|
|
|
* packet. It can be used to load *len* bytes from *offset* from
|
|
|
|
* the packet associated to *skb*, into the buffer pointed by
|
|
|
|
* *to*.
|
|
|
|
*
|
|
|
|
* Since Linux 4.7, usage of this helper has mostly been replaced
|
|
|
|
* by "direct packet access", enabling packet data to be
|
|
|
|
* manipulated with *skb*\ **->data** and *skb*\ **->data_end**
|
|
|
|
* pointing respectively to the first byte of packet data and to
|
|
|
|
* the byte after the last byte of packet data. However, it
|
|
|
|
* remains useful if one wishes to read large quantities of data
|
|
|
|
* at once from a packet into the eBPF stack.
|
|
|
|
* Return
|
|
|
|
* 0 on success, or a negative error in case of failure.
|
|
|
|
*
|
2018-04-26 00:16:54 +07:00
|
|
|
* int bpf_get_stackid(struct pt_reg *ctx, struct bpf_map *map, u64 flags)
|
|
|
|
* Description
|
|
|
|
* Walk a user or a kernel stack and return its id. To achieve
|
|
|
|
* this, the helper needs *ctx*, which is a pointer to the context
|
|
|
|
* on which the tracing program is executed, and a pointer to a
|
|
|
|
* *map* of type **BPF_MAP_TYPE_STACK_TRACE**.
|
|
|
|
*
|
|
|
|
* The last argument, *flags*, holds the number of stack frames to
|
|
|
|
* skip (from 0 to 255), masked with
|
|
|
|
* **BPF_F_SKIP_FIELD_MASK**. The next bits can be used to set
|
|
|
|
* a combination of the following flags:
|
|
|
|
*
|
|
|
|
* **BPF_F_USER_STACK**
|
|
|
|
* Collect a user space stack instead of a kernel stack.
|
|
|
|
* **BPF_F_FAST_STACK_CMP**
|
|
|
|
* Compare stacks by hash only.
|
|
|
|
* **BPF_F_REUSE_STACKID**
|
|
|
|
* If two different stacks hash into the same *stackid*,
|
|
|
|
* discard the old one.
|
|
|
|
*
|
|
|
|
* The stack id retrieved is a 32 bit long integer handle which
|
|
|
|
* can be further combined with other data (including other stack
|
|
|
|
* ids) and used as a key into maps. This can be useful for
|
|
|
|
* generating a variety of graphs (such as flame graphs or off-cpu
|
|
|
|
* graphs).
|
|
|
|
*
|
|
|
|
* For walking a stack, this helper is an improvement over
|
|
|
|
* **bpf_probe_read**\ (), which can be used with unrolled loops
|
|
|
|
* but is not efficient and consumes a lot of eBPF instructions.
|
|
|
|
* Instead, **bpf_get_stackid**\ () can collect up to
|
|
|
|
* **PERF_MAX_STACK_DEPTH** both kernel and user frames. Note that
|
|
|
|
* this limit can be controlled with the **sysctl** program, and
|
|
|
|
* that it should be manually increased in order to profile long
|
|
|
|
* user stacks (such as stacks for Java programs). To do so, use:
|
|
|
|
*
|
|
|
|
* ::
|
|
|
|
*
|
|
|
|
* # sysctl kernel.perf_event_max_stack=<new value>
|
|
|
|
*
|
|
|
|
* Return
|
|
|
|
* The positive or null stack id on success, or a negative error
|
|
|
|
* in case of failure.
|
|
|
|
*
|
2018-04-26 00:16:55 +07:00
|
|
|
* s64 bpf_csum_diff(__be32 *from, u32 from_size, __be32 *to, u32 to_size, __wsum seed)
|
|
|
|
* Description
|
|
|
|
* Compute a checksum difference, from the raw buffer pointed by
|
|
|
|
* *from*, of length *from_size* (that must be a multiple of 4),
|
|
|
|
* towards the raw buffer pointed by *to*, of size *to_size*
|
|
|
|
* (same remark). An optional *seed* can be added to the value
|
|
|
|
* (this can be cascaded, the seed may come from a previous call
|
|
|
|
* to the helper).
|
|
|
|
*
|
|
|
|
* This is flexible enough to be used in several ways:
|
|
|
|
*
|
|
|
|
* * With *from_size* == 0, *to_size* > 0 and *seed* set to
|
|
|
|
* checksum, it can be used when pushing new data.
|
|
|
|
* * With *from_size* > 0, *to_size* == 0 and *seed* set to
|
|
|
|
* checksum, it can be used when removing data from a packet.
|
|
|
|
* * With *from_size* > 0, *to_size* > 0 and *seed* set to 0, it
|
|
|
|
* can be used to compute a diff. Note that *from_size* and
|
|
|
|
* *to_size* do not need to be equal.
|
|
|
|
*
|
|
|
|
* This helper can be used in combination with
|
|
|
|
* **bpf_l3_csum_replace**\ () and **bpf_l4_csum_replace**\ (), to
|
|
|
|
* which one can feed in the difference computed with
|
|
|
|
* **bpf_csum_diff**\ ().
|
|
|
|
* Return
|
|
|
|
* The checksum result, or a negative error code in case of
|
|
|
|
* failure.
|
|
|
|
*
|
|
|
|
* int bpf_skb_get_tunnel_opt(struct sk_buff *skb, u8 *opt, u32 size)
|
|
|
|
* Description
|
|
|
|
* Retrieve tunnel options metadata for the packet associated to
|
|
|
|
* *skb*, and store the raw tunnel option data to the buffer *opt*
|
|
|
|
* of *size*.
|
|
|
|
*
|
|
|
|
* This helper can be used with encapsulation devices that can
|
|
|
|
* operate in "collect metadata" mode (please refer to the related
|
|
|
|
* note in the description of **bpf_skb_get_tunnel_key**\ () for
|
|
|
|
* more details). A particular example where this can be used is
|
|
|
|
* in combination with the Geneve encapsulation protocol, where it
|
|
|
|
* allows for pushing (with **bpf_skb_get_tunnel_opt**\ () helper)
|
|
|
|
* and retrieving arbitrary TLVs (Type-Length-Value headers) from
|
|
|
|
* the eBPF program. This allows for full customization of these
|
|
|
|
* headers.
|
|
|
|
* Return
|
|
|
|
* The size of the option data retrieved.
|
|
|
|
*
|
|
|
|
* int bpf_skb_set_tunnel_opt(struct sk_buff *skb, u8 *opt, u32 size)
|
|
|
|
* Description
|
|
|
|
* Set tunnel options metadata for the packet associated to *skb*
|
|
|
|
* to the option data contained in the raw buffer *opt* of *size*.
|
|
|
|
*
|
|
|
|
* See also the description of the **bpf_skb_get_tunnel_opt**\ ()
|
|
|
|
* helper for additional information.
|
|
|
|
* Return
|
|
|
|
* 0 on success, or a negative error in case of failure.
|
|
|
|
*
|
|
|
|
* int bpf_skb_change_proto(struct sk_buff *skb, __be16 proto, u64 flags)
|
|
|
|
* Description
|
|
|
|
* Change the protocol of the *skb* to *proto*. Currently
|
|
|
|
* supported are transition from IPv4 to IPv6, and from IPv6 to
|
|
|
|
* IPv4. The helper takes care of the groundwork for the
|
|
|
|
* transition, including resizing the socket buffer. The eBPF
|
|
|
|
* program is expected to fill the new headers, if any, via
|
|
|
|
* **skb_store_bytes**\ () and to recompute the checksums with
|
|
|
|
* **bpf_l3_csum_replace**\ () and **bpf_l4_csum_replace**\
|
|
|
|
* (). The main case for this helper is to perform NAT64
|
|
|
|
* operations out of an eBPF program.
|
|
|
|
*
|
|
|
|
* Internally, the GSO type is marked as dodgy so that headers are
|
|
|
|
* checked and segments are recalculated by the GSO/GRO engine.
|
|
|
|
* The size for GSO target is adapted as well.
|
|
|
|
*
|
|
|
|
* All values for *flags* are reserved for future usage, and must
|
|
|
|
* be left at zero.
|
|
|
|
*
|
|
|
|
* A call to this helper is susceptible to change the underlaying
|
|
|
|
* packet buffer. Therefore, at load time, all checks on pointers
|
|
|
|
* previously done by the verifier are invalidated and must be
|
|
|
|
* performed again, if the helper is used in combination with
|
|
|
|
* direct packet access.
|
|
|
|
* Return
|
|
|
|
* 0 on success, or a negative error in case of failure.
|
|
|
|
*
|
|
|
|
* int bpf_skb_change_type(struct sk_buff *skb, u32 type)
|
|
|
|
* Description
|
|
|
|
* Change the packet type for the packet associated to *skb*. This
|
|
|
|
* comes down to setting *skb*\ **->pkt_type** to *type*, except
|
|
|
|
* the eBPF program does not have a write access to *skb*\
|
|
|
|
* **->pkt_type** beside this helper. Using a helper here allows
|
|
|
|
* for graceful handling of errors.
|
|
|
|
*
|
|
|
|
* The major use case is to change incoming *skb*s to
|
|
|
|
* **PACKET_HOST** in a programmatic way instead of having to
|
|
|
|
* recirculate via **redirect**\ (..., **BPF_F_INGRESS**), for
|
|
|
|
* example.
|
|
|
|
*
|
|
|
|
* Note that *type* only allows certain values. At this time, they
|
|
|
|
* are:
|
|
|
|
*
|
|
|
|
* **PACKET_HOST**
|
|
|
|
* Packet is for us.
|
|
|
|
* **PACKET_BROADCAST**
|
|
|
|
* Send packet to all.
|
|
|
|
* **PACKET_MULTICAST**
|
|
|
|
* Send packet to group.
|
|
|
|
* **PACKET_OTHERHOST**
|
|
|
|
* Send packet to someone else.
|
|
|
|
* Return
|
|
|
|
* 0 on success, or a negative error in case of failure.
|
|
|
|
*
|
2018-04-26 00:16:56 +07:00
|
|
|
* u32 bpf_get_hash_recalc(struct sk_buff *skb)
|
|
|
|
* Description
|
|
|
|
* Retrieve the hash of the packet, *skb*\ **->hash**. If it is
|
|
|
|
* not set, in particular if the hash was cleared due to mangling,
|
|
|
|
* recompute this hash. Later accesses to the hash can be done
|
|
|
|
* directly with *skb*\ **->hash**.
|
|
|
|
*
|
|
|
|
* Calling **bpf_set_hash_invalid**\ (), changing a packet
|
|
|
|
* prototype with **bpf_skb_change_proto**\ (), or calling
|
|
|
|
* **bpf_skb_store_bytes**\ () with the
|
|
|
|
* **BPF_F_INVALIDATE_HASH** are actions susceptible to clear
|
|
|
|
* the hash and to trigger a new computation for the next call to
|
|
|
|
* **bpf_get_hash_recalc**\ ().
|
|
|
|
* Return
|
|
|
|
* The 32-bit hash.
|
|
|
|
*
|
2018-04-26 00:16:54 +07:00
|
|
|
* u64 bpf_get_current_task(void)
|
|
|
|
* Return
|
|
|
|
* A pointer to the current task struct.
|
2018-04-26 00:16:56 +07:00
|
|
|
*
|
|
|
|
* int bpf_skb_change_tail(struct sk_buff *skb, u32 len, u64 flags)
|
|
|
|
* Description
|
|
|
|
* Resize (trim or grow) the packet associated to *skb* to the
|
|
|
|
* new *len*. The *flags* are reserved for future usage, and must
|
|
|
|
* be left at zero.
|
|
|
|
*
|
|
|
|
* The basic idea is that the helper performs the needed work to
|
|
|
|
* change the size of the packet, then the eBPF program rewrites
|
|
|
|
* the rest via helpers like **bpf_skb_store_bytes**\ (),
|
|
|
|
* **bpf_l3_csum_replace**\ (), **bpf_l3_csum_replace**\ ()
|
|
|
|
* and others. This helper is a slow path utility intended for
|
|
|
|
* replies with control messages. And because it is targeted for
|
|
|
|
* slow path, the helper itself can afford to be slow: it
|
|
|
|
* implicitly linearizes, unclones and drops offloads from the
|
|
|
|
* *skb*.
|
|
|
|
*
|
|
|
|
* A call to this helper is susceptible to change the underlaying
|
|
|
|
* packet buffer. Therefore, at load time, all checks on pointers
|
|
|
|
* previously done by the verifier are invalidated and must be
|
|
|
|
* performed again, if the helper is used in combination with
|
|
|
|
* direct packet access.
|
|
|
|
* Return
|
|
|
|
* 0 on success, or a negative error in case of failure.
|
|
|
|
*
|
|
|
|
* int bpf_skb_pull_data(struct sk_buff *skb, u32 len)
|
|
|
|
* Description
|
|
|
|
* Pull in non-linear data in case the *skb* is non-linear and not
|
|
|
|
* all of *len* are part of the linear section. Make *len* bytes
|
|
|
|
* from *skb* readable and writable. If a zero value is passed for
|
|
|
|
* *len*, then the whole length of the *skb* is pulled.
|
|
|
|
*
|
|
|
|
* This helper is only needed for reading and writing with direct
|
|
|
|
* packet access.
|
|
|
|
*
|
|
|
|
* For direct packet access, testing that offsets to access
|
|
|
|
* are within packet boundaries (test on *skb*\ **->data_end**) is
|
|
|
|
* susceptible to fail if offsets are invalid, or if the requested
|
|
|
|
* data is in non-linear parts of the *skb*. On failure the
|
|
|
|
* program can just bail out, or in the case of a non-linear
|
|
|
|
* buffer, use a helper to make the data available. The
|
|
|
|
* **bpf_skb_load_bytes**\ () helper is a first solution to access
|
|
|
|
* the data. Another one consists in using **bpf_skb_pull_data**
|
|
|
|
* to pull in once the non-linear parts, then retesting and
|
|
|
|
* eventually access the data.
|
|
|
|
*
|
|
|
|
* At the same time, this also makes sure the *skb* is uncloned,
|
|
|
|
* which is a necessary condition for direct write. As this needs
|
|
|
|
* to be an invariant for the write part only, the verifier
|
|
|
|
* detects writes and adds a prologue that is calling
|
|
|
|
* **bpf_skb_pull_data()** to effectively unclone the *skb* from
|
|
|
|
* the very beginning in case it is indeed cloned.
|
|
|
|
*
|
|
|
|
* A call to this helper is susceptible to change the underlaying
|
|
|
|
* packet buffer. Therefore, at load time, all checks on pointers
|
|
|
|
* previously done by the verifier are invalidated and must be
|
|
|
|
* performed again, if the helper is used in combination with
|
|
|
|
* direct packet access.
|
|
|
|
* Return
|
|
|
|
* 0 on success, or a negative error in case of failure.
|
|
|
|
*
|
|
|
|
* s64 bpf_csum_update(struct sk_buff *skb, __wsum csum)
|
|
|
|
* Description
|
|
|
|
* Add the checksum *csum* into *skb*\ **->csum** in case the
|
|
|
|
* driver has supplied a checksum for the entire packet into that
|
|
|
|
* field. Return an error otherwise. This helper is intended to be
|
|
|
|
* used in combination with **bpf_csum_diff**\ (), in particular
|
|
|
|
* when the checksum needs to be updated after data has been
|
|
|
|
* written into the packet through direct packet access.
|
|
|
|
* Return
|
|
|
|
* The checksum on success, or a negative error code in case of
|
|
|
|
* failure.
|
|
|
|
*
|
|
|
|
* void bpf_set_hash_invalid(struct sk_buff *skb)
|
|
|
|
* Description
|
|
|
|
* Invalidate the current *skb*\ **->hash**. It can be used after
|
|
|
|
* mangling on headers through direct packet access, in order to
|
|
|
|
* indicate that the hash is outdated and to trigger a
|
|
|
|
* recalculation the next time the kernel tries to access this
|
|
|
|
* hash or when the **bpf_get_hash_recalc**\ () helper is called.
|
|
|
|
*
|
|
|
|
* int bpf_get_numa_node_id(void)
|
|
|
|
* Description
|
|
|
|
* Return the id of the current NUMA node. The primary use case
|
|
|
|
* for this helper is the selection of sockets for the local NUMA
|
|
|
|
* node, when the program is attached to sockets using the
|
|
|
|
* **SO_ATTACH_REUSEPORT_EBPF** option (see also **socket(7)**),
|
|
|
|
* but the helper is also available to other eBPF program types,
|
|
|
|
* similarly to **bpf_get_smp_processor_id**\ ().
|
|
|
|
* Return
|
|
|
|
* The id of current NUMA node.
|
|
|
|
*
|
|
|
|
* u32 bpf_set_hash(struct sk_buff *skb, u32 hash)
|
|
|
|
* Description
|
|
|
|
* Set the full hash for *skb* (set the field *skb*\ **->hash**)
|
|
|
|
* to value *hash*.
|
|
|
|
* Return
|
|
|
|
* 0
|
|
|
|
*
|
|
|
|
* int bpf_skb_adjust_room(struct sk_buff *skb, u32 len_diff, u32 mode, u64 flags)
|
|
|
|
* Description
|
|
|
|
* Grow or shrink the room for data in the packet associated to
|
|
|
|
* *skb* by *len_diff*, and according to the selected *mode*.
|
|
|
|
*
|
|
|
|
* There is a single supported mode at this time:
|
|
|
|
*
|
|
|
|
* * **BPF_ADJ_ROOM_NET**: Adjust room at the network layer
|
|
|
|
* (room space is added or removed below the layer 3 header).
|
|
|
|
*
|
|
|
|
* All values for *flags* are reserved for future usage, and must
|
|
|
|
* be left at zero.
|
|
|
|
*
|
|
|
|
* A call to this helper is susceptible to change the underlaying
|
|
|
|
* packet buffer. Therefore, at load time, all checks on pointers
|
|
|
|
* previously done by the verifier are invalidated and must be
|
|
|
|
* performed again, if the helper is used in combination with
|
|
|
|
* direct packet access.
|
|
|
|
* Return
|
|
|
|
* 0 on success, or a negative error in case of failure.
|
|
|
|
*
|
|
|
|
* int bpf_xdp_adjust_meta(struct xdp_buff *xdp_md, int delta)
|
|
|
|
* Description
|
|
|
|
* Adjust the address pointed by *xdp_md*\ **->data_meta** by
|
|
|
|
* *delta* (which can be positive or negative). Note that this
|
|
|
|
* operation modifies the address stored in *xdp_md*\ **->data**,
|
|
|
|
* so the latter must be loaded only after the helper has been
|
|
|
|
* called.
|
|
|
|
*
|
|
|
|
* The use of *xdp_md*\ **->data_meta** is optional and programs
|
|
|
|
* are not required to use it. The rationale is that when the
|
|
|
|
* packet is processed with XDP (e.g. as DoS filter), it is
|
|
|
|
* possible to push further meta data along with it before passing
|
|
|
|
* to the stack, and to give the guarantee that an ingress eBPF
|
|
|
|
* program attached as a TC classifier on the same device can pick
|
|
|
|
* this up for further post-processing. Since TC works with socket
|
|
|
|
* buffers, it remains possible to set from XDP the **mark** or
|
|
|
|
* **priority** pointers, or other pointers for the socket buffer.
|
|
|
|
* Having this scratch space generic and programmable allows for
|
|
|
|
* more flexibility as the user is free to store whatever meta
|
|
|
|
* data they need.
|
|
|
|
*
|
|
|
|
* A call to this helper is susceptible to change the underlaying
|
|
|
|
* packet buffer. Therefore, at load time, all checks on pointers
|
|
|
|
* previously done by the verifier are invalidated and must be
|
|
|
|
* performed again, if the helper is used in combination with
|
|
|
|
* direct packet access.
|
|
|
|
* Return
|
|
|
|
* 0 on success, or a negative error in case of failure.
|
2016-10-27 16:23:51 +07:00
|
|
|
*/
|
|
|
|
#define __BPF_FUNC_MAPPER(FN) \
|
|
|
|
FN(unspec), \
|
|
|
|
FN(map_lookup_elem), \
|
|
|
|
FN(map_update_elem), \
|
|
|
|
FN(map_delete_elem), \
|
|
|
|
FN(probe_read), \
|
|
|
|
FN(ktime_get_ns), \
|
|
|
|
FN(trace_printk), \
|
|
|
|
FN(get_prandom_u32), \
|
|
|
|
FN(get_smp_processor_id), \
|
|
|
|
FN(skb_store_bytes), \
|
|
|
|
FN(l3_csum_replace), \
|
|
|
|
FN(l4_csum_replace), \
|
|
|
|
FN(tail_call), \
|
|
|
|
FN(clone_redirect), \
|
|
|
|
FN(get_current_pid_tgid), \
|
|
|
|
FN(get_current_uid_gid), \
|
|
|
|
FN(get_current_comm), \
|
|
|
|
FN(get_cgroup_classid), \
|
|
|
|
FN(skb_vlan_push), \
|
|
|
|
FN(skb_vlan_pop), \
|
|
|
|
FN(skb_get_tunnel_key), \
|
|
|
|
FN(skb_set_tunnel_key), \
|
|
|
|
FN(perf_event_read), \
|
|
|
|
FN(redirect), \
|
|
|
|
FN(get_route_realm), \
|
|
|
|
FN(perf_event_output), \
|
|
|
|
FN(skb_load_bytes), \
|
|
|
|
FN(get_stackid), \
|
|
|
|
FN(csum_diff), \
|
|
|
|
FN(skb_get_tunnel_opt), \
|
|
|
|
FN(skb_set_tunnel_opt), \
|
|
|
|
FN(skb_change_proto), \
|
|
|
|
FN(skb_change_type), \
|
|
|
|
FN(skb_under_cgroup), \
|
|
|
|
FN(get_hash_recalc), \
|
|
|
|
FN(get_current_task), \
|
|
|
|
FN(probe_write_user), \
|
|
|
|
FN(current_task_under_cgroup), \
|
|
|
|
FN(skb_change_tail), \
|
|
|
|
FN(skb_pull_data), \
|
|
|
|
FN(csum_update), \
|
|
|
|
FN(set_hash_invalid), \
|
2016-11-30 23:10:10 +07:00
|
|
|
FN(get_numa_node_id), \
|
2016-12-08 06:53:11 +07:00
|
|
|
FN(skb_change_head), \
|
bpf: add bpf_probe_read_str helper
Provide a simple helper with the same semantics of strncpy_from_unsafe():
int bpf_probe_read_str(void *dst, int size, const void *unsafe_addr)
This gives more flexibility to a bpf program. A typical use case is
intercepting a file name during sys_open(). The current approach is:
SEC("kprobe/sys_open")
void bpf_sys_open(struct pt_regs *ctx)
{
char buf[PATHLEN]; // PATHLEN is defined to 256
bpf_probe_read(buf, sizeof(buf), ctx->di);
/* consume buf */
}
This is suboptimal because the size of the string needs to be estimated
at compile time, causing more memory to be copied than often necessary,
and can become more problematic if further processing on buf is done,
for example by pushing it to userspace via bpf_perf_event_output(),
since the real length of the string is unknown and the entire buffer
must be copied (and defining an unrolled strnlen() inside the bpf
program is a very inefficient and unfeasible approach).
With the new helper, the code can easily operate on the actual string
length rather than the buffer size:
SEC("kprobe/sys_open")
void bpf_sys_open(struct pt_regs *ctx)
{
char buf[PATHLEN]; // PATHLEN is defined to 256
int res = bpf_probe_read_str(buf, sizeof(buf), ctx->di);
/* consume buf, for example push it to userspace via
* bpf_perf_event_output(), but this time we can use
* res (the string length) as event size, after checking
* its boundaries.
*/
}
Another useful use case is when parsing individual process arguments or
individual environment variables navigating current->mm->arg_start and
current->mm->env_start: using this helper and the return value, one can
quickly iterate at the right offset of the memory area.
The code changes simply leverage the already existent
strncpy_from_unsafe() kernel function, which is safe to be called from a
bpf program as it is used in bpf_trace_printk().
Signed-off-by: Gianluca Borello <g.borello@gmail.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-01-19 00:55:49 +07:00
|
|
|
FN(xdp_adjust_head), \
|
2017-03-23 07:27:34 +07:00
|
|
|
FN(probe_read_str), \
|
2017-03-23 07:27:35 +07:00
|
|
|
FN(get_socket_cookie), \
|
2017-06-11 05:50:47 +07:00
|
|
|
FN(get_socket_uid), \
|
2017-07-01 10:02:46 +07:00
|
|
|
FN(set_hash), \
|
2017-07-02 07:13:26 +07:00
|
|
|
FN(setsockopt), \
|
2017-07-17 23:29:18 +07:00
|
|
|
FN(skb_adjust_room), \
|
2017-08-16 12:32:47 +07:00
|
|
|
FN(redirect_map), \
|
|
|
|
FN(sk_redirect_map), \
|
|
|
|
FN(sock_map_update), \
|
2017-10-05 23:19:20 +07:00
|
|
|
FN(xdp_adjust_meta), \
|
2017-10-05 23:19:22 +07:00
|
|
|
FN(perf_event_read_value), \
|
2017-10-21 01:05:40 +07:00
|
|
|
FN(perf_prog_read_value), \
|
2017-12-11 23:36:48 +07:00
|
|
|
FN(getsockopt), \
|
2018-01-26 07:14:10 +07:00
|
|
|
FN(override_return), \
|
bpf: create tcp_bpf_ulp allowing BPF to monitor socket TX/RX data
This implements a BPF ULP layer to allow policy enforcement and
monitoring at the socket layer. In order to support this a new
program type BPF_PROG_TYPE_SK_MSG is used to run the policy at
the sendmsg/sendpage hook. To attach the policy to sockets a
sockmap is used with a new program attach type BPF_SK_MSG_VERDICT.
Similar to previous sockmap usages when a sock is added to a
sockmap, via a map update, if the map contains a BPF_SK_MSG_VERDICT
program type attached then the BPF ULP layer is created on the
socket and the attached BPF_PROG_TYPE_SK_MSG program is run for
every msg in sendmsg case and page/offset in sendpage case.
BPF_PROG_TYPE_SK_MSG Semantics/API:
BPF_PROG_TYPE_SK_MSG supports only two return codes SK_PASS and
SK_DROP. Returning SK_DROP free's the copied data in the sendmsg
case and in the sendpage case leaves the data untouched. Both cases
return -EACESS to the user. Returning SK_PASS will allow the msg to
be sent.
In the sendmsg case data is copied into kernel space buffers before
running the BPF program. The kernel space buffers are stored in a
scatterlist object where each element is a kernel memory buffer.
Some effort is made to coalesce data from the sendmsg call here.
For example a sendmsg call with many one byte iov entries will
likely be pushed into a single entry. The BPF program is run with
data pointers (start/end) pointing to the first sg element.
In the sendpage case data is not copied. We opt not to copy the
data by default here, because the BPF infrastructure does not
know what bytes will be needed nor when they will be needed. So
copying all bytes may be wasteful. Because of this the initial
start/end data pointers are (0,0). Meaning no data can be read or
written. This avoids reading data that may be modified by the
user. A new helper is added later in this series if reading and
writing the data is needed. The helper call will do a copy by
default so that the page is exclusively owned by the BPF call.
The verdict from the BPF_PROG_TYPE_SK_MSG applies to the entire msg
in the sendmsg() case and the entire page/offset in the sendpage case.
This avoids ambiguity on how to handle mixed return codes in the
sendmsg case. Again a helper is added later in the series if
a verdict needs to apply to multiple system calls and/or only
a subpart of the currently being processed message.
The helper msg_redirect_map() can be used to select the socket to
send the data on. This is used similar to existing redirect use
cases. This allows policy to redirect msgs.
Pseudo code simple example:
The basic logic to attach a program to a socket is as follows,
// load the programs
bpf_prog_load(SOCKMAP_TCP_MSG_PROG, BPF_PROG_TYPE_SK_MSG,
&obj, &msg_prog);
// lookup the sockmap
bpf_map_msg = bpf_object__find_map_by_name(obj, "my_sock_map");
// get fd for sockmap
map_fd_msg = bpf_map__fd(bpf_map_msg);
// attach program to sockmap
bpf_prog_attach(msg_prog, map_fd_msg, BPF_SK_MSG_VERDICT, 0);
Adding sockets to the map is done in the normal way,
// Add a socket 'fd' to sockmap at location 'i'
bpf_map_update_elem(map_fd_msg, &i, fd, BPF_ANY);
After the above any socket attached to "my_sock_map", in this case
'fd', will run the BPF msg verdict program (msg_prog) on every
sendmsg and sendpage system call.
For a complete example see BPF selftests or sockmap samples.
Implementation notes:
It seemed the simplest, to me at least, to use a refcnt to ensure
psock is not lost across the sendmsg copy into the sg, the bpf program
running on the data in sg_data, and the final pass to the TCP stack.
Some performance testing may show a better method to do this and avoid
the refcnt cost, but for now use the simpler method.
Another item that will come after basic support is in place is
supporting MSG_MORE flag. At the moment we call sendpages even if
the MSG_MORE flag is set. An enhancement would be to collect the
pages into a larger scatterlist and pass down the stack. Notice that
bpf_tcp_sendmsg() could support this with some additional state saved
across sendmsg calls. I built the code to support this without having
to do refactoring work. Other features TBD include ZEROCOPY and the
TCP_RECV_QUEUE/TCP_NO_QUEUE support. This will follow initial series
shortly.
Future work could improve size limits on the scatterlist rings used
here. Currently, we use MAX_SKB_FRAGS simply because this was being
used already in the TLS case. Future work could extend the kernel sk
APIs to tune this depending on workload. This is a trade-off
between memory usage and throughput performance.
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: David S. Miller <davem@davemloft.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-19 02:57:10 +07:00
|
|
|
FN(sock_ops_cb_flags_set), \
|
2018-03-19 02:57:15 +07:00
|
|
|
FN(msg_redirect_map), \
|
2018-03-19 02:57:20 +07:00
|
|
|
FN(msg_apply_bytes), \
|
bpf: sk_msg program helper bpf_sk_msg_pull_data
Currently, if a bpf sk msg program is run the program
can only parse data that the (start,end) pointers already
consumed. For sendmsg hooks this is likely the first
scatterlist element. For sendpage this will be the range
(0,0) because the data is shared with userspace and by
default we want to avoid allowing userspace to modify
data while (or after) BPF verdict is being decided.
To support pulling in additional bytes for parsing use
a new helper bpf_sk_msg_pull(start, end, flags) which
works similar to cls tc logic. This helper will attempt
to point the data start pointer at 'start' bytes offest
into msg and data end pointer at 'end' bytes offset into
message.
After basic sanity checks to ensure 'start' <= 'end' and
'end' <= msg_length there are a few cases we need to
handle.
First the sendmsg hook has already copied the data from
userspace and has exclusive access to it. Therefor, it
is not necessesary to copy the data. However, it may
be required. After finding the scatterlist element with
'start' offset byte in it there are two cases. One the
range (start,end) is entirely contained in the sg element
and is already linear. All that is needed is to update the
data pointers, no allocate/copy is needed. The other case
is (start, end) crosses sg element boundaries. In this
case we allocate a block of size 'end - start' and copy
the data to linearize it.
Next sendpage hook has not copied any data in initial
state so that data pointers are (0,0). In this case we
handle it similar to the above sendmsg case except the
allocation/copy must always happen. Then when sending
the data we have possibly three memory regions that
need to be sent, (0, start - 1), (start, end), and
(end + 1, msg_length). This is required to ensure any
writes by the BPF program are correctly transmitted.
Lastly this operation will invalidate any previous
data checks so BPF programs will have to revalidate
pointers after making this BPF call.
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-19 02:57:25 +07:00
|
|
|
FN(msg_cork_bytes), \
|
2018-03-31 05:08:05 +07:00
|
|
|
FN(msg_pull_data), \
|
2018-04-18 11:42:13 +07:00
|
|
|
FN(bind), \
|
2018-04-24 21:50:29 +07:00
|
|
|
FN(xdp_adjust_tail), \
|
|
|
|
FN(skb_get_xfrm_state),
|
2016-10-27 16:23:51 +07:00
|
|
|
|
2014-09-26 14:17:00 +07:00
|
|
|
/* integer value in 'imm' field of BPF_CALL instruction selects which helper
|
|
|
|
* function eBPF program intends to call
|
|
|
|
*/
|
2016-10-27 16:23:51 +07:00
|
|
|
#define __BPF_ENUM_FN(x) BPF_FUNC_ ## x
|
2014-09-26 14:17:00 +07:00
|
|
|
enum bpf_func_id {
|
2016-10-27 16:23:51 +07:00
|
|
|
__BPF_FUNC_MAPPER(__BPF_ENUM_FN)
|
2014-09-26 14:17:00 +07:00
|
|
|
__BPF_FUNC_MAX_ID,
|
|
|
|
};
|
2016-10-27 16:23:51 +07:00
|
|
|
#undef __BPF_ENUM_FN
|
2014-09-26 14:17:00 +07:00
|
|
|
|
2016-01-11 07:16:38 +07:00
|
|
|
/* All flags used by eBPF helper functions, placed here. */
|
|
|
|
|
|
|
|
/* BPF_FUNC_skb_store_bytes flags. */
|
|
|
|
#define BPF_F_RECOMPUTE_CSUM (1ULL << 0)
|
2016-03-04 21:15:03 +07:00
|
|
|
#define BPF_F_INVALIDATE_HASH (1ULL << 1)
|
2016-01-11 07:16:38 +07:00
|
|
|
|
|
|
|
/* BPF_FUNC_l3_csum_replace and BPF_FUNC_l4_csum_replace flags.
|
|
|
|
* First 4 bits are for passing the header field size.
|
|
|
|
*/
|
|
|
|
#define BPF_F_HDR_FIELD_MASK 0xfULL
|
|
|
|
|
|
|
|
/* BPF_FUNC_l4_csum_replace flags. */
|
|
|
|
#define BPF_F_PSEUDO_HDR (1ULL << 4)
|
2016-02-20 05:05:26 +07:00
|
|
|
#define BPF_F_MARK_MANGLED_0 (1ULL << 5)
|
2017-01-24 07:06:28 +07:00
|
|
|
#define BPF_F_MARK_ENFORCE (1ULL << 6)
|
2016-01-11 07:16:38 +07:00
|
|
|
|
|
|
|
/* BPF_FUNC_clone_redirect and BPF_FUNC_redirect flags. */
|
|
|
|
#define BPF_F_INGRESS (1ULL << 0)
|
|
|
|
|
2016-01-11 07:16:39 +07:00
|
|
|
/* BPF_FUNC_skb_set_tunnel_key and BPF_FUNC_skb_get_tunnel_key flags. */
|
|
|
|
#define BPF_F_TUNINFO_IPV6 (1ULL << 0)
|
|
|
|
|
2016-02-18 10:58:58 +07:00
|
|
|
/* BPF_FUNC_get_stackid flags. */
|
|
|
|
#define BPF_F_SKIP_FIELD_MASK 0xffULL
|
|
|
|
#define BPF_F_USER_STACK (1ULL << 8)
|
|
|
|
#define BPF_F_FAST_STACK_CMP (1ULL << 9)
|
|
|
|
#define BPF_F_REUSE_STACKID (1ULL << 10)
|
|
|
|
|
2016-02-23 08:05:26 +07:00
|
|
|
/* BPF_FUNC_skb_set_tunnel_key flags. */
|
|
|
|
#define BPF_F_ZERO_CSUM_TX (1ULL << 1)
|
2016-03-04 21:15:05 +07:00
|
|
|
#define BPF_F_DONT_FRAGMENT (1ULL << 2)
|
2018-03-02 04:49:57 +07:00
|
|
|
#define BPF_F_SEQ_NUMBER (1ULL << 3)
|
2016-02-23 08:05:26 +07:00
|
|
|
|
2017-10-05 23:19:20 +07:00
|
|
|
/* BPF_FUNC_perf_event_output, BPF_FUNC_perf_event_read and
|
|
|
|
* BPF_FUNC_perf_event_read_value flags.
|
|
|
|
*/
|
2016-04-19 02:01:23 +07:00
|
|
|
#define BPF_F_INDEX_MASK 0xffffffffULL
|
|
|
|
#define BPF_F_CURRENT_CPU BPF_F_INDEX_MASK
|
2016-07-14 23:08:05 +07:00
|
|
|
/* BPF_FUNC_perf_event_output for sk_buff input context. */
|
|
|
|
#define BPF_F_CTXLEN_MASK (0xfffffULL << 32)
|
2016-04-19 02:01:23 +07:00
|
|
|
|
2017-07-02 07:13:26 +07:00
|
|
|
/* Mode for BPF_FUNC_skb_adjust_room helper. */
|
|
|
|
enum bpf_adj_room_mode {
|
|
|
|
BPF_ADJ_ROOM_NET,
|
|
|
|
};
|
|
|
|
|
2015-03-14 01:57:42 +07:00
|
|
|
/* user accessible mirror of in-kernel sk_buff.
|
|
|
|
* new fields can only be added to the end of this structure
|
|
|
|
*/
|
|
|
|
struct __sk_buff {
|
|
|
|
__u32 len;
|
|
|
|
__u32 pkt_type;
|
|
|
|
__u32 mark;
|
|
|
|
__u32 queue_mapping;
|
2015-03-17 08:06:02 +07:00
|
|
|
__u32 protocol;
|
|
|
|
__u32 vlan_present;
|
|
|
|
__u32 vlan_tci;
|
2015-03-24 20:48:41 +07:00
|
|
|
__u32 vlan_proto;
|
2015-04-04 01:52:24 +07:00
|
|
|
__u32 priority;
|
2015-05-28 05:30:39 +07:00
|
|
|
__u32 ingress_ifindex;
|
|
|
|
__u32 ifindex;
|
2015-06-05 00:11:54 +07:00
|
|
|
__u32 tc_index;
|
|
|
|
__u32 cb[5];
|
ebpf: add skb->hash to offset map for usage in {cls, act}_bpf or filters
Add skb->hash to the __sk_buff offset map, so it can be accessed from
an eBPF program. We currently already do this for classic BPF filters,
but not yet on eBPF, it might be useful as a demuxer in combination with
helpers like bpf_clone_redirect(), toy example:
__section("cls-lb") int ingress_main(struct __sk_buff *skb)
{
unsigned int which = 3 + (skb->hash & 7);
/* bpf_skb_store_bytes(skb, ...); */
/* bpf_l{3,4}_csum_replace(skb, ...); */
bpf_clone_redirect(skb, which, 0);
return -1;
}
I was thinking whether to add skb_get_hash(), but then concluded the
raw skb->hash seems fine in this case: we can directly access the hash
w/o extra eBPF helper function call, it's filled out by many NICs on
ingress, and in case the entropy level would not be sufficient, people
can still implement their own specific sw fallback hash mix anyway.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-01 05:46:29 +07:00
|
|
|
__u32 hash;
|
2015-09-16 13:05:42 +07:00
|
|
|
__u32 tc_classid;
|
2016-05-06 09:49:10 +07:00
|
|
|
__u32 data;
|
|
|
|
__u32 data_end;
|
2017-04-20 04:01:17 +07:00
|
|
|
__u32 napi_id;
|
2017-08-16 12:33:09 +07:00
|
|
|
|
bpf: add meta pointer for direct access
This work enables generic transfer of metadata from XDP into skb. The
basic idea is that we can make use of the fact that the resulting skb
must be linear and already comes with a larger headroom for supporting
bpf_xdp_adjust_head(), which mangles xdp->data. Here, we base our work
on a similar principle and introduce a small helper bpf_xdp_adjust_meta()
for adjusting a new pointer called xdp->data_meta. Thus, the packet has
a flexible and programmable room for meta data, followed by the actual
packet data. struct xdp_buff is therefore laid out that we first point
to data_hard_start, then data_meta directly prepended to data followed
by data_end marking the end of packet. bpf_xdp_adjust_head() takes into
account whether we have meta data already prepended and if so, memmove()s
this along with the given offset provided there's enough room.
xdp->data_meta is optional and programs are not required to use it. The
rationale is that when we process the packet in XDP (e.g. as DoS filter),
we can push further meta data along with it for the XDP_PASS case, and
give the guarantee that a clsact ingress BPF program on the same device
can pick this up for further post-processing. Since we work with skb
there, we can also set skb->mark, skb->priority or other skb meta data
out of BPF, thus having this scratch space generic and programmable
allows for more flexibility than defining a direct 1:1 transfer of
potentially new XDP members into skb (it's also more efficient as we
don't need to initialize/handle each of such new members). The facility
also works together with GRO aggregation. The scratch space at the head
of the packet can be multiple of 4 byte up to 32 byte large. Drivers not
yet supporting xdp->data_meta can simply be set up with xdp->data_meta
as xdp->data + 1 as bpf_xdp_adjust_meta() will detect this and bail out,
such that the subsequent match against xdp->data for later access is
guaranteed to fail.
The verifier treats xdp->data_meta/xdp->data the same way as we treat
xdp->data/xdp->data_end pointer comparisons. The requirement for doing
the compare against xdp->data is that it hasn't been modified from it's
original address we got from ctx access. It may have a range marking
already from prior successful xdp->data/xdp->data_end pointer comparisons
though.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-09-25 07:25:51 +07:00
|
|
|
/* Accessed by BPF_PROG_TYPE_sk_skb types from here to ... */
|
2017-08-16 12:33:09 +07:00
|
|
|
__u32 family;
|
|
|
|
__u32 remote_ip4; /* Stored in network byte order */
|
|
|
|
__u32 local_ip4; /* Stored in network byte order */
|
|
|
|
__u32 remote_ip6[4]; /* Stored in network byte order */
|
|
|
|
__u32 local_ip6[4]; /* Stored in network byte order */
|
|
|
|
__u32 remote_port; /* Stored in network byte order */
|
|
|
|
__u32 local_port; /* stored in host byte order */
|
bpf: add meta pointer for direct access
This work enables generic transfer of metadata from XDP into skb. The
basic idea is that we can make use of the fact that the resulting skb
must be linear and already comes with a larger headroom for supporting
bpf_xdp_adjust_head(), which mangles xdp->data. Here, we base our work
on a similar principle and introduce a small helper bpf_xdp_adjust_meta()
for adjusting a new pointer called xdp->data_meta. Thus, the packet has
a flexible and programmable room for meta data, followed by the actual
packet data. struct xdp_buff is therefore laid out that we first point
to data_hard_start, then data_meta directly prepended to data followed
by data_end marking the end of packet. bpf_xdp_adjust_head() takes into
account whether we have meta data already prepended and if so, memmove()s
this along with the given offset provided there's enough room.
xdp->data_meta is optional and programs are not required to use it. The
rationale is that when we process the packet in XDP (e.g. as DoS filter),
we can push further meta data along with it for the XDP_PASS case, and
give the guarantee that a clsact ingress BPF program on the same device
can pick this up for further post-processing. Since we work with skb
there, we can also set skb->mark, skb->priority or other skb meta data
out of BPF, thus having this scratch space generic and programmable
allows for more flexibility than defining a direct 1:1 transfer of
potentially new XDP members into skb (it's also more efficient as we
don't need to initialize/handle each of such new members). The facility
also works together with GRO aggregation. The scratch space at the head
of the packet can be multiple of 4 byte up to 32 byte large. Drivers not
yet supporting xdp->data_meta can simply be set up with xdp->data_meta
as xdp->data + 1 as bpf_xdp_adjust_meta() will detect this and bail out,
such that the subsequent match against xdp->data for later access is
guaranteed to fail.
The verifier treats xdp->data_meta/xdp->data the same way as we treat
xdp->data/xdp->data_end pointer comparisons. The requirement for doing
the compare against xdp->data is that it hasn't been modified from it's
original address we got from ctx access. It may have a range marking
already from prior successful xdp->data/xdp->data_end pointer comparisons
though.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-09-25 07:25:51 +07:00
|
|
|
/* ... here. */
|
|
|
|
|
|
|
|
__u32 data_meta;
|
2015-03-14 01:57:42 +07:00
|
|
|
};
|
|
|
|
|
bpf: add helpers to access tunnel metadata
Introduce helpers to let eBPF programs attached to TC manipulate tunnel metadata:
bpf_skb_[gs]et_tunnel_key(skb, key, size, flags)
skb: pointer to skb
key: pointer to 'struct bpf_tunnel_key'
size: size of 'struct bpf_tunnel_key'
flags: room for future extensions
First eBPF program that uses these helpers will allocate per_cpu
metadata_dst structures that will be used on TX.
On RX metadata_dst is allocated by tunnel driver.
Typical usage for TX:
struct bpf_tunnel_key tkey;
... populate tkey ...
bpf_skb_set_tunnel_key(skb, &tkey, sizeof(tkey), 0);
bpf_clone_redirect(skb, vxlan_dev_ifindex, 0);
RX:
struct bpf_tunnel_key tkey = {};
bpf_skb_get_tunnel_key(skb, &tkey, sizeof(tkey), 0);
... lookup or redirect based on tkey ...
'struct bpf_tunnel_key' will be extended in the future by adding
elements to the end and the 'size' argument will indicate which fields
are populated, thereby keeping backwards compatibility.
The 'flags' argument may be used as well when the 'size' is not enough or
to indicate completely different layout of bpf_tunnel_key.
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Acked-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-07-31 05:36:57 +07:00
|
|
|
struct bpf_tunnel_key {
|
|
|
|
__u32 tunnel_id;
|
2016-01-11 07:16:39 +07:00
|
|
|
union {
|
|
|
|
__u32 remote_ipv4;
|
|
|
|
__u32 remote_ipv6[4];
|
|
|
|
};
|
|
|
|
__u8 tunnel_tos;
|
|
|
|
__u8 tunnel_ttl;
|
2016-03-30 05:02:00 +07:00
|
|
|
__u16 tunnel_ext;
|
2016-03-09 09:00:05 +07:00
|
|
|
__u32 tunnel_label;
|
bpf: add helpers to access tunnel metadata
Introduce helpers to let eBPF programs attached to TC manipulate tunnel metadata:
bpf_skb_[gs]et_tunnel_key(skb, key, size, flags)
skb: pointer to skb
key: pointer to 'struct bpf_tunnel_key'
size: size of 'struct bpf_tunnel_key'
flags: room for future extensions
First eBPF program that uses these helpers will allocate per_cpu
metadata_dst structures that will be used on TX.
On RX metadata_dst is allocated by tunnel driver.
Typical usage for TX:
struct bpf_tunnel_key tkey;
... populate tkey ...
bpf_skb_set_tunnel_key(skb, &tkey, sizeof(tkey), 0);
bpf_clone_redirect(skb, vxlan_dev_ifindex, 0);
RX:
struct bpf_tunnel_key tkey = {};
bpf_skb_get_tunnel_key(skb, &tkey, sizeof(tkey), 0);
... lookup or redirect based on tkey ...
'struct bpf_tunnel_key' will be extended in the future by adding
elements to the end and the 'size' argument will indicate which fields
are populated, thereby keeping backwards compatibility.
The 'flags' argument may be used as well when the 'size' is not enough or
to indicate completely different layout of bpf_tunnel_key.
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Acked-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-07-31 05:36:57 +07:00
|
|
|
};
|
|
|
|
|
2018-04-24 21:50:29 +07:00
|
|
|
/* user accessible mirror of in-kernel xfrm_state.
|
|
|
|
* new fields can only be added to the end of this structure
|
|
|
|
*/
|
|
|
|
struct bpf_xfrm_state {
|
|
|
|
__u32 reqid;
|
|
|
|
__u32 spi; /* Stored in network byte order */
|
|
|
|
__u16 family;
|
|
|
|
union {
|
|
|
|
__u32 remote_ipv4; /* Stored in network byte order */
|
|
|
|
__u32 remote_ipv6[4]; /* Stored in network byte order */
|
|
|
|
};
|
|
|
|
};
|
|
|
|
|
2016-11-30 23:10:10 +07:00
|
|
|
/* Generic BPF return codes which all BPF program types may support.
|
|
|
|
* The values are binary compatible with their TC_ACT_* counter-part to
|
|
|
|
* provide backwards compatibility with existing SCHED_CLS and SCHED_ACT
|
|
|
|
* programs.
|
|
|
|
*
|
|
|
|
* XDP is handled seprately, see XDP_*.
|
|
|
|
*/
|
|
|
|
enum bpf_ret_code {
|
|
|
|
BPF_OK = 0,
|
|
|
|
/* 1 reserved */
|
|
|
|
BPF_DROP = 2,
|
|
|
|
/* 3-6 reserved */
|
|
|
|
BPF_REDIRECT = 7,
|
|
|
|
/* >127 are reserved for prog type specific return codes */
|
|
|
|
};
|
|
|
|
|
2016-12-01 23:48:04 +07:00
|
|
|
struct bpf_sock {
|
|
|
|
__u32 bound_dev_if;
|
2016-12-01 23:48:06 +07:00
|
|
|
__u32 family;
|
|
|
|
__u32 type;
|
|
|
|
__u32 protocol;
|
2017-09-01 05:05:44 +07:00
|
|
|
__u32 mark;
|
|
|
|
__u32 priority;
|
2018-03-31 05:08:07 +07:00
|
|
|
__u32 src_ip4; /* Allows 1,2,4-byte read.
|
|
|
|
* Stored in network byte order.
|
|
|
|
*/
|
|
|
|
__u32 src_ip6[4]; /* Allows 1,2,4-byte read.
|
|
|
|
* Stored in network byte order.
|
|
|
|
*/
|
|
|
|
__u32 src_port; /* Allows 4-byte read.
|
|
|
|
* Stored in host byte order
|
|
|
|
*/
|
2016-12-01 23:48:04 +07:00
|
|
|
};
|
|
|
|
|
2016-12-08 06:53:11 +07:00
|
|
|
#define XDP_PACKET_HEADROOM 256
|
|
|
|
|
2016-07-20 02:16:47 +07:00
|
|
|
/* User return codes for XDP prog type.
|
|
|
|
* A valid XDP program must return one of these defined values. All other
|
2017-09-09 06:40:35 +07:00
|
|
|
* return codes are reserved for future use. Unknown return codes will
|
|
|
|
* result in packet drops and a warning via bpf_warn_invalid_xdp_action().
|
2016-07-20 02:16:47 +07:00
|
|
|
*/
|
|
|
|
enum xdp_action {
|
|
|
|
XDP_ABORTED = 0,
|
|
|
|
XDP_DROP,
|
|
|
|
XDP_PASS,
|
2016-07-20 02:16:53 +07:00
|
|
|
XDP_TX,
|
2017-07-17 23:27:07 +07:00
|
|
|
XDP_REDIRECT,
|
2016-07-20 02:16:47 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
/* user accessible metadata for XDP packet hook
|
|
|
|
* new fields must be added to the end of this structure
|
|
|
|
*/
|
|
|
|
struct xdp_md {
|
|
|
|
__u32 data;
|
|
|
|
__u32 data_end;
|
bpf: add meta pointer for direct access
This work enables generic transfer of metadata from XDP into skb. The
basic idea is that we can make use of the fact that the resulting skb
must be linear and already comes with a larger headroom for supporting
bpf_xdp_adjust_head(), which mangles xdp->data. Here, we base our work
on a similar principle and introduce a small helper bpf_xdp_adjust_meta()
for adjusting a new pointer called xdp->data_meta. Thus, the packet has
a flexible and programmable room for meta data, followed by the actual
packet data. struct xdp_buff is therefore laid out that we first point
to data_hard_start, then data_meta directly prepended to data followed
by data_end marking the end of packet. bpf_xdp_adjust_head() takes into
account whether we have meta data already prepended and if so, memmove()s
this along with the given offset provided there's enough room.
xdp->data_meta is optional and programs are not required to use it. The
rationale is that when we process the packet in XDP (e.g. as DoS filter),
we can push further meta data along with it for the XDP_PASS case, and
give the guarantee that a clsact ingress BPF program on the same device
can pick this up for further post-processing. Since we work with skb
there, we can also set skb->mark, skb->priority or other skb meta data
out of BPF, thus having this scratch space generic and programmable
allows for more flexibility than defining a direct 1:1 transfer of
potentially new XDP members into skb (it's also more efficient as we
don't need to initialize/handle each of such new members). The facility
also works together with GRO aggregation. The scratch space at the head
of the packet can be multiple of 4 byte up to 32 byte large. Drivers not
yet supporting xdp->data_meta can simply be set up with xdp->data_meta
as xdp->data + 1 as bpf_xdp_adjust_meta() will detect this and bail out,
such that the subsequent match against xdp->data for later access is
guaranteed to fail.
The verifier treats xdp->data_meta/xdp->data the same way as we treat
xdp->data/xdp->data_end pointer comparisons. The requirement for doing
the compare against xdp->data is that it hasn't been modified from it's
original address we got from ctx access. It may have a range marking
already from prior successful xdp->data/xdp->data_end pointer comparisons
though.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-09-25 07:25:51 +07:00
|
|
|
__u32 data_meta;
|
2018-01-11 23:39:09 +07:00
|
|
|
/* Below access go through struct xdp_rxq_info */
|
2018-01-03 17:26:14 +07:00
|
|
|
__u32 ingress_ifindex; /* rxq->dev->ifindex */
|
|
|
|
__u32 rx_queue_index; /* rxq->queue_index */
|
2016-07-20 02:16:47 +07:00
|
|
|
};
|
|
|
|
|
2017-08-16 12:32:47 +07:00
|
|
|
enum sk_action {
|
2017-10-27 23:45:53 +07:00
|
|
|
SK_DROP = 0,
|
|
|
|
SK_PASS,
|
2017-08-16 12:32:47 +07:00
|
|
|
};
|
|
|
|
|
bpf: create tcp_bpf_ulp allowing BPF to monitor socket TX/RX data
This implements a BPF ULP layer to allow policy enforcement and
monitoring at the socket layer. In order to support this a new
program type BPF_PROG_TYPE_SK_MSG is used to run the policy at
the sendmsg/sendpage hook. To attach the policy to sockets a
sockmap is used with a new program attach type BPF_SK_MSG_VERDICT.
Similar to previous sockmap usages when a sock is added to a
sockmap, via a map update, if the map contains a BPF_SK_MSG_VERDICT
program type attached then the BPF ULP layer is created on the
socket and the attached BPF_PROG_TYPE_SK_MSG program is run for
every msg in sendmsg case and page/offset in sendpage case.
BPF_PROG_TYPE_SK_MSG Semantics/API:
BPF_PROG_TYPE_SK_MSG supports only two return codes SK_PASS and
SK_DROP. Returning SK_DROP free's the copied data in the sendmsg
case and in the sendpage case leaves the data untouched. Both cases
return -EACESS to the user. Returning SK_PASS will allow the msg to
be sent.
In the sendmsg case data is copied into kernel space buffers before
running the BPF program. The kernel space buffers are stored in a
scatterlist object where each element is a kernel memory buffer.
Some effort is made to coalesce data from the sendmsg call here.
For example a sendmsg call with many one byte iov entries will
likely be pushed into a single entry. The BPF program is run with
data pointers (start/end) pointing to the first sg element.
In the sendpage case data is not copied. We opt not to copy the
data by default here, because the BPF infrastructure does not
know what bytes will be needed nor when they will be needed. So
copying all bytes may be wasteful. Because of this the initial
start/end data pointers are (0,0). Meaning no data can be read or
written. This avoids reading data that may be modified by the
user. A new helper is added later in this series if reading and
writing the data is needed. The helper call will do a copy by
default so that the page is exclusively owned by the BPF call.
The verdict from the BPF_PROG_TYPE_SK_MSG applies to the entire msg
in the sendmsg() case and the entire page/offset in the sendpage case.
This avoids ambiguity on how to handle mixed return codes in the
sendmsg case. Again a helper is added later in the series if
a verdict needs to apply to multiple system calls and/or only
a subpart of the currently being processed message.
The helper msg_redirect_map() can be used to select the socket to
send the data on. This is used similar to existing redirect use
cases. This allows policy to redirect msgs.
Pseudo code simple example:
The basic logic to attach a program to a socket is as follows,
// load the programs
bpf_prog_load(SOCKMAP_TCP_MSG_PROG, BPF_PROG_TYPE_SK_MSG,
&obj, &msg_prog);
// lookup the sockmap
bpf_map_msg = bpf_object__find_map_by_name(obj, "my_sock_map");
// get fd for sockmap
map_fd_msg = bpf_map__fd(bpf_map_msg);
// attach program to sockmap
bpf_prog_attach(msg_prog, map_fd_msg, BPF_SK_MSG_VERDICT, 0);
Adding sockets to the map is done in the normal way,
// Add a socket 'fd' to sockmap at location 'i'
bpf_map_update_elem(map_fd_msg, &i, fd, BPF_ANY);
After the above any socket attached to "my_sock_map", in this case
'fd', will run the BPF msg verdict program (msg_prog) on every
sendmsg and sendpage system call.
For a complete example see BPF selftests or sockmap samples.
Implementation notes:
It seemed the simplest, to me at least, to use a refcnt to ensure
psock is not lost across the sendmsg copy into the sg, the bpf program
running on the data in sg_data, and the final pass to the TCP stack.
Some performance testing may show a better method to do this and avoid
the refcnt cost, but for now use the simpler method.
Another item that will come after basic support is in place is
supporting MSG_MORE flag. At the moment we call sendpages even if
the MSG_MORE flag is set. An enhancement would be to collect the
pages into a larger scatterlist and pass down the stack. Notice that
bpf_tcp_sendmsg() could support this with some additional state saved
across sendmsg calls. I built the code to support this without having
to do refactoring work. Other features TBD include ZEROCOPY and the
TCP_RECV_QUEUE/TCP_NO_QUEUE support. This will follow initial series
shortly.
Future work could improve size limits on the scatterlist rings used
here. Currently, we use MAX_SKB_FRAGS simply because this was being
used already in the TLS case. Future work could extend the kernel sk
APIs to tune this depending on workload. This is a trade-off
between memory usage and throughput performance.
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: David S. Miller <davem@davemloft.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-19 02:57:10 +07:00
|
|
|
/* user accessible metadata for SK_MSG packet hook, new fields must
|
|
|
|
* be added to the end of this structure
|
|
|
|
*/
|
|
|
|
struct sk_msg_md {
|
|
|
|
void *data;
|
|
|
|
void *data_end;
|
|
|
|
};
|
|
|
|
|
2017-06-06 02:15:52 +07:00
|
|
|
#define BPF_TAG_SIZE 8
|
|
|
|
|
|
|
|
struct bpf_prog_info {
|
|
|
|
__u32 type;
|
|
|
|
__u32 id;
|
|
|
|
__u8 tag[BPF_TAG_SIZE];
|
|
|
|
__u32 jited_prog_len;
|
|
|
|
__u32 xlated_prog_len;
|
|
|
|
__aligned_u64 jited_prog_insns;
|
|
|
|
__aligned_u64 xlated_prog_insns;
|
2017-09-28 04:37:52 +07:00
|
|
|
__u64 load_time; /* ns since boottime */
|
|
|
|
__u32 created_by_uid;
|
|
|
|
__u32 nr_map_ids;
|
|
|
|
__aligned_u64 map_ids;
|
2017-10-06 11:52:12 +07:00
|
|
|
char name[BPF_OBJ_NAME_LEN];
|
2017-12-28 09:39:09 +07:00
|
|
|
__u32 ifindex;
|
2018-04-26 00:41:06 +07:00
|
|
|
__u32 gpl_compatible:1;
|
2017-12-28 09:39:09 +07:00
|
|
|
__u64 netns_dev;
|
|
|
|
__u64 netns_ino;
|
2017-06-06 02:15:52 +07:00
|
|
|
} __attribute__((aligned(8)));
|
|
|
|
|
|
|
|
struct bpf_map_info {
|
|
|
|
__u32 type;
|
|
|
|
__u32 id;
|
|
|
|
__u32 key_size;
|
|
|
|
__u32 value_size;
|
|
|
|
__u32 max_entries;
|
|
|
|
__u32 map_flags;
|
2017-10-06 11:52:12 +07:00
|
|
|
char name[BPF_OBJ_NAME_LEN];
|
2018-01-18 10:13:28 +07:00
|
|
|
__u32 ifindex;
|
|
|
|
__u64 netns_dev;
|
|
|
|
__u64 netns_ino;
|
2017-06-06 02:15:52 +07:00
|
|
|
} __attribute__((aligned(8)));
|
|
|
|
|
2018-03-31 05:08:02 +07:00
|
|
|
/* User bpf_sock_addr struct to access socket fields and sockaddr struct passed
|
|
|
|
* by user and intended to be used by socket (e.g. to bind to, depends on
|
|
|
|
* attach attach type).
|
|
|
|
*/
|
|
|
|
struct bpf_sock_addr {
|
|
|
|
__u32 user_family; /* Allows 4-byte read, but no write. */
|
|
|
|
__u32 user_ip4; /* Allows 1,2,4-byte read and 4-byte write.
|
|
|
|
* Stored in network byte order.
|
|
|
|
*/
|
|
|
|
__u32 user_ip6[4]; /* Allows 1,2,4-byte read an 4-byte write.
|
|
|
|
* Stored in network byte order.
|
|
|
|
*/
|
|
|
|
__u32 user_port; /* Allows 4-byte read and write.
|
|
|
|
* Stored in network byte order
|
|
|
|
*/
|
|
|
|
__u32 family; /* Allows 4-byte read, but no write */
|
|
|
|
__u32 type; /* Allows 4-byte read, but no write */
|
|
|
|
__u32 protocol; /* Allows 4-byte read, but no write */
|
|
|
|
};
|
|
|
|
|
bpf: BPF support for sock_ops
Created a new BPF program type, BPF_PROG_TYPE_SOCK_OPS, and a corresponding
struct that allows BPF programs of this type to access some of the
socket's fields (such as IP addresses, ports, etc.). It uses the
existing bpf cgroups infrastructure so the programs can be attached per
cgroup with full inheritance support. The program will be called at
appropriate times to set relevant connections parameters such as buffer
sizes, SYN and SYN-ACK RTOs, etc., based on connection information such
as IP addresses, port numbers, etc.
Alghough there are already 3 mechanisms to set parameters (sysctls,
route metrics and setsockopts), this new mechanism provides some
distinct advantages. Unlike sysctls, it can set parameters per
connection. In contrast to route metrics, it can also use port numbers
and information provided by a user level program. In addition, it could
set parameters probabilistically for evaluation purposes (i.e. do
something different on 10% of the flows and compare results with the
other 90% of the flows). Also, in cases where IPv6 addresses contain
geographic information, the rules to make changes based on the distance
(or RTT) between the hosts are much easier than route metric rules and
can be global. Finally, unlike setsockopt, it oes not require
application changes and it can be updated easily at any time.
Although the bpf cgroup framework already contains a sock related
program type (BPF_PROG_TYPE_CGROUP_SOCK), I created the new type
(BPF_PROG_TYPE_SOCK_OPS) beccause the existing type expects to be called
only once during the connections's lifetime. In contrast, the new
program type will be called multiple times from different places in the
network stack code. For example, before sending SYN and SYN-ACKs to set
an appropriate timeout, when the connection is established to set
congestion control, etc. As a result it has "op" field to specify the
type of operation requested.
The purpose of this new program type is to simplify setting connection
parameters, such as buffer sizes, TCP's SYN RTO, etc. For example, it is
easy to use facebook's internal IPv6 addresses to determine if both hosts
of a connection are in the same datacenter. Therefore, it is easy to
write a BPF program to choose a small SYN RTO value when both hosts are
in the same datacenter.
This patch only contains the framework to support the new BPF program
type, following patches add the functionality to set various connection
parameters.
This patch defines a new BPF program type: BPF_PROG_TYPE_SOCKET_OPS
and a new bpf syscall command to load a new program of this type:
BPF_PROG_LOAD_SOCKET_OPS.
Two new corresponding structs (one for the kernel one for the user/BPF
program):
/* kernel version */
struct bpf_sock_ops_kern {
struct sock *sk;
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
};
/* user version
* Some fields are in network byte order reflecting the sock struct
* Use the bpf_ntohl helper macro in samples/bpf/bpf_endian.h to
* convert them to host byte order.
*/
struct bpf_sock_ops {
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
__u32 family;
__u32 remote_ip4; /* In network byte order */
__u32 local_ip4; /* In network byte order */
__u32 remote_ip6[4]; /* In network byte order */
__u32 local_ip6[4]; /* In network byte order */
__u32 remote_port; /* In network byte order */
__u32 local_port; /* In host byte horder */
};
Currently there are two types of ops. The first type expects the BPF
program to return a value which is then used by the caller (or a
negative value to indicate the operation is not supported). The second
type expects state changes to be done by the BPF program, for example
through a setsockopt BPF helper function, and they ignore the return
value.
The reply fields of the bpf_sockt_ops struct are there in case a bpf
program needs to return a value larger than an integer.
Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-01 10:02:40 +07:00
|
|
|
/* User bpf_sock_ops struct to access socket values and specify request ops
|
|
|
|
* and their replies.
|
|
|
|
* Some of this fields are in network (bigendian) byte order and may need
|
|
|
|
* to be converted before use (bpf_ntohl() defined in samples/bpf/bpf_endian.h).
|
|
|
|
* New fields can only be added at the end of this structure
|
|
|
|
*/
|
|
|
|
struct bpf_sock_ops {
|
|
|
|
__u32 op;
|
|
|
|
union {
|
2018-01-26 07:14:09 +07:00
|
|
|
__u32 args[4]; /* Optionally passed to bpf program */
|
|
|
|
__u32 reply; /* Returned by bpf program */
|
|
|
|
__u32 replylong[4]; /* Optionally returned by bpf prog */
|
bpf: BPF support for sock_ops
Created a new BPF program type, BPF_PROG_TYPE_SOCK_OPS, and a corresponding
struct that allows BPF programs of this type to access some of the
socket's fields (such as IP addresses, ports, etc.). It uses the
existing bpf cgroups infrastructure so the programs can be attached per
cgroup with full inheritance support. The program will be called at
appropriate times to set relevant connections parameters such as buffer
sizes, SYN and SYN-ACK RTOs, etc., based on connection information such
as IP addresses, port numbers, etc.
Alghough there are already 3 mechanisms to set parameters (sysctls,
route metrics and setsockopts), this new mechanism provides some
distinct advantages. Unlike sysctls, it can set parameters per
connection. In contrast to route metrics, it can also use port numbers
and information provided by a user level program. In addition, it could
set parameters probabilistically for evaluation purposes (i.e. do
something different on 10% of the flows and compare results with the
other 90% of the flows). Also, in cases where IPv6 addresses contain
geographic information, the rules to make changes based on the distance
(or RTT) between the hosts are much easier than route metric rules and
can be global. Finally, unlike setsockopt, it oes not require
application changes and it can be updated easily at any time.
Although the bpf cgroup framework already contains a sock related
program type (BPF_PROG_TYPE_CGROUP_SOCK), I created the new type
(BPF_PROG_TYPE_SOCK_OPS) beccause the existing type expects to be called
only once during the connections's lifetime. In contrast, the new
program type will be called multiple times from different places in the
network stack code. For example, before sending SYN and SYN-ACKs to set
an appropriate timeout, when the connection is established to set
congestion control, etc. As a result it has "op" field to specify the
type of operation requested.
The purpose of this new program type is to simplify setting connection
parameters, such as buffer sizes, TCP's SYN RTO, etc. For example, it is
easy to use facebook's internal IPv6 addresses to determine if both hosts
of a connection are in the same datacenter. Therefore, it is easy to
write a BPF program to choose a small SYN RTO value when both hosts are
in the same datacenter.
This patch only contains the framework to support the new BPF program
type, following patches add the functionality to set various connection
parameters.
This patch defines a new BPF program type: BPF_PROG_TYPE_SOCKET_OPS
and a new bpf syscall command to load a new program of this type:
BPF_PROG_LOAD_SOCKET_OPS.
Two new corresponding structs (one for the kernel one for the user/BPF
program):
/* kernel version */
struct bpf_sock_ops_kern {
struct sock *sk;
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
};
/* user version
* Some fields are in network byte order reflecting the sock struct
* Use the bpf_ntohl helper macro in samples/bpf/bpf_endian.h to
* convert them to host byte order.
*/
struct bpf_sock_ops {
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
__u32 family;
__u32 remote_ip4; /* In network byte order */
__u32 local_ip4; /* In network byte order */
__u32 remote_ip6[4]; /* In network byte order */
__u32 local_ip6[4]; /* In network byte order */
__u32 remote_port; /* In network byte order */
__u32 local_port; /* In host byte horder */
};
Currently there are two types of ops. The first type expects the BPF
program to return a value which is then used by the caller (or a
negative value to indicate the operation is not supported). The second
type expects state changes to be done by the BPF program, for example
through a setsockopt BPF helper function, and they ignore the return
value.
The reply fields of the bpf_sockt_ops struct are there in case a bpf
program needs to return a value larger than an integer.
Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-01 10:02:40 +07:00
|
|
|
};
|
|
|
|
__u32 family;
|
|
|
|
__u32 remote_ip4; /* Stored in network byte order */
|
|
|
|
__u32 local_ip4; /* Stored in network byte order */
|
|
|
|
__u32 remote_ip6[4]; /* Stored in network byte order */
|
|
|
|
__u32 local_ip6[4]; /* Stored in network byte order */
|
|
|
|
__u32 remote_port; /* Stored in network byte order */
|
|
|
|
__u32 local_port; /* stored in host byte order */
|
2017-12-02 01:15:04 +07:00
|
|
|
__u32 is_fullsock; /* Some TCP fields are only valid if
|
|
|
|
* there is a full socket. If not, the
|
|
|
|
* fields read as zero.
|
|
|
|
*/
|
|
|
|
__u32 snd_cwnd;
|
|
|
|
__u32 srtt_us; /* Averaged RTT << 3 in usecs */
|
2018-01-26 07:14:10 +07:00
|
|
|
__u32 bpf_sock_ops_cb_flags; /* flags defined in uapi/linux/tcp.h */
|
2018-01-26 07:14:12 +07:00
|
|
|
__u32 state;
|
|
|
|
__u32 rtt_min;
|
|
|
|
__u32 snd_ssthresh;
|
|
|
|
__u32 rcv_nxt;
|
|
|
|
__u32 snd_nxt;
|
|
|
|
__u32 snd_una;
|
|
|
|
__u32 mss_cache;
|
|
|
|
__u32 ecn_flags;
|
|
|
|
__u32 rate_delivered;
|
|
|
|
__u32 rate_interval_us;
|
|
|
|
__u32 packets_out;
|
|
|
|
__u32 retrans_out;
|
|
|
|
__u32 total_retrans;
|
|
|
|
__u32 segs_in;
|
|
|
|
__u32 data_segs_in;
|
|
|
|
__u32 segs_out;
|
|
|
|
__u32 data_segs_out;
|
|
|
|
__u32 lost_out;
|
|
|
|
__u32 sacked_out;
|
|
|
|
__u32 sk_txhash;
|
|
|
|
__u64 bytes_received;
|
|
|
|
__u64 bytes_acked;
|
bpf: BPF support for sock_ops
Created a new BPF program type, BPF_PROG_TYPE_SOCK_OPS, and a corresponding
struct that allows BPF programs of this type to access some of the
socket's fields (such as IP addresses, ports, etc.). It uses the
existing bpf cgroups infrastructure so the programs can be attached per
cgroup with full inheritance support. The program will be called at
appropriate times to set relevant connections parameters such as buffer
sizes, SYN and SYN-ACK RTOs, etc., based on connection information such
as IP addresses, port numbers, etc.
Alghough there are already 3 mechanisms to set parameters (sysctls,
route metrics and setsockopts), this new mechanism provides some
distinct advantages. Unlike sysctls, it can set parameters per
connection. In contrast to route metrics, it can also use port numbers
and information provided by a user level program. In addition, it could
set parameters probabilistically for evaluation purposes (i.e. do
something different on 10% of the flows and compare results with the
other 90% of the flows). Also, in cases where IPv6 addresses contain
geographic information, the rules to make changes based on the distance
(or RTT) between the hosts are much easier than route metric rules and
can be global. Finally, unlike setsockopt, it oes not require
application changes and it can be updated easily at any time.
Although the bpf cgroup framework already contains a sock related
program type (BPF_PROG_TYPE_CGROUP_SOCK), I created the new type
(BPF_PROG_TYPE_SOCK_OPS) beccause the existing type expects to be called
only once during the connections's lifetime. In contrast, the new
program type will be called multiple times from different places in the
network stack code. For example, before sending SYN and SYN-ACKs to set
an appropriate timeout, when the connection is established to set
congestion control, etc. As a result it has "op" field to specify the
type of operation requested.
The purpose of this new program type is to simplify setting connection
parameters, such as buffer sizes, TCP's SYN RTO, etc. For example, it is
easy to use facebook's internal IPv6 addresses to determine if both hosts
of a connection are in the same datacenter. Therefore, it is easy to
write a BPF program to choose a small SYN RTO value when both hosts are
in the same datacenter.
This patch only contains the framework to support the new BPF program
type, following patches add the functionality to set various connection
parameters.
This patch defines a new BPF program type: BPF_PROG_TYPE_SOCKET_OPS
and a new bpf syscall command to load a new program of this type:
BPF_PROG_LOAD_SOCKET_OPS.
Two new corresponding structs (one for the kernel one for the user/BPF
program):
/* kernel version */
struct bpf_sock_ops_kern {
struct sock *sk;
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
};
/* user version
* Some fields are in network byte order reflecting the sock struct
* Use the bpf_ntohl helper macro in samples/bpf/bpf_endian.h to
* convert them to host byte order.
*/
struct bpf_sock_ops {
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
__u32 family;
__u32 remote_ip4; /* In network byte order */
__u32 local_ip4; /* In network byte order */
__u32 remote_ip6[4]; /* In network byte order */
__u32 local_ip6[4]; /* In network byte order */
__u32 remote_port; /* In network byte order */
__u32 local_port; /* In host byte horder */
};
Currently there are two types of ops. The first type expects the BPF
program to return a value which is then used by the caller (or a
negative value to indicate the operation is not supported). The second
type expects state changes to be done by the BPF program, for example
through a setsockopt BPF helper function, and they ignore the return
value.
The reply fields of the bpf_sockt_ops struct are there in case a bpf
program needs to return a value larger than an integer.
Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-01 10:02:40 +07:00
|
|
|
};
|
|
|
|
|
2018-01-26 07:14:10 +07:00
|
|
|
/* Definitions for bpf_sock_ops_cb_flags */
|
2018-01-26 07:14:11 +07:00
|
|
|
#define BPF_SOCK_OPS_RTO_CB_FLAG (1<<0)
|
2018-01-26 07:14:14 +07:00
|
|
|
#define BPF_SOCK_OPS_RETRANS_CB_FLAG (1<<1)
|
2018-01-26 07:14:15 +07:00
|
|
|
#define BPF_SOCK_OPS_STATE_CB_FLAG (1<<2)
|
|
|
|
#define BPF_SOCK_OPS_ALL_CB_FLAGS 0x7 /* Mask of all currently
|
2018-01-26 07:14:10 +07:00
|
|
|
* supported cb flags
|
|
|
|
*/
|
|
|
|
|
bpf: BPF support for sock_ops
Created a new BPF program type, BPF_PROG_TYPE_SOCK_OPS, and a corresponding
struct that allows BPF programs of this type to access some of the
socket's fields (such as IP addresses, ports, etc.). It uses the
existing bpf cgroups infrastructure so the programs can be attached per
cgroup with full inheritance support. The program will be called at
appropriate times to set relevant connections parameters such as buffer
sizes, SYN and SYN-ACK RTOs, etc., based on connection information such
as IP addresses, port numbers, etc.
Alghough there are already 3 mechanisms to set parameters (sysctls,
route metrics and setsockopts), this new mechanism provides some
distinct advantages. Unlike sysctls, it can set parameters per
connection. In contrast to route metrics, it can also use port numbers
and information provided by a user level program. In addition, it could
set parameters probabilistically for evaluation purposes (i.e. do
something different on 10% of the flows and compare results with the
other 90% of the flows). Also, in cases where IPv6 addresses contain
geographic information, the rules to make changes based on the distance
(or RTT) between the hosts are much easier than route metric rules and
can be global. Finally, unlike setsockopt, it oes not require
application changes and it can be updated easily at any time.
Although the bpf cgroup framework already contains a sock related
program type (BPF_PROG_TYPE_CGROUP_SOCK), I created the new type
(BPF_PROG_TYPE_SOCK_OPS) beccause the existing type expects to be called
only once during the connections's lifetime. In contrast, the new
program type will be called multiple times from different places in the
network stack code. For example, before sending SYN and SYN-ACKs to set
an appropriate timeout, when the connection is established to set
congestion control, etc. As a result it has "op" field to specify the
type of operation requested.
The purpose of this new program type is to simplify setting connection
parameters, such as buffer sizes, TCP's SYN RTO, etc. For example, it is
easy to use facebook's internal IPv6 addresses to determine if both hosts
of a connection are in the same datacenter. Therefore, it is easy to
write a BPF program to choose a small SYN RTO value when both hosts are
in the same datacenter.
This patch only contains the framework to support the new BPF program
type, following patches add the functionality to set various connection
parameters.
This patch defines a new BPF program type: BPF_PROG_TYPE_SOCKET_OPS
and a new bpf syscall command to load a new program of this type:
BPF_PROG_LOAD_SOCKET_OPS.
Two new corresponding structs (one for the kernel one for the user/BPF
program):
/* kernel version */
struct bpf_sock_ops_kern {
struct sock *sk;
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
};
/* user version
* Some fields are in network byte order reflecting the sock struct
* Use the bpf_ntohl helper macro in samples/bpf/bpf_endian.h to
* convert them to host byte order.
*/
struct bpf_sock_ops {
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
__u32 family;
__u32 remote_ip4; /* In network byte order */
__u32 local_ip4; /* In network byte order */
__u32 remote_ip6[4]; /* In network byte order */
__u32 local_ip6[4]; /* In network byte order */
__u32 remote_port; /* In network byte order */
__u32 local_port; /* In host byte horder */
};
Currently there are two types of ops. The first type expects the BPF
program to return a value which is then used by the caller (or a
negative value to indicate the operation is not supported). The second
type expects state changes to be done by the BPF program, for example
through a setsockopt BPF helper function, and they ignore the return
value.
The reply fields of the bpf_sockt_ops struct are there in case a bpf
program needs to return a value larger than an integer.
Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-01 10:02:40 +07:00
|
|
|
/* List of known BPF sock_ops operators.
|
|
|
|
* New entries can only be added at the end
|
|
|
|
*/
|
|
|
|
enum {
|
|
|
|
BPF_SOCK_OPS_VOID,
|
2017-07-01 10:02:42 +07:00
|
|
|
BPF_SOCK_OPS_TIMEOUT_INIT, /* Should return SYN-RTO value to use or
|
|
|
|
* -1 if default value should be used
|
|
|
|
*/
|
2017-07-01 10:02:44 +07:00
|
|
|
BPF_SOCK_OPS_RWND_INIT, /* Should return initial advertized
|
|
|
|
* window (in packets) or -1 if default
|
|
|
|
* value should be used
|
|
|
|
*/
|
2017-07-01 10:02:47 +07:00
|
|
|
BPF_SOCK_OPS_TCP_CONNECT_CB, /* Calls BPF program right before an
|
|
|
|
* active connection is initialized
|
|
|
|
*/
|
|
|
|
BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB, /* Calls BPF program when an
|
|
|
|
* active connection is
|
|
|
|
* established
|
|
|
|
*/
|
|
|
|
BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB, /* Calls BPF program when a
|
|
|
|
* passive connection is
|
|
|
|
* established
|
|
|
|
*/
|
2017-07-01 10:02:49 +07:00
|
|
|
BPF_SOCK_OPS_NEEDS_ECN, /* If connection's congestion control
|
|
|
|
* needs ECN
|
|
|
|
*/
|
bpf: add support for BPF_SOCK_OPS_BASE_RTT
A congestion control algorithm can make a call to the BPF socket_ops
program to request the base RTT. The base RTT can be congestion control
dependent and is meant to represent a congestion threshold such that
RTTs above it indicate congestion. This is especially useful for flows
within a DC where the base RTT is easy to obtain.
Being provided a base RTT solves a basic problem in RTT based congestion
avoidance algorithms (such as Vegas, NV and BBR). Although it is easy
to get the base RTT when the network is not congested, it is very
diffcult to do when it is very congested. Newer connections get an
inflated value of the base RTT leading to unfariness (newer flows with a
larger base RTT get more bandwidth). As a result, RTT based congestion
avoidance algorithms tend to update their base RTTs to improve fairness.
In very congested networks this can lead to base RTT inflation, reducing
the ability of these RTT based congestion control algorithms to prevent
congestion.
Note that in my experiments with TCP-NV, the base RTT provided can be
much larger than the actual hardware RTT. For example, experimenting
with hosts within a rack where the hardware RTT is 16-20us, I've used
base RTTs up to 150us. The effect of using a larger base RTT is that the
congestion avoidance algorithm will allow more queueing. When there are
only a few flows the main effect is larger measured RTTs and RPC
latencies due to the increased queueing. When there are a lot of flows,
a larger base RTT can lead to more congestion and more packet drops.
For this case, where the hardware RTT is 20us, a base RTT of 80us
produces good results.
This patch only introduces BPF_SOCK_OPS_BASE_RTT, a later patch in this
set adds support for using it in TCP-NV. Further study and testing is
needed before support can be added to other delay based congestion
avoidance algorithms.
Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
Acked-by: Alexei Starovoitov <ast@fb.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-21 01:05:39 +07:00
|
|
|
BPF_SOCK_OPS_BASE_RTT, /* Get base RTT. The correct value is
|
|
|
|
* based on the path and may be
|
|
|
|
* dependent on the congestion control
|
|
|
|
* algorithm. In general it indicates
|
|
|
|
* a congestion threshold. RTTs above
|
|
|
|
* this indicate congestion
|
|
|
|
*/
|
2018-01-26 07:14:11 +07:00
|
|
|
BPF_SOCK_OPS_RTO_CB, /* Called when an RTO has triggered.
|
|
|
|
* Arg1: value of icsk_retransmits
|
|
|
|
* Arg2: value of icsk_rto
|
|
|
|
* Arg3: whether RTO has expired
|
|
|
|
*/
|
2018-01-26 07:14:14 +07:00
|
|
|
BPF_SOCK_OPS_RETRANS_CB, /* Called when skb is retransmitted.
|
|
|
|
* Arg1: sequence number of 1st byte
|
|
|
|
* Arg2: # segments
|
|
|
|
* Arg3: return value of
|
|
|
|
* tcp_transmit_skb (0 => success)
|
|
|
|
*/
|
2018-01-26 07:14:15 +07:00
|
|
|
BPF_SOCK_OPS_STATE_CB, /* Called when TCP changes state.
|
|
|
|
* Arg1: old_state
|
|
|
|
* Arg2: new_state
|
|
|
|
*/
|
|
|
|
};
|
|
|
|
|
|
|
|
/* List of TCP states. There is a build check in net/ipv4/tcp.c to detect
|
|
|
|
* changes between the TCP and BPF versions. Ideally this should never happen.
|
|
|
|
* If it does, we need to add code to convert them before calling
|
|
|
|
* the BPF sock_ops function.
|
|
|
|
*/
|
|
|
|
enum {
|
|
|
|
BPF_TCP_ESTABLISHED = 1,
|
|
|
|
BPF_TCP_SYN_SENT,
|
|
|
|
BPF_TCP_SYN_RECV,
|
|
|
|
BPF_TCP_FIN_WAIT1,
|
|
|
|
BPF_TCP_FIN_WAIT2,
|
|
|
|
BPF_TCP_TIME_WAIT,
|
|
|
|
BPF_TCP_CLOSE,
|
|
|
|
BPF_TCP_CLOSE_WAIT,
|
|
|
|
BPF_TCP_LAST_ACK,
|
|
|
|
BPF_TCP_LISTEN,
|
|
|
|
BPF_TCP_CLOSING, /* Now a valid state */
|
|
|
|
BPF_TCP_NEW_SYN_RECV,
|
|
|
|
|
|
|
|
BPF_TCP_MAX_STATES /* Leave at the end! */
|
bpf: BPF support for sock_ops
Created a new BPF program type, BPF_PROG_TYPE_SOCK_OPS, and a corresponding
struct that allows BPF programs of this type to access some of the
socket's fields (such as IP addresses, ports, etc.). It uses the
existing bpf cgroups infrastructure so the programs can be attached per
cgroup with full inheritance support. The program will be called at
appropriate times to set relevant connections parameters such as buffer
sizes, SYN and SYN-ACK RTOs, etc., based on connection information such
as IP addresses, port numbers, etc.
Alghough there are already 3 mechanisms to set parameters (sysctls,
route metrics and setsockopts), this new mechanism provides some
distinct advantages. Unlike sysctls, it can set parameters per
connection. In contrast to route metrics, it can also use port numbers
and information provided by a user level program. In addition, it could
set parameters probabilistically for evaluation purposes (i.e. do
something different on 10% of the flows and compare results with the
other 90% of the flows). Also, in cases where IPv6 addresses contain
geographic information, the rules to make changes based on the distance
(or RTT) between the hosts are much easier than route metric rules and
can be global. Finally, unlike setsockopt, it oes not require
application changes and it can be updated easily at any time.
Although the bpf cgroup framework already contains a sock related
program type (BPF_PROG_TYPE_CGROUP_SOCK), I created the new type
(BPF_PROG_TYPE_SOCK_OPS) beccause the existing type expects to be called
only once during the connections's lifetime. In contrast, the new
program type will be called multiple times from different places in the
network stack code. For example, before sending SYN and SYN-ACKs to set
an appropriate timeout, when the connection is established to set
congestion control, etc. As a result it has "op" field to specify the
type of operation requested.
The purpose of this new program type is to simplify setting connection
parameters, such as buffer sizes, TCP's SYN RTO, etc. For example, it is
easy to use facebook's internal IPv6 addresses to determine if both hosts
of a connection are in the same datacenter. Therefore, it is easy to
write a BPF program to choose a small SYN RTO value when both hosts are
in the same datacenter.
This patch only contains the framework to support the new BPF program
type, following patches add the functionality to set various connection
parameters.
This patch defines a new BPF program type: BPF_PROG_TYPE_SOCKET_OPS
and a new bpf syscall command to load a new program of this type:
BPF_PROG_LOAD_SOCKET_OPS.
Two new corresponding structs (one for the kernel one for the user/BPF
program):
/* kernel version */
struct bpf_sock_ops_kern {
struct sock *sk;
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
};
/* user version
* Some fields are in network byte order reflecting the sock struct
* Use the bpf_ntohl helper macro in samples/bpf/bpf_endian.h to
* convert them to host byte order.
*/
struct bpf_sock_ops {
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
__u32 family;
__u32 remote_ip4; /* In network byte order */
__u32 local_ip4; /* In network byte order */
__u32 remote_ip6[4]; /* In network byte order */
__u32 local_ip6[4]; /* In network byte order */
__u32 remote_port; /* In network byte order */
__u32 local_port; /* In host byte horder */
};
Currently there are two types of ops. The first type expects the BPF
program to return a value which is then used by the caller (or a
negative value to indicate the operation is not supported). The second
type expects state changes to be done by the BPF program, for example
through a setsockopt BPF helper function, and they ignore the return
value.
The reply fields of the bpf_sockt_ops struct are there in case a bpf
program needs to return a value larger than an integer.
Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-01 10:02:40 +07:00
|
|
|
};
|
|
|
|
|
2017-07-01 10:02:51 +07:00
|
|
|
#define TCP_BPF_IW 1001 /* Set TCP initial congestion window */
|
2017-07-01 10:02:53 +07:00
|
|
|
#define TCP_BPF_SNDCWND_CLAMP 1002 /* Set sndcwnd_clamp */
|
2017-07-01 10:02:51 +07:00
|
|
|
|
2017-10-05 23:19:20 +07:00
|
|
|
struct bpf_perf_event_value {
|
|
|
|
__u64 counter;
|
|
|
|
__u64 enabled;
|
|
|
|
__u64 running;
|
|
|
|
};
|
|
|
|
|
2017-11-05 20:15:32 +07:00
|
|
|
#define BPF_DEVCG_ACC_MKNOD (1ULL << 0)
|
|
|
|
#define BPF_DEVCG_ACC_READ (1ULL << 1)
|
|
|
|
#define BPF_DEVCG_ACC_WRITE (1ULL << 2)
|
|
|
|
|
|
|
|
#define BPF_DEVCG_DEV_BLOCK (1ULL << 0)
|
|
|
|
#define BPF_DEVCG_DEV_CHAR (1ULL << 1)
|
|
|
|
|
|
|
|
struct bpf_cgroup_dev_ctx {
|
2017-12-19 01:13:44 +07:00
|
|
|
/* access_type encoded as (BPF_DEVCG_ACC_* << 16) | BPF_DEVCG_DEV_* */
|
|
|
|
__u32 access_type;
|
2017-11-05 20:15:32 +07:00
|
|
|
__u32 major;
|
|
|
|
__u32 minor;
|
|
|
|
};
|
|
|
|
|
2018-03-29 02:05:37 +07:00
|
|
|
struct bpf_raw_tracepoint_args {
|
|
|
|
__u64 args[0];
|
|
|
|
};
|
|
|
|
|
2014-09-05 12:17:18 +07:00
|
|
|
#endif /* _UAPI__LINUX_BPF_H__ */
|