2014-09-26 15:16:57 +08: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.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful, but
|
|
|
|
* WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* General Public License for more details.
|
|
|
|
*/
|
|
|
|
#include <linux/bpf.h>
|
bpf: add initial bpf tracepoints
This work adds a number of tracepoints to paths that are either
considered slow-path or exception-like states, where monitoring or
inspecting them would be desirable.
For bpf(2) syscall, tracepoints have been placed for main commands
when they succeed. In XDP case, tracepoint is for exceptions, that
is, f.e. on abnormal BPF program exit such as unknown or XDP_ABORTED
return code, or when error occurs during XDP_TX action and the packet
could not be forwarded.
Both have been split into separate event headers, and can be further
extended. Worst case, if they unexpectedly should get into our way in
future, they can also removed [1]. Of course, these tracepoints (like
any other) can be analyzed by eBPF itself, etc. Example output:
# ./perf record -a -e bpf:* sleep 10
# ./perf script
sock_example 6197 [005] 283.980322: bpf:bpf_map_create: map type=ARRAY ufd=4 key=4 val=8 max=256 flags=0
sock_example 6197 [005] 283.980721: bpf:bpf_prog_load: prog=a5ea8fa30ea6849c type=SOCKET_FILTER ufd=5
sock_example 6197 [005] 283.988423: bpf:bpf_prog_get_type: prog=a5ea8fa30ea6849c type=SOCKET_FILTER
sock_example 6197 [005] 283.988443: bpf:bpf_map_lookup_elem: map type=ARRAY ufd=4 key=[06 00 00 00] val=[00 00 00 00 00 00 00 00]
[...]
sock_example 6197 [005] 288.990868: bpf:bpf_map_lookup_elem: map type=ARRAY ufd=4 key=[01 00 00 00] val=[14 00 00 00 00 00 00 00]
swapper 0 [005] 289.338243: bpf:bpf_prog_put_rcu: prog=a5ea8fa30ea6849c type=SOCKET_FILTER
[1] https://lwn.net/Articles/705270/
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-01-25 09:28:18 +08:00
|
|
|
#include <linux/bpf_trace.h>
|
2018-05-27 19:24:09 +08:00
|
|
|
#include <linux/bpf_lirc.h>
|
2018-04-19 06:56:01 +08:00
|
|
|
#include <linux/btf.h>
|
2014-09-26 15:16:57 +08:00
|
|
|
#include <linux/syscalls.h>
|
|
|
|
#include <linux/slab.h>
|
2017-02-09 01:51:30 +08:00
|
|
|
#include <linux/sched/signal.h>
|
bpf: don't trigger OOM killer under pressure with map alloc
This patch adds two helpers, bpf_map_area_alloc() and bpf_map_area_free(),
that are to be used for map allocations. Using kmalloc() for very large
allocations can cause excessive work within the page allocator, so i) fall
back earlier to vmalloc() when the attempt is considered costly anyway,
and even more importantly ii) don't trigger OOM killer with any of the
allocators.
Since this is based on a user space request, for example, when creating
maps with element pre-allocation, we really want such requests to fail
instead of killing other user space processes.
Also, don't spam the kernel log with warnings should any of the allocations
fail under pressure. Given that, we can make backend selection in
bpf_map_area_alloc() generic, and convert all maps over to use this API
for spots with potentially large allocation requests.
Note, replacing the one kmalloc_array() is fine as overflow checks happen
earlier in htab_map_alloc(), since it must also protect the multiplication
for vmalloc() should kmalloc_array() fail.
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-01-18 22:14:17 +08:00
|
|
|
#include <linux/vmalloc.h>
|
|
|
|
#include <linux/mmzone.h>
|
2014-09-26 15:16:57 +08:00
|
|
|
#include <linux/anon_inodes.h>
|
bpf: introduce bpf subcommand BPF_TASK_FD_QUERY
Currently, suppose a userspace application has loaded a bpf program
and attached it to a tracepoint/kprobe/uprobe, and a bpf
introspection tool, e.g., bpftool, wants to show which bpf program
is attached to which tracepoint/kprobe/uprobe. Such attachment
information will be really useful to understand the overall bpf
deployment in the system.
There is a name field (16 bytes) for each program, which could
be used to encode the attachment point. There are some drawbacks
for this approaches. First, bpftool user (e.g., an admin) may not
really understand the association between the name and the
attachment point. Second, if one program is attached to multiple
places, encoding a proper name which can imply all these
attachments becomes difficult.
This patch introduces a new bpf subcommand BPF_TASK_FD_QUERY.
Given a pid and fd, if the <pid, fd> is associated with a
tracepoint/kprobe/uprobe perf event, BPF_TASK_FD_QUERY will return
. prog_id
. tracepoint name, or
. k[ret]probe funcname + offset or kernel addr, or
. u[ret]probe filename + offset
to the userspace.
The user can use "bpftool prog" to find more information about
bpf program itself with prog_id.
Acked-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-05-25 02:21:09 +08:00
|
|
|
#include <linux/fdtable.h>
|
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 15:16:59 +08:00
|
|
|
#include <linux/file.h>
|
bpf: introduce bpf subcommand BPF_TASK_FD_QUERY
Currently, suppose a userspace application has loaded a bpf program
and attached it to a tracepoint/kprobe/uprobe, and a bpf
introspection tool, e.g., bpftool, wants to show which bpf program
is attached to which tracepoint/kprobe/uprobe. Such attachment
information will be really useful to understand the overall bpf
deployment in the system.
There is a name field (16 bytes) for each program, which could
be used to encode the attachment point. There are some drawbacks
for this approaches. First, bpftool user (e.g., an admin) may not
really understand the association between the name and the
attachment point. Second, if one program is attached to multiple
places, encoding a proper name which can imply all these
attachments becomes difficult.
This patch introduces a new bpf subcommand BPF_TASK_FD_QUERY.
Given a pid and fd, if the <pid, fd> is associated with a
tracepoint/kprobe/uprobe perf event, BPF_TASK_FD_QUERY will return
. prog_id
. tracepoint name, or
. k[ret]probe funcname + offset or kernel addr, or
. u[ret]probe filename + offset
to the userspace.
The user can use "bpftool prog" to find more information about
bpf program itself with prog_id.
Acked-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-05-25 02:21:09 +08:00
|
|
|
#include <linux/fs.h>
|
2014-09-26 15:17:00 +08:00
|
|
|
#include <linux/license.h>
|
|
|
|
#include <linux/filter.h>
|
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 03:49:20 +08:00
|
|
|
#include <linux/version.h>
|
2016-11-14 02:44:03 +08:00
|
|
|
#include <linux/kernel.h>
|
2017-06-06 03:15:46 +08:00
|
|
|
#include <linux/idr.h>
|
2017-09-28 05:37:52 +08:00
|
|
|
#include <linux/cred.h>
|
|
|
|
#include <linux/timekeeping.h>
|
|
|
|
#include <linux/ctype.h>
|
2018-05-04 00:04:59 +08:00
|
|
|
#include <linux/nospec.h>
|
2014-09-26 15:16:57 +08:00
|
|
|
|
2017-06-28 14:08:34 +08:00
|
|
|
#define IS_FD_ARRAY(map) ((map)->map_type == BPF_MAP_TYPE_PROG_ARRAY || \
|
|
|
|
(map)->map_type == BPF_MAP_TYPE_PERF_EVENT_ARRAY || \
|
|
|
|
(map)->map_type == BPF_MAP_TYPE_CGROUP_ARRAY || \
|
|
|
|
(map)->map_type == BPF_MAP_TYPE_ARRAY_OF_MAPS)
|
|
|
|
#define IS_FD_HASH(map) ((map)->map_type == BPF_MAP_TYPE_HASH_OF_MAPS)
|
|
|
|
#define IS_FD_MAP(map) (IS_FD_ARRAY(map) || IS_FD_HASH(map))
|
|
|
|
|
2017-10-19 04:00:22 +08:00
|
|
|
#define BPF_OBJ_FLAG_MASK (BPF_F_RDONLY | BPF_F_WRONLY)
|
|
|
|
|
2016-03-08 13:57:13 +08:00
|
|
|
DEFINE_PER_CPU(int, bpf_prog_active);
|
2017-06-06 03:15:46 +08:00
|
|
|
static DEFINE_IDR(prog_idr);
|
|
|
|
static DEFINE_SPINLOCK(prog_idr_lock);
|
2017-06-06 03:15:47 +08:00
|
|
|
static DEFINE_IDR(map_idr);
|
|
|
|
static DEFINE_SPINLOCK(map_idr_lock);
|
2016-03-08 13:57:13 +08:00
|
|
|
|
bpf: enable non-root eBPF programs
In order to let unprivileged users load and execute eBPF programs
teach verifier to prevent pointer leaks.
Verifier will prevent
- any arithmetic on pointers
(except R10+Imm which is used to compute stack addresses)
- comparison of pointers
(except if (map_value_ptr == 0) ... )
- passing pointers to helper functions
- indirectly passing pointers in stack to helper functions
- returning pointer from bpf program
- storing pointers into ctx or maps
Spill/fill of pointers into stack is allowed, but mangling
of pointers stored in the stack or reading them byte by byte is not.
Within bpf programs the pointers do exist, since programs need to
be able to access maps, pass skb pointer to LD_ABS insns, etc
but programs cannot pass such pointer values to the outside
or obfuscate them.
Only allow BPF_PROG_TYPE_SOCKET_FILTER unprivileged programs,
so that socket filters (tcpdump), af_packet (quic acceleration)
and future kcm can use it.
tracing and tc cls/act program types still require root permissions,
since tracing actually needs to be able to see all kernel pointers
and tc is for root only.
For example, the following unprivileged socket filter program is allowed:
int bpf_prog1(struct __sk_buff *skb)
{
u32 index = load_byte(skb, ETH_HLEN + offsetof(struct iphdr, protocol));
u64 *value = bpf_map_lookup_elem(&my_map, &index);
if (value)
*value += skb->len;
return 0;
}
but the following program is not:
int bpf_prog1(struct __sk_buff *skb)
{
u32 index = load_byte(skb, ETH_HLEN + offsetof(struct iphdr, protocol));
u64 *value = bpf_map_lookup_elem(&my_map, &index);
if (value)
*value += (u64) skb;
return 0;
}
since it would leak the kernel address into the map.
Unprivileged socket filter bpf programs have access to the
following helper functions:
- map lookup/update/delete (but they cannot store kernel pointers into them)
- get_random (it's already exposed to unprivileged user space)
- get_smp_processor_id
- tail_call into another socket filter program
- ktime_get_ns
The feature is controlled by sysctl kernel.unprivileged_bpf_disabled.
This toggle defaults to off (0), but can be set true (1). Once true,
bpf programs and maps cannot be accessed from unprivileged process,
and the toggle cannot be set back to false.
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-10-08 13:23:21 +08:00
|
|
|
int sysctl_unprivileged_bpf_disabled __read_mostly;
|
|
|
|
|
2017-04-11 21:34:58 +08:00
|
|
|
static const struct bpf_map_ops * const bpf_map_types[] = {
|
|
|
|
#define BPF_PROG_TYPE(_id, _ops)
|
|
|
|
#define BPF_MAP_TYPE(_id, _ops) \
|
|
|
|
[_id] = &_ops,
|
|
|
|
#include <linux/bpf_types.h>
|
|
|
|
#undef BPF_PROG_TYPE
|
|
|
|
#undef BPF_MAP_TYPE
|
|
|
|
};
|
2014-09-26 15:16:57 +08:00
|
|
|
|
2017-08-08 02:45:20 +08:00
|
|
|
/*
|
|
|
|
* If we're handed a bigger struct than we know of, ensure all the unknown bits
|
|
|
|
* are 0 - i.e. new user-space does not rely on any kernel feature extensions
|
|
|
|
* we don't know about yet.
|
|
|
|
*
|
|
|
|
* There is a ToCToU between this function call and the following
|
|
|
|
* copy_from_user() call. However, this is not a concern since this function is
|
|
|
|
* meant to be a future-proofing of bits.
|
|
|
|
*/
|
2018-05-23 06:03:31 +08:00
|
|
|
int bpf_check_uarg_tail_zero(void __user *uaddr,
|
|
|
|
size_t expected_size,
|
|
|
|
size_t actual_size)
|
2017-08-08 02:45:19 +08:00
|
|
|
{
|
|
|
|
unsigned char __user *addr;
|
|
|
|
unsigned char __user *end;
|
|
|
|
unsigned char val;
|
|
|
|
int err;
|
|
|
|
|
2017-08-08 02:45:20 +08:00
|
|
|
if (unlikely(actual_size > PAGE_SIZE)) /* silly large */
|
|
|
|
return -E2BIG;
|
|
|
|
|
|
|
|
if (unlikely(!access_ok(VERIFY_READ, uaddr, actual_size)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
2017-08-08 02:45:19 +08:00
|
|
|
if (actual_size <= expected_size)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
addr = uaddr + expected_size;
|
|
|
|
end = uaddr + actual_size;
|
|
|
|
|
|
|
|
for (; addr < end; addr++) {
|
|
|
|
err = get_user(val, addr);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
if (val)
|
|
|
|
return -E2BIG;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-01-12 12:29:09 +08:00
|
|
|
const struct bpf_map_ops bpf_map_offload_ops = {
|
|
|
|
.map_alloc = bpf_map_offload_map_alloc,
|
|
|
|
.map_free = bpf_map_offload_map_free,
|
2018-08-12 07:59:17 +08:00
|
|
|
.map_check_btf = map_check_no_btf,
|
2018-01-12 12:29:09 +08:00
|
|
|
};
|
|
|
|
|
2014-09-26 15:16:57 +08:00
|
|
|
static struct bpf_map *find_and_alloc_map(union bpf_attr *attr)
|
|
|
|
{
|
2018-01-12 12:29:03 +08:00
|
|
|
const struct bpf_map_ops *ops;
|
2018-05-04 00:04:59 +08:00
|
|
|
u32 type = attr->map_type;
|
2014-09-26 15:16:57 +08:00
|
|
|
struct bpf_map *map;
|
2018-01-12 12:29:03 +08:00
|
|
|
int err;
|
2014-09-26 15:16:57 +08:00
|
|
|
|
2018-05-04 00:04:59 +08:00
|
|
|
if (type >= ARRAY_SIZE(bpf_map_types))
|
2018-01-12 12:29:03 +08:00
|
|
|
return ERR_PTR(-EINVAL);
|
2018-05-04 00:04:59 +08:00
|
|
|
type = array_index_nospec(type, ARRAY_SIZE(bpf_map_types));
|
|
|
|
ops = bpf_map_types[type];
|
2018-01-12 12:29:03 +08:00
|
|
|
if (!ops)
|
2017-04-11 21:34:58 +08:00
|
|
|
return ERR_PTR(-EINVAL);
|
2014-09-26 15:16:57 +08:00
|
|
|
|
2018-01-12 12:29:03 +08:00
|
|
|
if (ops->map_alloc_check) {
|
|
|
|
err = ops->map_alloc_check(attr);
|
|
|
|
if (err)
|
|
|
|
return ERR_PTR(err);
|
|
|
|
}
|
2018-01-12 12:29:09 +08:00
|
|
|
if (attr->map_ifindex)
|
|
|
|
ops = &bpf_map_offload_ops;
|
2018-01-12 12:29:03 +08:00
|
|
|
map = ops->map_alloc(attr);
|
2017-04-11 21:34:58 +08:00
|
|
|
if (IS_ERR(map))
|
|
|
|
return map;
|
2018-01-12 12:29:03 +08:00
|
|
|
map->ops = ops;
|
2018-05-04 00:04:59 +08:00
|
|
|
map->map_type = type;
|
2017-04-11 21:34:58 +08:00
|
|
|
return map;
|
2014-09-26 15:16:57 +08:00
|
|
|
}
|
|
|
|
|
2017-08-19 02:28:00 +08:00
|
|
|
void *bpf_map_area_alloc(size_t size, int numa_node)
|
bpf: don't trigger OOM killer under pressure with map alloc
This patch adds two helpers, bpf_map_area_alloc() and bpf_map_area_free(),
that are to be used for map allocations. Using kmalloc() for very large
allocations can cause excessive work within the page allocator, so i) fall
back earlier to vmalloc() when the attempt is considered costly anyway,
and even more importantly ii) don't trigger OOM killer with any of the
allocators.
Since this is based on a user space request, for example, when creating
maps with element pre-allocation, we really want such requests to fail
instead of killing other user space processes.
Also, don't spam the kernel log with warnings should any of the allocations
fail under pressure. Given that, we can make backend selection in
bpf_map_area_alloc() generic, and convert all maps over to use this API
for spots with potentially large allocation requests.
Note, replacing the one kmalloc_array() is fine as overflow checks happen
earlier in htab_map_alloc(), since it must also protect the multiplication
for vmalloc() should kmalloc_array() fail.
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-01-18 22:14:17 +08:00
|
|
|
{
|
|
|
|
/* We definitely need __GFP_NORETRY, so OOM killer doesn't
|
|
|
|
* trigger under memory pressure as we really just want to
|
|
|
|
* fail instead.
|
|
|
|
*/
|
|
|
|
const gfp_t flags = __GFP_NOWARN | __GFP_NORETRY | __GFP_ZERO;
|
|
|
|
void *area;
|
|
|
|
|
|
|
|
if (size <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER)) {
|
2017-08-19 02:28:00 +08:00
|
|
|
area = kmalloc_node(size, GFP_USER | flags, numa_node);
|
bpf: don't trigger OOM killer under pressure with map alloc
This patch adds two helpers, bpf_map_area_alloc() and bpf_map_area_free(),
that are to be used for map allocations. Using kmalloc() for very large
allocations can cause excessive work within the page allocator, so i) fall
back earlier to vmalloc() when the attempt is considered costly anyway,
and even more importantly ii) don't trigger OOM killer with any of the
allocators.
Since this is based on a user space request, for example, when creating
maps with element pre-allocation, we really want such requests to fail
instead of killing other user space processes.
Also, don't spam the kernel log with warnings should any of the allocations
fail under pressure. Given that, we can make backend selection in
bpf_map_area_alloc() generic, and convert all maps over to use this API
for spots with potentially large allocation requests.
Note, replacing the one kmalloc_array() is fine as overflow checks happen
earlier in htab_map_alloc(), since it must also protect the multiplication
for vmalloc() should kmalloc_array() fail.
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-01-18 22:14:17 +08:00
|
|
|
if (area != NULL)
|
|
|
|
return area;
|
|
|
|
}
|
|
|
|
|
2017-08-19 02:28:00 +08:00
|
|
|
return __vmalloc_node_flags_caller(size, numa_node, GFP_KERNEL | flags,
|
|
|
|
__builtin_return_address(0));
|
bpf: don't trigger OOM killer under pressure with map alloc
This patch adds two helpers, bpf_map_area_alloc() and bpf_map_area_free(),
that are to be used for map allocations. Using kmalloc() for very large
allocations can cause excessive work within the page allocator, so i) fall
back earlier to vmalloc() when the attempt is considered costly anyway,
and even more importantly ii) don't trigger OOM killer with any of the
allocators.
Since this is based on a user space request, for example, when creating
maps with element pre-allocation, we really want such requests to fail
instead of killing other user space processes.
Also, don't spam the kernel log with warnings should any of the allocations
fail under pressure. Given that, we can make backend selection in
bpf_map_area_alloc() generic, and convert all maps over to use this API
for spots with potentially large allocation requests.
Note, replacing the one kmalloc_array() is fine as overflow checks happen
earlier in htab_map_alloc(), since it must also protect the multiplication
for vmalloc() should kmalloc_array() fail.
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-01-18 22:14:17 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void bpf_map_area_free(void *area)
|
|
|
|
{
|
|
|
|
kvfree(area);
|
|
|
|
}
|
|
|
|
|
2018-01-12 12:29:06 +08:00
|
|
|
void bpf_map_init_from_attr(struct bpf_map *map, union bpf_attr *attr)
|
|
|
|
{
|
|
|
|
map->map_type = attr->map_type;
|
|
|
|
map->key_size = attr->key_size;
|
|
|
|
map->value_size = attr->value_size;
|
|
|
|
map->max_entries = attr->max_entries;
|
|
|
|
map->map_flags = attr->map_flags;
|
|
|
|
map->numa_node = bpf_map_attr_numa_node(attr);
|
|
|
|
}
|
|
|
|
|
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 13:57:15 +08:00
|
|
|
int bpf_map_precharge_memlock(u32 pages)
|
|
|
|
{
|
|
|
|
struct user_struct *user = get_current_user();
|
|
|
|
unsigned long memlock_limit, cur;
|
|
|
|
|
|
|
|
memlock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
|
|
|
|
cur = atomic_long_read(&user->locked_vm);
|
|
|
|
free_uid(user);
|
|
|
|
if (cur + pages > memlock_limit)
|
|
|
|
return -EPERM;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-08-03 05:27:17 +08:00
|
|
|
static int bpf_charge_memlock(struct user_struct *user, u32 pages)
|
2015-10-08 13:23:22 +08:00
|
|
|
{
|
2018-08-03 05:27:17 +08:00
|
|
|
unsigned long memlock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
|
2015-10-08 13:23:22 +08:00
|
|
|
|
2018-08-03 05:27:17 +08:00
|
|
|
if (atomic_long_add_return(pages, &user->locked_vm) > memlock_limit) {
|
|
|
|
atomic_long_sub(pages, &user->locked_vm);
|
|
|
|
return -EPERM;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
2015-10-08 13:23:22 +08:00
|
|
|
|
2018-08-03 05:27:17 +08:00
|
|
|
static void bpf_uncharge_memlock(struct user_struct *user, u32 pages)
|
|
|
|
{
|
|
|
|
atomic_long_sub(pages, &user->locked_vm);
|
|
|
|
}
|
2015-10-08 13:23:22 +08:00
|
|
|
|
2018-08-03 05:27:17 +08:00
|
|
|
static int bpf_map_init_memlock(struct bpf_map *map)
|
|
|
|
{
|
|
|
|
struct user_struct *user = get_current_user();
|
|
|
|
int ret;
|
2015-10-08 13:23:22 +08:00
|
|
|
|
2018-08-03 05:27:17 +08:00
|
|
|
ret = bpf_charge_memlock(user, map->pages);
|
|
|
|
if (ret) {
|
2015-10-08 13:23:22 +08:00
|
|
|
free_uid(user);
|
2018-08-03 05:27:17 +08:00
|
|
|
return ret;
|
2015-10-08 13:23:22 +08:00
|
|
|
}
|
|
|
|
map->user = user;
|
2018-08-03 05:27:17 +08:00
|
|
|
return ret;
|
2015-10-08 13:23:22 +08:00
|
|
|
}
|
|
|
|
|
2018-08-03 05:27:17 +08:00
|
|
|
static void bpf_map_release_memlock(struct bpf_map *map)
|
2015-10-08 13:23:22 +08:00
|
|
|
{
|
|
|
|
struct user_struct *user = map->user;
|
2018-08-03 05:27:17 +08:00
|
|
|
bpf_uncharge_memlock(user, map->pages);
|
2015-10-08 13:23:22 +08:00
|
|
|
free_uid(user);
|
|
|
|
}
|
|
|
|
|
2018-08-03 05:27:17 +08:00
|
|
|
int bpf_map_charge_memlock(struct bpf_map *map, u32 pages)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = bpf_charge_memlock(map->user, pages);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
map->pages += pages;
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
void bpf_map_uncharge_memlock(struct bpf_map *map, u32 pages)
|
|
|
|
{
|
|
|
|
bpf_uncharge_memlock(map->user, pages);
|
|
|
|
map->pages -= pages;
|
|
|
|
}
|
|
|
|
|
2017-06-06 03:15:47 +08:00
|
|
|
static int bpf_map_alloc_id(struct bpf_map *map)
|
|
|
|
{
|
|
|
|
int id;
|
|
|
|
|
2018-03-28 02:53:21 +08:00
|
|
|
idr_preload(GFP_KERNEL);
|
2017-06-06 03:15:47 +08:00
|
|
|
spin_lock_bh(&map_idr_lock);
|
|
|
|
id = idr_alloc_cyclic(&map_idr, map, 1, INT_MAX, GFP_ATOMIC);
|
|
|
|
if (id > 0)
|
|
|
|
map->id = id;
|
|
|
|
spin_unlock_bh(&map_idr_lock);
|
2018-03-28 02:53:21 +08:00
|
|
|
idr_preload_end();
|
2017-06-06 03:15:47 +08:00
|
|
|
|
|
|
|
if (WARN_ON_ONCE(!id))
|
|
|
|
return -ENOSPC;
|
|
|
|
|
|
|
|
return id > 0 ? 0 : id;
|
|
|
|
}
|
|
|
|
|
2018-01-12 12:29:09 +08:00
|
|
|
void bpf_map_free_id(struct bpf_map *map, bool do_idr_lock)
|
2017-06-06 03:15:47 +08:00
|
|
|
{
|
2017-09-20 00:15:59 +08:00
|
|
|
unsigned long flags;
|
|
|
|
|
2018-01-12 12:29:09 +08:00
|
|
|
/* Offloaded maps are removed from the IDR store when their device
|
|
|
|
* disappears - even if someone holds an fd to them they are unusable,
|
|
|
|
* the memory is gone, all ops will fail; they are simply waiting for
|
|
|
|
* refcnt to drop to be freed.
|
|
|
|
*/
|
|
|
|
if (!map->id)
|
|
|
|
return;
|
|
|
|
|
2017-06-06 03:15:50 +08:00
|
|
|
if (do_idr_lock)
|
2017-09-20 00:15:59 +08:00
|
|
|
spin_lock_irqsave(&map_idr_lock, flags);
|
2017-06-06 03:15:50 +08:00
|
|
|
else
|
|
|
|
__acquire(&map_idr_lock);
|
|
|
|
|
2017-06-06 03:15:47 +08:00
|
|
|
idr_remove(&map_idr, map->id);
|
2018-01-12 12:29:09 +08:00
|
|
|
map->id = 0;
|
2017-06-06 03:15:50 +08:00
|
|
|
|
|
|
|
if (do_idr_lock)
|
2017-09-20 00:15:59 +08:00
|
|
|
spin_unlock_irqrestore(&map_idr_lock, flags);
|
2017-06-06 03:15:50 +08:00
|
|
|
else
|
|
|
|
__release(&map_idr_lock);
|
2017-06-06 03:15:47 +08:00
|
|
|
}
|
|
|
|
|
2014-09-26 15:16:57 +08:00
|
|
|
/* called from workqueue */
|
|
|
|
static void bpf_map_free_deferred(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct bpf_map *map = container_of(work, struct bpf_map, work);
|
|
|
|
|
2018-08-03 05:27:17 +08:00
|
|
|
bpf_map_release_memlock(map);
|
2017-10-19 04:00:24 +08:00
|
|
|
security_bpf_map_free(map);
|
2014-09-26 15:16:57 +08:00
|
|
|
/* implementation dependent freeing */
|
|
|
|
map->ops->map_free(map);
|
|
|
|
}
|
|
|
|
|
bpf: fix clearing on persistent program array maps
Currently, when having map file descriptors pointing to program arrays,
there's still the issue that we unconditionally flush program array
contents via bpf_fd_array_map_clear() in bpf_map_release(). This happens
when such a file descriptor is released and is independent of the map's
refcount.
Having this flush independent of the refcount is for a reason: there
can be arbitrary complex dependency chains among tail calls, also circular
ones (direct or indirect, nesting limit determined during runtime), and
we need to make sure that the map drops all references to eBPF programs
it holds, so that the map's refcount can eventually drop to zero and
initiate its freeing. Btw, a walk of the whole dependency graph would
not be possible for various reasons, one being complexity and another
one inconsistency, i.e. new programs can be added to parts of the graph
at any time, so there's no guaranteed consistent state for the time of
such a walk.
Now, the program array pinning itself works, but the issue is that each
derived file descriptor on close would nevertheless call unconditionally
into bpf_fd_array_map_clear(). Instead, keep track of users and postpone
this flush until the last reference to a user is dropped. As this only
concerns a subset of references (f.e. a prog array could hold a program
that itself has reference on the prog array holding it, etc), we need to
track them separately.
Short analysis on the refcounting: on map creation time usercnt will be
one, so there's no change in behaviour for bpf_map_release(), if unpinned.
If we already fail in map_create(), we are immediately freed, and no
file descriptor has been made public yet. In bpf_obj_pin_user(), we need
to probe for a possible map in bpf_fd_probe_obj() already with a usercnt
reference, so before we drop the reference on the fd with fdput().
Therefore, if actual pinning fails, we need to drop that reference again
in bpf_any_put(), otherwise we keep holding it. When last reference
drops on the inode, the bpf_any_put() in bpf_evict_inode() will take
care of dropping the usercnt again. In the bpf_obj_get_user() case, the
bpf_any_get() will grab a reference on the usercnt, still at a time when
we have the reference on the path. Should we later on fail to grab a new
file descriptor, bpf_any_put() will drop it, otherwise we hold it until
bpf_map_release() time.
Joint work with Alexei.
Fixes: b2197755b263 ("bpf: add support for persistent maps/progs")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-11-25 04:28:15 +08:00
|
|
|
static void bpf_map_put_uref(struct bpf_map *map)
|
|
|
|
{
|
|
|
|
if (atomic_dec_and_test(&map->usercnt)) {
|
2018-04-24 06:39:23 +08:00
|
|
|
if (map->ops->map_release_uref)
|
|
|
|
map->ops->map_release_uref(map);
|
bpf: fix clearing on persistent program array maps
Currently, when having map file descriptors pointing to program arrays,
there's still the issue that we unconditionally flush program array
contents via bpf_fd_array_map_clear() in bpf_map_release(). This happens
when such a file descriptor is released and is independent of the map's
refcount.
Having this flush independent of the refcount is for a reason: there
can be arbitrary complex dependency chains among tail calls, also circular
ones (direct or indirect, nesting limit determined during runtime), and
we need to make sure that the map drops all references to eBPF programs
it holds, so that the map's refcount can eventually drop to zero and
initiate its freeing. Btw, a walk of the whole dependency graph would
not be possible for various reasons, one being complexity and another
one inconsistency, i.e. new programs can be added to parts of the graph
at any time, so there's no guaranteed consistent state for the time of
such a walk.
Now, the program array pinning itself works, but the issue is that each
derived file descriptor on close would nevertheless call unconditionally
into bpf_fd_array_map_clear(). Instead, keep track of users and postpone
this flush until the last reference to a user is dropped. As this only
concerns a subset of references (f.e. a prog array could hold a program
that itself has reference on the prog array holding it, etc), we need to
track them separately.
Short analysis on the refcounting: on map creation time usercnt will be
one, so there's no change in behaviour for bpf_map_release(), if unpinned.
If we already fail in map_create(), we are immediately freed, and no
file descriptor has been made public yet. In bpf_obj_pin_user(), we need
to probe for a possible map in bpf_fd_probe_obj() already with a usercnt
reference, so before we drop the reference on the fd with fdput().
Therefore, if actual pinning fails, we need to drop that reference again
in bpf_any_put(), otherwise we keep holding it. When last reference
drops on the inode, the bpf_any_put() in bpf_evict_inode() will take
care of dropping the usercnt again. In the bpf_obj_get_user() case, the
bpf_any_get() will grab a reference on the usercnt, still at a time when
we have the reference on the path. Should we later on fail to grab a new
file descriptor, bpf_any_put() will drop it, otherwise we hold it until
bpf_map_release() time.
Joint work with Alexei.
Fixes: b2197755b263 ("bpf: add support for persistent maps/progs")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-11-25 04:28:15 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-09-26 15:16:57 +08:00
|
|
|
/* decrement map refcnt and schedule it for freeing via workqueue
|
|
|
|
* (unrelying map implementation ops->map_free() might sleep)
|
|
|
|
*/
|
2017-06-06 03:15:50 +08:00
|
|
|
static void __bpf_map_put(struct bpf_map *map, bool do_idr_lock)
|
2014-09-26 15:16:57 +08:00
|
|
|
{
|
|
|
|
if (atomic_dec_and_test(&map->refcnt)) {
|
2017-06-06 03:15:48 +08:00
|
|
|
/* bpf_map_free_id() must be called first */
|
2017-06-06 03:15:50 +08:00
|
|
|
bpf_map_free_id(map, do_idr_lock);
|
2018-05-05 05:49:51 +08:00
|
|
|
btf_put(map->btf);
|
2014-09-26 15:16:57 +08:00
|
|
|
INIT_WORK(&map->work, bpf_map_free_deferred);
|
|
|
|
schedule_work(&map->work);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-06-06 03:15:50 +08:00
|
|
|
void bpf_map_put(struct bpf_map *map)
|
|
|
|
{
|
|
|
|
__bpf_map_put(map, true);
|
|
|
|
}
|
2018-05-04 09:37:09 +08:00
|
|
|
EXPORT_SYMBOL_GPL(bpf_map_put);
|
2017-06-06 03:15:50 +08:00
|
|
|
|
bpf: fix clearing on persistent program array maps
Currently, when having map file descriptors pointing to program arrays,
there's still the issue that we unconditionally flush program array
contents via bpf_fd_array_map_clear() in bpf_map_release(). This happens
when such a file descriptor is released and is independent of the map's
refcount.
Having this flush independent of the refcount is for a reason: there
can be arbitrary complex dependency chains among tail calls, also circular
ones (direct or indirect, nesting limit determined during runtime), and
we need to make sure that the map drops all references to eBPF programs
it holds, so that the map's refcount can eventually drop to zero and
initiate its freeing. Btw, a walk of the whole dependency graph would
not be possible for various reasons, one being complexity and another
one inconsistency, i.e. new programs can be added to parts of the graph
at any time, so there's no guaranteed consistent state for the time of
such a walk.
Now, the program array pinning itself works, but the issue is that each
derived file descriptor on close would nevertheless call unconditionally
into bpf_fd_array_map_clear(). Instead, keep track of users and postpone
this flush until the last reference to a user is dropped. As this only
concerns a subset of references (f.e. a prog array could hold a program
that itself has reference on the prog array holding it, etc), we need to
track them separately.
Short analysis on the refcounting: on map creation time usercnt will be
one, so there's no change in behaviour for bpf_map_release(), if unpinned.
If we already fail in map_create(), we are immediately freed, and no
file descriptor has been made public yet. In bpf_obj_pin_user(), we need
to probe for a possible map in bpf_fd_probe_obj() already with a usercnt
reference, so before we drop the reference on the fd with fdput().
Therefore, if actual pinning fails, we need to drop that reference again
in bpf_any_put(), otherwise we keep holding it. When last reference
drops on the inode, the bpf_any_put() in bpf_evict_inode() will take
care of dropping the usercnt again. In the bpf_obj_get_user() case, the
bpf_any_get() will grab a reference on the usercnt, still at a time when
we have the reference on the path. Should we later on fail to grab a new
file descriptor, bpf_any_put() will drop it, otherwise we hold it until
bpf_map_release() time.
Joint work with Alexei.
Fixes: b2197755b263 ("bpf: add support for persistent maps/progs")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-11-25 04:28:15 +08:00
|
|
|
void bpf_map_put_with_uref(struct bpf_map *map)
|
2014-09-26 15:16:57 +08:00
|
|
|
{
|
bpf: fix clearing on persistent program array maps
Currently, when having map file descriptors pointing to program arrays,
there's still the issue that we unconditionally flush program array
contents via bpf_fd_array_map_clear() in bpf_map_release(). This happens
when such a file descriptor is released and is independent of the map's
refcount.
Having this flush independent of the refcount is for a reason: there
can be arbitrary complex dependency chains among tail calls, also circular
ones (direct or indirect, nesting limit determined during runtime), and
we need to make sure that the map drops all references to eBPF programs
it holds, so that the map's refcount can eventually drop to zero and
initiate its freeing. Btw, a walk of the whole dependency graph would
not be possible for various reasons, one being complexity and another
one inconsistency, i.e. new programs can be added to parts of the graph
at any time, so there's no guaranteed consistent state for the time of
such a walk.
Now, the program array pinning itself works, but the issue is that each
derived file descriptor on close would nevertheless call unconditionally
into bpf_fd_array_map_clear(). Instead, keep track of users and postpone
this flush until the last reference to a user is dropped. As this only
concerns a subset of references (f.e. a prog array could hold a program
that itself has reference on the prog array holding it, etc), we need to
track them separately.
Short analysis on the refcounting: on map creation time usercnt will be
one, so there's no change in behaviour for bpf_map_release(), if unpinned.
If we already fail in map_create(), we are immediately freed, and no
file descriptor has been made public yet. In bpf_obj_pin_user(), we need
to probe for a possible map in bpf_fd_probe_obj() already with a usercnt
reference, so before we drop the reference on the fd with fdput().
Therefore, if actual pinning fails, we need to drop that reference again
in bpf_any_put(), otherwise we keep holding it. When last reference
drops on the inode, the bpf_any_put() in bpf_evict_inode() will take
care of dropping the usercnt again. In the bpf_obj_get_user() case, the
bpf_any_get() will grab a reference on the usercnt, still at a time when
we have the reference on the path. Should we later on fail to grab a new
file descriptor, bpf_any_put() will drop it, otherwise we hold it until
bpf_map_release() time.
Joint work with Alexei.
Fixes: b2197755b263 ("bpf: add support for persistent maps/progs")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-11-25 04:28:15 +08:00
|
|
|
bpf_map_put_uref(map);
|
2014-09-26 15:16:57 +08:00
|
|
|
bpf_map_put(map);
|
bpf: fix clearing on persistent program array maps
Currently, when having map file descriptors pointing to program arrays,
there's still the issue that we unconditionally flush program array
contents via bpf_fd_array_map_clear() in bpf_map_release(). This happens
when such a file descriptor is released and is independent of the map's
refcount.
Having this flush independent of the refcount is for a reason: there
can be arbitrary complex dependency chains among tail calls, also circular
ones (direct or indirect, nesting limit determined during runtime), and
we need to make sure that the map drops all references to eBPF programs
it holds, so that the map's refcount can eventually drop to zero and
initiate its freeing. Btw, a walk of the whole dependency graph would
not be possible for various reasons, one being complexity and another
one inconsistency, i.e. new programs can be added to parts of the graph
at any time, so there's no guaranteed consistent state for the time of
such a walk.
Now, the program array pinning itself works, but the issue is that each
derived file descriptor on close would nevertheless call unconditionally
into bpf_fd_array_map_clear(). Instead, keep track of users and postpone
this flush until the last reference to a user is dropped. As this only
concerns a subset of references (f.e. a prog array could hold a program
that itself has reference on the prog array holding it, etc), we need to
track them separately.
Short analysis on the refcounting: on map creation time usercnt will be
one, so there's no change in behaviour for bpf_map_release(), if unpinned.
If we already fail in map_create(), we are immediately freed, and no
file descriptor has been made public yet. In bpf_obj_pin_user(), we need
to probe for a possible map in bpf_fd_probe_obj() already with a usercnt
reference, so before we drop the reference on the fd with fdput().
Therefore, if actual pinning fails, we need to drop that reference again
in bpf_any_put(), otherwise we keep holding it. When last reference
drops on the inode, the bpf_any_put() in bpf_evict_inode() will take
care of dropping the usercnt again. In the bpf_obj_get_user() case, the
bpf_any_get() will grab a reference on the usercnt, still at a time when
we have the reference on the path. Should we later on fail to grab a new
file descriptor, bpf_any_put() will drop it, otherwise we hold it until
bpf_map_release() time.
Joint work with Alexei.
Fixes: b2197755b263 ("bpf: add support for persistent maps/progs")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-11-25 04:28:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int bpf_map_release(struct inode *inode, struct file *filp)
|
|
|
|
{
|
2016-06-16 04:47:12 +08:00
|
|
|
struct bpf_map *map = filp->private_data;
|
|
|
|
|
|
|
|
if (map->ops->map_release)
|
|
|
|
map->ops->map_release(map, filp);
|
|
|
|
|
|
|
|
bpf_map_put_with_uref(map);
|
2014-09-26 15:16:57 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-11-19 18:56:22 +08:00
|
|
|
#ifdef CONFIG_PROC_FS
|
|
|
|
static void bpf_map_show_fdinfo(struct seq_file *m, struct file *filp)
|
|
|
|
{
|
|
|
|
const struct bpf_map *map = filp->private_data;
|
2016-11-26 08:28:07 +08:00
|
|
|
const struct bpf_array *array;
|
|
|
|
u32 owner_prog_type = 0;
|
2017-07-02 08:13:28 +08:00
|
|
|
u32 owner_jited = 0;
|
2016-11-26 08:28:07 +08:00
|
|
|
|
|
|
|
if (map->map_type == BPF_MAP_TYPE_PROG_ARRAY) {
|
|
|
|
array = container_of(map, struct bpf_array, map);
|
|
|
|
owner_prog_type = array->owner_prog_type;
|
2017-07-02 08:13:28 +08:00
|
|
|
owner_jited = array->owner_jited;
|
2016-11-26 08:28:07 +08:00
|
|
|
}
|
2015-11-19 18:56:22 +08:00
|
|
|
|
|
|
|
seq_printf(m,
|
|
|
|
"map_type:\t%u\n"
|
|
|
|
"key_size:\t%u\n"
|
|
|
|
"value_size:\t%u\n"
|
2016-03-25 07:30:25 +08:00
|
|
|
"max_entries:\t%u\n"
|
2016-11-26 08:28:07 +08:00
|
|
|
"map_flags:\t%#x\n"
|
2018-06-03 05:06:34 +08:00
|
|
|
"memlock:\t%llu\n"
|
|
|
|
"map_id:\t%u\n",
|
2015-11-19 18:56:22 +08:00
|
|
|
map->map_type,
|
|
|
|
map->key_size,
|
|
|
|
map->value_size,
|
2016-03-25 07:30:25 +08:00
|
|
|
map->max_entries,
|
2016-11-26 08:28:07 +08:00
|
|
|
map->map_flags,
|
2018-06-03 05:06:34 +08:00
|
|
|
map->pages * 1ULL << PAGE_SHIFT,
|
|
|
|
map->id);
|
2016-11-26 08:28:07 +08:00
|
|
|
|
2017-07-02 08:13:28 +08:00
|
|
|
if (owner_prog_type) {
|
2016-11-26 08:28:07 +08:00
|
|
|
seq_printf(m, "owner_prog_type:\t%u\n",
|
|
|
|
owner_prog_type);
|
2017-07-02 08:13:28 +08:00
|
|
|
seq_printf(m, "owner_jited:\t%u\n",
|
|
|
|
owner_jited);
|
|
|
|
}
|
2015-11-19 18:56:22 +08:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2017-10-19 04:00:22 +08:00
|
|
|
static ssize_t bpf_dummy_read(struct file *filp, char __user *buf, size_t siz,
|
|
|
|
loff_t *ppos)
|
|
|
|
{
|
|
|
|
/* We need this handler such that alloc_file() enables
|
|
|
|
* f_mode with FMODE_CAN_READ.
|
|
|
|
*/
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t bpf_dummy_write(struct file *filp, const char __user *buf,
|
|
|
|
size_t siz, loff_t *ppos)
|
|
|
|
{
|
|
|
|
/* We need this handler such that alloc_file() enables
|
|
|
|
* f_mode with FMODE_CAN_WRITE.
|
|
|
|
*/
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2017-10-19 04:00:26 +08:00
|
|
|
const struct file_operations bpf_map_fops = {
|
2015-11-19 18:56:22 +08:00
|
|
|
#ifdef CONFIG_PROC_FS
|
|
|
|
.show_fdinfo = bpf_map_show_fdinfo,
|
|
|
|
#endif
|
|
|
|
.release = bpf_map_release,
|
2017-10-19 04:00:22 +08:00
|
|
|
.read = bpf_dummy_read,
|
|
|
|
.write = bpf_dummy_write,
|
2014-09-26 15:16:57 +08:00
|
|
|
};
|
|
|
|
|
2017-10-19 04:00:22 +08:00
|
|
|
int bpf_map_new_fd(struct bpf_map *map, int flags)
|
2015-10-29 21:58:06 +08:00
|
|
|
{
|
2017-10-19 04:00:24 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = security_bpf_map(map, OPEN_FMODE(flags));
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
2015-10-29 21:58:06 +08:00
|
|
|
return anon_inode_getfd("bpf-map", &bpf_map_fops, map,
|
2017-10-19 04:00:22 +08:00
|
|
|
flags | O_CLOEXEC);
|
|
|
|
}
|
|
|
|
|
|
|
|
int bpf_get_file_flag(int flags)
|
|
|
|
{
|
|
|
|
if ((flags & BPF_F_RDONLY) && (flags & BPF_F_WRONLY))
|
|
|
|
return -EINVAL;
|
|
|
|
if (flags & BPF_F_RDONLY)
|
|
|
|
return O_RDONLY;
|
|
|
|
if (flags & BPF_F_WRONLY)
|
|
|
|
return O_WRONLY;
|
|
|
|
return O_RDWR;
|
2015-10-29 21:58:06 +08:00
|
|
|
}
|
|
|
|
|
2014-09-26 15:16:57 +08:00
|
|
|
/* helper macro to check that unused fields 'union bpf_attr' are zero */
|
|
|
|
#define CHECK_ATTR(CMD) \
|
|
|
|
memchr_inv((void *) &attr->CMD##_LAST_FIELD + \
|
|
|
|
sizeof(attr->CMD##_LAST_FIELD), 0, \
|
|
|
|
sizeof(*attr) - \
|
|
|
|
offsetof(union bpf_attr, CMD##_LAST_FIELD) - \
|
|
|
|
sizeof(attr->CMD##_LAST_FIELD)) != NULL
|
|
|
|
|
2017-09-28 05:37:52 +08:00
|
|
|
/* dst and src must have at least BPF_OBJ_NAME_LEN number of bytes.
|
|
|
|
* Return 0 on success and < 0 on error.
|
|
|
|
*/
|
|
|
|
static int bpf_obj_name_cpy(char *dst, const char *src)
|
|
|
|
{
|
|
|
|
const char *end = src + BPF_OBJ_NAME_LEN;
|
|
|
|
|
2017-10-06 12:52:11 +08:00
|
|
|
memset(dst, 0, BPF_OBJ_NAME_LEN);
|
|
|
|
|
2017-09-28 05:37:52 +08:00
|
|
|
/* Copy all isalnum() and '_' char */
|
|
|
|
while (src < end && *src) {
|
|
|
|
if (!isalnum(*src) && *src != '_')
|
|
|
|
return -EINVAL;
|
|
|
|
*dst++ = *src++;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* No '\0' found in BPF_OBJ_NAME_LEN number of bytes */
|
|
|
|
if (src == end)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-08-12 07:59:17 +08:00
|
|
|
int map_check_no_btf(const struct bpf_map *map,
|
|
|
|
const struct btf_type *key_type,
|
|
|
|
const struct btf_type *value_type)
|
|
|
|
{
|
|
|
|
return -ENOTSUPP;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int map_check_btf(const struct bpf_map *map, const struct btf *btf,
|
|
|
|
u32 btf_key_id, u32 btf_value_id)
|
|
|
|
{
|
|
|
|
const struct btf_type *key_type, *value_type;
|
|
|
|
u32 key_size, value_size;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
key_type = btf_type_id_size(btf, &btf_key_id, &key_size);
|
|
|
|
if (!key_type || key_size != map->key_size)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
value_type = btf_type_id_size(btf, &btf_value_id, &value_size);
|
|
|
|
if (!value_type || value_size != map->value_size)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (map->ops->map_check_btf)
|
|
|
|
ret = map->ops->map_check_btf(map, key_type, value_type);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2018-05-23 05:57:21 +08:00
|
|
|
#define BPF_MAP_CREATE_LAST_FIELD btf_value_type_id
|
2014-09-26 15:16:57 +08:00
|
|
|
/* called via syscall */
|
|
|
|
static int map_create(union bpf_attr *attr)
|
|
|
|
{
|
2017-08-19 02:28:00 +08:00
|
|
|
int numa_node = bpf_map_attr_numa_node(attr);
|
2014-09-26 15:16:57 +08:00
|
|
|
struct bpf_map *map;
|
2017-10-19 04:00:22 +08:00
|
|
|
int f_flags;
|
2014-09-26 15:16:57 +08:00
|
|
|
int err;
|
|
|
|
|
|
|
|
err = CHECK_ATTR(BPF_MAP_CREATE);
|
|
|
|
if (err)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2017-10-19 04:00:22 +08:00
|
|
|
f_flags = bpf_get_file_flag(attr->map_flags);
|
|
|
|
if (f_flags < 0)
|
|
|
|
return f_flags;
|
|
|
|
|
2017-08-19 02:28:00 +08:00
|
|
|
if (numa_node != NUMA_NO_NODE &&
|
2017-09-05 13:41:02 +08:00
|
|
|
((unsigned int)numa_node >= nr_node_ids ||
|
|
|
|
!node_online(numa_node)))
|
2017-08-19 02:28:00 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2014-09-26 15:16:57 +08:00
|
|
|
/* find map type and init map: hashtable vs rbtree vs bloom vs ... */
|
|
|
|
map = find_and_alloc_map(attr);
|
|
|
|
if (IS_ERR(map))
|
|
|
|
return PTR_ERR(map);
|
|
|
|
|
2017-09-28 05:37:53 +08:00
|
|
|
err = bpf_obj_name_cpy(map->name, attr->map_name);
|
|
|
|
if (err)
|
|
|
|
goto free_map_nouncharge;
|
|
|
|
|
2014-09-26 15:16:57 +08:00
|
|
|
atomic_set(&map->refcnt, 1);
|
bpf: fix clearing on persistent program array maps
Currently, when having map file descriptors pointing to program arrays,
there's still the issue that we unconditionally flush program array
contents via bpf_fd_array_map_clear() in bpf_map_release(). This happens
when such a file descriptor is released and is independent of the map's
refcount.
Having this flush independent of the refcount is for a reason: there
can be arbitrary complex dependency chains among tail calls, also circular
ones (direct or indirect, nesting limit determined during runtime), and
we need to make sure that the map drops all references to eBPF programs
it holds, so that the map's refcount can eventually drop to zero and
initiate its freeing. Btw, a walk of the whole dependency graph would
not be possible for various reasons, one being complexity and another
one inconsistency, i.e. new programs can be added to parts of the graph
at any time, so there's no guaranteed consistent state for the time of
such a walk.
Now, the program array pinning itself works, but the issue is that each
derived file descriptor on close would nevertheless call unconditionally
into bpf_fd_array_map_clear(). Instead, keep track of users and postpone
this flush until the last reference to a user is dropped. As this only
concerns a subset of references (f.e. a prog array could hold a program
that itself has reference on the prog array holding it, etc), we need to
track them separately.
Short analysis on the refcounting: on map creation time usercnt will be
one, so there's no change in behaviour for bpf_map_release(), if unpinned.
If we already fail in map_create(), we are immediately freed, and no
file descriptor has been made public yet. In bpf_obj_pin_user(), we need
to probe for a possible map in bpf_fd_probe_obj() already with a usercnt
reference, so before we drop the reference on the fd with fdput().
Therefore, if actual pinning fails, we need to drop that reference again
in bpf_any_put(), otherwise we keep holding it. When last reference
drops on the inode, the bpf_any_put() in bpf_evict_inode() will take
care of dropping the usercnt again. In the bpf_obj_get_user() case, the
bpf_any_get() will grab a reference on the usercnt, still at a time when
we have the reference on the path. Should we later on fail to grab a new
file descriptor, bpf_any_put() will drop it, otherwise we hold it until
bpf_map_release() time.
Joint work with Alexei.
Fixes: b2197755b263 ("bpf: add support for persistent maps/progs")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-11-25 04:28:15 +08:00
|
|
|
atomic_set(&map->usercnt, 1);
|
2014-09-26 15:16:57 +08:00
|
|
|
|
2018-08-12 07:59:17 +08:00
|
|
|
if (attr->btf_key_type_id || attr->btf_value_type_id) {
|
2018-04-19 06:56:03 +08:00
|
|
|
struct btf *btf;
|
|
|
|
|
2018-05-23 05:57:21 +08:00
|
|
|
if (!attr->btf_key_type_id || !attr->btf_value_type_id) {
|
2018-04-19 06:56:03 +08:00
|
|
|
err = -EINVAL;
|
|
|
|
goto free_map_nouncharge;
|
|
|
|
}
|
|
|
|
|
|
|
|
btf = btf_get_by_fd(attr->btf_fd);
|
|
|
|
if (IS_ERR(btf)) {
|
|
|
|
err = PTR_ERR(btf);
|
|
|
|
goto free_map_nouncharge;
|
|
|
|
}
|
|
|
|
|
2018-08-12 07:59:17 +08:00
|
|
|
err = map_check_btf(map, btf, attr->btf_key_type_id,
|
|
|
|
attr->btf_value_type_id);
|
2018-04-19 06:56:03 +08:00
|
|
|
if (err) {
|
|
|
|
btf_put(btf);
|
|
|
|
goto free_map_nouncharge;
|
|
|
|
}
|
|
|
|
|
|
|
|
map->btf = btf;
|
2018-05-23 05:57:21 +08:00
|
|
|
map->btf_key_type_id = attr->btf_key_type_id;
|
|
|
|
map->btf_value_type_id = attr->btf_value_type_id;
|
2018-04-19 06:56:03 +08:00
|
|
|
}
|
|
|
|
|
2017-10-19 04:00:24 +08:00
|
|
|
err = security_bpf_map_alloc(map);
|
2015-10-08 13:23:22 +08:00
|
|
|
if (err)
|
2016-11-04 07:56:31 +08:00
|
|
|
goto free_map_nouncharge;
|
2015-10-08 13:23:22 +08:00
|
|
|
|
2018-08-03 05:27:17 +08:00
|
|
|
err = bpf_map_init_memlock(map);
|
2017-10-19 04:00:24 +08:00
|
|
|
if (err)
|
|
|
|
goto free_map_sec;
|
|
|
|
|
2017-06-06 03:15:47 +08:00
|
|
|
err = bpf_map_alloc_id(map);
|
|
|
|
if (err)
|
|
|
|
goto free_map;
|
|
|
|
|
2017-10-19 04:00:22 +08:00
|
|
|
err = bpf_map_new_fd(map, f_flags);
|
2017-06-06 03:15:50 +08:00
|
|
|
if (err < 0) {
|
|
|
|
/* failed to allocate fd.
|
|
|
|
* bpf_map_put() is needed because the above
|
|
|
|
* bpf_map_alloc_id() has published the map
|
|
|
|
* to the userspace and the userspace may
|
|
|
|
* have refcnt-ed it through BPF_MAP_GET_FD_BY_ID.
|
|
|
|
*/
|
|
|
|
bpf_map_put(map);
|
|
|
|
return err;
|
|
|
|
}
|
2014-09-26 15:16:57 +08:00
|
|
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
free_map:
|
2018-08-03 05:27:17 +08:00
|
|
|
bpf_map_release_memlock(map);
|
2017-10-19 04:00:24 +08:00
|
|
|
free_map_sec:
|
|
|
|
security_bpf_map_free(map);
|
2016-11-04 07:56:31 +08:00
|
|
|
free_map_nouncharge:
|
2018-04-19 06:56:03 +08:00
|
|
|
btf_put(map->btf);
|
2014-09-26 15:16:57 +08:00
|
|
|
map->ops->map_free(map);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
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 15:16:59 +08:00
|
|
|
/* if error is returned, fd is released.
|
|
|
|
* On success caller should complete fd access with matching fdput()
|
|
|
|
*/
|
2015-10-29 21:58:07 +08:00
|
|
|
struct bpf_map *__bpf_map_get(struct fd f)
|
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 15:16:59 +08:00
|
|
|
{
|
|
|
|
if (!f.file)
|
|
|
|
return ERR_PTR(-EBADF);
|
|
|
|
if (f.file->f_op != &bpf_map_fops) {
|
|
|
|
fdput(f);
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
}
|
|
|
|
|
2015-10-29 21:58:07 +08:00
|
|
|
return f.file->private_data;
|
|
|
|
}
|
|
|
|
|
2016-04-28 09:56:20 +08:00
|
|
|
/* prog's and map's refcnt limit */
|
|
|
|
#define BPF_MAX_REFCNT 32768
|
|
|
|
|
|
|
|
struct bpf_map *bpf_map_inc(struct bpf_map *map, bool uref)
|
bpf: fix clearing on persistent program array maps
Currently, when having map file descriptors pointing to program arrays,
there's still the issue that we unconditionally flush program array
contents via bpf_fd_array_map_clear() in bpf_map_release(). This happens
when such a file descriptor is released and is independent of the map's
refcount.
Having this flush independent of the refcount is for a reason: there
can be arbitrary complex dependency chains among tail calls, also circular
ones (direct or indirect, nesting limit determined during runtime), and
we need to make sure that the map drops all references to eBPF programs
it holds, so that the map's refcount can eventually drop to zero and
initiate its freeing. Btw, a walk of the whole dependency graph would
not be possible for various reasons, one being complexity and another
one inconsistency, i.e. new programs can be added to parts of the graph
at any time, so there's no guaranteed consistent state for the time of
such a walk.
Now, the program array pinning itself works, but the issue is that each
derived file descriptor on close would nevertheless call unconditionally
into bpf_fd_array_map_clear(). Instead, keep track of users and postpone
this flush until the last reference to a user is dropped. As this only
concerns a subset of references (f.e. a prog array could hold a program
that itself has reference on the prog array holding it, etc), we need to
track them separately.
Short analysis on the refcounting: on map creation time usercnt will be
one, so there's no change in behaviour for bpf_map_release(), if unpinned.
If we already fail in map_create(), we are immediately freed, and no
file descriptor has been made public yet. In bpf_obj_pin_user(), we need
to probe for a possible map in bpf_fd_probe_obj() already with a usercnt
reference, so before we drop the reference on the fd with fdput().
Therefore, if actual pinning fails, we need to drop that reference again
in bpf_any_put(), otherwise we keep holding it. When last reference
drops on the inode, the bpf_any_put() in bpf_evict_inode() will take
care of dropping the usercnt again. In the bpf_obj_get_user() case, the
bpf_any_get() will grab a reference on the usercnt, still at a time when
we have the reference on the path. Should we later on fail to grab a new
file descriptor, bpf_any_put() will drop it, otherwise we hold it until
bpf_map_release() time.
Joint work with Alexei.
Fixes: b2197755b263 ("bpf: add support for persistent maps/progs")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-11-25 04:28:15 +08:00
|
|
|
{
|
2016-04-28 09:56:20 +08:00
|
|
|
if (atomic_inc_return(&map->refcnt) > BPF_MAX_REFCNT) {
|
|
|
|
atomic_dec(&map->refcnt);
|
|
|
|
return ERR_PTR(-EBUSY);
|
|
|
|
}
|
bpf: fix clearing on persistent program array maps
Currently, when having map file descriptors pointing to program arrays,
there's still the issue that we unconditionally flush program array
contents via bpf_fd_array_map_clear() in bpf_map_release(). This happens
when such a file descriptor is released and is independent of the map's
refcount.
Having this flush independent of the refcount is for a reason: there
can be arbitrary complex dependency chains among tail calls, also circular
ones (direct or indirect, nesting limit determined during runtime), and
we need to make sure that the map drops all references to eBPF programs
it holds, so that the map's refcount can eventually drop to zero and
initiate its freeing. Btw, a walk of the whole dependency graph would
not be possible for various reasons, one being complexity and another
one inconsistency, i.e. new programs can be added to parts of the graph
at any time, so there's no guaranteed consistent state for the time of
such a walk.
Now, the program array pinning itself works, but the issue is that each
derived file descriptor on close would nevertheless call unconditionally
into bpf_fd_array_map_clear(). Instead, keep track of users and postpone
this flush until the last reference to a user is dropped. As this only
concerns a subset of references (f.e. a prog array could hold a program
that itself has reference on the prog array holding it, etc), we need to
track them separately.
Short analysis on the refcounting: on map creation time usercnt will be
one, so there's no change in behaviour for bpf_map_release(), if unpinned.
If we already fail in map_create(), we are immediately freed, and no
file descriptor has been made public yet. In bpf_obj_pin_user(), we need
to probe for a possible map in bpf_fd_probe_obj() already with a usercnt
reference, so before we drop the reference on the fd with fdput().
Therefore, if actual pinning fails, we need to drop that reference again
in bpf_any_put(), otherwise we keep holding it. When last reference
drops on the inode, the bpf_any_put() in bpf_evict_inode() will take
care of dropping the usercnt again. In the bpf_obj_get_user() case, the
bpf_any_get() will grab a reference on the usercnt, still at a time when
we have the reference on the path. Should we later on fail to grab a new
file descriptor, bpf_any_put() will drop it, otherwise we hold it until
bpf_map_release() time.
Joint work with Alexei.
Fixes: b2197755b263 ("bpf: add support for persistent maps/progs")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-11-25 04:28:15 +08:00
|
|
|
if (uref)
|
|
|
|
atomic_inc(&map->usercnt);
|
2016-04-28 09:56:20 +08:00
|
|
|
return map;
|
bpf: fix clearing on persistent program array maps
Currently, when having map file descriptors pointing to program arrays,
there's still the issue that we unconditionally flush program array
contents via bpf_fd_array_map_clear() in bpf_map_release(). This happens
when such a file descriptor is released and is independent of the map's
refcount.
Having this flush independent of the refcount is for a reason: there
can be arbitrary complex dependency chains among tail calls, also circular
ones (direct or indirect, nesting limit determined during runtime), and
we need to make sure that the map drops all references to eBPF programs
it holds, so that the map's refcount can eventually drop to zero and
initiate its freeing. Btw, a walk of the whole dependency graph would
not be possible for various reasons, one being complexity and another
one inconsistency, i.e. new programs can be added to parts of the graph
at any time, so there's no guaranteed consistent state for the time of
such a walk.
Now, the program array pinning itself works, but the issue is that each
derived file descriptor on close would nevertheless call unconditionally
into bpf_fd_array_map_clear(). Instead, keep track of users and postpone
this flush until the last reference to a user is dropped. As this only
concerns a subset of references (f.e. a prog array could hold a program
that itself has reference on the prog array holding it, etc), we need to
track them separately.
Short analysis on the refcounting: on map creation time usercnt will be
one, so there's no change in behaviour for bpf_map_release(), if unpinned.
If we already fail in map_create(), we are immediately freed, and no
file descriptor has been made public yet. In bpf_obj_pin_user(), we need
to probe for a possible map in bpf_fd_probe_obj() already with a usercnt
reference, so before we drop the reference on the fd with fdput().
Therefore, if actual pinning fails, we need to drop that reference again
in bpf_any_put(), otherwise we keep holding it. When last reference
drops on the inode, the bpf_any_put() in bpf_evict_inode() will take
care of dropping the usercnt again. In the bpf_obj_get_user() case, the
bpf_any_get() will grab a reference on the usercnt, still at a time when
we have the reference on the path. Should we later on fail to grab a new
file descriptor, bpf_any_put() will drop it, otherwise we hold it until
bpf_map_release() time.
Joint work with Alexei.
Fixes: b2197755b263 ("bpf: add support for persistent maps/progs")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-11-25 04:28:15 +08:00
|
|
|
}
|
2018-05-04 09:37:09 +08:00
|
|
|
EXPORT_SYMBOL_GPL(bpf_map_inc);
|
bpf: fix clearing on persistent program array maps
Currently, when having map file descriptors pointing to program arrays,
there's still the issue that we unconditionally flush program array
contents via bpf_fd_array_map_clear() in bpf_map_release(). This happens
when such a file descriptor is released and is independent of the map's
refcount.
Having this flush independent of the refcount is for a reason: there
can be arbitrary complex dependency chains among tail calls, also circular
ones (direct or indirect, nesting limit determined during runtime), and
we need to make sure that the map drops all references to eBPF programs
it holds, so that the map's refcount can eventually drop to zero and
initiate its freeing. Btw, a walk of the whole dependency graph would
not be possible for various reasons, one being complexity and another
one inconsistency, i.e. new programs can be added to parts of the graph
at any time, so there's no guaranteed consistent state for the time of
such a walk.
Now, the program array pinning itself works, but the issue is that each
derived file descriptor on close would nevertheless call unconditionally
into bpf_fd_array_map_clear(). Instead, keep track of users and postpone
this flush until the last reference to a user is dropped. As this only
concerns a subset of references (f.e. a prog array could hold a program
that itself has reference on the prog array holding it, etc), we need to
track them separately.
Short analysis on the refcounting: on map creation time usercnt will be
one, so there's no change in behaviour for bpf_map_release(), if unpinned.
If we already fail in map_create(), we are immediately freed, and no
file descriptor has been made public yet. In bpf_obj_pin_user(), we need
to probe for a possible map in bpf_fd_probe_obj() already with a usercnt
reference, so before we drop the reference on the fd with fdput().
Therefore, if actual pinning fails, we need to drop that reference again
in bpf_any_put(), otherwise we keep holding it. When last reference
drops on the inode, the bpf_any_put() in bpf_evict_inode() will take
care of dropping the usercnt again. In the bpf_obj_get_user() case, the
bpf_any_get() will grab a reference on the usercnt, still at a time when
we have the reference on the path. Should we later on fail to grab a new
file descriptor, bpf_any_put() will drop it, otherwise we hold it until
bpf_map_release() time.
Joint work with Alexei.
Fixes: b2197755b263 ("bpf: add support for persistent maps/progs")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-11-25 04:28:15 +08:00
|
|
|
|
|
|
|
struct bpf_map *bpf_map_get_with_uref(u32 ufd)
|
2015-10-29 21:58:07 +08:00
|
|
|
{
|
|
|
|
struct fd f = fdget(ufd);
|
|
|
|
struct bpf_map *map;
|
|
|
|
|
|
|
|
map = __bpf_map_get(f);
|
|
|
|
if (IS_ERR(map))
|
|
|
|
return map;
|
|
|
|
|
2016-04-28 09:56:20 +08:00
|
|
|
map = bpf_map_inc(map, true);
|
2015-10-29 21:58:07 +08:00
|
|
|
fdput(f);
|
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 15:16:59 +08:00
|
|
|
|
|
|
|
return map;
|
|
|
|
}
|
|
|
|
|
2017-06-06 03:15:50 +08:00
|
|
|
/* map_idr_lock should have been held */
|
|
|
|
static struct bpf_map *bpf_map_inc_not_zero(struct bpf_map *map,
|
|
|
|
bool uref)
|
|
|
|
{
|
|
|
|
int refold;
|
|
|
|
|
atomics/treewide: Rename __atomic_add_unless() => atomic_fetch_add_unless()
While __atomic_add_unless() was originally intended as a building-block
for atomic_add_unless(), it's now used in a number of places around the
kernel. It's the only common atomic operation named __atomic*(), rather
than atomic_*(), and for consistency it would be better named
atomic_fetch_add_unless().
This lack of consistency is slightly confusing, and gets in the way of
scripting atomics. Given that, let's clean things up and promote it to
an official part of the atomics API, in the form of
atomic_fetch_add_unless().
This patch converts definitions and invocations over to the new name,
including the instrumented version, using the following script:
----
git grep -w __atomic_add_unless | while read line; do
sed -i '{s/\<__atomic_add_unless\>/atomic_fetch_add_unless/}' "${line%%:*}";
done
git grep -w __arch_atomic_add_unless | while read line; do
sed -i '{s/\<__arch_atomic_add_unless\>/arch_atomic_fetch_add_unless/}' "${line%%:*}";
done
----
Note that we do not have atomic{64,_long}_fetch_add_unless(), which will
be introduced by later patches.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Will Deacon <will.deacon@arm.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Palmer Dabbelt <palmer@sifive.com>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/lkml/20180621121321.4761-2-mark.rutland@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-06-21 20:13:04 +08:00
|
|
|
refold = atomic_fetch_add_unless(&map->refcnt, 1, 0);
|
2017-06-06 03:15:50 +08:00
|
|
|
|
|
|
|
if (refold >= BPF_MAX_REFCNT) {
|
|
|
|
__bpf_map_put(map, false);
|
|
|
|
return ERR_PTR(-EBUSY);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!refold)
|
|
|
|
return ERR_PTR(-ENOENT);
|
|
|
|
|
|
|
|
if (uref)
|
|
|
|
atomic_inc(&map->usercnt);
|
|
|
|
|
|
|
|
return map;
|
|
|
|
}
|
|
|
|
|
2016-03-10 10:56:49 +08:00
|
|
|
int __weak bpf_stackmap_copy(struct bpf_map *map, void *key, void *value)
|
|
|
|
{
|
|
|
|
return -ENOTSUPP;
|
|
|
|
}
|
|
|
|
|
2018-10-18 21:16:14 +08:00
|
|
|
static void *__bpf_copy_key(void __user *ukey, u64 key_size)
|
|
|
|
{
|
|
|
|
if (key_size)
|
|
|
|
return memdup_user(ukey, key_size);
|
|
|
|
|
|
|
|
if (ukey)
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
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 15:16:59 +08:00
|
|
|
/* last field in 'union bpf_attr' used by this command */
|
|
|
|
#define BPF_MAP_LOOKUP_ELEM_LAST_FIELD value
|
|
|
|
|
|
|
|
static int map_lookup_elem(union bpf_attr *attr)
|
|
|
|
{
|
2016-11-14 02:44:03 +08:00
|
|
|
void __user *ukey = u64_to_user_ptr(attr->key);
|
|
|
|
void __user *uvalue = u64_to_user_ptr(attr->value);
|
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 15:16:59 +08:00
|
|
|
int ufd = attr->map_fd;
|
|
|
|
struct bpf_map *map;
|
2015-01-23 09:11:08 +08:00
|
|
|
void *key, *value, *ptr;
|
bpf: add lookup/update support for per-cpu hash and array maps
The functions bpf_map_lookup_elem(map, key, value) and
bpf_map_update_elem(map, key, value, flags) need to get/set
values from all-cpus for per-cpu hash and array maps,
so that user space can aggregate/update them as necessary.
Example of single counter aggregation in user space:
unsigned int nr_cpus = sysconf(_SC_NPROCESSORS_CONF);
long values[nr_cpus];
long value = 0;
bpf_lookup_elem(fd, key, values);
for (i = 0; i < nr_cpus; i++)
value += values[i];
The user space must provide round_up(value_size, 8) * nr_cpus
array to get/set values, since kernel will use 'long' copy
of per-cpu values to try to copy good counters atomically.
It's a best-effort, since bpf programs and user space are racing
to access the same memory.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-02 14:39:55 +08:00
|
|
|
u32 value_size;
|
2015-09-09 00:00:09 +08:00
|
|
|
struct fd f;
|
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 15:16:59 +08:00
|
|
|
int err;
|
|
|
|
|
|
|
|
if (CHECK_ATTR(BPF_MAP_LOOKUP_ELEM))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2015-09-09 00:00:09 +08:00
|
|
|
f = fdget(ufd);
|
2015-10-29 21:58:07 +08:00
|
|
|
map = __bpf_map_get(f);
|
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 15:16:59 +08:00
|
|
|
if (IS_ERR(map))
|
|
|
|
return PTR_ERR(map);
|
|
|
|
|
2017-10-19 04:00:22 +08:00
|
|
|
if (!(f.file->f_mode & FMODE_CAN_READ)) {
|
|
|
|
err = -EPERM;
|
|
|
|
goto err_put;
|
|
|
|
}
|
|
|
|
|
2018-10-18 21:16:14 +08:00
|
|
|
key = __bpf_copy_key(ukey, map->key_size);
|
2017-05-14 06:43:00 +08:00
|
|
|
if (IS_ERR(key)) {
|
|
|
|
err = PTR_ERR(key);
|
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 15:16:59 +08:00
|
|
|
goto err_put;
|
2017-05-14 06:43:00 +08: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 15:16:59 +08:00
|
|
|
|
bpf: add lookup/update support for per-cpu hash and array maps
The functions bpf_map_lookup_elem(map, key, value) and
bpf_map_update_elem(map, key, value, flags) need to get/set
values from all-cpus for per-cpu hash and array maps,
so that user space can aggregate/update them as necessary.
Example of single counter aggregation in user space:
unsigned int nr_cpus = sysconf(_SC_NPROCESSORS_CONF);
long values[nr_cpus];
long value = 0;
bpf_lookup_elem(fd, key, values);
for (i = 0; i < nr_cpus; i++)
value += values[i];
The user space must provide round_up(value_size, 8) * nr_cpus
array to get/set values, since kernel will use 'long' copy
of per-cpu values to try to copy good counters atomically.
It's a best-effort, since bpf programs and user space are racing
to access the same memory.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-02 14:39:55 +08:00
|
|
|
if (map->map_type == BPF_MAP_TYPE_PERCPU_HASH ||
|
2016-11-12 02:55:10 +08:00
|
|
|
map->map_type == BPF_MAP_TYPE_LRU_PERCPU_HASH ||
|
2018-09-28 22:45:43 +08:00
|
|
|
map->map_type == BPF_MAP_TYPE_PERCPU_ARRAY ||
|
|
|
|
map->map_type == BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE)
|
bpf: add lookup/update support for per-cpu hash and array maps
The functions bpf_map_lookup_elem(map, key, value) and
bpf_map_update_elem(map, key, value, flags) need to get/set
values from all-cpus for per-cpu hash and array maps,
so that user space can aggregate/update them as necessary.
Example of single counter aggregation in user space:
unsigned int nr_cpus = sysconf(_SC_NPROCESSORS_CONF);
long values[nr_cpus];
long value = 0;
bpf_lookup_elem(fd, key, values);
for (i = 0; i < nr_cpus; i++)
value += values[i];
The user space must provide round_up(value_size, 8) * nr_cpus
array to get/set values, since kernel will use 'long' copy
of per-cpu values to try to copy good counters atomically.
It's a best-effort, since bpf programs and user space are racing
to access the same memory.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-02 14:39:55 +08:00
|
|
|
value_size = round_up(map->value_size, 8) * num_possible_cpus();
|
2017-06-28 14:08:34 +08:00
|
|
|
else if (IS_FD_MAP(map))
|
|
|
|
value_size = sizeof(u32);
|
bpf: add lookup/update support for per-cpu hash and array maps
The functions bpf_map_lookup_elem(map, key, value) and
bpf_map_update_elem(map, key, value, flags) need to get/set
values from all-cpus for per-cpu hash and array maps,
so that user space can aggregate/update them as necessary.
Example of single counter aggregation in user space:
unsigned int nr_cpus = sysconf(_SC_NPROCESSORS_CONF);
long values[nr_cpus];
long value = 0;
bpf_lookup_elem(fd, key, values);
for (i = 0; i < nr_cpus; i++)
value += values[i];
The user space must provide round_up(value_size, 8) * nr_cpus
array to get/set values, since kernel will use 'long' copy
of per-cpu values to try to copy good counters atomically.
It's a best-effort, since bpf programs and user space are racing
to access the same memory.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-02 14:39:55 +08:00
|
|
|
else
|
|
|
|
value_size = map->value_size;
|
|
|
|
|
2015-01-23 09:11:08 +08:00
|
|
|
err = -ENOMEM;
|
bpf: add lookup/update support for per-cpu hash and array maps
The functions bpf_map_lookup_elem(map, key, value) and
bpf_map_update_elem(map, key, value, flags) need to get/set
values from all-cpus for per-cpu hash and array maps,
so that user space can aggregate/update them as necessary.
Example of single counter aggregation in user space:
unsigned int nr_cpus = sysconf(_SC_NPROCESSORS_CONF);
long values[nr_cpus];
long value = 0;
bpf_lookup_elem(fd, key, values);
for (i = 0; i < nr_cpus; i++)
value += values[i];
The user space must provide round_up(value_size, 8) * nr_cpus
array to get/set values, since kernel will use 'long' copy
of per-cpu values to try to copy good counters atomically.
It's a best-effort, since bpf programs and user space are racing
to access the same memory.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-02 14:39:55 +08:00
|
|
|
value = kmalloc(value_size, GFP_USER | __GFP_NOWARN);
|
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 15:16:59 +08:00
|
|
|
if (!value)
|
2015-01-23 09:11:08 +08:00
|
|
|
goto free_key;
|
|
|
|
|
2018-01-12 12:29:09 +08:00
|
|
|
if (bpf_map_is_dev_bound(map)) {
|
|
|
|
err = bpf_map_offload_lookup_elem(map, key, value);
|
|
|
|
} else if (map->map_type == BPF_MAP_TYPE_PERCPU_HASH ||
|
|
|
|
map->map_type == BPF_MAP_TYPE_LRU_PERCPU_HASH) {
|
bpf: add lookup/update support for per-cpu hash and array maps
The functions bpf_map_lookup_elem(map, key, value) and
bpf_map_update_elem(map, key, value, flags) need to get/set
values from all-cpus for per-cpu hash and array maps,
so that user space can aggregate/update them as necessary.
Example of single counter aggregation in user space:
unsigned int nr_cpus = sysconf(_SC_NPROCESSORS_CONF);
long values[nr_cpus];
long value = 0;
bpf_lookup_elem(fd, key, values);
for (i = 0; i < nr_cpus; i++)
value += values[i];
The user space must provide round_up(value_size, 8) * nr_cpus
array to get/set values, since kernel will use 'long' copy
of per-cpu values to try to copy good counters atomically.
It's a best-effort, since bpf programs and user space are racing
to access the same memory.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-02 14:39:55 +08:00
|
|
|
err = bpf_percpu_hash_copy(map, key, value);
|
|
|
|
} else if (map->map_type == BPF_MAP_TYPE_PERCPU_ARRAY) {
|
|
|
|
err = bpf_percpu_array_copy(map, key, value);
|
2018-09-28 22:45:43 +08:00
|
|
|
} else if (map->map_type == BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE) {
|
|
|
|
err = bpf_percpu_cgroup_storage_copy(map, key, value);
|
2016-03-08 13:57:17 +08:00
|
|
|
} else if (map->map_type == BPF_MAP_TYPE_STACK_TRACE) {
|
|
|
|
err = bpf_stackmap_copy(map, key, value);
|
2017-06-28 14:08:34 +08:00
|
|
|
} else if (IS_FD_ARRAY(map)) {
|
|
|
|
err = bpf_fd_array_map_lookup_elem(map, key, value);
|
|
|
|
} else if (IS_FD_HASH(map)) {
|
|
|
|
err = bpf_fd_htab_map_lookup_elem(map, key, value);
|
bpf: Introduce BPF_MAP_TYPE_REUSEPORT_SOCKARRAY
This patch introduces a new map type BPF_MAP_TYPE_REUSEPORT_SOCKARRAY.
To unleash the full potential of a bpf prog, it is essential for the
userspace to be capable of directly setting up a bpf map which can then
be consumed by the bpf prog to make decision. In this case, decide which
SO_REUSEPORT sk to serve the incoming request.
By adding BPF_MAP_TYPE_REUSEPORT_SOCKARRAY, the userspace has total control
and visibility on where a SO_REUSEPORT sk should be located in a bpf map.
The later patch will introduce BPF_PROG_TYPE_SK_REUSEPORT such that
the bpf prog can directly select a sk from the bpf map. That will
raise the programmability of the bpf prog attached to a reuseport
group (a group of sk serving the same IP:PORT).
For example, in UDP, the bpf prog can peek into the payload (e.g.
through the "data" pointer introduced in the later patch) to learn
the application level's connection information and then decide which sk
to pick from a bpf map. The userspace can tightly couple the sk's location
in a bpf map with the application logic in generating the UDP payload's
connection information. This connection info contact/API stays within the
userspace.
Also, when used with map-in-map, the userspace can switch the
old-server-process's inner map to a new-server-process's inner map
in one call "bpf_map_update_elem(outer_map, &index, &new_reuseport_array)".
The bpf prog will then direct incoming requests to the new process instead
of the old process. The old process can finish draining the pending
requests (e.g. by "accept()") before closing the old-fds. [Note that
deleting a fd from a bpf map does not necessary mean the fd is closed]
During map_update_elem(),
Only SO_REUSEPORT sk (i.e. which has already been added
to a reuse->socks[]) can be used. That means a SO_REUSEPORT sk that is
"bind()" for UDP or "bind()+listen()" for TCP. These conditions are
ensured in "reuseport_array_update_check()".
A SO_REUSEPORT sk can only be added once to a map (i.e. the
same sk cannot be added twice even to the same map). SO_REUSEPORT
already allows another sk to be created for the same IP:PORT.
There is no need to re-create a similar usage in the BPF side.
When a SO_REUSEPORT is deleted from the "reuse->socks[]" (e.g. "close()"),
it will notify the bpf map to remove it from the map also. It is
done through "bpf_sk_reuseport_detach()" and it will only be called
if >=1 of the "reuse->sock[]" has ever been added to a bpf map.
The map_update()/map_delete() has to be in-sync with the
"reuse->socks[]". Hence, the same "reuseport_lock" used
by "reuse->socks[]" has to be used here also. Care has
been taken to ensure the lock is only acquired when the
adding sk passes some strict tests. and
freeing the map does not require the reuseport_lock.
The reuseport_array will also support lookup from the syscall
side. It will return a sock_gen_cookie(). The sock_gen_cookie()
is on-demand (i.e. a sk's cookie is not generated until the very
first map_lookup_elem()).
The lookup cookie is 64bits but it goes against the logical userspace
expectation on 32bits sizeof(fd) (and as other fd based bpf maps do also).
It may catch user in surprise if we enforce value_size=8 while
userspace still pass a 32bits fd during update. Supporting different
value_size between lookup and update seems unintuitive also.
We also need to consider what if other existing fd based maps want
to return 64bits value from syscall's lookup in the future.
Hence, reuseport_array supports both value_size 4 and 8, and
assuming user will usually use value_size=4. The syscall's lookup
will return ENOSPC on value_size=4. It will will only
return 64bits value from sock_gen_cookie() when user consciously
choose value_size=8 (as a signal that lookup is desired) which then
requires a 64bits value in both lookup and update.
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-08-08 16:01:24 +08:00
|
|
|
} else if (map->map_type == BPF_MAP_TYPE_REUSEPORT_SOCKARRAY) {
|
|
|
|
err = bpf_fd_reuseport_array_lookup_elem(map, key, value);
|
2018-10-18 21:16:25 +08:00
|
|
|
} else if (map->map_type == BPF_MAP_TYPE_QUEUE ||
|
|
|
|
map->map_type == BPF_MAP_TYPE_STACK) {
|
|
|
|
err = map->ops->map_peek_elem(map, value);
|
bpf: add lookup/update support for per-cpu hash and array maps
The functions bpf_map_lookup_elem(map, key, value) and
bpf_map_update_elem(map, key, value, flags) need to get/set
values from all-cpus for per-cpu hash and array maps,
so that user space can aggregate/update them as necessary.
Example of single counter aggregation in user space:
unsigned int nr_cpus = sysconf(_SC_NPROCESSORS_CONF);
long values[nr_cpus];
long value = 0;
bpf_lookup_elem(fd, key, values);
for (i = 0; i < nr_cpus; i++)
value += values[i];
The user space must provide round_up(value_size, 8) * nr_cpus
array to get/set values, since kernel will use 'long' copy
of per-cpu values to try to copy good counters atomically.
It's a best-effort, since bpf programs and user space are racing
to access the same memory.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-02 14:39:55 +08:00
|
|
|
} else {
|
|
|
|
rcu_read_lock();
|
|
|
|
ptr = map->ops->map_lookup_elem(map, key);
|
2018-10-09 09:04:49 +08:00
|
|
|
if (IS_ERR(ptr)) {
|
|
|
|
err = PTR_ERR(ptr);
|
|
|
|
} else if (!ptr) {
|
|
|
|
err = -ENOENT;
|
|
|
|
} else {
|
|
|
|
err = 0;
|
bpf: add lookup/update support for per-cpu hash and array maps
The functions bpf_map_lookup_elem(map, key, value) and
bpf_map_update_elem(map, key, value, flags) need to get/set
values from all-cpus for per-cpu hash and array maps,
so that user space can aggregate/update them as necessary.
Example of single counter aggregation in user space:
unsigned int nr_cpus = sysconf(_SC_NPROCESSORS_CONF);
long values[nr_cpus];
long value = 0;
bpf_lookup_elem(fd, key, values);
for (i = 0; i < nr_cpus; i++)
value += values[i];
The user space must provide round_up(value_size, 8) * nr_cpus
array to get/set values, since kernel will use 'long' copy
of per-cpu values to try to copy good counters atomically.
It's a best-effort, since bpf programs and user space are racing
to access the same memory.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-02 14:39:55 +08:00
|
|
|
memcpy(value, ptr, value_size);
|
2018-10-09 09:04:49 +08:00
|
|
|
}
|
bpf: add lookup/update support for per-cpu hash and array maps
The functions bpf_map_lookup_elem(map, key, value) and
bpf_map_update_elem(map, key, value, flags) need to get/set
values from all-cpus for per-cpu hash and array maps,
so that user space can aggregate/update them as necessary.
Example of single counter aggregation in user space:
unsigned int nr_cpus = sysconf(_SC_NPROCESSORS_CONF);
long values[nr_cpus];
long value = 0;
bpf_lookup_elem(fd, key, values);
for (i = 0; i < nr_cpus; i++)
value += values[i];
The user space must provide round_up(value_size, 8) * nr_cpus
array to get/set values, since kernel will use 'long' copy
of per-cpu values to try to copy good counters atomically.
It's a best-effort, since bpf programs and user space are racing
to access the same memory.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-02 14:39:55 +08:00
|
|
|
rcu_read_unlock();
|
|
|
|
}
|
2015-01-23 09:11:08 +08:00
|
|
|
|
bpf: add lookup/update support for per-cpu hash and array maps
The functions bpf_map_lookup_elem(map, key, value) and
bpf_map_update_elem(map, key, value, flags) need to get/set
values from all-cpus for per-cpu hash and array maps,
so that user space can aggregate/update them as necessary.
Example of single counter aggregation in user space:
unsigned int nr_cpus = sysconf(_SC_NPROCESSORS_CONF);
long values[nr_cpus];
long value = 0;
bpf_lookup_elem(fd, key, values);
for (i = 0; i < nr_cpus; i++)
value += values[i];
The user space must provide round_up(value_size, 8) * nr_cpus
array to get/set values, since kernel will use 'long' copy
of per-cpu values to try to copy good counters atomically.
It's a best-effort, since bpf programs and user space are racing
to access the same memory.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-02 14:39:55 +08:00
|
|
|
if (err)
|
2015-01-23 09:11:08 +08:00
|
|
|
goto free_value;
|
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 15:16:59 +08:00
|
|
|
|
|
|
|
err = -EFAULT;
|
bpf: add lookup/update support for per-cpu hash and array maps
The functions bpf_map_lookup_elem(map, key, value) and
bpf_map_update_elem(map, key, value, flags) need to get/set
values from all-cpus for per-cpu hash and array maps,
so that user space can aggregate/update them as necessary.
Example of single counter aggregation in user space:
unsigned int nr_cpus = sysconf(_SC_NPROCESSORS_CONF);
long values[nr_cpus];
long value = 0;
bpf_lookup_elem(fd, key, values);
for (i = 0; i < nr_cpus; i++)
value += values[i];
The user space must provide round_up(value_size, 8) * nr_cpus
array to get/set values, since kernel will use 'long' copy
of per-cpu values to try to copy good counters atomically.
It's a best-effort, since bpf programs and user space are racing
to access the same memory.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-02 14:39:55 +08:00
|
|
|
if (copy_to_user(uvalue, value, value_size) != 0)
|
2015-01-23 09:11:08 +08:00
|
|
|
goto free_value;
|
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 15:16:59 +08:00
|
|
|
|
|
|
|
err = 0;
|
|
|
|
|
2015-01-23 09:11:08 +08:00
|
|
|
free_value:
|
|
|
|
kfree(value);
|
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 15:16:59 +08:00
|
|
|
free_key:
|
|
|
|
kfree(key);
|
|
|
|
err_put:
|
|
|
|
fdput(f);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2018-10-12 18:54:27 +08:00
|
|
|
static void maybe_wait_bpf_programs(struct bpf_map *map)
|
|
|
|
{
|
|
|
|
/* Wait for any running BPF programs to complete so that
|
|
|
|
* userspace, when we return to it, knows that all programs
|
|
|
|
* that could be running use the new map value.
|
|
|
|
*/
|
|
|
|
if (map->map_type == BPF_MAP_TYPE_HASH_OF_MAPS ||
|
|
|
|
map->map_type == BPF_MAP_TYPE_ARRAY_OF_MAPS)
|
|
|
|
synchronize_rcu();
|
|
|
|
}
|
|
|
|
|
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 09:36:44 +08:00
|
|
|
#define BPF_MAP_UPDATE_ELEM_LAST_FIELD 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 15:16:59 +08:00
|
|
|
|
|
|
|
static int map_update_elem(union bpf_attr *attr)
|
|
|
|
{
|
2016-11-14 02:44:03 +08:00
|
|
|
void __user *ukey = u64_to_user_ptr(attr->key);
|
|
|
|
void __user *uvalue = u64_to_user_ptr(attr->value);
|
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 15:16:59 +08:00
|
|
|
int ufd = attr->map_fd;
|
|
|
|
struct bpf_map *map;
|
|
|
|
void *key, *value;
|
bpf: add lookup/update support for per-cpu hash and array maps
The functions bpf_map_lookup_elem(map, key, value) and
bpf_map_update_elem(map, key, value, flags) need to get/set
values from all-cpus for per-cpu hash and array maps,
so that user space can aggregate/update them as necessary.
Example of single counter aggregation in user space:
unsigned int nr_cpus = sysconf(_SC_NPROCESSORS_CONF);
long values[nr_cpus];
long value = 0;
bpf_lookup_elem(fd, key, values);
for (i = 0; i < nr_cpus; i++)
value += values[i];
The user space must provide round_up(value_size, 8) * nr_cpus
array to get/set values, since kernel will use 'long' copy
of per-cpu values to try to copy good counters atomically.
It's a best-effort, since bpf programs and user space are racing
to access the same memory.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-02 14:39:55 +08:00
|
|
|
u32 value_size;
|
2015-09-09 00:00:09 +08:00
|
|
|
struct fd f;
|
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 15:16:59 +08:00
|
|
|
int err;
|
|
|
|
|
|
|
|
if (CHECK_ATTR(BPF_MAP_UPDATE_ELEM))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2015-09-09 00:00:09 +08:00
|
|
|
f = fdget(ufd);
|
2015-10-29 21:58:07 +08:00
|
|
|
map = __bpf_map_get(f);
|
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 15:16:59 +08:00
|
|
|
if (IS_ERR(map))
|
|
|
|
return PTR_ERR(map);
|
|
|
|
|
2017-10-19 04:00:22 +08:00
|
|
|
if (!(f.file->f_mode & FMODE_CAN_WRITE)) {
|
|
|
|
err = -EPERM;
|
|
|
|
goto err_put;
|
|
|
|
}
|
|
|
|
|
2018-10-18 21:16:14 +08:00
|
|
|
key = __bpf_copy_key(ukey, map->key_size);
|
2017-05-14 06:43:00 +08:00
|
|
|
if (IS_ERR(key)) {
|
|
|
|
err = PTR_ERR(key);
|
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 15:16:59 +08:00
|
|
|
goto err_put;
|
2017-05-14 06:43:00 +08: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 15:16:59 +08:00
|
|
|
|
bpf: add lookup/update support for per-cpu hash and array maps
The functions bpf_map_lookup_elem(map, key, value) and
bpf_map_update_elem(map, key, value, flags) need to get/set
values from all-cpus for per-cpu hash and array maps,
so that user space can aggregate/update them as necessary.
Example of single counter aggregation in user space:
unsigned int nr_cpus = sysconf(_SC_NPROCESSORS_CONF);
long values[nr_cpus];
long value = 0;
bpf_lookup_elem(fd, key, values);
for (i = 0; i < nr_cpus; i++)
value += values[i];
The user space must provide round_up(value_size, 8) * nr_cpus
array to get/set values, since kernel will use 'long' copy
of per-cpu values to try to copy good counters atomically.
It's a best-effort, since bpf programs and user space are racing
to access the same memory.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-02 14:39:55 +08:00
|
|
|
if (map->map_type == BPF_MAP_TYPE_PERCPU_HASH ||
|
2016-11-12 02:55:10 +08:00
|
|
|
map->map_type == BPF_MAP_TYPE_LRU_PERCPU_HASH ||
|
2018-09-28 22:45:43 +08:00
|
|
|
map->map_type == BPF_MAP_TYPE_PERCPU_ARRAY ||
|
|
|
|
map->map_type == BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE)
|
bpf: add lookup/update support for per-cpu hash and array maps
The functions bpf_map_lookup_elem(map, key, value) and
bpf_map_update_elem(map, key, value, flags) need to get/set
values from all-cpus for per-cpu hash and array maps,
so that user space can aggregate/update them as necessary.
Example of single counter aggregation in user space:
unsigned int nr_cpus = sysconf(_SC_NPROCESSORS_CONF);
long values[nr_cpus];
long value = 0;
bpf_lookup_elem(fd, key, values);
for (i = 0; i < nr_cpus; i++)
value += values[i];
The user space must provide round_up(value_size, 8) * nr_cpus
array to get/set values, since kernel will use 'long' copy
of per-cpu values to try to copy good counters atomically.
It's a best-effort, since bpf programs and user space are racing
to access the same memory.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-02 14:39:55 +08:00
|
|
|
value_size = round_up(map->value_size, 8) * num_possible_cpus();
|
|
|
|
else
|
|
|
|
value_size = map->value_size;
|
|
|
|
|
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 15:16:59 +08:00
|
|
|
err = -ENOMEM;
|
bpf: add lookup/update support for per-cpu hash and array maps
The functions bpf_map_lookup_elem(map, key, value) and
bpf_map_update_elem(map, key, value, flags) need to get/set
values from all-cpus for per-cpu hash and array maps,
so that user space can aggregate/update them as necessary.
Example of single counter aggregation in user space:
unsigned int nr_cpus = sysconf(_SC_NPROCESSORS_CONF);
long values[nr_cpus];
long value = 0;
bpf_lookup_elem(fd, key, values);
for (i = 0; i < nr_cpus; i++)
value += values[i];
The user space must provide round_up(value_size, 8) * nr_cpus
array to get/set values, since kernel will use 'long' copy
of per-cpu values to try to copy good counters atomically.
It's a best-effort, since bpf programs and user space are racing
to access the same memory.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-02 14:39:55 +08:00
|
|
|
value = kmalloc(value_size, GFP_USER | __GFP_NOWARN);
|
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 15:16:59 +08:00
|
|
|
if (!value)
|
|
|
|
goto free_key;
|
|
|
|
|
|
|
|
err = -EFAULT;
|
bpf: add lookup/update support for per-cpu hash and array maps
The functions bpf_map_lookup_elem(map, key, value) and
bpf_map_update_elem(map, key, value, flags) need to get/set
values from all-cpus for per-cpu hash and array maps,
so that user space can aggregate/update them as necessary.
Example of single counter aggregation in user space:
unsigned int nr_cpus = sysconf(_SC_NPROCESSORS_CONF);
long values[nr_cpus];
long value = 0;
bpf_lookup_elem(fd, key, values);
for (i = 0; i < nr_cpus; i++)
value += values[i];
The user space must provide round_up(value_size, 8) * nr_cpus
array to get/set values, since kernel will use 'long' copy
of per-cpu values to try to copy good counters atomically.
It's a best-effort, since bpf programs and user space are racing
to access the same memory.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-02 14:39:55 +08:00
|
|
|
if (copy_from_user(value, uvalue, value_size) != 0)
|
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 15:16:59 +08:00
|
|
|
goto free_value;
|
|
|
|
|
2017-10-16 18:19:28 +08:00
|
|
|
/* Need to create a kthread, thus must support schedule */
|
2018-01-12 12:29:09 +08:00
|
|
|
if (bpf_map_is_dev_bound(map)) {
|
|
|
|
err = bpf_map_offload_update_elem(map, key, value, attr->flags);
|
|
|
|
goto out;
|
2018-07-05 23:50:04 +08:00
|
|
|
} else if (map->map_type == BPF_MAP_TYPE_CPUMAP ||
|
|
|
|
map->map_type == BPF_MAP_TYPE_SOCKHASH ||
|
|
|
|
map->map_type == BPF_MAP_TYPE_SOCKMAP) {
|
2017-10-16 18:19:28 +08:00
|
|
|
err = map->ops->map_update_elem(map, key, value, attr->flags);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2016-03-08 13:57:13 +08:00
|
|
|
/* must increment bpf_prog_active to avoid kprobe+bpf triggering from
|
|
|
|
* inside bpf map update or delete otherwise deadlocks are possible
|
|
|
|
*/
|
|
|
|
preempt_disable();
|
|
|
|
__this_cpu_inc(bpf_prog_active);
|
2016-11-12 02:55:10 +08:00
|
|
|
if (map->map_type == BPF_MAP_TYPE_PERCPU_HASH ||
|
|
|
|
map->map_type == BPF_MAP_TYPE_LRU_PERCPU_HASH) {
|
bpf: add lookup/update support for per-cpu hash and array maps
The functions bpf_map_lookup_elem(map, key, value) and
bpf_map_update_elem(map, key, value, flags) need to get/set
values from all-cpus for per-cpu hash and array maps,
so that user space can aggregate/update them as necessary.
Example of single counter aggregation in user space:
unsigned int nr_cpus = sysconf(_SC_NPROCESSORS_CONF);
long values[nr_cpus];
long value = 0;
bpf_lookup_elem(fd, key, values);
for (i = 0; i < nr_cpus; i++)
value += values[i];
The user space must provide round_up(value_size, 8) * nr_cpus
array to get/set values, since kernel will use 'long' copy
of per-cpu values to try to copy good counters atomically.
It's a best-effort, since bpf programs and user space are racing
to access the same memory.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-02 14:39:55 +08:00
|
|
|
err = bpf_percpu_hash_update(map, key, value, attr->flags);
|
|
|
|
} else if (map->map_type == BPF_MAP_TYPE_PERCPU_ARRAY) {
|
|
|
|
err = bpf_percpu_array_update(map, key, value, attr->flags);
|
2018-09-28 22:45:43 +08:00
|
|
|
} else if (map->map_type == BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE) {
|
|
|
|
err = bpf_percpu_cgroup_storage_update(map, key, value,
|
|
|
|
attr->flags);
|
2018-01-26 07:54:02 +08:00
|
|
|
} else if (IS_FD_ARRAY(map)) {
|
2016-06-16 04:47:13 +08:00
|
|
|
rcu_read_lock();
|
|
|
|
err = bpf_fd_array_map_update_elem(map, f.file, key, value,
|
|
|
|
attr->flags);
|
|
|
|
rcu_read_unlock();
|
2017-03-23 01:00:34 +08:00
|
|
|
} else if (map->map_type == BPF_MAP_TYPE_HASH_OF_MAPS) {
|
|
|
|
rcu_read_lock();
|
|
|
|
err = bpf_fd_htab_map_update_elem(map, f.file, key, value,
|
|
|
|
attr->flags);
|
|
|
|
rcu_read_unlock();
|
bpf: Introduce BPF_MAP_TYPE_REUSEPORT_SOCKARRAY
This patch introduces a new map type BPF_MAP_TYPE_REUSEPORT_SOCKARRAY.
To unleash the full potential of a bpf prog, it is essential for the
userspace to be capable of directly setting up a bpf map which can then
be consumed by the bpf prog to make decision. In this case, decide which
SO_REUSEPORT sk to serve the incoming request.
By adding BPF_MAP_TYPE_REUSEPORT_SOCKARRAY, the userspace has total control
and visibility on where a SO_REUSEPORT sk should be located in a bpf map.
The later patch will introduce BPF_PROG_TYPE_SK_REUSEPORT such that
the bpf prog can directly select a sk from the bpf map. That will
raise the programmability of the bpf prog attached to a reuseport
group (a group of sk serving the same IP:PORT).
For example, in UDP, the bpf prog can peek into the payload (e.g.
through the "data" pointer introduced in the later patch) to learn
the application level's connection information and then decide which sk
to pick from a bpf map. The userspace can tightly couple the sk's location
in a bpf map with the application logic in generating the UDP payload's
connection information. This connection info contact/API stays within the
userspace.
Also, when used with map-in-map, the userspace can switch the
old-server-process's inner map to a new-server-process's inner map
in one call "bpf_map_update_elem(outer_map, &index, &new_reuseport_array)".
The bpf prog will then direct incoming requests to the new process instead
of the old process. The old process can finish draining the pending
requests (e.g. by "accept()") before closing the old-fds. [Note that
deleting a fd from a bpf map does not necessary mean the fd is closed]
During map_update_elem(),
Only SO_REUSEPORT sk (i.e. which has already been added
to a reuse->socks[]) can be used. That means a SO_REUSEPORT sk that is
"bind()" for UDP or "bind()+listen()" for TCP. These conditions are
ensured in "reuseport_array_update_check()".
A SO_REUSEPORT sk can only be added once to a map (i.e. the
same sk cannot be added twice even to the same map). SO_REUSEPORT
already allows another sk to be created for the same IP:PORT.
There is no need to re-create a similar usage in the BPF side.
When a SO_REUSEPORT is deleted from the "reuse->socks[]" (e.g. "close()"),
it will notify the bpf map to remove it from the map also. It is
done through "bpf_sk_reuseport_detach()" and it will only be called
if >=1 of the "reuse->sock[]" has ever been added to a bpf map.
The map_update()/map_delete() has to be in-sync with the
"reuse->socks[]". Hence, the same "reuseport_lock" used
by "reuse->socks[]" has to be used here also. Care has
been taken to ensure the lock is only acquired when the
adding sk passes some strict tests. and
freeing the map does not require the reuseport_lock.
The reuseport_array will also support lookup from the syscall
side. It will return a sock_gen_cookie(). The sock_gen_cookie()
is on-demand (i.e. a sk's cookie is not generated until the very
first map_lookup_elem()).
The lookup cookie is 64bits but it goes against the logical userspace
expectation on 32bits sizeof(fd) (and as other fd based bpf maps do also).
It may catch user in surprise if we enforce value_size=8 while
userspace still pass a 32bits fd during update. Supporting different
value_size between lookup and update seems unintuitive also.
We also need to consider what if other existing fd based maps want
to return 64bits value from syscall's lookup in the future.
Hence, reuseport_array supports both value_size 4 and 8, and
assuming user will usually use value_size=4. The syscall's lookup
will return ENOSPC on value_size=4. It will will only
return 64bits value from sock_gen_cookie() when user consciously
choose value_size=8 (as a signal that lookup is desired) which then
requires a 64bits value in both lookup and update.
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-08-08 16:01:24 +08:00
|
|
|
} else if (map->map_type == BPF_MAP_TYPE_REUSEPORT_SOCKARRAY) {
|
|
|
|
/* rcu_read_lock() is not needed */
|
|
|
|
err = bpf_fd_reuseport_array_update_elem(map, key, value,
|
|
|
|
attr->flags);
|
2018-10-18 21:16:25 +08:00
|
|
|
} else if (map->map_type == BPF_MAP_TYPE_QUEUE ||
|
|
|
|
map->map_type == BPF_MAP_TYPE_STACK) {
|
|
|
|
err = map->ops->map_push_elem(map, value, attr->flags);
|
bpf: add lookup/update support for per-cpu hash and array maps
The functions bpf_map_lookup_elem(map, key, value) and
bpf_map_update_elem(map, key, value, flags) need to get/set
values from all-cpus for per-cpu hash and array maps,
so that user space can aggregate/update them as necessary.
Example of single counter aggregation in user space:
unsigned int nr_cpus = sysconf(_SC_NPROCESSORS_CONF);
long values[nr_cpus];
long value = 0;
bpf_lookup_elem(fd, key, values);
for (i = 0; i < nr_cpus; i++)
value += values[i];
The user space must provide round_up(value_size, 8) * nr_cpus
array to get/set values, since kernel will use 'long' copy
of per-cpu values to try to copy good counters atomically.
It's a best-effort, since bpf programs and user space are racing
to access the same memory.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-02 14:39:55 +08:00
|
|
|
} else {
|
|
|
|
rcu_read_lock();
|
|
|
|
err = map->ops->map_update_elem(map, key, value, attr->flags);
|
|
|
|
rcu_read_unlock();
|
|
|
|
}
|
2016-03-08 13:57:13 +08:00
|
|
|
__this_cpu_dec(bpf_prog_active);
|
|
|
|
preempt_enable();
|
2018-10-12 18:54:27 +08:00
|
|
|
maybe_wait_bpf_programs(map);
|
2017-10-16 18:19:28 +08:00
|
|
|
out:
|
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 15:16:59 +08:00
|
|
|
free_value:
|
|
|
|
kfree(value);
|
|
|
|
free_key:
|
|
|
|
kfree(key);
|
|
|
|
err_put:
|
|
|
|
fdput(f);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define BPF_MAP_DELETE_ELEM_LAST_FIELD key
|
|
|
|
|
|
|
|
static int map_delete_elem(union bpf_attr *attr)
|
|
|
|
{
|
2016-11-14 02:44:03 +08:00
|
|
|
void __user *ukey = u64_to_user_ptr(attr->key);
|
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 15:16:59 +08:00
|
|
|
int ufd = attr->map_fd;
|
|
|
|
struct bpf_map *map;
|
2015-09-09 00:00:09 +08:00
|
|
|
struct fd f;
|
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 15:16:59 +08:00
|
|
|
void *key;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
if (CHECK_ATTR(BPF_MAP_DELETE_ELEM))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2015-09-09 00:00:09 +08:00
|
|
|
f = fdget(ufd);
|
2015-10-29 21:58:07 +08:00
|
|
|
map = __bpf_map_get(f);
|
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 15:16:59 +08:00
|
|
|
if (IS_ERR(map))
|
|
|
|
return PTR_ERR(map);
|
|
|
|
|
2017-10-19 04:00:22 +08:00
|
|
|
if (!(f.file->f_mode & FMODE_CAN_WRITE)) {
|
|
|
|
err = -EPERM;
|
|
|
|
goto err_put;
|
|
|
|
}
|
|
|
|
|
2018-10-18 21:16:14 +08:00
|
|
|
key = __bpf_copy_key(ukey, map->key_size);
|
2017-05-14 06:43:00 +08:00
|
|
|
if (IS_ERR(key)) {
|
|
|
|
err = PTR_ERR(key);
|
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 15:16:59 +08:00
|
|
|
goto err_put;
|
2017-05-14 06:43:00 +08: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 15:16:59 +08:00
|
|
|
|
2018-01-12 12:29:09 +08:00
|
|
|
if (bpf_map_is_dev_bound(map)) {
|
|
|
|
err = bpf_map_offload_delete_elem(map, key);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2016-03-08 13:57:13 +08:00
|
|
|
preempt_disable();
|
|
|
|
__this_cpu_inc(bpf_prog_active);
|
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 15:16:59 +08:00
|
|
|
rcu_read_lock();
|
|
|
|
err = map->ops->map_delete_elem(map, key);
|
|
|
|
rcu_read_unlock();
|
2016-03-08 13:57:13 +08:00
|
|
|
__this_cpu_dec(bpf_prog_active);
|
|
|
|
preempt_enable();
|
2018-10-12 18:54:27 +08:00
|
|
|
maybe_wait_bpf_programs(map);
|
2018-01-12 12:29:09 +08:00
|
|
|
out:
|
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 15:16:59 +08:00
|
|
|
kfree(key);
|
|
|
|
err_put:
|
|
|
|
fdput(f);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* last field in 'union bpf_attr' used by this command */
|
|
|
|
#define BPF_MAP_GET_NEXT_KEY_LAST_FIELD next_key
|
|
|
|
|
|
|
|
static int map_get_next_key(union bpf_attr *attr)
|
|
|
|
{
|
2016-11-14 02:44:03 +08:00
|
|
|
void __user *ukey = u64_to_user_ptr(attr->key);
|
|
|
|
void __user *unext_key = u64_to_user_ptr(attr->next_key);
|
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 15:16:59 +08:00
|
|
|
int ufd = attr->map_fd;
|
|
|
|
struct bpf_map *map;
|
|
|
|
void *key, *next_key;
|
2015-09-09 00:00:09 +08:00
|
|
|
struct fd f;
|
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 15:16:59 +08:00
|
|
|
int err;
|
|
|
|
|
|
|
|
if (CHECK_ATTR(BPF_MAP_GET_NEXT_KEY))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2015-09-09 00:00:09 +08:00
|
|
|
f = fdget(ufd);
|
2015-10-29 21:58:07 +08:00
|
|
|
map = __bpf_map_get(f);
|
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 15:16:59 +08:00
|
|
|
if (IS_ERR(map))
|
|
|
|
return PTR_ERR(map);
|
|
|
|
|
2017-10-19 04:00:22 +08:00
|
|
|
if (!(f.file->f_mode & FMODE_CAN_READ)) {
|
|
|
|
err = -EPERM;
|
|
|
|
goto err_put;
|
|
|
|
}
|
|
|
|
|
2017-04-25 10:00:37 +08:00
|
|
|
if (ukey) {
|
2018-10-18 21:16:14 +08:00
|
|
|
key = __bpf_copy_key(ukey, map->key_size);
|
2017-05-14 06:43:00 +08:00
|
|
|
if (IS_ERR(key)) {
|
|
|
|
err = PTR_ERR(key);
|
2017-04-25 10:00:37 +08:00
|
|
|
goto err_put;
|
2017-05-14 06:43:00 +08:00
|
|
|
}
|
2017-04-25 10:00:37 +08:00
|
|
|
} else {
|
|
|
|
key = NULL;
|
|
|
|
}
|
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 15:16:59 +08:00
|
|
|
|
|
|
|
err = -ENOMEM;
|
|
|
|
next_key = kmalloc(map->key_size, GFP_USER);
|
|
|
|
if (!next_key)
|
|
|
|
goto free_key;
|
|
|
|
|
2018-01-12 12:29:09 +08:00
|
|
|
if (bpf_map_is_dev_bound(map)) {
|
|
|
|
err = bpf_map_offload_get_next_key(map, key, next_key);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
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 15:16:59 +08:00
|
|
|
rcu_read_lock();
|
|
|
|
err = map->ops->map_get_next_key(map, key, next_key);
|
|
|
|
rcu_read_unlock();
|
2018-01-12 12:29:09 +08:00
|
|
|
out:
|
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 15:16:59 +08:00
|
|
|
if (err)
|
|
|
|
goto free_next_key;
|
|
|
|
|
|
|
|
err = -EFAULT;
|
|
|
|
if (copy_to_user(unext_key, next_key, map->key_size) != 0)
|
|
|
|
goto free_next_key;
|
|
|
|
|
|
|
|
err = 0;
|
|
|
|
|
|
|
|
free_next_key:
|
|
|
|
kfree(next_key);
|
|
|
|
free_key:
|
|
|
|
kfree(key);
|
|
|
|
err_put:
|
|
|
|
fdput(f);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2018-10-18 21:16:30 +08:00
|
|
|
#define BPF_MAP_LOOKUP_AND_DELETE_ELEM_LAST_FIELD value
|
|
|
|
|
|
|
|
static int map_lookup_and_delete_elem(union bpf_attr *attr)
|
|
|
|
{
|
|
|
|
void __user *ukey = u64_to_user_ptr(attr->key);
|
|
|
|
void __user *uvalue = u64_to_user_ptr(attr->value);
|
|
|
|
int ufd = attr->map_fd;
|
|
|
|
struct bpf_map *map;
|
2018-10-20 04:52:38 +08:00
|
|
|
void *key, *value;
|
2018-10-18 21:16:30 +08:00
|
|
|
u32 value_size;
|
|
|
|
struct fd f;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
if (CHECK_ATTR(BPF_MAP_LOOKUP_AND_DELETE_ELEM))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
f = fdget(ufd);
|
|
|
|
map = __bpf_map_get(f);
|
|
|
|
if (IS_ERR(map))
|
|
|
|
return PTR_ERR(map);
|
|
|
|
|
|
|
|
if (!(f.file->f_mode & FMODE_CAN_WRITE)) {
|
|
|
|
err = -EPERM;
|
|
|
|
goto err_put;
|
|
|
|
}
|
|
|
|
|
|
|
|
key = __bpf_copy_key(ukey, map->key_size);
|
|
|
|
if (IS_ERR(key)) {
|
|
|
|
err = PTR_ERR(key);
|
|
|
|
goto err_put;
|
|
|
|
}
|
|
|
|
|
|
|
|
value_size = map->value_size;
|
|
|
|
|
|
|
|
err = -ENOMEM;
|
|
|
|
value = kmalloc(value_size, GFP_USER | __GFP_NOWARN);
|
|
|
|
if (!value)
|
|
|
|
goto free_key;
|
|
|
|
|
|
|
|
if (map->map_type == BPF_MAP_TYPE_QUEUE ||
|
|
|
|
map->map_type == BPF_MAP_TYPE_STACK) {
|
|
|
|
err = map->ops->map_pop_elem(map, value);
|
|
|
|
} else {
|
|
|
|
err = -ENOTSUPP;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (err)
|
|
|
|
goto free_value;
|
|
|
|
|
|
|
|
if (copy_to_user(uvalue, value, value_size) != 0)
|
|
|
|
goto free_value;
|
|
|
|
|
|
|
|
err = 0;
|
|
|
|
|
|
|
|
free_value:
|
|
|
|
kfree(value);
|
|
|
|
free_key:
|
|
|
|
kfree(key);
|
|
|
|
err_put:
|
|
|
|
fdput(f);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2017-10-17 07:40:53 +08:00
|
|
|
static const struct bpf_prog_ops * const bpf_prog_types[] = {
|
|
|
|
#define BPF_PROG_TYPE(_id, _name) \
|
|
|
|
[_id] = & _name ## _prog_ops,
|
|
|
|
#define BPF_MAP_TYPE(_id, _ops)
|
|
|
|
#include <linux/bpf_types.h>
|
|
|
|
#undef BPF_PROG_TYPE
|
|
|
|
#undef BPF_MAP_TYPE
|
|
|
|
};
|
|
|
|
|
2014-09-26 15:17:00 +08:00
|
|
|
static int find_prog_type(enum bpf_prog_type type, struct bpf_prog *prog)
|
|
|
|
{
|
2018-05-04 08:13:57 +08:00
|
|
|
const struct bpf_prog_ops *ops;
|
|
|
|
|
|
|
|
if (type >= ARRAY_SIZE(bpf_prog_types))
|
|
|
|
return -EINVAL;
|
|
|
|
type = array_index_nospec(type, ARRAY_SIZE(bpf_prog_types));
|
|
|
|
ops = bpf_prog_types[type];
|
|
|
|
if (!ops)
|
2017-04-11 21:34:57 +08:00
|
|
|
return -EINVAL;
|
2014-09-26 15:17:00 +08:00
|
|
|
|
2017-11-04 04:56:17 +08:00
|
|
|
if (!bpf_prog_is_dev_bound(prog->aux))
|
2018-05-04 08:13:57 +08:00
|
|
|
prog->aux->ops = ops;
|
2017-11-04 04:56:17 +08:00
|
|
|
else
|
|
|
|
prog->aux->ops = &bpf_offload_prog_ops;
|
2017-04-11 21:34:57 +08:00
|
|
|
prog->type = type;
|
|
|
|
return 0;
|
2014-09-26 15:17:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* drop refcnt on maps used by eBPF program and free auxilary data */
|
|
|
|
static void free_used_maps(struct bpf_prog_aux *aux)
|
|
|
|
{
|
2018-09-28 22:45:36 +08:00
|
|
|
enum bpf_cgroup_storage_type stype;
|
2014-09-26 15:17:00 +08:00
|
|
|
int i;
|
|
|
|
|
2018-09-28 22:45:36 +08:00
|
|
|
for_each_cgroup_storage_type(stype) {
|
|
|
|
if (!aux->cgroup_storage[stype])
|
|
|
|
continue;
|
|
|
|
bpf_cgroup_storage_release(aux->prog,
|
|
|
|
aux->cgroup_storage[stype]);
|
|
|
|
}
|
2018-08-03 05:27:18 +08:00
|
|
|
|
2014-09-26 15:17:00 +08:00
|
|
|
for (i = 0; i < aux->used_map_cnt; i++)
|
|
|
|
bpf_map_put(aux->used_maps[i]);
|
|
|
|
|
|
|
|
kfree(aux->used_maps);
|
|
|
|
}
|
|
|
|
|
bpf: fix overflow in prog accounting
Commit aaac3ba95e4c ("bpf: charge user for creation of BPF maps and
programs") made a wrong assumption of charging against prog->pages.
Unlike map->pages, prog->pages are still subject to change when we
need to expand the program through bpf_prog_realloc().
This can for example happen during verification stage when we need to
expand and rewrite parts of the program. Should the required space
cross a page boundary, then prog->pages is not the same anymore as
its original value that we used to bpf_prog_charge_memlock() on. Thus,
we'll hit a wrap-around during bpf_prog_uncharge_memlock() when prog
is freed eventually. I noticed this that despite having unlimited
memlock, programs suddenly refused to load with EPERM error due to
insufficient memlock.
There are two ways to fix this issue. One would be to add a cached
variable to struct bpf_prog that takes a snapshot of prog->pages at the
time of charging. The other approach is to also account for resizes. I
chose to go with the latter for a couple of reasons: i) We want accounting
rather to be more accurate instead of further fooling limits, ii) adding
yet another page counter on struct bpf_prog would also be a waste just
for this purpose. We also do want to charge as early as possible to
avoid going into the verifier just to find out later on that we crossed
limits. The only place that needs to be fixed is bpf_prog_realloc(),
since only here we expand the program, so we try to account for the
needed delta and should we fail, call-sites check for outcome anyway.
On cBPF to eBPF migrations, we don't grab a reference to the user as
they are charged differently. With that in place, my test case worked
fine.
Fixes: aaac3ba95e4c ("bpf: charge user for creation of BPF maps and programs")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-18 08:52:58 +08:00
|
|
|
int __bpf_prog_charge(struct user_struct *user, u32 pages)
|
|
|
|
{
|
|
|
|
unsigned long memlock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
|
|
|
|
unsigned long user_bufs;
|
|
|
|
|
|
|
|
if (user) {
|
|
|
|
user_bufs = atomic_long_add_return(pages, &user->locked_vm);
|
|
|
|
if (user_bufs > memlock_limit) {
|
|
|
|
atomic_long_sub(pages, &user->locked_vm);
|
|
|
|
return -EPERM;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
void __bpf_prog_uncharge(struct user_struct *user, u32 pages)
|
|
|
|
{
|
|
|
|
if (user)
|
|
|
|
atomic_long_sub(pages, &user->locked_vm);
|
|
|
|
}
|
|
|
|
|
2015-10-08 13:23:22 +08:00
|
|
|
static int bpf_prog_charge_memlock(struct bpf_prog *prog)
|
|
|
|
{
|
|
|
|
struct user_struct *user = get_current_user();
|
bpf: fix overflow in prog accounting
Commit aaac3ba95e4c ("bpf: charge user for creation of BPF maps and
programs") made a wrong assumption of charging against prog->pages.
Unlike map->pages, prog->pages are still subject to change when we
need to expand the program through bpf_prog_realloc().
This can for example happen during verification stage when we need to
expand and rewrite parts of the program. Should the required space
cross a page boundary, then prog->pages is not the same anymore as
its original value that we used to bpf_prog_charge_memlock() on. Thus,
we'll hit a wrap-around during bpf_prog_uncharge_memlock() when prog
is freed eventually. I noticed this that despite having unlimited
memlock, programs suddenly refused to load with EPERM error due to
insufficient memlock.
There are two ways to fix this issue. One would be to add a cached
variable to struct bpf_prog that takes a snapshot of prog->pages at the
time of charging. The other approach is to also account for resizes. I
chose to go with the latter for a couple of reasons: i) We want accounting
rather to be more accurate instead of further fooling limits, ii) adding
yet another page counter on struct bpf_prog would also be a waste just
for this purpose. We also do want to charge as early as possible to
avoid going into the verifier just to find out later on that we crossed
limits. The only place that needs to be fixed is bpf_prog_realloc(),
since only here we expand the program, so we try to account for the
needed delta and should we fail, call-sites check for outcome anyway.
On cBPF to eBPF migrations, we don't grab a reference to the user as
they are charged differently. With that in place, my test case worked
fine.
Fixes: aaac3ba95e4c ("bpf: charge user for creation of BPF maps and programs")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-18 08:52:58 +08:00
|
|
|
int ret;
|
2015-10-08 13:23:22 +08:00
|
|
|
|
bpf: fix overflow in prog accounting
Commit aaac3ba95e4c ("bpf: charge user for creation of BPF maps and
programs") made a wrong assumption of charging against prog->pages.
Unlike map->pages, prog->pages are still subject to change when we
need to expand the program through bpf_prog_realloc().
This can for example happen during verification stage when we need to
expand and rewrite parts of the program. Should the required space
cross a page boundary, then prog->pages is not the same anymore as
its original value that we used to bpf_prog_charge_memlock() on. Thus,
we'll hit a wrap-around during bpf_prog_uncharge_memlock() when prog
is freed eventually. I noticed this that despite having unlimited
memlock, programs suddenly refused to load with EPERM error due to
insufficient memlock.
There are two ways to fix this issue. One would be to add a cached
variable to struct bpf_prog that takes a snapshot of prog->pages at the
time of charging. The other approach is to also account for resizes. I
chose to go with the latter for a couple of reasons: i) We want accounting
rather to be more accurate instead of further fooling limits, ii) adding
yet another page counter on struct bpf_prog would also be a waste just
for this purpose. We also do want to charge as early as possible to
avoid going into the verifier just to find out later on that we crossed
limits. The only place that needs to be fixed is bpf_prog_realloc(),
since only here we expand the program, so we try to account for the
needed delta and should we fail, call-sites check for outcome anyway.
On cBPF to eBPF migrations, we don't grab a reference to the user as
they are charged differently. With that in place, my test case worked
fine.
Fixes: aaac3ba95e4c ("bpf: charge user for creation of BPF maps and programs")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-18 08:52:58 +08:00
|
|
|
ret = __bpf_prog_charge(user, prog->pages);
|
|
|
|
if (ret) {
|
2015-10-08 13:23:22 +08:00
|
|
|
free_uid(user);
|
bpf: fix overflow in prog accounting
Commit aaac3ba95e4c ("bpf: charge user for creation of BPF maps and
programs") made a wrong assumption of charging against prog->pages.
Unlike map->pages, prog->pages are still subject to change when we
need to expand the program through bpf_prog_realloc().
This can for example happen during verification stage when we need to
expand and rewrite parts of the program. Should the required space
cross a page boundary, then prog->pages is not the same anymore as
its original value that we used to bpf_prog_charge_memlock() on. Thus,
we'll hit a wrap-around during bpf_prog_uncharge_memlock() when prog
is freed eventually. I noticed this that despite having unlimited
memlock, programs suddenly refused to load with EPERM error due to
insufficient memlock.
There are two ways to fix this issue. One would be to add a cached
variable to struct bpf_prog that takes a snapshot of prog->pages at the
time of charging. The other approach is to also account for resizes. I
chose to go with the latter for a couple of reasons: i) We want accounting
rather to be more accurate instead of further fooling limits, ii) adding
yet another page counter on struct bpf_prog would also be a waste just
for this purpose. We also do want to charge as early as possible to
avoid going into the verifier just to find out later on that we crossed
limits. The only place that needs to be fixed is bpf_prog_realloc(),
since only here we expand the program, so we try to account for the
needed delta and should we fail, call-sites check for outcome anyway.
On cBPF to eBPF migrations, we don't grab a reference to the user as
they are charged differently. With that in place, my test case worked
fine.
Fixes: aaac3ba95e4c ("bpf: charge user for creation of BPF maps and programs")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-18 08:52:58 +08:00
|
|
|
return ret;
|
2015-10-08 13:23:22 +08:00
|
|
|
}
|
bpf: fix overflow in prog accounting
Commit aaac3ba95e4c ("bpf: charge user for creation of BPF maps and
programs") made a wrong assumption of charging against prog->pages.
Unlike map->pages, prog->pages are still subject to change when we
need to expand the program through bpf_prog_realloc().
This can for example happen during verification stage when we need to
expand and rewrite parts of the program. Should the required space
cross a page boundary, then prog->pages is not the same anymore as
its original value that we used to bpf_prog_charge_memlock() on. Thus,
we'll hit a wrap-around during bpf_prog_uncharge_memlock() when prog
is freed eventually. I noticed this that despite having unlimited
memlock, programs suddenly refused to load with EPERM error due to
insufficient memlock.
There are two ways to fix this issue. One would be to add a cached
variable to struct bpf_prog that takes a snapshot of prog->pages at the
time of charging. The other approach is to also account for resizes. I
chose to go with the latter for a couple of reasons: i) We want accounting
rather to be more accurate instead of further fooling limits, ii) adding
yet another page counter on struct bpf_prog would also be a waste just
for this purpose. We also do want to charge as early as possible to
avoid going into the verifier just to find out later on that we crossed
limits. The only place that needs to be fixed is bpf_prog_realloc(),
since only here we expand the program, so we try to account for the
needed delta and should we fail, call-sites check for outcome anyway.
On cBPF to eBPF migrations, we don't grab a reference to the user as
they are charged differently. With that in place, my test case worked
fine.
Fixes: aaac3ba95e4c ("bpf: charge user for creation of BPF maps and programs")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-18 08:52:58 +08:00
|
|
|
|
2015-10-08 13:23:22 +08:00
|
|
|
prog->aux->user = user;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void bpf_prog_uncharge_memlock(struct bpf_prog *prog)
|
|
|
|
{
|
|
|
|
struct user_struct *user = prog->aux->user;
|
|
|
|
|
bpf: fix overflow in prog accounting
Commit aaac3ba95e4c ("bpf: charge user for creation of BPF maps and
programs") made a wrong assumption of charging against prog->pages.
Unlike map->pages, prog->pages are still subject to change when we
need to expand the program through bpf_prog_realloc().
This can for example happen during verification stage when we need to
expand and rewrite parts of the program. Should the required space
cross a page boundary, then prog->pages is not the same anymore as
its original value that we used to bpf_prog_charge_memlock() on. Thus,
we'll hit a wrap-around during bpf_prog_uncharge_memlock() when prog
is freed eventually. I noticed this that despite having unlimited
memlock, programs suddenly refused to load with EPERM error due to
insufficient memlock.
There are two ways to fix this issue. One would be to add a cached
variable to struct bpf_prog that takes a snapshot of prog->pages at the
time of charging. The other approach is to also account for resizes. I
chose to go with the latter for a couple of reasons: i) We want accounting
rather to be more accurate instead of further fooling limits, ii) adding
yet another page counter on struct bpf_prog would also be a waste just
for this purpose. We also do want to charge as early as possible to
avoid going into the verifier just to find out later on that we crossed
limits. The only place that needs to be fixed is bpf_prog_realloc(),
since only here we expand the program, so we try to account for the
needed delta and should we fail, call-sites check for outcome anyway.
On cBPF to eBPF migrations, we don't grab a reference to the user as
they are charged differently. With that in place, my test case worked
fine.
Fixes: aaac3ba95e4c ("bpf: charge user for creation of BPF maps and programs")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-18 08:52:58 +08:00
|
|
|
__bpf_prog_uncharge(user, prog->pages);
|
2015-10-08 13:23:22 +08:00
|
|
|
free_uid(user);
|
|
|
|
}
|
|
|
|
|
2017-06-06 03:15:46 +08:00
|
|
|
static int bpf_prog_alloc_id(struct bpf_prog *prog)
|
|
|
|
{
|
|
|
|
int id;
|
|
|
|
|
2018-03-28 02:53:21 +08:00
|
|
|
idr_preload(GFP_KERNEL);
|
2017-06-06 03:15:46 +08:00
|
|
|
spin_lock_bh(&prog_idr_lock);
|
|
|
|
id = idr_alloc_cyclic(&prog_idr, prog, 1, INT_MAX, GFP_ATOMIC);
|
|
|
|
if (id > 0)
|
|
|
|
prog->aux->id = id;
|
|
|
|
spin_unlock_bh(&prog_idr_lock);
|
2018-03-28 02:53:21 +08:00
|
|
|
idr_preload_end();
|
2017-06-06 03:15:46 +08:00
|
|
|
|
|
|
|
/* id is in [1, INT_MAX) */
|
|
|
|
if (WARN_ON_ONCE(!id))
|
|
|
|
return -ENOSPC;
|
|
|
|
|
|
|
|
return id > 0 ? 0 : id;
|
|
|
|
}
|
|
|
|
|
2017-12-28 10:39:07 +08:00
|
|
|
void bpf_prog_free_id(struct bpf_prog *prog, bool do_idr_lock)
|
2017-06-06 03:15:46 +08:00
|
|
|
{
|
2017-12-28 10:39:07 +08:00
|
|
|
/* cBPF to eBPF migrations are currently not in the idr store.
|
|
|
|
* Offloaded programs are removed from the store when their device
|
|
|
|
* disappears - even if someone grabs an fd to them they are unusable,
|
|
|
|
* simply waiting for refcnt to drop to be freed.
|
|
|
|
*/
|
2017-06-06 03:15:46 +08:00
|
|
|
if (!prog->aux->id)
|
|
|
|
return;
|
|
|
|
|
2017-06-06 03:15:49 +08:00
|
|
|
if (do_idr_lock)
|
|
|
|
spin_lock_bh(&prog_idr_lock);
|
|
|
|
else
|
|
|
|
__acquire(&prog_idr_lock);
|
|
|
|
|
2017-06-06 03:15:46 +08:00
|
|
|
idr_remove(&prog_idr, prog->aux->id);
|
2017-12-28 10:39:07 +08:00
|
|
|
prog->aux->id = 0;
|
2017-06-06 03:15:49 +08:00
|
|
|
|
|
|
|
if (do_idr_lock)
|
|
|
|
spin_unlock_bh(&prog_idr_lock);
|
|
|
|
else
|
|
|
|
__release(&prog_idr_lock);
|
2017-06-06 03:15:46 +08:00
|
|
|
}
|
|
|
|
|
bpf: generally move prog destruction to RCU deferral
Jann Horn reported following analysis that could potentially result
in a very hard to trigger (if not impossible) UAF race, to quote his
event timeline:
- Set up a process with threads T1, T2 and T3
- Let T1 set up a socket filter F1 that invokes another filter F2
through a BPF map [tail call]
- Let T1 trigger the socket filter via a unix domain socket write,
don't wait for completion
- Let T2 call PERF_EVENT_IOC_SET_BPF with F2, don't wait for completion
- Now T2 should be behind bpf_prog_get(), but before bpf_prog_put()
- Let T3 close the file descriptor for F2, dropping the reference
count of F2 to 2
- At this point, T1 should have looked up F2 from the map, but not
finished executing it
- Let T3 remove F2 from the BPF map, dropping the reference count of
F2 to 1
- Now T2 should call bpf_prog_put() (wrong BPF program type), dropping
the reference count of F2 to 0 and scheduling bpf_prog_free_deferred()
via schedule_work()
- At this point, the BPF program could be freed
- BPF execution is still running in a freed BPF program
While at PERF_EVENT_IOC_SET_BPF time it's only guaranteed that the perf
event fd we're doing the syscall on doesn't disappear from underneath us
for whole syscall time, it may not be the case for the bpf fd used as
an argument only after we did the put. It needs to be a valid fd pointing
to a BPF program at the time of the call to make the bpf_prog_get() and
while T2 gets preempted, F2 must have dropped reference to 1 on the other
CPU. The fput() from the close() in T3 should also add additionally delay
to the reference drop via exit_task_work() when bpf_prog_release() gets
called as well as scheduling bpf_prog_free_deferred().
That said, it makes nevertheless sense to move the BPF prog destruction
generally after RCU grace period to guarantee that such scenario above,
but also others as recently fixed in ceb56070359b ("bpf, perf: delay release
of BPF prog after grace period") with regards to tail calls won't happen.
Integrating bpf_prog_free_deferred() directly into the RCU callback is
not allowed since the invocation might happen from either softirq or
process context, so we're not permitted to block. Reviewing all bpf_prog_put()
invocations from eBPF side (note, cBPF -> eBPF progs don't use this for
their destruction) with call_rcu() look good to me.
Since we don't know whether at the time of attaching the program, we're
already part of a tail call map, we need to use RCU variant. However, due
to this, there won't be severely more stress on the RCU callback queue:
situations with above bpf_prog_get() and bpf_prog_put() combo in practice
normally won't lead to releases, but even if they would, enough effort/
cycles have to be put into loading a BPF program into the kernel already.
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-30 23:24:43 +08:00
|
|
|
static void __bpf_prog_put_rcu(struct rcu_head *rcu)
|
2015-05-29 10:26:02 +08:00
|
|
|
{
|
|
|
|
struct bpf_prog_aux *aux = container_of(rcu, struct bpf_prog_aux, rcu);
|
|
|
|
|
|
|
|
free_used_maps(aux);
|
2015-10-08 13:23:22 +08:00
|
|
|
bpf_prog_uncharge_memlock(aux->prog);
|
2017-10-19 04:00:24 +08:00
|
|
|
security_bpf_prog_free(aux);
|
2015-05-29 10:26:02 +08:00
|
|
|
bpf_prog_free(aux->prog);
|
|
|
|
}
|
|
|
|
|
2017-06-06 03:15:49 +08:00
|
|
|
static void __bpf_prog_put(struct bpf_prog *prog, bool do_idr_lock)
|
2014-09-26 15:17:00 +08:00
|
|
|
{
|
bpf: add initial bpf tracepoints
This work adds a number of tracepoints to paths that are either
considered slow-path or exception-like states, where monitoring or
inspecting them would be desirable.
For bpf(2) syscall, tracepoints have been placed for main commands
when they succeed. In XDP case, tracepoint is for exceptions, that
is, f.e. on abnormal BPF program exit such as unknown or XDP_ABORTED
return code, or when error occurs during XDP_TX action and the packet
could not be forwarded.
Both have been split into separate event headers, and can be further
extended. Worst case, if they unexpectedly should get into our way in
future, they can also removed [1]. Of course, these tracepoints (like
any other) can be analyzed by eBPF itself, etc. Example output:
# ./perf record -a -e bpf:* sleep 10
# ./perf script
sock_example 6197 [005] 283.980322: bpf:bpf_map_create: map type=ARRAY ufd=4 key=4 val=8 max=256 flags=0
sock_example 6197 [005] 283.980721: bpf:bpf_prog_load: prog=a5ea8fa30ea6849c type=SOCKET_FILTER ufd=5
sock_example 6197 [005] 283.988423: bpf:bpf_prog_get_type: prog=a5ea8fa30ea6849c type=SOCKET_FILTER
sock_example 6197 [005] 283.988443: bpf:bpf_map_lookup_elem: map type=ARRAY ufd=4 key=[06 00 00 00] val=[00 00 00 00 00 00 00 00]
[...]
sock_example 6197 [005] 288.990868: bpf:bpf_map_lookup_elem: map type=ARRAY ufd=4 key=[01 00 00 00] val=[14 00 00 00 00 00 00 00]
swapper 0 [005] 289.338243: bpf:bpf_prog_put_rcu: prog=a5ea8fa30ea6849c type=SOCKET_FILTER
[1] https://lwn.net/Articles/705270/
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-01-25 09:28:18 +08:00
|
|
|
if (atomic_dec_and_test(&prog->aux->refcnt)) {
|
2017-06-06 03:15:48 +08:00
|
|
|
/* bpf_prog_free_id() must be called first */
|
2017-06-06 03:15:49 +08:00
|
|
|
bpf_prog_free_id(prog, do_idr_lock);
|
2018-06-15 08:30:47 +08:00
|
|
|
bpf_prog_kallsyms_del_all(prog);
|
bpf: Introduce bpf_func_info
This patch added interface to load a program with the following
additional information:
. prog_btf_fd
. func_info, func_info_rec_size and func_info_cnt
where func_info will provide function range and type_id
corresponding to each function.
The func_info_rec_size is introduced in the UAPI to specify
struct bpf_func_info size passed from user space. This
intends to make bpf_func_info structure growable in the future.
If the kernel gets a different bpf_func_info size from userspace,
it will try to handle user request with part of bpf_func_info
it can understand. In this patch, kernel can understand
struct bpf_func_info {
__u32 insn_offset;
__u32 type_id;
};
If user passed a bpf func_info record size of 16 bytes, the
kernel can still handle part of records with the above definition.
If verifier agrees with function range provided by the user,
the bpf_prog ksym for each function will use the func name
provided in the type_id, which is supposed to provide better
encoding as it is not limited by 16 bytes program name
limitation and this is better for bpf program which contains
multiple subprograms.
The bpf_prog_info interface is also extended to
return btf_id, func_info, func_info_rec_size and func_info_cnt
to userspace, so userspace can print out the function prototype
for each xlated function. The insn_offset in the returned
func_info corresponds to the insn offset for xlated functions.
With other jit related fields in bpf_prog_info, userspace can also
print out function prototypes for each jited function.
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-11-20 07:29:11 +08:00
|
|
|
btf_put(prog->aux->btf);
|
2018-11-25 15:20:44 +08:00
|
|
|
kvfree(prog->aux->func_info);
|
bpf: fix kallsyms handling for subprogs
Right now kallsyms handling is not working with JITed subprogs.
The reason is that when in 1c2a088a6626 ("bpf: x64: add JIT support
for multi-function programs") in jit_subprogs() they are passed
to bpf_prog_kallsyms_add(), then their prog type is 0, which BPF
core will think it's a cBPF program as only cBPF programs have a
0 type. Thus, they need to inherit the type from the main prog.
Once that is fixed, they are indeed added to the BPF kallsyms
infra, but their tag is 0. Therefore, since intention is to add
them as bpf_prog_F_<tag>, we need to pass them to bpf_prog_calc_tag()
first. And once this is resolved, there is a use-after-free on
prog cleanup: we remove the kallsyms entry from the main prog,
later walk all subprogs and call bpf_jit_free() on them. However,
the kallsyms linkage was never released on them. Thus, do that
for all subprogs right in __bpf_prog_put() when refcount hits 0.
Fixes: 1c2a088a6626 ("bpf: x64: add JIT support for multi-function programs")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2017-12-20 20:42:56 +08:00
|
|
|
|
bpf: generally move prog destruction to RCU deferral
Jann Horn reported following analysis that could potentially result
in a very hard to trigger (if not impossible) UAF race, to quote his
event timeline:
- Set up a process with threads T1, T2 and T3
- Let T1 set up a socket filter F1 that invokes another filter F2
through a BPF map [tail call]
- Let T1 trigger the socket filter via a unix domain socket write,
don't wait for completion
- Let T2 call PERF_EVENT_IOC_SET_BPF with F2, don't wait for completion
- Now T2 should be behind bpf_prog_get(), but before bpf_prog_put()
- Let T3 close the file descriptor for F2, dropping the reference
count of F2 to 2
- At this point, T1 should have looked up F2 from the map, but not
finished executing it
- Let T3 remove F2 from the BPF map, dropping the reference count of
F2 to 1
- Now T2 should call bpf_prog_put() (wrong BPF program type), dropping
the reference count of F2 to 0 and scheduling bpf_prog_free_deferred()
via schedule_work()
- At this point, the BPF program could be freed
- BPF execution is still running in a freed BPF program
While at PERF_EVENT_IOC_SET_BPF time it's only guaranteed that the perf
event fd we're doing the syscall on doesn't disappear from underneath us
for whole syscall time, it may not be the case for the bpf fd used as
an argument only after we did the put. It needs to be a valid fd pointing
to a BPF program at the time of the call to make the bpf_prog_get() and
while T2 gets preempted, F2 must have dropped reference to 1 on the other
CPU. The fput() from the close() in T3 should also add additionally delay
to the reference drop via exit_task_work() when bpf_prog_release() gets
called as well as scheduling bpf_prog_free_deferred().
That said, it makes nevertheless sense to move the BPF prog destruction
generally after RCU grace period to guarantee that such scenario above,
but also others as recently fixed in ceb56070359b ("bpf, perf: delay release
of BPF prog after grace period") with regards to tail calls won't happen.
Integrating bpf_prog_free_deferred() directly into the RCU callback is
not allowed since the invocation might happen from either softirq or
process context, so we're not permitted to block. Reviewing all bpf_prog_put()
invocations from eBPF side (note, cBPF -> eBPF progs don't use this for
their destruction) with call_rcu() look good to me.
Since we don't know whether at the time of attaching the program, we're
already part of a tail call map, we need to use RCU variant. However, due
to this, there won't be severely more stress on the RCU callback queue:
situations with above bpf_prog_get() and bpf_prog_put() combo in practice
normally won't lead to releases, but even if they would, enough effort/
cycles have to be put into loading a BPF program into the kernel already.
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-30 23:24:43 +08:00
|
|
|
call_rcu(&prog->aux->rcu, __bpf_prog_put_rcu);
|
bpf: add initial bpf tracepoints
This work adds a number of tracepoints to paths that are either
considered slow-path or exception-like states, where monitoring or
inspecting them would be desirable.
For bpf(2) syscall, tracepoints have been placed for main commands
when they succeed. In XDP case, tracepoint is for exceptions, that
is, f.e. on abnormal BPF program exit such as unknown or XDP_ABORTED
return code, or when error occurs during XDP_TX action and the packet
could not be forwarded.
Both have been split into separate event headers, and can be further
extended. Worst case, if they unexpectedly should get into our way in
future, they can also removed [1]. Of course, these tracepoints (like
any other) can be analyzed by eBPF itself, etc. Example output:
# ./perf record -a -e bpf:* sleep 10
# ./perf script
sock_example 6197 [005] 283.980322: bpf:bpf_map_create: map type=ARRAY ufd=4 key=4 val=8 max=256 flags=0
sock_example 6197 [005] 283.980721: bpf:bpf_prog_load: prog=a5ea8fa30ea6849c type=SOCKET_FILTER ufd=5
sock_example 6197 [005] 283.988423: bpf:bpf_prog_get_type: prog=a5ea8fa30ea6849c type=SOCKET_FILTER
sock_example 6197 [005] 283.988443: bpf:bpf_map_lookup_elem: map type=ARRAY ufd=4 key=[06 00 00 00] val=[00 00 00 00 00 00 00 00]
[...]
sock_example 6197 [005] 288.990868: bpf:bpf_map_lookup_elem: map type=ARRAY ufd=4 key=[01 00 00 00] val=[14 00 00 00 00 00 00 00]
swapper 0 [005] 289.338243: bpf:bpf_prog_put_rcu: prog=a5ea8fa30ea6849c type=SOCKET_FILTER
[1] https://lwn.net/Articles/705270/
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-01-25 09:28:18 +08:00
|
|
|
}
|
2014-09-26 15:17:00 +08:00
|
|
|
}
|
2017-06-06 03:15:49 +08:00
|
|
|
|
|
|
|
void bpf_prog_put(struct bpf_prog *prog)
|
|
|
|
{
|
|
|
|
__bpf_prog_put(prog, true);
|
|
|
|
}
|
cls_bpf: add initial eBPF support for programmable classifiers
This work extends the "classic" BPF programmable tc classifier by
extending its scope also to native eBPF code!
This allows for user space to implement own custom, 'safe' C like
classifiers (or whatever other frontend language LLVM et al may
provide in future), that can then be compiled with the LLVM eBPF
backend to an eBPF elf file. The result of this can be loaded into
the kernel via iproute2's tc. In the kernel, they can be JITed on
major archs and thus run in native performance.
Simple, minimal toy example to demonstrate the workflow:
#include <linux/ip.h>
#include <linux/if_ether.h>
#include <linux/bpf.h>
#include "tc_bpf_api.h"
__section("classify")
int cls_main(struct sk_buff *skb)
{
return (0x800 << 16) | load_byte(skb, ETH_HLEN + __builtin_offsetof(struct iphdr, tos));
}
char __license[] __section("license") = "GPL";
The classifier can then be compiled into eBPF opcodes and loaded
via tc, for example:
clang -O2 -emit-llvm -c cls.c -o - | llc -march=bpf -filetype=obj -o cls.o
tc filter add dev em1 parent 1: bpf cls.o [...]
As it has been demonstrated, the scope can even reach up to a fully
fledged flow dissector (similarly as in samples/bpf/sockex2_kern.c).
For tc, maps are allowed to be used, but from kernel context only,
in other words, eBPF code can keep state across filter invocations.
In future, we perhaps may reattach from a different application to
those maps e.g., to read out collected statistics/state.
Similarly as in socket filters, we may extend functionality for eBPF
classifiers over time depending on the use cases. For that purpose,
cls_bpf programs are using BPF_PROG_TYPE_SCHED_CLS program type, so
we can allow additional functions/accessors (e.g. an ABI compatible
offset translation to skb fields/metadata). For an initial cls_bpf
support, we allow the same set of helper functions as eBPF socket
filters, but we could diverge at some point in time w/o problem.
I was wondering whether cls_bpf and act_bpf could share C programs,
I can imagine that at some point, we introduce i) further common
handlers for both (or even beyond their scope), and/or if truly needed
ii) some restricted function space for each of them. Both can be
abstracted easily through struct bpf_verifier_ops in future.
The context of cls_bpf versus act_bpf is slightly different though:
a cls_bpf program will return a specific classid whereas act_bpf a
drop/non-drop return code, latter may also in future mangle skbs.
That said, we can surely have a "classify" and "action" section in
a single object file, or considered mentioned constraint add a
possibility of a shared section.
The workflow for getting native eBPF running from tc [1] is as
follows: for f_bpf, I've added a slightly modified ELF parser code
from Alexei's kernel sample, which reads out the LLVM compiled
object, sets up maps (and dynamically fixes up map fds) if any, and
loads the eBPF instructions all centrally through the bpf syscall.
The resulting fd from the loaded program itself is being passed down
to cls_bpf, which looks up struct bpf_prog from the fd store, and
holds reference, so that it stays available also after tc program
lifetime. On tc filter destruction, it will then drop its reference.
Moreover, I've also added the optional possibility to annotate an
eBPF filter with a name (e.g. path to object file, or something
else if preferred) so that when tc dumps currently installed filters,
some more context can be given to an admin for a given instance (as
opposed to just the file descriptor number).
Last but not least, bpf_prog_get() and bpf_prog_put() needed to be
exported, so that eBPF can be used from cls_bpf built as a module.
Thanks to 60a3b2253c41 ("net: bpf: make eBPF interpreter images
read-only") I think this is of no concern since anything wanting to
alter eBPF opcode after verification stage would crash the kernel.
[1] http://git.breakpoint.cc/cgit/dborkman/iproute2.git/log/?h=ebpf
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Jiri Pirko <jiri@resnulli.us>
Acked-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-01 19:31:48 +08:00
|
|
|
EXPORT_SYMBOL_GPL(bpf_prog_put);
|
2014-09-26 15:17:00 +08:00
|
|
|
|
|
|
|
static int bpf_prog_release(struct inode *inode, struct file *filp)
|
|
|
|
{
|
|
|
|
struct bpf_prog *prog = filp->private_data;
|
|
|
|
|
bpf: generally move prog destruction to RCU deferral
Jann Horn reported following analysis that could potentially result
in a very hard to trigger (if not impossible) UAF race, to quote his
event timeline:
- Set up a process with threads T1, T2 and T3
- Let T1 set up a socket filter F1 that invokes another filter F2
through a BPF map [tail call]
- Let T1 trigger the socket filter via a unix domain socket write,
don't wait for completion
- Let T2 call PERF_EVENT_IOC_SET_BPF with F2, don't wait for completion
- Now T2 should be behind bpf_prog_get(), but before bpf_prog_put()
- Let T3 close the file descriptor for F2, dropping the reference
count of F2 to 2
- At this point, T1 should have looked up F2 from the map, but not
finished executing it
- Let T3 remove F2 from the BPF map, dropping the reference count of
F2 to 1
- Now T2 should call bpf_prog_put() (wrong BPF program type), dropping
the reference count of F2 to 0 and scheduling bpf_prog_free_deferred()
via schedule_work()
- At this point, the BPF program could be freed
- BPF execution is still running in a freed BPF program
While at PERF_EVENT_IOC_SET_BPF time it's only guaranteed that the perf
event fd we're doing the syscall on doesn't disappear from underneath us
for whole syscall time, it may not be the case for the bpf fd used as
an argument only after we did the put. It needs to be a valid fd pointing
to a BPF program at the time of the call to make the bpf_prog_get() and
while T2 gets preempted, F2 must have dropped reference to 1 on the other
CPU. The fput() from the close() in T3 should also add additionally delay
to the reference drop via exit_task_work() when bpf_prog_release() gets
called as well as scheduling bpf_prog_free_deferred().
That said, it makes nevertheless sense to move the BPF prog destruction
generally after RCU grace period to guarantee that such scenario above,
but also others as recently fixed in ceb56070359b ("bpf, perf: delay release
of BPF prog after grace period") with regards to tail calls won't happen.
Integrating bpf_prog_free_deferred() directly into the RCU callback is
not allowed since the invocation might happen from either softirq or
process context, so we're not permitted to block. Reviewing all bpf_prog_put()
invocations from eBPF side (note, cBPF -> eBPF progs don't use this for
their destruction) with call_rcu() look good to me.
Since we don't know whether at the time of attaching the program, we're
already part of a tail call map, we need to use RCU variant. However, due
to this, there won't be severely more stress on the RCU callback queue:
situations with above bpf_prog_get() and bpf_prog_put() combo in practice
normally won't lead to releases, but even if they would, enough effort/
cycles have to be put into loading a BPF program into the kernel already.
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-30 23:24:43 +08:00
|
|
|
bpf_prog_put(prog);
|
2014-09-26 15:17:00 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-12-05 06:19:41 +08:00
|
|
|
#ifdef CONFIG_PROC_FS
|
|
|
|
static void bpf_prog_show_fdinfo(struct seq_file *m, struct file *filp)
|
|
|
|
{
|
|
|
|
const struct bpf_prog *prog = filp->private_data;
|
2017-01-14 06:38:15 +08:00
|
|
|
char prog_tag[sizeof(prog->tag) * 2 + 1] = { };
|
2016-12-05 06:19:41 +08:00
|
|
|
|
2017-01-14 06:38:15 +08:00
|
|
|
bin2hex(prog_tag, prog->tag, sizeof(prog->tag));
|
2016-12-05 06:19:41 +08:00
|
|
|
seq_printf(m,
|
|
|
|
"prog_type:\t%u\n"
|
|
|
|
"prog_jited:\t%u\n"
|
2017-01-14 06:38:15 +08:00
|
|
|
"prog_tag:\t%s\n"
|
2018-06-03 05:06:34 +08:00
|
|
|
"memlock:\t%llu\n"
|
|
|
|
"prog_id:\t%u\n",
|
2016-12-05 06:19:41 +08:00
|
|
|
prog->type,
|
|
|
|
prog->jited,
|
2017-01-14 06:38:15 +08:00
|
|
|
prog_tag,
|
2018-06-03 05:06:34 +08:00
|
|
|
prog->pages * 1ULL << PAGE_SHIFT,
|
|
|
|
prog->aux->id);
|
2016-12-05 06:19:41 +08:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2017-10-19 04:00:26 +08:00
|
|
|
const struct file_operations bpf_prog_fops = {
|
2016-12-05 06:19:41 +08:00
|
|
|
#ifdef CONFIG_PROC_FS
|
|
|
|
.show_fdinfo = bpf_prog_show_fdinfo,
|
|
|
|
#endif
|
|
|
|
.release = bpf_prog_release,
|
2017-10-19 04:00:22 +08:00
|
|
|
.read = bpf_dummy_read,
|
|
|
|
.write = bpf_dummy_write,
|
2014-09-26 15:17:00 +08:00
|
|
|
};
|
|
|
|
|
2015-10-29 21:58:09 +08:00
|
|
|
int bpf_prog_new_fd(struct bpf_prog *prog)
|
2015-10-29 21:58:06 +08:00
|
|
|
{
|
2017-10-19 04:00:24 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = security_bpf_prog(prog);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
2015-10-29 21:58:06 +08:00
|
|
|
return anon_inode_getfd("bpf-prog", &bpf_prog_fops, prog,
|
|
|
|
O_RDWR | O_CLOEXEC);
|
|
|
|
}
|
|
|
|
|
2016-06-30 23:24:44 +08:00
|
|
|
static struct bpf_prog *____bpf_prog_get(struct fd f)
|
2014-09-26 15:17:00 +08:00
|
|
|
{
|
|
|
|
if (!f.file)
|
|
|
|
return ERR_PTR(-EBADF);
|
|
|
|
if (f.file->f_op != &bpf_prog_fops) {
|
|
|
|
fdput(f);
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
}
|
|
|
|
|
2015-10-29 21:58:07 +08:00
|
|
|
return f.file->private_data;
|
2014-09-26 15:17:00 +08:00
|
|
|
}
|
|
|
|
|
2016-07-20 03:16:46 +08:00
|
|
|
struct bpf_prog *bpf_prog_add(struct bpf_prog *prog, int i)
|
2016-04-28 09:56:20 +08:00
|
|
|
{
|
2016-07-20 03:16:46 +08:00
|
|
|
if (atomic_add_return(i, &prog->aux->refcnt) > BPF_MAX_REFCNT) {
|
|
|
|
atomic_sub(i, &prog->aux->refcnt);
|
2016-04-28 09:56:20 +08:00
|
|
|
return ERR_PTR(-EBUSY);
|
|
|
|
}
|
|
|
|
return prog;
|
|
|
|
}
|
2016-07-20 03:16:46 +08:00
|
|
|
EXPORT_SYMBOL_GPL(bpf_prog_add);
|
|
|
|
|
2016-11-10 05:02:34 +08:00
|
|
|
void bpf_prog_sub(struct bpf_prog *prog, int i)
|
|
|
|
{
|
|
|
|
/* Only to be used for undoing previous bpf_prog_add() in some
|
|
|
|
* error path. We still know that another entity in our call
|
|
|
|
* path holds a reference to the program, thus atomic_sub() can
|
|
|
|
* be safely used in such cases!
|
|
|
|
*/
|
|
|
|
WARN_ON(atomic_sub_return(i, &prog->aux->refcnt) == 0);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(bpf_prog_sub);
|
|
|
|
|
2016-07-20 03:16:46 +08:00
|
|
|
struct bpf_prog *bpf_prog_inc(struct bpf_prog *prog)
|
|
|
|
{
|
|
|
|
return bpf_prog_add(prog, 1);
|
|
|
|
}
|
2016-11-19 08:45:00 +08:00
|
|
|
EXPORT_SYMBOL_GPL(bpf_prog_inc);
|
2016-04-28 09:56:20 +08:00
|
|
|
|
2017-06-06 03:15:49 +08:00
|
|
|
/* prog_idr_lock should have been held */
|
2017-08-16 13:32:22 +08:00
|
|
|
struct bpf_prog *bpf_prog_inc_not_zero(struct bpf_prog *prog)
|
2017-06-06 03:15:49 +08:00
|
|
|
{
|
|
|
|
int refold;
|
|
|
|
|
atomics/treewide: Rename __atomic_add_unless() => atomic_fetch_add_unless()
While __atomic_add_unless() was originally intended as a building-block
for atomic_add_unless(), it's now used in a number of places around the
kernel. It's the only common atomic operation named __atomic*(), rather
than atomic_*(), and for consistency it would be better named
atomic_fetch_add_unless().
This lack of consistency is slightly confusing, and gets in the way of
scripting atomics. Given that, let's clean things up and promote it to
an official part of the atomics API, in the form of
atomic_fetch_add_unless().
This patch converts definitions and invocations over to the new name,
including the instrumented version, using the following script:
----
git grep -w __atomic_add_unless | while read line; do
sed -i '{s/\<__atomic_add_unless\>/atomic_fetch_add_unless/}' "${line%%:*}";
done
git grep -w __arch_atomic_add_unless | while read line; do
sed -i '{s/\<__arch_atomic_add_unless\>/arch_atomic_fetch_add_unless/}' "${line%%:*}";
done
----
Note that we do not have atomic{64,_long}_fetch_add_unless(), which will
be introduced by later patches.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Will Deacon <will.deacon@arm.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Palmer Dabbelt <palmer@sifive.com>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/lkml/20180621121321.4761-2-mark.rutland@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-06-21 20:13:04 +08:00
|
|
|
refold = atomic_fetch_add_unless(&prog->aux->refcnt, 1, 0);
|
2017-06-06 03:15:49 +08:00
|
|
|
|
|
|
|
if (refold >= BPF_MAX_REFCNT) {
|
|
|
|
__bpf_prog_put(prog, false);
|
|
|
|
return ERR_PTR(-EBUSY);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!refold)
|
|
|
|
return ERR_PTR(-ENOENT);
|
|
|
|
|
|
|
|
return prog;
|
|
|
|
}
|
2017-08-16 13:32:22 +08:00
|
|
|
EXPORT_SYMBOL_GPL(bpf_prog_inc_not_zero);
|
2017-06-06 03:15:49 +08:00
|
|
|
|
2017-12-03 09:20:38 +08:00
|
|
|
bool bpf_prog_get_ok(struct bpf_prog *prog,
|
2017-11-21 07:21:54 +08:00
|
|
|
enum bpf_prog_type *attach_type, bool attach_drv)
|
2017-11-04 04:56:20 +08:00
|
|
|
{
|
2017-11-21 07:21:54 +08:00
|
|
|
/* not an attachment, just a refcount inc, always allow */
|
|
|
|
if (!attach_type)
|
|
|
|
return true;
|
2017-11-04 04:56:20 +08:00
|
|
|
|
|
|
|
if (prog->type != *attach_type)
|
|
|
|
return false;
|
2017-11-21 07:21:54 +08:00
|
|
|
if (bpf_prog_is_dev_bound(prog->aux) && !attach_drv)
|
2017-11-04 04:56:20 +08:00
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct bpf_prog *__bpf_prog_get(u32 ufd, enum bpf_prog_type *attach_type,
|
2017-11-21 07:21:54 +08:00
|
|
|
bool attach_drv)
|
2014-09-26 15:17:00 +08:00
|
|
|
{
|
|
|
|
struct fd f = fdget(ufd);
|
|
|
|
struct bpf_prog *prog;
|
|
|
|
|
2016-06-30 23:24:44 +08:00
|
|
|
prog = ____bpf_prog_get(f);
|
2014-09-26 15:17:00 +08:00
|
|
|
if (IS_ERR(prog))
|
|
|
|
return prog;
|
2017-11-21 07:21:54 +08:00
|
|
|
if (!bpf_prog_get_ok(prog, attach_type, attach_drv)) {
|
2016-06-30 23:24:44 +08:00
|
|
|
prog = ERR_PTR(-EINVAL);
|
|
|
|
goto out;
|
|
|
|
}
|
2014-09-26 15:17:00 +08:00
|
|
|
|
2016-04-28 09:56:20 +08:00
|
|
|
prog = bpf_prog_inc(prog);
|
2016-06-30 23:24:44 +08:00
|
|
|
out:
|
2014-09-26 15:17:00 +08:00
|
|
|
fdput(f);
|
|
|
|
return prog;
|
|
|
|
}
|
2016-06-30 23:24:44 +08:00
|
|
|
|
|
|
|
struct bpf_prog *bpf_prog_get(u32 ufd)
|
|
|
|
{
|
2017-11-21 07:21:54 +08:00
|
|
|
return __bpf_prog_get(ufd, NULL, false);
|
2016-06-30 23:24:44 +08:00
|
|
|
}
|
|
|
|
|
2017-11-04 04:56:20 +08:00
|
|
|
struct bpf_prog *bpf_prog_get_type_dev(u32 ufd, enum bpf_prog_type type,
|
2017-11-21 07:21:54 +08:00
|
|
|
bool attach_drv)
|
2017-11-04 04:56:20 +08:00
|
|
|
{
|
2018-04-29 10:56:37 +08:00
|
|
|
return __bpf_prog_get(ufd, &type, attach_drv);
|
2017-11-04 04:56:20 +08:00
|
|
|
}
|
2017-11-04 04:56:21 +08:00
|
|
|
EXPORT_SYMBOL_GPL(bpf_prog_get_type_dev);
|
2017-11-04 04:56:20 +08:00
|
|
|
|
2018-03-31 06:08:07 +08:00
|
|
|
/* Initially all BPF programs could be loaded w/o specifying
|
|
|
|
* expected_attach_type. Later for some of them specifying expected_attach_type
|
|
|
|
* at load time became required so that program could be validated properly.
|
|
|
|
* Programs of types that are allowed to be loaded both w/ and w/o (for
|
|
|
|
* backward compatibility) expected_attach_type, should have the default attach
|
|
|
|
* type assigned to expected_attach_type for the latter case, so that it can be
|
|
|
|
* validated later at attach time.
|
|
|
|
*
|
|
|
|
* bpf_prog_load_fixup_attach_type() sets expected_attach_type in @attr if
|
|
|
|
* prog type requires it but has some attach types that have to be backward
|
|
|
|
* compatible.
|
|
|
|
*/
|
|
|
|
static void bpf_prog_load_fixup_attach_type(union bpf_attr *attr)
|
|
|
|
{
|
|
|
|
switch (attr->prog_type) {
|
|
|
|
case BPF_PROG_TYPE_CGROUP_SOCK:
|
|
|
|
/* Unfortunately BPF_ATTACH_TYPE_UNSPEC enumeration doesn't
|
|
|
|
* exist so checking for non-zero is the way to go here.
|
|
|
|
*/
|
|
|
|
if (!attr->expected_attach_type)
|
|
|
|
attr->expected_attach_type =
|
|
|
|
BPF_CGROUP_INET_SOCK_CREATE;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-03-31 06:08:00 +08:00
|
|
|
static int
|
|
|
|
bpf_prog_load_check_attach_type(enum bpf_prog_type prog_type,
|
|
|
|
enum bpf_attach_type expected_attach_type)
|
|
|
|
{
|
2018-03-31 06:08:02 +08:00
|
|
|
switch (prog_type) {
|
2018-03-31 06:08:07 +08:00
|
|
|
case BPF_PROG_TYPE_CGROUP_SOCK:
|
|
|
|
switch (expected_attach_type) {
|
|
|
|
case BPF_CGROUP_INET_SOCK_CREATE:
|
|
|
|
case BPF_CGROUP_INET4_POST_BIND:
|
|
|
|
case BPF_CGROUP_INET6_POST_BIND:
|
|
|
|
return 0;
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2018-03-31 06:08:02 +08:00
|
|
|
case BPF_PROG_TYPE_CGROUP_SOCK_ADDR:
|
|
|
|
switch (expected_attach_type) {
|
|
|
|
case BPF_CGROUP_INET4_BIND:
|
|
|
|
case BPF_CGROUP_INET6_BIND:
|
2018-03-31 06:08:05 +08:00
|
|
|
case BPF_CGROUP_INET4_CONNECT:
|
|
|
|
case BPF_CGROUP_INET6_CONNECT:
|
2018-05-25 23:55:23 +08:00
|
|
|
case BPF_CGROUP_UDP4_SENDMSG:
|
|
|
|
case BPF_CGROUP_UDP6_SENDMSG:
|
2018-03-31 06:08:02 +08:00
|
|
|
return 0;
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
return 0;
|
|
|
|
}
|
2018-03-31 06:08:00 +08:00
|
|
|
}
|
|
|
|
|
2014-09-26 15:17:00 +08:00
|
|
|
/* last field in 'union bpf_attr' used by this command */
|
bpf: Introduce bpf_func_info
This patch added interface to load a program with the following
additional information:
. prog_btf_fd
. func_info, func_info_rec_size and func_info_cnt
where func_info will provide function range and type_id
corresponding to each function.
The func_info_rec_size is introduced in the UAPI to specify
struct bpf_func_info size passed from user space. This
intends to make bpf_func_info structure growable in the future.
If the kernel gets a different bpf_func_info size from userspace,
it will try to handle user request with part of bpf_func_info
it can understand. In this patch, kernel can understand
struct bpf_func_info {
__u32 insn_offset;
__u32 type_id;
};
If user passed a bpf func_info record size of 16 bytes, the
kernel can still handle part of records with the above definition.
If verifier agrees with function range provided by the user,
the bpf_prog ksym for each function will use the func name
provided in the type_id, which is supposed to provide better
encoding as it is not limited by 16 bytes program name
limitation and this is better for bpf program which contains
multiple subprograms.
The bpf_prog_info interface is also extended to
return btf_id, func_info, func_info_rec_size and func_info_cnt
to userspace, so userspace can print out the function prototype
for each xlated function. The insn_offset in the returned
func_info corresponds to the insn offset for xlated functions.
With other jit related fields in bpf_prog_info, userspace can also
print out function prototypes for each jited function.
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-11-20 07:29:11 +08:00
|
|
|
#define BPF_PROG_LOAD_LAST_FIELD func_info_cnt
|
2014-09-26 15:17:00 +08:00
|
|
|
|
bpf: Introduce bpf_func_info
This patch added interface to load a program with the following
additional information:
. prog_btf_fd
. func_info, func_info_rec_size and func_info_cnt
where func_info will provide function range and type_id
corresponding to each function.
The func_info_rec_size is introduced in the UAPI to specify
struct bpf_func_info size passed from user space. This
intends to make bpf_func_info structure growable in the future.
If the kernel gets a different bpf_func_info size from userspace,
it will try to handle user request with part of bpf_func_info
it can understand. In this patch, kernel can understand
struct bpf_func_info {
__u32 insn_offset;
__u32 type_id;
};
If user passed a bpf func_info record size of 16 bytes, the
kernel can still handle part of records with the above definition.
If verifier agrees with function range provided by the user,
the bpf_prog ksym for each function will use the func name
provided in the type_id, which is supposed to provide better
encoding as it is not limited by 16 bytes program name
limitation and this is better for bpf program which contains
multiple subprograms.
The bpf_prog_info interface is also extended to
return btf_id, func_info, func_info_rec_size and func_info_cnt
to userspace, so userspace can print out the function prototype
for each xlated function. The insn_offset in the returned
func_info corresponds to the insn offset for xlated functions.
With other jit related fields in bpf_prog_info, userspace can also
print out function prototypes for each jited function.
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-11-20 07:29:11 +08:00
|
|
|
static int bpf_prog_load(union bpf_attr *attr, union bpf_attr __user *uattr)
|
2014-09-26 15:17:00 +08:00
|
|
|
{
|
|
|
|
enum bpf_prog_type type = attr->prog_type;
|
|
|
|
struct bpf_prog *prog;
|
|
|
|
int err;
|
|
|
|
char license[128];
|
|
|
|
bool is_gpl;
|
|
|
|
|
|
|
|
if (CHECK_ATTR(BPF_PROG_LOAD))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2018-12-01 13:08:14 +08:00
|
|
|
if (attr->prog_flags & ~(BPF_F_STRICT_ALIGNMENT | BPF_F_ANY_ALIGNMENT))
|
2017-05-11 02:38:07 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2018-12-01 13:08:14 +08:00
|
|
|
if (!IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) &&
|
|
|
|
(attr->prog_flags & BPF_F_ANY_ALIGNMENT) &&
|
|
|
|
!capable(CAP_SYS_ADMIN))
|
|
|
|
return -EPERM;
|
|
|
|
|
2014-09-26 15:17:00 +08:00
|
|
|
/* copy eBPF program license from user space */
|
2016-11-14 02:44:03 +08:00
|
|
|
if (strncpy_from_user(license, u64_to_user_ptr(attr->license),
|
2014-09-26 15:17:00 +08:00
|
|
|
sizeof(license) - 1) < 0)
|
|
|
|
return -EFAULT;
|
|
|
|
license[sizeof(license) - 1] = 0;
|
|
|
|
|
|
|
|
/* eBPF programs must be GPL compatible to use GPL-ed functions */
|
|
|
|
is_gpl = license_is_gpl_compatible(license);
|
|
|
|
|
2016-12-07 08:15:44 +08:00
|
|
|
if (attr->insn_cnt == 0 || attr->insn_cnt > BPF_MAXINSNS)
|
|
|
|
return -E2BIG;
|
2014-09-26 15:17:00 +08:00
|
|
|
|
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 03:49:20 +08:00
|
|
|
if (type == BPF_PROG_TYPE_KPROBE &&
|
|
|
|
attr->kern_version != LINUX_VERSION_CODE)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2017-06-01 09:16:00 +08:00
|
|
|
if (type != BPF_PROG_TYPE_SOCKET_FILTER &&
|
|
|
|
type != BPF_PROG_TYPE_CGROUP_SKB &&
|
|
|
|
!capable(CAP_SYS_ADMIN))
|
bpf: enable non-root eBPF programs
In order to let unprivileged users load and execute eBPF programs
teach verifier to prevent pointer leaks.
Verifier will prevent
- any arithmetic on pointers
(except R10+Imm which is used to compute stack addresses)
- comparison of pointers
(except if (map_value_ptr == 0) ... )
- passing pointers to helper functions
- indirectly passing pointers in stack to helper functions
- returning pointer from bpf program
- storing pointers into ctx or maps
Spill/fill of pointers into stack is allowed, but mangling
of pointers stored in the stack or reading them byte by byte is not.
Within bpf programs the pointers do exist, since programs need to
be able to access maps, pass skb pointer to LD_ABS insns, etc
but programs cannot pass such pointer values to the outside
or obfuscate them.
Only allow BPF_PROG_TYPE_SOCKET_FILTER unprivileged programs,
so that socket filters (tcpdump), af_packet (quic acceleration)
and future kcm can use it.
tracing and tc cls/act program types still require root permissions,
since tracing actually needs to be able to see all kernel pointers
and tc is for root only.
For example, the following unprivileged socket filter program is allowed:
int bpf_prog1(struct __sk_buff *skb)
{
u32 index = load_byte(skb, ETH_HLEN + offsetof(struct iphdr, protocol));
u64 *value = bpf_map_lookup_elem(&my_map, &index);
if (value)
*value += skb->len;
return 0;
}
but the following program is not:
int bpf_prog1(struct __sk_buff *skb)
{
u32 index = load_byte(skb, ETH_HLEN + offsetof(struct iphdr, protocol));
u64 *value = bpf_map_lookup_elem(&my_map, &index);
if (value)
*value += (u64) skb;
return 0;
}
since it would leak the kernel address into the map.
Unprivileged socket filter bpf programs have access to the
following helper functions:
- map lookup/update/delete (but they cannot store kernel pointers into them)
- get_random (it's already exposed to unprivileged user space)
- get_smp_processor_id
- tail_call into another socket filter program
- ktime_get_ns
The feature is controlled by sysctl kernel.unprivileged_bpf_disabled.
This toggle defaults to off (0), but can be set true (1). Once true,
bpf programs and maps cannot be accessed from unprivileged process,
and the toggle cannot be set back to false.
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-10-08 13:23:21 +08:00
|
|
|
return -EPERM;
|
|
|
|
|
2018-03-31 06:08:07 +08:00
|
|
|
bpf_prog_load_fixup_attach_type(attr);
|
2018-03-31 06:08:00 +08:00
|
|
|
if (bpf_prog_load_check_attach_type(type, attr->expected_attach_type))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2014-09-26 15:17:00 +08:00
|
|
|
/* plain bpf_prog allocation */
|
|
|
|
prog = bpf_prog_alloc(bpf_prog_size(attr->insn_cnt), GFP_USER);
|
|
|
|
if (!prog)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2018-03-31 06:08:00 +08:00
|
|
|
prog->expected_attach_type = attr->expected_attach_type;
|
|
|
|
|
2017-12-28 10:39:04 +08:00
|
|
|
prog->aux->offload_requested = !!attr->prog_ifindex;
|
|
|
|
|
2017-10-19 04:00:24 +08:00
|
|
|
err = security_bpf_prog_alloc(prog->aux);
|
2015-10-08 13:23:22 +08:00
|
|
|
if (err)
|
|
|
|
goto free_prog_nouncharge;
|
|
|
|
|
2017-10-19 04:00:24 +08:00
|
|
|
err = bpf_prog_charge_memlock(prog);
|
|
|
|
if (err)
|
|
|
|
goto free_prog_sec;
|
|
|
|
|
2014-09-26 15:17:00 +08:00
|
|
|
prog->len = attr->insn_cnt;
|
|
|
|
|
|
|
|
err = -EFAULT;
|
2016-11-14 02:44:03 +08:00
|
|
|
if (copy_from_user(prog->insns, u64_to_user_ptr(attr->insns),
|
2016-12-18 08:52:57 +08:00
|
|
|
bpf_prog_insn_size(prog)) != 0)
|
2014-09-26 15:17:00 +08:00
|
|
|
goto free_prog;
|
|
|
|
|
|
|
|
prog->orig_prog = NULL;
|
2015-09-30 07:41:50 +08:00
|
|
|
prog->jited = 0;
|
2014-09-26 15:17:00 +08:00
|
|
|
|
|
|
|
atomic_set(&prog->aux->refcnt, 1);
|
2015-09-30 07:41:50 +08:00
|
|
|
prog->gpl_compatible = is_gpl ? 1 : 0;
|
2014-09-26 15:17:00 +08:00
|
|
|
|
2017-12-28 10:39:04 +08:00
|
|
|
if (bpf_prog_is_dev_bound(prog->aux)) {
|
2017-11-04 04:56:17 +08:00
|
|
|
err = bpf_prog_offload_init(prog, attr);
|
|
|
|
if (err)
|
|
|
|
goto free_prog;
|
|
|
|
}
|
|
|
|
|
2014-09-26 15:17:00 +08:00
|
|
|
/* find program type: socket_filter vs tracing_filter */
|
|
|
|
err = find_prog_type(type, prog);
|
|
|
|
if (err < 0)
|
|
|
|
goto free_prog;
|
|
|
|
|
2017-09-28 05:37:52 +08:00
|
|
|
prog->aux->load_time = ktime_get_boot_ns();
|
|
|
|
err = bpf_obj_name_cpy(prog->aux->name, attr->prog_name);
|
|
|
|
if (err)
|
|
|
|
goto free_prog;
|
|
|
|
|
2014-09-26 15:17:00 +08:00
|
|
|
/* run eBPF verifier */
|
bpf: Introduce bpf_func_info
This patch added interface to load a program with the following
additional information:
. prog_btf_fd
. func_info, func_info_rec_size and func_info_cnt
where func_info will provide function range and type_id
corresponding to each function.
The func_info_rec_size is introduced in the UAPI to specify
struct bpf_func_info size passed from user space. This
intends to make bpf_func_info structure growable in the future.
If the kernel gets a different bpf_func_info size from userspace,
it will try to handle user request with part of bpf_func_info
it can understand. In this patch, kernel can understand
struct bpf_func_info {
__u32 insn_offset;
__u32 type_id;
};
If user passed a bpf func_info record size of 16 bytes, the
kernel can still handle part of records with the above definition.
If verifier agrees with function range provided by the user,
the bpf_prog ksym for each function will use the func name
provided in the type_id, which is supposed to provide better
encoding as it is not limited by 16 bytes program name
limitation and this is better for bpf program which contains
multiple subprograms.
The bpf_prog_info interface is also extended to
return btf_id, func_info, func_info_rec_size and func_info_cnt
to userspace, so userspace can print out the function prototype
for each xlated function. The insn_offset in the returned
func_info corresponds to the insn offset for xlated functions.
With other jit related fields in bpf_prog_info, userspace can also
print out function prototypes for each jited function.
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-11-20 07:29:11 +08:00
|
|
|
err = bpf_check(&prog, attr, uattr);
|
2014-09-26 15:17:00 +08:00
|
|
|
if (err < 0)
|
|
|
|
goto free_used_maps;
|
|
|
|
|
bpf: reject any prog that failed read-only lock
We currently lock any JITed image as read-only via bpf_jit_binary_lock_ro()
as well as the BPF image as read-only through bpf_prog_lock_ro(). In
the case any of these would fail we throw a WARN_ON_ONCE() in order to
yell loudly to the log. Perhaps, to some extend, this may be comparable
to an allocation where __GFP_NOWARN is explicitly not set.
Added via 65869a47f348 ("bpf: improve read-only handling"), this behavior
is slightly different compared to any of the other in-kernel set_memory_ro()
users who do not check the return code of set_memory_ro() and friends /at
all/ (e.g. in the case of module_enable_ro() / module_disable_ro()). Given
in BPF this is mandatory hardening step, we want to know whether there
are any issues that would leave both BPF data writable. So it happens
that syzkaller enabled fault injection and it triggered memory allocation
failure deep inside x86's change_page_attr_set_clr() which was triggered
from set_memory_ro().
Now, there are two options: i) leaving everything as is, and ii) reworking
the image locking code in order to have a final checkpoint out of the
central bpf_prog_select_runtime() which probes whether any of the calls
during prog setup weren't successful, and then bailing out with an error.
Option ii) is a better approach since this additional paranoia avoids
altogether leaving any potential W+X pages from BPF side in the system.
Therefore, lets be strict about it, and reject programs in such unlikely
occasion. While testing I noticed also that one bpf_prog_lock_ro()
call was missing on the outer dummy prog in case of calls, e.g. in the
destructor we call bpf_prog_free_deferred() on the main prog where we
try to bpf_prog_unlock_free() the program, and since we go via
bpf_prog_select_runtime() do that as well.
Reported-by: syzbot+3b889862e65a98317058@syzkaller.appspotmail.com
Reported-by: syzbot+9e762b52dd17e616a7a5@syzkaller.appspotmail.com
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-06-15 08:30:48 +08:00
|
|
|
prog = bpf_prog_select_runtime(prog, &err);
|
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 07:59:03 +08:00
|
|
|
if (err < 0)
|
|
|
|
goto free_used_maps;
|
2014-09-26 15:17:00 +08:00
|
|
|
|
2017-06-06 03:15:46 +08:00
|
|
|
err = bpf_prog_alloc_id(prog);
|
|
|
|
if (err)
|
|
|
|
goto free_used_maps;
|
|
|
|
|
2015-10-29 21:58:06 +08:00
|
|
|
err = bpf_prog_new_fd(prog);
|
2017-06-06 03:15:49 +08:00
|
|
|
if (err < 0) {
|
|
|
|
/* failed to allocate fd.
|
|
|
|
* bpf_prog_put() is needed because the above
|
|
|
|
* bpf_prog_alloc_id() has published the prog
|
|
|
|
* to the userspace and the userspace may
|
|
|
|
* have refcnt-ed it through BPF_PROG_GET_FD_BY_ID.
|
|
|
|
*/
|
|
|
|
bpf_prog_put(prog);
|
|
|
|
return err;
|
|
|
|
}
|
2014-09-26 15:17:00 +08:00
|
|
|
|
bpf: make jited programs visible in traces
Long standing issue with JITed programs is that stack traces from
function tracing check whether a given address is kernel code
through {__,}kernel_text_address(), which checks for code in core
kernel, modules and dynamically allocated ftrace trampolines. But
what is still missing is BPF JITed programs (interpreted programs
are not an issue as __bpf_prog_run() will be attributed to them),
thus when a stack trace is triggered, the code walking the stack
won't see any of the JITed ones. The same for address correlation
done from user space via reading /proc/kallsyms. This is read by
tools like perf, but the latter is also useful for permanent live
tracing with eBPF itself in combination with stack maps when other
eBPF types are part of the callchain. See offwaketime example on
dumping stack from a map.
This work tries to tackle that issue by making the addresses and
symbols known to the kernel. The lookup from *kernel_text_address()
is implemented through a latched RB tree that can be read under
RCU in fast-path that is also shared for symbol/size/offset lookup
for a specific given address in kallsyms. The slow-path iteration
through all symbols in the seq file done via RCU list, which holds
a tiny fraction of all exported ksyms, usually below 0.1 percent.
Function symbols are exported as bpf_prog_<tag>, in order to aide
debugging and attribution. This facility is currently enabled for
root-only when bpf_jit_kallsyms is set to 1, and disabled if hardening
is active in any mode. The rationale behind this is that still a lot
of systems ship with world read permissions on kallsyms thus addresses
should not get suddenly exposed for them. If that situation gets
much better in future, we always have the option to change the
default on this. Likewise, unprivileged programs are not allowed
to add entries there either, but that is less of a concern as most
such programs types relevant in this context are for root-only anyway.
If enabled, call graphs and stack traces will then show a correct
attribution; one example is illustrated below, where the trace is
now visible in tooling such as perf script --kallsyms=/proc/kallsyms
and friends.
Before:
7fff8166889d bpf_clone_redirect+0x80007f0020ed (/lib/modules/4.9.0-rc8+/build/vmlinux)
f5d80 __sendmsg_nocancel+0xffff006451f1a007 (/usr/lib64/libc-2.18.so)
After:
7fff816688b7 bpf_clone_redirect+0x80007f002107 (/lib/modules/4.9.0-rc8+/build/vmlinux)
7fffa0575728 bpf_prog_33c45a467c9e061a+0x8000600020fb (/lib/modules/4.9.0-rc8+/build/vmlinux)
7fffa07ef1fc cls_bpf_classify+0x8000600020dc (/lib/modules/4.9.0-rc8+/build/vmlinux)
7fff81678b68 tc_classify+0x80007f002078 (/lib/modules/4.9.0-rc8+/build/vmlinux)
7fff8164d40b __netif_receive_skb_core+0x80007f0025fb (/lib/modules/4.9.0-rc8+/build/vmlinux)
7fff8164d718 __netif_receive_skb+0x80007f002018 (/lib/modules/4.9.0-rc8+/build/vmlinux)
7fff8164e565 process_backlog+0x80007f002095 (/lib/modules/4.9.0-rc8+/build/vmlinux)
7fff8164dc71 net_rx_action+0x80007f002231 (/lib/modules/4.9.0-rc8+/build/vmlinux)
7fff81767461 __softirqentry_text_start+0x80007f0020d1 (/lib/modules/4.9.0-rc8+/build/vmlinux)
7fff817658ac do_softirq_own_stack+0x80007f00201c (/lib/modules/4.9.0-rc8+/build/vmlinux)
7fff810a2c20 do_softirq+0x80007f002050 (/lib/modules/4.9.0-rc8+/build/vmlinux)
7fff810a2cb5 __local_bh_enable_ip+0x80007f002085 (/lib/modules/4.9.0-rc8+/build/vmlinux)
7fff8168d452 ip_finish_output2+0x80007f002152 (/lib/modules/4.9.0-rc8+/build/vmlinux)
7fff8168ea3d ip_finish_output+0x80007f00217d (/lib/modules/4.9.0-rc8+/build/vmlinux)
7fff8168f2af ip_output+0x80007f00203f (/lib/modules/4.9.0-rc8+/build/vmlinux)
[...]
7fff81005854 do_syscall_64+0x80007f002054 (/lib/modules/4.9.0-rc8+/build/vmlinux)
7fff817649eb return_from_SYSCALL_64+0x80007f002000 (/lib/modules/4.9.0-rc8+/build/vmlinux)
f5d80 __sendmsg_nocancel+0xffff01c484812007 (/usr/lib64/libc-2.18.so)
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-17 05:24:50 +08:00
|
|
|
bpf_prog_kallsyms_add(prog);
|
2014-09-26 15:17:00 +08:00
|
|
|
return err;
|
|
|
|
|
|
|
|
free_used_maps:
|
2018-12-02 09:08:44 +08:00
|
|
|
kvfree(prog->aux->func_info);
|
|
|
|
btf_put(prog->aux->btf);
|
2018-06-15 08:30:47 +08:00
|
|
|
bpf_prog_kallsyms_del_subprogs(prog);
|
2014-09-26 15:17:00 +08:00
|
|
|
free_used_maps(prog->aux);
|
|
|
|
free_prog:
|
2015-10-08 13:23:22 +08:00
|
|
|
bpf_prog_uncharge_memlock(prog);
|
2017-10-19 04:00:24 +08:00
|
|
|
free_prog_sec:
|
|
|
|
security_bpf_prog_free(prog->aux);
|
2015-10-08 13:23:22 +08:00
|
|
|
free_prog_nouncharge:
|
2014-09-26 15:17:00 +08:00
|
|
|
bpf_prog_free(prog);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2017-10-19 04:00:22 +08:00
|
|
|
#define BPF_OBJ_LAST_FIELD file_flags
|
2015-10-29 21:58:09 +08:00
|
|
|
|
|
|
|
static int bpf_obj_pin(const union bpf_attr *attr)
|
|
|
|
{
|
2017-10-19 04:00:22 +08:00
|
|
|
if (CHECK_ATTR(BPF_OBJ) || attr->file_flags != 0)
|
2015-10-29 21:58:09 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2016-11-14 02:44:03 +08:00
|
|
|
return bpf_obj_pin_user(attr->bpf_fd, u64_to_user_ptr(attr->pathname));
|
2015-10-29 21:58:09 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int bpf_obj_get(const union bpf_attr *attr)
|
|
|
|
{
|
2017-10-19 04:00:22 +08:00
|
|
|
if (CHECK_ATTR(BPF_OBJ) || attr->bpf_fd != 0 ||
|
|
|
|
attr->file_flags & ~BPF_OBJ_FLAG_MASK)
|
2015-10-29 21:58:09 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2017-10-19 04:00:22 +08:00
|
|
|
return bpf_obj_get_user(u64_to_user_ptr(attr->pathname),
|
|
|
|
attr->file_flags);
|
2015-10-29 21:58:09 +08:00
|
|
|
}
|
|
|
|
|
2018-03-29 03:05:37 +08:00
|
|
|
struct bpf_raw_tracepoint {
|
|
|
|
struct bpf_raw_event_map *btp;
|
|
|
|
struct bpf_prog *prog;
|
|
|
|
};
|
|
|
|
|
|
|
|
static int bpf_raw_tracepoint_release(struct inode *inode, struct file *filp)
|
|
|
|
{
|
|
|
|
struct bpf_raw_tracepoint *raw_tp = filp->private_data;
|
|
|
|
|
|
|
|
if (raw_tp->prog) {
|
|
|
|
bpf_probe_unregister(raw_tp->btp, raw_tp->prog);
|
|
|
|
bpf_prog_put(raw_tp->prog);
|
|
|
|
}
|
|
|
|
kfree(raw_tp);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct file_operations bpf_raw_tp_fops = {
|
|
|
|
.release = bpf_raw_tracepoint_release,
|
|
|
|
.read = bpf_dummy_read,
|
|
|
|
.write = bpf_dummy_write,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define BPF_RAW_TRACEPOINT_OPEN_LAST_FIELD raw_tracepoint.prog_fd
|
|
|
|
|
|
|
|
static int bpf_raw_tracepoint_open(const union bpf_attr *attr)
|
|
|
|
{
|
|
|
|
struct bpf_raw_tracepoint *raw_tp;
|
|
|
|
struct bpf_raw_event_map *btp;
|
|
|
|
struct bpf_prog *prog;
|
|
|
|
char tp_name[128];
|
|
|
|
int tp_fd, err;
|
|
|
|
|
|
|
|
if (strncpy_from_user(tp_name, u64_to_user_ptr(attr->raw_tracepoint.name),
|
|
|
|
sizeof(tp_name) - 1) < 0)
|
|
|
|
return -EFAULT;
|
|
|
|
tp_name[sizeof(tp_name) - 1] = 0;
|
|
|
|
|
|
|
|
btp = bpf_find_raw_tracepoint(tp_name);
|
|
|
|
if (!btp)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
raw_tp = kzalloc(sizeof(*raw_tp), GFP_USER);
|
|
|
|
if (!raw_tp)
|
|
|
|
return -ENOMEM;
|
|
|
|
raw_tp->btp = btp;
|
|
|
|
|
|
|
|
prog = bpf_prog_get_type(attr->raw_tracepoint.prog_fd,
|
|
|
|
BPF_PROG_TYPE_RAW_TRACEPOINT);
|
|
|
|
if (IS_ERR(prog)) {
|
|
|
|
err = PTR_ERR(prog);
|
|
|
|
goto out_free_tp;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = bpf_probe_register(raw_tp->btp, prog);
|
|
|
|
if (err)
|
|
|
|
goto out_put_prog;
|
|
|
|
|
|
|
|
raw_tp->prog = prog;
|
|
|
|
tp_fd = anon_inode_getfd("bpf-raw-tracepoint", &bpf_raw_tp_fops, raw_tp,
|
|
|
|
O_CLOEXEC);
|
|
|
|
if (tp_fd < 0) {
|
|
|
|
bpf_probe_unregister(raw_tp->btp, prog);
|
|
|
|
err = tp_fd;
|
|
|
|
goto out_put_prog;
|
|
|
|
}
|
|
|
|
return tp_fd;
|
|
|
|
|
|
|
|
out_put_prog:
|
|
|
|
bpf_prog_put(prog);
|
|
|
|
out_free_tp:
|
|
|
|
kfree(raw_tp);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2018-04-03 20:09:47 +08:00
|
|
|
static int bpf_prog_attach_check_attach_type(const struct bpf_prog *prog,
|
|
|
|
enum bpf_attach_type attach_type)
|
|
|
|
{
|
|
|
|
switch (prog->type) {
|
|
|
|
case BPF_PROG_TYPE_CGROUP_SOCK:
|
|
|
|
case BPF_PROG_TYPE_CGROUP_SOCK_ADDR:
|
|
|
|
return attach_type == prog->expected_attach_type ? 0 : -EINVAL;
|
|
|
|
default:
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-08-28 22:10:04 +08:00
|
|
|
#define BPF_PROG_ATTACH_LAST_FIELD attach_flags
|
2017-08-16 13:32:47 +08:00
|
|
|
|
2017-10-03 13:50:21 +08:00
|
|
|
#define BPF_F_ATTACH_MASK \
|
|
|
|
(BPF_F_ALLOW_OVERRIDE | BPF_F_ALLOW_MULTI)
|
|
|
|
|
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 23:52:27 +08:00
|
|
|
static int bpf_prog_attach(const union bpf_attr *attr)
|
|
|
|
{
|
2017-02-11 12:28:24 +08:00
|
|
|
enum bpf_prog_type ptype;
|
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 23:52:27 +08:00
|
|
|
struct bpf_prog *prog;
|
2017-02-11 12:28:24 +08:00
|
|
|
int ret;
|
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 23:52:27 +08:00
|
|
|
|
|
|
|
if (!capable(CAP_NET_ADMIN))
|
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
if (CHECK_ATTR(BPF_PROG_ATTACH))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2017-10-03 13:50:21 +08:00
|
|
|
if (attr->attach_flags & ~BPF_F_ATTACH_MASK)
|
2017-02-11 12:28:24 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
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 23:52:27 +08:00
|
|
|
switch (attr->attach_type) {
|
|
|
|
case BPF_CGROUP_INET_INGRESS:
|
|
|
|
case BPF_CGROUP_INET_EGRESS:
|
2016-12-02 00:48:03 +08:00
|
|
|
ptype = BPF_PROG_TYPE_CGROUP_SKB;
|
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 23:52:27 +08:00
|
|
|
break;
|
2016-12-02 00:48:04 +08:00
|
|
|
case BPF_CGROUP_INET_SOCK_CREATE:
|
2018-03-31 06:08:07 +08:00
|
|
|
case BPF_CGROUP_INET4_POST_BIND:
|
|
|
|
case BPF_CGROUP_INET6_POST_BIND:
|
2016-12-02 00:48:04 +08:00
|
|
|
ptype = BPF_PROG_TYPE_CGROUP_SOCK;
|
|
|
|
break;
|
2018-03-31 06:08:02 +08:00
|
|
|
case BPF_CGROUP_INET4_BIND:
|
|
|
|
case BPF_CGROUP_INET6_BIND:
|
2018-03-31 06:08:05 +08:00
|
|
|
case BPF_CGROUP_INET4_CONNECT:
|
|
|
|
case BPF_CGROUP_INET6_CONNECT:
|
2018-05-25 23:55:23 +08:00
|
|
|
case BPF_CGROUP_UDP4_SENDMSG:
|
|
|
|
case BPF_CGROUP_UDP6_SENDMSG:
|
2018-03-31 06:08:02 +08:00
|
|
|
ptype = BPF_PROG_TYPE_CGROUP_SOCK_ADDR;
|
|
|
|
break;
|
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 11:02:40 +08:00
|
|
|
case BPF_CGROUP_SOCK_OPS:
|
|
|
|
ptype = BPF_PROG_TYPE_SOCK_OPS;
|
|
|
|
break;
|
2017-11-05 21:15:32 +08:00
|
|
|
case BPF_CGROUP_DEVICE:
|
|
|
|
ptype = BPF_PROG_TYPE_CGROUP_DEVICE;
|
|
|
|
break;
|
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 03:57:10 +08:00
|
|
|
case BPF_SK_MSG_VERDICT:
|
2018-06-19 07:04:24 +08:00
|
|
|
ptype = BPF_PROG_TYPE_SK_MSG;
|
|
|
|
break;
|
2017-08-28 22:10:04 +08:00
|
|
|
case BPF_SK_SKB_STREAM_PARSER:
|
|
|
|
case BPF_SK_SKB_STREAM_VERDICT:
|
2018-06-19 07:04:24 +08:00
|
|
|
ptype = BPF_PROG_TYPE_SK_SKB;
|
|
|
|
break;
|
2018-05-27 19:24:09 +08:00
|
|
|
case BPF_LIRC_MODE2:
|
2018-06-19 07:04:24 +08:00
|
|
|
ptype = BPF_PROG_TYPE_LIRC_MODE2;
|
|
|
|
break;
|
2018-09-14 22:46:18 +08:00
|
|
|
case BPF_FLOW_DISSECTOR:
|
|
|
|
ptype = BPF_PROG_TYPE_FLOW_DISSECTOR;
|
|
|
|
break;
|
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 23:52:27 +08:00
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2016-12-02 00:48:03 +08:00
|
|
|
prog = bpf_prog_get_type(attr->attach_bpf_fd, ptype);
|
|
|
|
if (IS_ERR(prog))
|
|
|
|
return PTR_ERR(prog);
|
|
|
|
|
2018-03-31 06:08:00 +08:00
|
|
|
if (bpf_prog_attach_check_attach_type(prog, attr->attach_type)) {
|
|
|
|
bpf_prog_put(prog);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2018-06-19 07:04:24 +08:00
|
|
|
switch (ptype) {
|
|
|
|
case BPF_PROG_TYPE_SK_SKB:
|
|
|
|
case BPF_PROG_TYPE_SK_MSG:
|
bpf, sockmap: convert to generic sk_msg interface
Add a generic sk_msg layer, and convert current sockmap and later
kTLS over to make use of it. While sk_buff handles network packet
representation from netdevice up to socket, sk_msg handles data
representation from application to socket layer.
This means that sk_msg framework spans across ULP users in the
kernel, and enables features such as introspection or filtering
of data with the help of BPF programs that operate on this data
structure.
Latter becomes in particular useful for kTLS where data encryption
is deferred into the kernel, and as such enabling the kernel to
perform L7 introspection and policy based on BPF for TLS connections
where the record is being encrypted after BPF has run and came to
a verdict. In order to get there, first step is to transform open
coding of scatter-gather list handling into a common core framework
that subsystems can use.
The code itself has been split and refactored into three bigger
pieces: i) the generic sk_msg API which deals with managing the
scatter gather ring, providing helpers for walking and mangling,
transferring application data from user space into it, and preparing
it for BPF pre/post-processing, ii) the plain sock map itself
where sockets can be attached to or detached from; these bits
are independent of i) which can now be used also without sock
map, and iii) the integration with plain TCP as one protocol
to be used for processing L7 application data (later this could
e.g. also be extended to other protocols like UDP). The semantics
are the same with the old sock map code and therefore no change
of user facing behavior or APIs. While pursuing this work it
also helped finding a number of bugs in the old sockmap code
that we've fixed already in earlier commits. The test_sockmap
kselftest suite passes through fine as well.
Joint work with John.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-10-13 08:45:58 +08:00
|
|
|
ret = sock_map_get_from_fd(attr, prog);
|
2018-06-19 07:04:24 +08:00
|
|
|
break;
|
|
|
|
case BPF_PROG_TYPE_LIRC_MODE2:
|
|
|
|
ret = lirc_prog_attach(attr, prog);
|
|
|
|
break;
|
2018-09-14 22:46:18 +08:00
|
|
|
case BPF_PROG_TYPE_FLOW_DISSECTOR:
|
|
|
|
ret = skb_flow_dissector_bpf_prog_attach(attr, prog);
|
|
|
|
break;
|
2018-06-19 07:04:24 +08:00
|
|
|
default:
|
|
|
|
ret = cgroup_bpf_prog_attach(attr, ptype, prog);
|
2016-12-02 00:48:03 +08:00
|
|
|
}
|
|
|
|
|
2017-02-11 12:28:24 +08:00
|
|
|
if (ret)
|
|
|
|
bpf_prog_put(prog);
|
|
|
|
return ret;
|
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 23:52:27 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
#define BPF_PROG_DETACH_LAST_FIELD attach_type
|
|
|
|
|
|
|
|
static int bpf_prog_detach(const union bpf_attr *attr)
|
|
|
|
{
|
2017-10-03 13:50:21 +08:00
|
|
|
enum bpf_prog_type ptype;
|
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 23:52:27 +08:00
|
|
|
|
|
|
|
if (!capable(CAP_NET_ADMIN))
|
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
if (CHECK_ATTR(BPF_PROG_DETACH))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
switch (attr->attach_type) {
|
|
|
|
case BPF_CGROUP_INET_INGRESS:
|
|
|
|
case BPF_CGROUP_INET_EGRESS:
|
2017-10-03 13:50:21 +08:00
|
|
|
ptype = BPF_PROG_TYPE_CGROUP_SKB;
|
|
|
|
break;
|
2016-12-02 00:48:04 +08:00
|
|
|
case BPF_CGROUP_INET_SOCK_CREATE:
|
2018-03-31 06:08:07 +08:00
|
|
|
case BPF_CGROUP_INET4_POST_BIND:
|
|
|
|
case BPF_CGROUP_INET6_POST_BIND:
|
2017-10-03 13:50:21 +08:00
|
|
|
ptype = BPF_PROG_TYPE_CGROUP_SOCK;
|
|
|
|
break;
|
2018-03-31 06:08:02 +08:00
|
|
|
case BPF_CGROUP_INET4_BIND:
|
|
|
|
case BPF_CGROUP_INET6_BIND:
|
2018-03-31 06:08:05 +08:00
|
|
|
case BPF_CGROUP_INET4_CONNECT:
|
|
|
|
case BPF_CGROUP_INET6_CONNECT:
|
2018-05-25 23:55:23 +08:00
|
|
|
case BPF_CGROUP_UDP4_SENDMSG:
|
|
|
|
case BPF_CGROUP_UDP6_SENDMSG:
|
2018-03-31 06:08:02 +08:00
|
|
|
ptype = BPF_PROG_TYPE_CGROUP_SOCK_ADDR;
|
|
|
|
break;
|
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 11:02:40 +08:00
|
|
|
case BPF_CGROUP_SOCK_OPS:
|
2017-10-03 13:50:21 +08:00
|
|
|
ptype = BPF_PROG_TYPE_SOCK_OPS;
|
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 23:52:27 +08:00
|
|
|
break;
|
2017-11-05 21:15:32 +08:00
|
|
|
case BPF_CGROUP_DEVICE:
|
|
|
|
ptype = BPF_PROG_TYPE_CGROUP_DEVICE;
|
|
|
|
break;
|
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 03:57:10 +08:00
|
|
|
case BPF_SK_MSG_VERDICT:
|
bpf, sockmap: convert to generic sk_msg interface
Add a generic sk_msg layer, and convert current sockmap and later
kTLS over to make use of it. While sk_buff handles network packet
representation from netdevice up to socket, sk_msg handles data
representation from application to socket layer.
This means that sk_msg framework spans across ULP users in the
kernel, and enables features such as introspection or filtering
of data with the help of BPF programs that operate on this data
structure.
Latter becomes in particular useful for kTLS where data encryption
is deferred into the kernel, and as such enabling the kernel to
perform L7 introspection and policy based on BPF for TLS connections
where the record is being encrypted after BPF has run and came to
a verdict. In order to get there, first step is to transform open
coding of scatter-gather list handling into a common core framework
that subsystems can use.
The code itself has been split and refactored into three bigger
pieces: i) the generic sk_msg API which deals with managing the
scatter gather ring, providing helpers for walking and mangling,
transferring application data from user space into it, and preparing
it for BPF pre/post-processing, ii) the plain sock map itself
where sockets can be attached to or detached from; these bits
are independent of i) which can now be used also without sock
map, and iii) the integration with plain TCP as one protocol
to be used for processing L7 application data (later this could
e.g. also be extended to other protocols like UDP). The semantics
are the same with the old sock map code and therefore no change
of user facing behavior or APIs. While pursuing this work it
also helped finding a number of bugs in the old sockmap code
that we've fixed already in earlier commits. The test_sockmap
kselftest suite passes through fine as well.
Joint work with John.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-10-13 08:45:58 +08:00
|
|
|
return sock_map_get_from_fd(attr, NULL);
|
2017-09-09 05:00:49 +08:00
|
|
|
case BPF_SK_SKB_STREAM_PARSER:
|
|
|
|
case BPF_SK_SKB_STREAM_VERDICT:
|
bpf, sockmap: convert to generic sk_msg interface
Add a generic sk_msg layer, and convert current sockmap and later
kTLS over to make use of it. While sk_buff handles network packet
representation from netdevice up to socket, sk_msg handles data
representation from application to socket layer.
This means that sk_msg framework spans across ULP users in the
kernel, and enables features such as introspection or filtering
of data with the help of BPF programs that operate on this data
structure.
Latter becomes in particular useful for kTLS where data encryption
is deferred into the kernel, and as such enabling the kernel to
perform L7 introspection and policy based on BPF for TLS connections
where the record is being encrypted after BPF has run and came to
a verdict. In order to get there, first step is to transform open
coding of scatter-gather list handling into a common core framework
that subsystems can use.
The code itself has been split and refactored into three bigger
pieces: i) the generic sk_msg API which deals with managing the
scatter gather ring, providing helpers for walking and mangling,
transferring application data from user space into it, and preparing
it for BPF pre/post-processing, ii) the plain sock map itself
where sockets can be attached to or detached from; these bits
are independent of i) which can now be used also without sock
map, and iii) the integration with plain TCP as one protocol
to be used for processing L7 application data (later this could
e.g. also be extended to other protocols like UDP). The semantics
are the same with the old sock map code and therefore no change
of user facing behavior or APIs. While pursuing this work it
also helped finding a number of bugs in the old sockmap code
that we've fixed already in earlier commits. The test_sockmap
kselftest suite passes through fine as well.
Joint work with John.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-10-13 08:45:58 +08:00
|
|
|
return sock_map_get_from_fd(attr, NULL);
|
2018-05-27 19:24:09 +08:00
|
|
|
case BPF_LIRC_MODE2:
|
|
|
|
return lirc_prog_detach(attr);
|
2018-09-14 22:46:18 +08:00
|
|
|
case BPF_FLOW_DISSECTOR:
|
|
|
|
return skb_flow_dissector_bpf_prog_detach(attr);
|
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 23:52:27 +08:00
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2018-06-19 07:04:24 +08:00
|
|
|
return cgroup_bpf_prog_detach(attr, ptype);
|
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 23:52:27 +08:00
|
|
|
}
|
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 11:02:40 +08:00
|
|
|
|
2017-10-03 13:50:22 +08:00
|
|
|
#define BPF_PROG_QUERY_LAST_FIELD query.prog_cnt
|
|
|
|
|
|
|
|
static int bpf_prog_query(const union bpf_attr *attr,
|
|
|
|
union bpf_attr __user *uattr)
|
|
|
|
{
|
|
|
|
if (!capable(CAP_NET_ADMIN))
|
|
|
|
return -EPERM;
|
|
|
|
if (CHECK_ATTR(BPF_PROG_QUERY))
|
|
|
|
return -EINVAL;
|
|
|
|
if (attr->query.query_flags & ~BPF_F_QUERY_EFFECTIVE)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
switch (attr->query.attach_type) {
|
|
|
|
case BPF_CGROUP_INET_INGRESS:
|
|
|
|
case BPF_CGROUP_INET_EGRESS:
|
|
|
|
case BPF_CGROUP_INET_SOCK_CREATE:
|
2018-03-31 06:08:02 +08:00
|
|
|
case BPF_CGROUP_INET4_BIND:
|
|
|
|
case BPF_CGROUP_INET6_BIND:
|
2018-03-31 06:08:07 +08:00
|
|
|
case BPF_CGROUP_INET4_POST_BIND:
|
|
|
|
case BPF_CGROUP_INET6_POST_BIND:
|
2018-03-31 06:08:05 +08:00
|
|
|
case BPF_CGROUP_INET4_CONNECT:
|
|
|
|
case BPF_CGROUP_INET6_CONNECT:
|
2018-05-25 23:55:23 +08:00
|
|
|
case BPF_CGROUP_UDP4_SENDMSG:
|
|
|
|
case BPF_CGROUP_UDP6_SENDMSG:
|
2017-10-03 13:50:22 +08:00
|
|
|
case BPF_CGROUP_SOCK_OPS:
|
2017-11-05 21:15:32 +08:00
|
|
|
case BPF_CGROUP_DEVICE:
|
2017-10-03 13:50:22 +08:00
|
|
|
break;
|
2018-05-27 19:24:09 +08:00
|
|
|
case BPF_LIRC_MODE2:
|
|
|
|
return lirc_prog_query(attr, uattr);
|
2017-10-03 13:50:22 +08:00
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2018-06-19 07:04:24 +08:00
|
|
|
|
|
|
|
return cgroup_bpf_prog_query(attr, uattr);
|
2017-10-03 13:50:22 +08: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 23:52:27 +08:00
|
|
|
|
2017-03-31 12:45:38 +08:00
|
|
|
#define BPF_PROG_TEST_RUN_LAST_FIELD test.duration
|
|
|
|
|
|
|
|
static int bpf_prog_test_run(const union bpf_attr *attr,
|
|
|
|
union bpf_attr __user *uattr)
|
|
|
|
{
|
|
|
|
struct bpf_prog *prog;
|
|
|
|
int ret = -ENOTSUPP;
|
|
|
|
|
2018-01-18 08:52:02 +08:00
|
|
|
if (!capable(CAP_SYS_ADMIN))
|
|
|
|
return -EPERM;
|
2017-03-31 12:45:38 +08:00
|
|
|
if (CHECK_ATTR(BPF_PROG_TEST_RUN))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
prog = bpf_prog_get(attr->test.prog_fd);
|
|
|
|
if (IS_ERR(prog))
|
|
|
|
return PTR_ERR(prog);
|
|
|
|
|
|
|
|
if (prog->aux->ops->test_run)
|
|
|
|
ret = prog->aux->ops->test_run(prog, attr, uattr);
|
|
|
|
|
|
|
|
bpf_prog_put(prog);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2017-06-06 03:15:48 +08:00
|
|
|
#define BPF_OBJ_GET_NEXT_ID_LAST_FIELD next_id
|
|
|
|
|
|
|
|
static int bpf_obj_get_next_id(const union bpf_attr *attr,
|
|
|
|
union bpf_attr __user *uattr,
|
|
|
|
struct idr *idr,
|
|
|
|
spinlock_t *lock)
|
|
|
|
{
|
|
|
|
u32 next_id = attr->start_id;
|
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
if (CHECK_ATTR(BPF_OBJ_GET_NEXT_ID) || next_id >= INT_MAX)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (!capable(CAP_SYS_ADMIN))
|
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
next_id++;
|
|
|
|
spin_lock_bh(lock);
|
|
|
|
if (!idr_get_next(idr, &next_id))
|
|
|
|
err = -ENOENT;
|
|
|
|
spin_unlock_bh(lock);
|
|
|
|
|
|
|
|
if (!err)
|
|
|
|
err = put_user(next_id, &uattr->next_id);
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2017-06-06 03:15:49 +08:00
|
|
|
#define BPF_PROG_GET_FD_BY_ID_LAST_FIELD prog_id
|
|
|
|
|
|
|
|
static int bpf_prog_get_fd_by_id(const union bpf_attr *attr)
|
|
|
|
{
|
|
|
|
struct bpf_prog *prog;
|
|
|
|
u32 id = attr->prog_id;
|
|
|
|
int fd;
|
|
|
|
|
|
|
|
if (CHECK_ATTR(BPF_PROG_GET_FD_BY_ID))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (!capable(CAP_SYS_ADMIN))
|
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
spin_lock_bh(&prog_idr_lock);
|
|
|
|
prog = idr_find(&prog_idr, id);
|
|
|
|
if (prog)
|
|
|
|
prog = bpf_prog_inc_not_zero(prog);
|
|
|
|
else
|
|
|
|
prog = ERR_PTR(-ENOENT);
|
|
|
|
spin_unlock_bh(&prog_idr_lock);
|
|
|
|
|
|
|
|
if (IS_ERR(prog))
|
|
|
|
return PTR_ERR(prog);
|
|
|
|
|
|
|
|
fd = bpf_prog_new_fd(prog);
|
|
|
|
if (fd < 0)
|
|
|
|
bpf_prog_put(prog);
|
|
|
|
|
|
|
|
return fd;
|
|
|
|
}
|
|
|
|
|
2017-10-19 04:00:22 +08:00
|
|
|
#define BPF_MAP_GET_FD_BY_ID_LAST_FIELD open_flags
|
2017-06-06 03:15:50 +08:00
|
|
|
|
|
|
|
static int bpf_map_get_fd_by_id(const union bpf_attr *attr)
|
|
|
|
{
|
|
|
|
struct bpf_map *map;
|
|
|
|
u32 id = attr->map_id;
|
2017-10-19 04:00:22 +08:00
|
|
|
int f_flags;
|
2017-06-06 03:15:50 +08:00
|
|
|
int fd;
|
|
|
|
|
2017-10-19 04:00:22 +08:00
|
|
|
if (CHECK_ATTR(BPF_MAP_GET_FD_BY_ID) ||
|
|
|
|
attr->open_flags & ~BPF_OBJ_FLAG_MASK)
|
2017-06-06 03:15:50 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (!capable(CAP_SYS_ADMIN))
|
|
|
|
return -EPERM;
|
|
|
|
|
2017-10-19 04:00:22 +08:00
|
|
|
f_flags = bpf_get_file_flag(attr->open_flags);
|
|
|
|
if (f_flags < 0)
|
|
|
|
return f_flags;
|
|
|
|
|
2017-06-06 03:15:50 +08:00
|
|
|
spin_lock_bh(&map_idr_lock);
|
|
|
|
map = idr_find(&map_idr, id);
|
|
|
|
if (map)
|
|
|
|
map = bpf_map_inc_not_zero(map, true);
|
|
|
|
else
|
|
|
|
map = ERR_PTR(-ENOENT);
|
|
|
|
spin_unlock_bh(&map_idr_lock);
|
|
|
|
|
|
|
|
if (IS_ERR(map))
|
|
|
|
return PTR_ERR(map);
|
|
|
|
|
2017-10-19 04:00:22 +08:00
|
|
|
fd = bpf_map_new_fd(map, f_flags);
|
2017-06-06 03:15:50 +08:00
|
|
|
if (fd < 0)
|
|
|
|
bpf_map_put(map);
|
|
|
|
|
|
|
|
return fd;
|
|
|
|
}
|
|
|
|
|
bpf: allow for correlation of maps and helpers in dump
Currently a dump of an xlated prog (post verifier stage) doesn't
correlate used helpers as well as maps. The prog info lists
involved map ids, however there's no correlation of where in the
program they are used as of today. Likewise, bpftool does not
correlate helper calls with the target functions.
The latter can be done w/o any kernel changes through kallsyms,
and also has the advantage that this works with inlined helpers
and BPF calls.
Example, via interpreter:
# tc filter show dev foo ingress
filter protocol all pref 49152 bpf chain 0
filter protocol all pref 49152 bpf chain 0 handle 0x1 foo.o:[ingress] \
direct-action not_in_hw id 1 tag c74773051b364165 <-- prog id:1
* Output before patch (calls/maps remain unclear):
# bpftool prog dump xlated id 1 <-- dump prog id:1
0: (b7) r1 = 2
1: (63) *(u32 *)(r10 -4) = r1
2: (bf) r2 = r10
3: (07) r2 += -4
4: (18) r1 = 0xffff95c47a8d4800
6: (85) call unknown#73040
7: (15) if r0 == 0x0 goto pc+18
8: (bf) r2 = r10
9: (07) r2 += -4
10: (bf) r1 = r0
11: (85) call unknown#73040
12: (15) if r0 == 0x0 goto pc+23
[...]
* Output after patch:
# bpftool prog dump xlated id 1
0: (b7) r1 = 2
1: (63) *(u32 *)(r10 -4) = r1
2: (bf) r2 = r10
3: (07) r2 += -4
4: (18) r1 = map[id:2] <-- map id:2
6: (85) call bpf_map_lookup_elem#73424 <-- helper call
7: (15) if r0 == 0x0 goto pc+18
8: (bf) r2 = r10
9: (07) r2 += -4
10: (bf) r1 = r0
11: (85) call bpf_map_lookup_elem#73424
12: (15) if r0 == 0x0 goto pc+23
[...]
# bpftool map show id 2 <-- show/dump/etc map id:2
2: hash_of_maps flags 0x0
key 4B value 4B max_entries 3 memlock 4096B
Example, JITed, same prog:
# tc filter show dev foo ingress
filter protocol all pref 49152 bpf chain 0
filter protocol all pref 49152 bpf chain 0 handle 0x1 foo.o:[ingress] \
direct-action not_in_hw id 3 tag c74773051b364165 jited
# bpftool prog show id 3
3: sched_cls tag c74773051b364165
loaded_at Dec 19/13:48 uid 0
xlated 384B jited 257B memlock 4096B map_ids 2
# bpftool prog dump xlated id 3
0: (b7) r1 = 2
1: (63) *(u32 *)(r10 -4) = r1
2: (bf) r2 = r10
3: (07) r2 += -4
4: (18) r1 = map[id:2] <-- map id:2
6: (85) call __htab_map_lookup_elem#77408 <-+ inlined rewrite
7: (15) if r0 == 0x0 goto pc+2 |
8: (07) r0 += 56 |
9: (79) r0 = *(u64 *)(r0 +0) <-+
10: (15) if r0 == 0x0 goto pc+24
11: (bf) r2 = r10
12: (07) r2 += -4
[...]
Example, same prog, but kallsyms disabled (in that case we are
also not allowed to pass any relative offsets, etc, so prog
becomes pointer sanitized on dump):
# sysctl kernel.kptr_restrict=2
kernel.kptr_restrict = 2
# bpftool prog dump xlated id 3
0: (b7) r1 = 2
1: (63) *(u32 *)(r10 -4) = r1
2: (bf) r2 = r10
3: (07) r2 += -4
4: (18) r1 = map[id:2]
6: (85) call bpf_unspec#0
7: (15) if r0 == 0x0 goto pc+2
[...]
Example, BPF calls via interpreter:
# bpftool prog dump xlated id 1
0: (85) call pc+2#__bpf_prog_run_args32
1: (b7) r0 = 1
2: (95) exit
3: (b7) r0 = 2
4: (95) exit
Example, BPF calls via JIT:
# sysctl net.core.bpf_jit_enable=1
net.core.bpf_jit_enable = 1
# sysctl net.core.bpf_jit_kallsyms=1
net.core.bpf_jit_kallsyms = 1
# bpftool prog dump xlated id 1
0: (85) call pc+2#bpf_prog_3b185187f1855c4c_F
1: (b7) r0 = 1
2: (95) exit
3: (b7) r0 = 2
4: (95) exit
And finally, an example for tail calls that is now working
as well wrt correlation:
# bpftool prog dump xlated id 2
[...]
10: (b7) r2 = 8
11: (85) call bpf_trace_printk#-41312
12: (bf) r1 = r6
13: (18) r2 = map[id:1]
15: (b7) r3 = 0
16: (85) call bpf_tail_call#12
17: (b7) r1 = 42
18: (6b) *(u16 *)(r6 +46) = r1
19: (b7) r0 = 0
20: (95) exit
# bpftool map show id 1
1: prog_array flags 0x0
key 4B value 4B max_entries 1 memlock 4096B
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2017-12-20 20:42:57 +08:00
|
|
|
static const struct bpf_map *bpf_map_from_imm(const struct bpf_prog *prog,
|
|
|
|
unsigned long addr)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < prog->aux->used_map_cnt; i++)
|
|
|
|
if (prog->aux->used_maps[i] == (void *)addr)
|
|
|
|
return prog->aux->used_maps[i];
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct bpf_insn *bpf_insn_prepare_dump(const struct bpf_prog *prog)
|
|
|
|
{
|
|
|
|
const struct bpf_map *map;
|
|
|
|
struct bpf_insn *insns;
|
|
|
|
u64 imm;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
insns = kmemdup(prog->insnsi, bpf_prog_insn_size(prog),
|
|
|
|
GFP_USER);
|
|
|
|
if (!insns)
|
|
|
|
return insns;
|
|
|
|
|
|
|
|
for (i = 0; i < prog->len; i++) {
|
|
|
|
if (insns[i].code == (BPF_JMP | BPF_TAIL_CALL)) {
|
|
|
|
insns[i].code = BPF_JMP | BPF_CALL;
|
|
|
|
insns[i].imm = BPF_FUNC_tail_call;
|
|
|
|
/* fall-through */
|
|
|
|
}
|
|
|
|
if (insns[i].code == (BPF_JMP | BPF_CALL) ||
|
|
|
|
insns[i].code == (BPF_JMP | BPF_CALL_ARGS)) {
|
|
|
|
if (insns[i].code == (BPF_JMP | BPF_CALL_ARGS))
|
|
|
|
insns[i].code = BPF_JMP | BPF_CALL;
|
|
|
|
if (!bpf_dump_raw_ok())
|
|
|
|
insns[i].imm = 0;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (insns[i].code != (BPF_LD | BPF_IMM | BPF_DW))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
imm = ((u64)insns[i + 1].imm << 32) | (u32)insns[i].imm;
|
|
|
|
map = bpf_map_from_imm(prog, imm);
|
|
|
|
if (map) {
|
|
|
|
insns[i].src_reg = BPF_PSEUDO_MAP_FD;
|
|
|
|
insns[i].imm = map->id;
|
|
|
|
insns[i + 1].imm = 0;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!bpf_dump_raw_ok() &&
|
|
|
|
imm == (unsigned long)prog->aux) {
|
|
|
|
insns[i].imm = 0;
|
|
|
|
insns[i + 1].imm = 0;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return insns;
|
|
|
|
}
|
|
|
|
|
2017-06-06 03:15:52 +08:00
|
|
|
static int bpf_prog_get_info_by_fd(struct bpf_prog *prog,
|
|
|
|
const union bpf_attr *attr,
|
|
|
|
union bpf_attr __user *uattr)
|
|
|
|
{
|
|
|
|
struct bpf_prog_info __user *uinfo = u64_to_user_ptr(attr->info.info);
|
|
|
|
struct bpf_prog_info info = {};
|
|
|
|
u32 info_len = attr->info.info_len;
|
|
|
|
char __user *uinsns;
|
|
|
|
u32 ulen;
|
|
|
|
int err;
|
|
|
|
|
2018-05-23 06:03:31 +08:00
|
|
|
err = bpf_check_uarg_tail_zero(uinfo, sizeof(info), info_len);
|
2017-06-06 03:15:52 +08:00
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
info_len = min_t(u32, sizeof(info), info_len);
|
|
|
|
|
|
|
|
if (copy_from_user(&info, uinfo, info_len))
|
2017-07-28 03:02:46 +08:00
|
|
|
return -EFAULT;
|
2017-06-06 03:15:52 +08:00
|
|
|
|
|
|
|
info.type = prog->type;
|
|
|
|
info.id = prog->aux->id;
|
2017-09-28 05:37:52 +08:00
|
|
|
info.load_time = prog->aux->load_time;
|
|
|
|
info.created_by_uid = from_kuid_munged(current_user_ns(),
|
|
|
|
prog->aux->user->uid);
|
2018-04-26 01:41:06 +08:00
|
|
|
info.gpl_compatible = prog->gpl_compatible;
|
2017-06-06 03:15:52 +08:00
|
|
|
|
|
|
|
memcpy(info.tag, prog->tag, sizeof(prog->tag));
|
2017-09-28 05:37:52 +08:00
|
|
|
memcpy(info.name, prog->aux->name, sizeof(prog->aux->name));
|
|
|
|
|
|
|
|
ulen = info.nr_map_ids;
|
|
|
|
info.nr_map_ids = prog->aux->used_map_cnt;
|
|
|
|
ulen = min_t(u32, info.nr_map_ids, ulen);
|
|
|
|
if (ulen) {
|
2017-09-30 01:52:17 +08:00
|
|
|
u32 __user *user_map_ids = u64_to_user_ptr(info.map_ids);
|
2017-09-28 05:37:52 +08:00
|
|
|
u32 i;
|
|
|
|
|
|
|
|
for (i = 0; i < ulen; i++)
|
|
|
|
if (put_user(prog->aux->used_maps[i]->id,
|
|
|
|
&user_map_ids[i]))
|
|
|
|
return -EFAULT;
|
|
|
|
}
|
2017-06-06 03:15:52 +08:00
|
|
|
|
2018-12-06 09:35:43 +08:00
|
|
|
if ((info.func_info_cnt || info.func_info_rec_size) &&
|
|
|
|
info.func_info_rec_size != sizeof(struct bpf_func_info))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
info.func_info_rec_size = sizeof(struct bpf_func_info);
|
|
|
|
|
2017-06-06 03:15:52 +08:00
|
|
|
if (!capable(CAP_SYS_ADMIN)) {
|
|
|
|
info.jited_prog_len = 0;
|
|
|
|
info.xlated_prog_len = 0;
|
2018-05-24 14:56:48 +08:00
|
|
|
info.nr_jited_ksyms = 0;
|
2018-11-02 18:35:46 +08:00
|
|
|
info.nr_jited_func_lens = 0;
|
bpf: Introduce bpf_func_info
This patch added interface to load a program with the following
additional information:
. prog_btf_fd
. func_info, func_info_rec_size and func_info_cnt
where func_info will provide function range and type_id
corresponding to each function.
The func_info_rec_size is introduced in the UAPI to specify
struct bpf_func_info size passed from user space. This
intends to make bpf_func_info structure growable in the future.
If the kernel gets a different bpf_func_info size from userspace,
it will try to handle user request with part of bpf_func_info
it can understand. In this patch, kernel can understand
struct bpf_func_info {
__u32 insn_offset;
__u32 type_id;
};
If user passed a bpf func_info record size of 16 bytes, the
kernel can still handle part of records with the above definition.
If verifier agrees with function range provided by the user,
the bpf_prog ksym for each function will use the func name
provided in the type_id, which is supposed to provide better
encoding as it is not limited by 16 bytes program name
limitation and this is better for bpf program which contains
multiple subprograms.
The bpf_prog_info interface is also extended to
return btf_id, func_info, func_info_rec_size and func_info_cnt
to userspace, so userspace can print out the function prototype
for each xlated function. The insn_offset in the returned
func_info corresponds to the insn offset for xlated functions.
With other jit related fields in bpf_prog_info, userspace can also
print out function prototypes for each jited function.
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-11-20 07:29:11 +08:00
|
|
|
info.func_info_cnt = 0;
|
2017-06-06 03:15:52 +08:00
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
|
|
|
|
ulen = info.xlated_prog_len;
|
2017-07-28 23:05:25 +08:00
|
|
|
info.xlated_prog_len = bpf_prog_insn_size(prog);
|
2017-06-06 03:15:52 +08:00
|
|
|
if (info.xlated_prog_len && ulen) {
|
bpf: allow for correlation of maps and helpers in dump
Currently a dump of an xlated prog (post verifier stage) doesn't
correlate used helpers as well as maps. The prog info lists
involved map ids, however there's no correlation of where in the
program they are used as of today. Likewise, bpftool does not
correlate helper calls with the target functions.
The latter can be done w/o any kernel changes through kallsyms,
and also has the advantage that this works with inlined helpers
and BPF calls.
Example, via interpreter:
# tc filter show dev foo ingress
filter protocol all pref 49152 bpf chain 0
filter protocol all pref 49152 bpf chain 0 handle 0x1 foo.o:[ingress] \
direct-action not_in_hw id 1 tag c74773051b364165 <-- prog id:1
* Output before patch (calls/maps remain unclear):
# bpftool prog dump xlated id 1 <-- dump prog id:1
0: (b7) r1 = 2
1: (63) *(u32 *)(r10 -4) = r1
2: (bf) r2 = r10
3: (07) r2 += -4
4: (18) r1 = 0xffff95c47a8d4800
6: (85) call unknown#73040
7: (15) if r0 == 0x0 goto pc+18
8: (bf) r2 = r10
9: (07) r2 += -4
10: (bf) r1 = r0
11: (85) call unknown#73040
12: (15) if r0 == 0x0 goto pc+23
[...]
* Output after patch:
# bpftool prog dump xlated id 1
0: (b7) r1 = 2
1: (63) *(u32 *)(r10 -4) = r1
2: (bf) r2 = r10
3: (07) r2 += -4
4: (18) r1 = map[id:2] <-- map id:2
6: (85) call bpf_map_lookup_elem#73424 <-- helper call
7: (15) if r0 == 0x0 goto pc+18
8: (bf) r2 = r10
9: (07) r2 += -4
10: (bf) r1 = r0
11: (85) call bpf_map_lookup_elem#73424
12: (15) if r0 == 0x0 goto pc+23
[...]
# bpftool map show id 2 <-- show/dump/etc map id:2
2: hash_of_maps flags 0x0
key 4B value 4B max_entries 3 memlock 4096B
Example, JITed, same prog:
# tc filter show dev foo ingress
filter protocol all pref 49152 bpf chain 0
filter protocol all pref 49152 bpf chain 0 handle 0x1 foo.o:[ingress] \
direct-action not_in_hw id 3 tag c74773051b364165 jited
# bpftool prog show id 3
3: sched_cls tag c74773051b364165
loaded_at Dec 19/13:48 uid 0
xlated 384B jited 257B memlock 4096B map_ids 2
# bpftool prog dump xlated id 3
0: (b7) r1 = 2
1: (63) *(u32 *)(r10 -4) = r1
2: (bf) r2 = r10
3: (07) r2 += -4
4: (18) r1 = map[id:2] <-- map id:2
6: (85) call __htab_map_lookup_elem#77408 <-+ inlined rewrite
7: (15) if r0 == 0x0 goto pc+2 |
8: (07) r0 += 56 |
9: (79) r0 = *(u64 *)(r0 +0) <-+
10: (15) if r0 == 0x0 goto pc+24
11: (bf) r2 = r10
12: (07) r2 += -4
[...]
Example, same prog, but kallsyms disabled (in that case we are
also not allowed to pass any relative offsets, etc, so prog
becomes pointer sanitized on dump):
# sysctl kernel.kptr_restrict=2
kernel.kptr_restrict = 2
# bpftool prog dump xlated id 3
0: (b7) r1 = 2
1: (63) *(u32 *)(r10 -4) = r1
2: (bf) r2 = r10
3: (07) r2 += -4
4: (18) r1 = map[id:2]
6: (85) call bpf_unspec#0
7: (15) if r0 == 0x0 goto pc+2
[...]
Example, BPF calls via interpreter:
# bpftool prog dump xlated id 1
0: (85) call pc+2#__bpf_prog_run_args32
1: (b7) r0 = 1
2: (95) exit
3: (b7) r0 = 2
4: (95) exit
Example, BPF calls via JIT:
# sysctl net.core.bpf_jit_enable=1
net.core.bpf_jit_enable = 1
# sysctl net.core.bpf_jit_kallsyms=1
net.core.bpf_jit_kallsyms = 1
# bpftool prog dump xlated id 1
0: (85) call pc+2#bpf_prog_3b185187f1855c4c_F
1: (b7) r0 = 1
2: (95) exit
3: (b7) r0 = 2
4: (95) exit
And finally, an example for tail calls that is now working
as well wrt correlation:
# bpftool prog dump xlated id 2
[...]
10: (b7) r2 = 8
11: (85) call bpf_trace_printk#-41312
12: (bf) r1 = r6
13: (18) r2 = map[id:1]
15: (b7) r3 = 0
16: (85) call bpf_tail_call#12
17: (b7) r1 = 42
18: (6b) *(u16 *)(r6 +46) = r1
19: (b7) r0 = 0
20: (95) exit
# bpftool map show id 1
1: prog_array flags 0x0
key 4B value 4B max_entries 1 memlock 4096B
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2017-12-20 20:42:57 +08:00
|
|
|
struct bpf_insn *insns_sanitized;
|
|
|
|
bool fault;
|
|
|
|
|
|
|
|
if (prog->blinded && !bpf_dump_raw_ok()) {
|
|
|
|
info.xlated_prog_insns = 0;
|
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
insns_sanitized = bpf_insn_prepare_dump(prog);
|
|
|
|
if (!insns_sanitized)
|
|
|
|
return -ENOMEM;
|
2017-06-06 03:15:52 +08:00
|
|
|
uinsns = u64_to_user_ptr(info.xlated_prog_insns);
|
|
|
|
ulen = min_t(u32, info.xlated_prog_len, ulen);
|
bpf: allow for correlation of maps and helpers in dump
Currently a dump of an xlated prog (post verifier stage) doesn't
correlate used helpers as well as maps. The prog info lists
involved map ids, however there's no correlation of where in the
program they are used as of today. Likewise, bpftool does not
correlate helper calls with the target functions.
The latter can be done w/o any kernel changes through kallsyms,
and also has the advantage that this works with inlined helpers
and BPF calls.
Example, via interpreter:
# tc filter show dev foo ingress
filter protocol all pref 49152 bpf chain 0
filter protocol all pref 49152 bpf chain 0 handle 0x1 foo.o:[ingress] \
direct-action not_in_hw id 1 tag c74773051b364165 <-- prog id:1
* Output before patch (calls/maps remain unclear):
# bpftool prog dump xlated id 1 <-- dump prog id:1
0: (b7) r1 = 2
1: (63) *(u32 *)(r10 -4) = r1
2: (bf) r2 = r10
3: (07) r2 += -4
4: (18) r1 = 0xffff95c47a8d4800
6: (85) call unknown#73040
7: (15) if r0 == 0x0 goto pc+18
8: (bf) r2 = r10
9: (07) r2 += -4
10: (bf) r1 = r0
11: (85) call unknown#73040
12: (15) if r0 == 0x0 goto pc+23
[...]
* Output after patch:
# bpftool prog dump xlated id 1
0: (b7) r1 = 2
1: (63) *(u32 *)(r10 -4) = r1
2: (bf) r2 = r10
3: (07) r2 += -4
4: (18) r1 = map[id:2] <-- map id:2
6: (85) call bpf_map_lookup_elem#73424 <-- helper call
7: (15) if r0 == 0x0 goto pc+18
8: (bf) r2 = r10
9: (07) r2 += -4
10: (bf) r1 = r0
11: (85) call bpf_map_lookup_elem#73424
12: (15) if r0 == 0x0 goto pc+23
[...]
# bpftool map show id 2 <-- show/dump/etc map id:2
2: hash_of_maps flags 0x0
key 4B value 4B max_entries 3 memlock 4096B
Example, JITed, same prog:
# tc filter show dev foo ingress
filter protocol all pref 49152 bpf chain 0
filter protocol all pref 49152 bpf chain 0 handle 0x1 foo.o:[ingress] \
direct-action not_in_hw id 3 tag c74773051b364165 jited
# bpftool prog show id 3
3: sched_cls tag c74773051b364165
loaded_at Dec 19/13:48 uid 0
xlated 384B jited 257B memlock 4096B map_ids 2
# bpftool prog dump xlated id 3
0: (b7) r1 = 2
1: (63) *(u32 *)(r10 -4) = r1
2: (bf) r2 = r10
3: (07) r2 += -4
4: (18) r1 = map[id:2] <-- map id:2
6: (85) call __htab_map_lookup_elem#77408 <-+ inlined rewrite
7: (15) if r0 == 0x0 goto pc+2 |
8: (07) r0 += 56 |
9: (79) r0 = *(u64 *)(r0 +0) <-+
10: (15) if r0 == 0x0 goto pc+24
11: (bf) r2 = r10
12: (07) r2 += -4
[...]
Example, same prog, but kallsyms disabled (in that case we are
also not allowed to pass any relative offsets, etc, so prog
becomes pointer sanitized on dump):
# sysctl kernel.kptr_restrict=2
kernel.kptr_restrict = 2
# bpftool prog dump xlated id 3
0: (b7) r1 = 2
1: (63) *(u32 *)(r10 -4) = r1
2: (bf) r2 = r10
3: (07) r2 += -4
4: (18) r1 = map[id:2]
6: (85) call bpf_unspec#0
7: (15) if r0 == 0x0 goto pc+2
[...]
Example, BPF calls via interpreter:
# bpftool prog dump xlated id 1
0: (85) call pc+2#__bpf_prog_run_args32
1: (b7) r0 = 1
2: (95) exit
3: (b7) r0 = 2
4: (95) exit
Example, BPF calls via JIT:
# sysctl net.core.bpf_jit_enable=1
net.core.bpf_jit_enable = 1
# sysctl net.core.bpf_jit_kallsyms=1
net.core.bpf_jit_kallsyms = 1
# bpftool prog dump xlated id 1
0: (85) call pc+2#bpf_prog_3b185187f1855c4c_F
1: (b7) r0 = 1
2: (95) exit
3: (b7) r0 = 2
4: (95) exit
And finally, an example for tail calls that is now working
as well wrt correlation:
# bpftool prog dump xlated id 2
[...]
10: (b7) r2 = 8
11: (85) call bpf_trace_printk#-41312
12: (bf) r1 = r6
13: (18) r2 = map[id:1]
15: (b7) r3 = 0
16: (85) call bpf_tail_call#12
17: (b7) r1 = 42
18: (6b) *(u16 *)(r6 +46) = r1
19: (b7) r0 = 0
20: (95) exit
# bpftool map show id 1
1: prog_array flags 0x0
key 4B value 4B max_entries 1 memlock 4096B
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2017-12-20 20:42:57 +08:00
|
|
|
fault = copy_to_user(uinsns, insns_sanitized, ulen);
|
|
|
|
kfree(insns_sanitized);
|
|
|
|
if (fault)
|
2017-06-06 03:15:52 +08:00
|
|
|
return -EFAULT;
|
|
|
|
}
|
|
|
|
|
2017-12-28 10:39:09 +08:00
|
|
|
if (bpf_prog_is_dev_bound(prog->aux)) {
|
|
|
|
err = bpf_prog_offload_info_fill(&info, prog);
|
|
|
|
if (err)
|
|
|
|
return err;
|
2018-01-17 08:05:19 +08:00
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* NOTE: the following code is supposed to be skipped for offload.
|
|
|
|
* bpf_prog_offload_info_fill() is the place to fill similar fields
|
|
|
|
* for offload.
|
|
|
|
*/
|
|
|
|
ulen = info.jited_prog_len;
|
bpf: fix multi-function JITed dump obtained via syscall
Currently, for multi-function programs, we cannot get the JITed
instructions using the bpf system call's BPF_OBJ_GET_INFO_BY_FD
command. Because of this, userspace tools such as bpftool fail
to identify a multi-function program as being JITed or not.
With the JIT enabled and the test program running, this can be
verified as follows:
# cat /proc/sys/net/core/bpf_jit_enable
1
Before applying this patch:
# bpftool prog list
1: kprobe name foo tag b811aab41a39ad3d gpl
loaded_at 2018-05-16T11:43:38+0530 uid 0
xlated 216B not jited memlock 65536B
...
# bpftool prog dump jited id 1
no instructions returned
After applying this patch:
# bpftool prog list
1: kprobe name foo tag b811aab41a39ad3d gpl
loaded_at 2018-05-16T12:13:01+0530 uid 0
xlated 216B jited 308B memlock 65536B
...
# bpftool prog dump jited id 1
0: nop
4: nop
8: mflr r0
c: std r0,16(r1)
10: stdu r1,-112(r1)
14: std r31,104(r1)
18: addi r31,r1,48
1c: li r3,10
...
Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-05-24 14:56:51 +08:00
|
|
|
if (prog->aux->func_cnt) {
|
|
|
|
u32 i;
|
|
|
|
|
|
|
|
info.jited_prog_len = 0;
|
|
|
|
for (i = 0; i < prog->aux->func_cnt; i++)
|
|
|
|
info.jited_prog_len += prog->aux->func[i]->jited_len;
|
|
|
|
} else {
|
|
|
|
info.jited_prog_len = prog->jited_len;
|
|
|
|
}
|
|
|
|
|
2018-01-17 08:05:19 +08:00
|
|
|
if (info.jited_prog_len && ulen) {
|
|
|
|
if (bpf_dump_raw_ok()) {
|
|
|
|
uinsns = u64_to_user_ptr(info.jited_prog_insns);
|
|
|
|
ulen = min_t(u32, info.jited_prog_len, ulen);
|
bpf: fix multi-function JITed dump obtained via syscall
Currently, for multi-function programs, we cannot get the JITed
instructions using the bpf system call's BPF_OBJ_GET_INFO_BY_FD
command. Because of this, userspace tools such as bpftool fail
to identify a multi-function program as being JITed or not.
With the JIT enabled and the test program running, this can be
verified as follows:
# cat /proc/sys/net/core/bpf_jit_enable
1
Before applying this patch:
# bpftool prog list
1: kprobe name foo tag b811aab41a39ad3d gpl
loaded_at 2018-05-16T11:43:38+0530 uid 0
xlated 216B not jited memlock 65536B
...
# bpftool prog dump jited id 1
no instructions returned
After applying this patch:
# bpftool prog list
1: kprobe name foo tag b811aab41a39ad3d gpl
loaded_at 2018-05-16T12:13:01+0530 uid 0
xlated 216B jited 308B memlock 65536B
...
# bpftool prog dump jited id 1
0: nop
4: nop
8: mflr r0
c: std r0,16(r1)
10: stdu r1,-112(r1)
14: std r31,104(r1)
18: addi r31,r1,48
1c: li r3,10
...
Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-05-24 14:56:51 +08:00
|
|
|
|
|
|
|
/* for multi-function programs, copy the JITed
|
|
|
|
* instructions for all the functions
|
|
|
|
*/
|
|
|
|
if (prog->aux->func_cnt) {
|
|
|
|
u32 len, free, i;
|
|
|
|
u8 *img;
|
|
|
|
|
|
|
|
free = ulen;
|
|
|
|
for (i = 0; i < prog->aux->func_cnt; i++) {
|
|
|
|
len = prog->aux->func[i]->jited_len;
|
|
|
|
len = min_t(u32, len, free);
|
|
|
|
img = (u8 *) prog->aux->func[i]->bpf_func;
|
|
|
|
if (copy_to_user(uinsns, img, len))
|
|
|
|
return -EFAULT;
|
|
|
|
uinsns += len;
|
|
|
|
free -= len;
|
|
|
|
if (!free)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if (copy_to_user(uinsns, prog->bpf_func, ulen))
|
|
|
|
return -EFAULT;
|
|
|
|
}
|
2018-01-17 08:05:19 +08:00
|
|
|
} else {
|
|
|
|
info.jited_prog_insns = 0;
|
|
|
|
}
|
2017-12-28 10:39:09 +08:00
|
|
|
}
|
|
|
|
|
2018-05-24 14:56:48 +08:00
|
|
|
ulen = info.nr_jited_ksyms;
|
2018-11-03 01:16:17 +08:00
|
|
|
info.nr_jited_ksyms = prog->aux->func_cnt ? : 1;
|
2018-05-24 14:56:48 +08:00
|
|
|
if (info.nr_jited_ksyms && ulen) {
|
|
|
|
if (bpf_dump_raw_ok()) {
|
2018-11-03 01:16:17 +08:00
|
|
|
unsigned long ksym_addr;
|
2018-05-24 14:56:48 +08:00
|
|
|
u64 __user *user_ksyms;
|
|
|
|
u32 i;
|
|
|
|
|
|
|
|
/* copy the address of the kernel symbol
|
|
|
|
* corresponding to each function
|
|
|
|
*/
|
|
|
|
ulen = min_t(u32, info.nr_jited_ksyms, ulen);
|
|
|
|
user_ksyms = u64_to_user_ptr(info.jited_ksyms);
|
2018-11-03 01:16:17 +08:00
|
|
|
if (prog->aux->func_cnt) {
|
|
|
|
for (i = 0; i < ulen; i++) {
|
|
|
|
ksym_addr = (unsigned long)
|
|
|
|
prog->aux->func[i]->bpf_func;
|
|
|
|
if (put_user((u64) ksym_addr,
|
|
|
|
&user_ksyms[i]))
|
|
|
|
return -EFAULT;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
ksym_addr = (unsigned long) prog->bpf_func;
|
|
|
|
if (put_user((u64) ksym_addr, &user_ksyms[0]))
|
2018-05-24 14:56:48 +08:00
|
|
|
return -EFAULT;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
info.jited_ksyms = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-05-24 14:56:52 +08:00
|
|
|
ulen = info.nr_jited_func_lens;
|
2018-11-03 01:16:17 +08:00
|
|
|
info.nr_jited_func_lens = prog->aux->func_cnt ? : 1;
|
2018-05-24 14:56:52 +08:00
|
|
|
if (info.nr_jited_func_lens && ulen) {
|
|
|
|
if (bpf_dump_raw_ok()) {
|
|
|
|
u32 __user *user_lens;
|
|
|
|
u32 func_len, i;
|
|
|
|
|
|
|
|
/* copy the JITed image lengths for each function */
|
|
|
|
ulen = min_t(u32, info.nr_jited_func_lens, ulen);
|
|
|
|
user_lens = u64_to_user_ptr(info.jited_func_lens);
|
2018-11-03 01:16:17 +08:00
|
|
|
if (prog->aux->func_cnt) {
|
|
|
|
for (i = 0; i < ulen; i++) {
|
|
|
|
func_len =
|
|
|
|
prog->aux->func[i]->jited_len;
|
|
|
|
if (put_user(func_len, &user_lens[i]))
|
|
|
|
return -EFAULT;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
func_len = prog->jited_len;
|
|
|
|
if (put_user(func_len, &user_lens[0]))
|
2018-05-24 14:56:52 +08:00
|
|
|
return -EFAULT;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
info.jited_func_lens = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-12-06 09:35:43 +08:00
|
|
|
if (prog->aux->btf)
|
bpf: Introduce bpf_func_info
This patch added interface to load a program with the following
additional information:
. prog_btf_fd
. func_info, func_info_rec_size and func_info_cnt
where func_info will provide function range and type_id
corresponding to each function.
The func_info_rec_size is introduced in the UAPI to specify
struct bpf_func_info size passed from user space. This
intends to make bpf_func_info structure growable in the future.
If the kernel gets a different bpf_func_info size from userspace,
it will try to handle user request with part of bpf_func_info
it can understand. In this patch, kernel can understand
struct bpf_func_info {
__u32 insn_offset;
__u32 type_id;
};
If user passed a bpf func_info record size of 16 bytes, the
kernel can still handle part of records with the above definition.
If verifier agrees with function range provided by the user,
the bpf_prog ksym for each function will use the func name
provided in the type_id, which is supposed to provide better
encoding as it is not limited by 16 bytes program name
limitation and this is better for bpf program which contains
multiple subprograms.
The bpf_prog_info interface is also extended to
return btf_id, func_info, func_info_rec_size and func_info_cnt
to userspace, so userspace can print out the function prototype
for each xlated function. The insn_offset in the returned
func_info corresponds to the insn offset for xlated functions.
With other jit related fields in bpf_prog_info, userspace can also
print out function prototypes for each jited function.
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-11-20 07:29:11 +08:00
|
|
|
info.btf_id = btf_id(prog->aux->btf);
|
|
|
|
|
2018-12-06 09:35:43 +08:00
|
|
|
ulen = info.func_info_cnt;
|
|
|
|
info.func_info_cnt = prog->aux->func_info_cnt;
|
|
|
|
if (info.func_info_cnt && ulen) {
|
|
|
|
if (bpf_dump_raw_ok()) {
|
|
|
|
char __user *user_finfo;
|
|
|
|
|
|
|
|
user_finfo = u64_to_user_ptr(info.func_info);
|
|
|
|
ulen = min_t(u32, info.func_info_cnt, ulen);
|
|
|
|
if (copy_to_user(user_finfo, prog->aux->func_info,
|
|
|
|
info.func_info_rec_size * ulen))
|
|
|
|
return -EFAULT;
|
|
|
|
} else {
|
|
|
|
info.func_info = 0;
|
bpf: Introduce bpf_func_info
This patch added interface to load a program with the following
additional information:
. prog_btf_fd
. func_info, func_info_rec_size and func_info_cnt
where func_info will provide function range and type_id
corresponding to each function.
The func_info_rec_size is introduced in the UAPI to specify
struct bpf_func_info size passed from user space. This
intends to make bpf_func_info structure growable in the future.
If the kernel gets a different bpf_func_info size from userspace,
it will try to handle user request with part of bpf_func_info
it can understand. In this patch, kernel can understand
struct bpf_func_info {
__u32 insn_offset;
__u32 type_id;
};
If user passed a bpf func_info record size of 16 bytes, the
kernel can still handle part of records with the above definition.
If verifier agrees with function range provided by the user,
the bpf_prog ksym for each function will use the func name
provided in the type_id, which is supposed to provide better
encoding as it is not limited by 16 bytes program name
limitation and this is better for bpf program which contains
multiple subprograms.
The bpf_prog_info interface is also extended to
return btf_id, func_info, func_info_rec_size and func_info_cnt
to userspace, so userspace can print out the function prototype
for each xlated function. The insn_offset in the returned
func_info corresponds to the insn offset for xlated functions.
With other jit related fields in bpf_prog_info, userspace can also
print out function prototypes for each jited function.
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-11-20 07:29:11 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-06-06 03:15:52 +08:00
|
|
|
done:
|
|
|
|
if (copy_to_user(uinfo, &info, info_len) ||
|
|
|
|
put_user(info_len, &uattr->info.info_len))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int bpf_map_get_info_by_fd(struct bpf_map *map,
|
|
|
|
const union bpf_attr *attr,
|
|
|
|
union bpf_attr __user *uattr)
|
|
|
|
{
|
|
|
|
struct bpf_map_info __user *uinfo = u64_to_user_ptr(attr->info.info);
|
|
|
|
struct bpf_map_info info = {};
|
|
|
|
u32 info_len = attr->info.info_len;
|
|
|
|
int err;
|
|
|
|
|
2018-05-23 06:03:31 +08:00
|
|
|
err = bpf_check_uarg_tail_zero(uinfo, sizeof(info), info_len);
|
2017-06-06 03:15:52 +08:00
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
info_len = min_t(u32, sizeof(info), info_len);
|
|
|
|
|
|
|
|
info.type = map->map_type;
|
|
|
|
info.id = map->id;
|
|
|
|
info.key_size = map->key_size;
|
|
|
|
info.value_size = map->value_size;
|
|
|
|
info.max_entries = map->max_entries;
|
|
|
|
info.map_flags = map->map_flags;
|
2017-09-28 05:37:53 +08:00
|
|
|
memcpy(info.name, map->name, sizeof(map->name));
|
2017-06-06 03:15:52 +08:00
|
|
|
|
2018-05-05 05:49:51 +08:00
|
|
|
if (map->btf) {
|
|
|
|
info.btf_id = btf_id(map->btf);
|
2018-05-23 05:57:21 +08:00
|
|
|
info.btf_key_type_id = map->btf_key_type_id;
|
|
|
|
info.btf_value_type_id = map->btf_value_type_id;
|
2018-05-05 05:49:51 +08:00
|
|
|
}
|
|
|
|
|
2018-01-18 11:13:28 +08:00
|
|
|
if (bpf_map_is_dev_bound(map)) {
|
|
|
|
err = bpf_map_offload_info_fill(&info, map);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2017-06-06 03:15:52 +08:00
|
|
|
if (copy_to_user(uinfo, &info, info_len) ||
|
|
|
|
put_user(info_len, &uattr->info.info_len))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-05-05 05:49:52 +08:00
|
|
|
static int bpf_btf_get_info_by_fd(struct btf *btf,
|
|
|
|
const union bpf_attr *attr,
|
|
|
|
union bpf_attr __user *uattr)
|
|
|
|
{
|
|
|
|
struct bpf_btf_info __user *uinfo = u64_to_user_ptr(attr->info.info);
|
|
|
|
u32 info_len = attr->info.info_len;
|
|
|
|
int err;
|
|
|
|
|
2018-05-23 06:03:31 +08:00
|
|
|
err = bpf_check_uarg_tail_zero(uinfo, sizeof(*uinfo), info_len);
|
2018-05-05 05:49:52 +08:00
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
return btf_get_info_by_fd(btf, attr, uattr);
|
|
|
|
}
|
|
|
|
|
2017-06-06 03:15:52 +08:00
|
|
|
#define BPF_OBJ_GET_INFO_BY_FD_LAST_FIELD info.info
|
|
|
|
|
|
|
|
static int bpf_obj_get_info_by_fd(const union bpf_attr *attr,
|
|
|
|
union bpf_attr __user *uattr)
|
|
|
|
{
|
|
|
|
int ufd = attr->info.bpf_fd;
|
|
|
|
struct fd f;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
if (CHECK_ATTR(BPF_OBJ_GET_INFO_BY_FD))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
f = fdget(ufd);
|
|
|
|
if (!f.file)
|
|
|
|
return -EBADFD;
|
|
|
|
|
|
|
|
if (f.file->f_op == &bpf_prog_fops)
|
|
|
|
err = bpf_prog_get_info_by_fd(f.file->private_data, attr,
|
|
|
|
uattr);
|
|
|
|
else if (f.file->f_op == &bpf_map_fops)
|
|
|
|
err = bpf_map_get_info_by_fd(f.file->private_data, attr,
|
|
|
|
uattr);
|
2018-04-19 06:56:02 +08:00
|
|
|
else if (f.file->f_op == &btf_fops)
|
2018-05-05 05:49:52 +08:00
|
|
|
err = bpf_btf_get_info_by_fd(f.file->private_data, attr, uattr);
|
2017-06-06 03:15:52 +08:00
|
|
|
else
|
|
|
|
err = -EINVAL;
|
|
|
|
|
|
|
|
fdput(f);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2018-04-19 06:56:01 +08:00
|
|
|
#define BPF_BTF_LOAD_LAST_FIELD btf_log_level
|
|
|
|
|
|
|
|
static int bpf_btf_load(const union bpf_attr *attr)
|
|
|
|
{
|
|
|
|
if (CHECK_ATTR(BPF_BTF_LOAD))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (!capable(CAP_SYS_ADMIN))
|
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
return btf_new_fd(attr);
|
|
|
|
}
|
|
|
|
|
2018-05-05 05:49:51 +08:00
|
|
|
#define BPF_BTF_GET_FD_BY_ID_LAST_FIELD btf_id
|
|
|
|
|
|
|
|
static int bpf_btf_get_fd_by_id(const union bpf_attr *attr)
|
|
|
|
{
|
|
|
|
if (CHECK_ATTR(BPF_BTF_GET_FD_BY_ID))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (!capable(CAP_SYS_ADMIN))
|
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
return btf_get_fd_by_id(attr->btf_id);
|
|
|
|
}
|
|
|
|
|
bpf: introduce bpf subcommand BPF_TASK_FD_QUERY
Currently, suppose a userspace application has loaded a bpf program
and attached it to a tracepoint/kprobe/uprobe, and a bpf
introspection tool, e.g., bpftool, wants to show which bpf program
is attached to which tracepoint/kprobe/uprobe. Such attachment
information will be really useful to understand the overall bpf
deployment in the system.
There is a name field (16 bytes) for each program, which could
be used to encode the attachment point. There are some drawbacks
for this approaches. First, bpftool user (e.g., an admin) may not
really understand the association between the name and the
attachment point. Second, if one program is attached to multiple
places, encoding a proper name which can imply all these
attachments becomes difficult.
This patch introduces a new bpf subcommand BPF_TASK_FD_QUERY.
Given a pid and fd, if the <pid, fd> is associated with a
tracepoint/kprobe/uprobe perf event, BPF_TASK_FD_QUERY will return
. prog_id
. tracepoint name, or
. k[ret]probe funcname + offset or kernel addr, or
. u[ret]probe filename + offset
to the userspace.
The user can use "bpftool prog" to find more information about
bpf program itself with prog_id.
Acked-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-05-25 02:21:09 +08:00
|
|
|
static int bpf_task_fd_query_copy(const union bpf_attr *attr,
|
|
|
|
union bpf_attr __user *uattr,
|
|
|
|
u32 prog_id, u32 fd_type,
|
|
|
|
const char *buf, u64 probe_offset,
|
|
|
|
u64 probe_addr)
|
|
|
|
{
|
|
|
|
char __user *ubuf = u64_to_user_ptr(attr->task_fd_query.buf);
|
|
|
|
u32 len = buf ? strlen(buf) : 0, input_len;
|
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
if (put_user(len, &uattr->task_fd_query.buf_len))
|
|
|
|
return -EFAULT;
|
|
|
|
input_len = attr->task_fd_query.buf_len;
|
|
|
|
if (input_len && ubuf) {
|
|
|
|
if (!len) {
|
|
|
|
/* nothing to copy, just make ubuf NULL terminated */
|
|
|
|
char zero = '\0';
|
|
|
|
|
|
|
|
if (put_user(zero, ubuf))
|
|
|
|
return -EFAULT;
|
|
|
|
} else if (input_len >= len + 1) {
|
|
|
|
/* ubuf can hold the string with NULL terminator */
|
|
|
|
if (copy_to_user(ubuf, buf, len + 1))
|
|
|
|
return -EFAULT;
|
|
|
|
} else {
|
|
|
|
/* ubuf cannot hold the string with NULL terminator,
|
|
|
|
* do a partial copy with NULL terminator.
|
|
|
|
*/
|
|
|
|
char zero = '\0';
|
|
|
|
|
|
|
|
err = -ENOSPC;
|
|
|
|
if (copy_to_user(ubuf, buf, input_len - 1))
|
|
|
|
return -EFAULT;
|
|
|
|
if (put_user(zero, ubuf + input_len - 1))
|
|
|
|
return -EFAULT;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (put_user(prog_id, &uattr->task_fd_query.prog_id) ||
|
|
|
|
put_user(fd_type, &uattr->task_fd_query.fd_type) ||
|
|
|
|
put_user(probe_offset, &uattr->task_fd_query.probe_offset) ||
|
|
|
|
put_user(probe_addr, &uattr->task_fd_query.probe_addr))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define BPF_TASK_FD_QUERY_LAST_FIELD task_fd_query.probe_addr
|
|
|
|
|
|
|
|
static int bpf_task_fd_query(const union bpf_attr *attr,
|
|
|
|
union bpf_attr __user *uattr)
|
|
|
|
{
|
|
|
|
pid_t pid = attr->task_fd_query.pid;
|
|
|
|
u32 fd = attr->task_fd_query.fd;
|
|
|
|
const struct perf_event *event;
|
|
|
|
struct files_struct *files;
|
|
|
|
struct task_struct *task;
|
|
|
|
struct file *file;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
if (CHECK_ATTR(BPF_TASK_FD_QUERY))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (!capable(CAP_SYS_ADMIN))
|
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
if (attr->task_fd_query.flags != 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
task = get_pid_task(find_vpid(pid), PIDTYPE_PID);
|
|
|
|
if (!task)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
files = get_files_struct(task);
|
|
|
|
put_task_struct(task);
|
|
|
|
if (!files)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
err = 0;
|
|
|
|
spin_lock(&files->file_lock);
|
|
|
|
file = fcheck_files(files, fd);
|
|
|
|
if (!file)
|
|
|
|
err = -EBADF;
|
|
|
|
else
|
|
|
|
get_file(file);
|
|
|
|
spin_unlock(&files->file_lock);
|
|
|
|
put_files_struct(files);
|
|
|
|
|
|
|
|
if (err)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
if (file->f_op == &bpf_raw_tp_fops) {
|
|
|
|
struct bpf_raw_tracepoint *raw_tp = file->private_data;
|
|
|
|
struct bpf_raw_event_map *btp = raw_tp->btp;
|
|
|
|
|
|
|
|
err = bpf_task_fd_query_copy(attr, uattr,
|
|
|
|
raw_tp->prog->aux->id,
|
|
|
|
BPF_FD_TYPE_RAW_TRACEPOINT,
|
|
|
|
btp->tp->name, 0, 0);
|
|
|
|
goto put_file;
|
|
|
|
}
|
|
|
|
|
|
|
|
event = perf_get_event(file);
|
|
|
|
if (!IS_ERR(event)) {
|
|
|
|
u64 probe_offset, probe_addr;
|
|
|
|
u32 prog_id, fd_type;
|
|
|
|
const char *buf;
|
|
|
|
|
|
|
|
err = bpf_get_perf_event_info(event, &prog_id, &fd_type,
|
|
|
|
&buf, &probe_offset,
|
|
|
|
&probe_addr);
|
|
|
|
if (!err)
|
|
|
|
err = bpf_task_fd_query_copy(attr, uattr, prog_id,
|
|
|
|
fd_type, buf,
|
|
|
|
probe_offset,
|
|
|
|
probe_addr);
|
|
|
|
goto put_file;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = -ENOTSUPP;
|
|
|
|
put_file:
|
|
|
|
fput(file);
|
|
|
|
out:
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2014-09-26 15:16:57 +08:00
|
|
|
SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr __user *, uattr, unsigned int, size)
|
|
|
|
{
|
|
|
|
union bpf_attr attr = {};
|
|
|
|
int err;
|
|
|
|
|
2018-03-20 08:57:27 +08:00
|
|
|
if (sysctl_unprivileged_bpf_disabled && !capable(CAP_SYS_ADMIN))
|
2014-09-26 15:16:57 +08:00
|
|
|
return -EPERM;
|
|
|
|
|
2018-05-23 06:03:31 +08:00
|
|
|
err = bpf_check_uarg_tail_zero(uattr, sizeof(attr), size);
|
2017-06-06 03:15:52 +08:00
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
size = min_t(u32, size, sizeof(attr));
|
2014-09-26 15:16:57 +08:00
|
|
|
|
|
|
|
/* copy attributes from user space, may be less than sizeof(bpf_attr) */
|
|
|
|
if (copy_from_user(&attr, uattr, size) != 0)
|
|
|
|
return -EFAULT;
|
|
|
|
|
2017-10-19 04:00:24 +08:00
|
|
|
err = security_bpf(cmd, &attr, size);
|
|
|
|
if (err < 0)
|
|
|
|
return err;
|
|
|
|
|
2014-09-26 15:16:57 +08:00
|
|
|
switch (cmd) {
|
|
|
|
case BPF_MAP_CREATE:
|
|
|
|
err = map_create(&attr);
|
|
|
|
break;
|
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 15:16:59 +08:00
|
|
|
case BPF_MAP_LOOKUP_ELEM:
|
|
|
|
err = map_lookup_elem(&attr);
|
|
|
|
break;
|
|
|
|
case BPF_MAP_UPDATE_ELEM:
|
|
|
|
err = map_update_elem(&attr);
|
|
|
|
break;
|
|
|
|
case BPF_MAP_DELETE_ELEM:
|
|
|
|
err = map_delete_elem(&attr);
|
|
|
|
break;
|
|
|
|
case BPF_MAP_GET_NEXT_KEY:
|
|
|
|
err = map_get_next_key(&attr);
|
|
|
|
break;
|
2014-09-26 15:17:00 +08:00
|
|
|
case BPF_PROG_LOAD:
|
bpf: Introduce bpf_func_info
This patch added interface to load a program with the following
additional information:
. prog_btf_fd
. func_info, func_info_rec_size and func_info_cnt
where func_info will provide function range and type_id
corresponding to each function.
The func_info_rec_size is introduced in the UAPI to specify
struct bpf_func_info size passed from user space. This
intends to make bpf_func_info structure growable in the future.
If the kernel gets a different bpf_func_info size from userspace,
it will try to handle user request with part of bpf_func_info
it can understand. In this patch, kernel can understand
struct bpf_func_info {
__u32 insn_offset;
__u32 type_id;
};
If user passed a bpf func_info record size of 16 bytes, the
kernel can still handle part of records with the above definition.
If verifier agrees with function range provided by the user,
the bpf_prog ksym for each function will use the func name
provided in the type_id, which is supposed to provide better
encoding as it is not limited by 16 bytes program name
limitation and this is better for bpf program which contains
multiple subprograms.
The bpf_prog_info interface is also extended to
return btf_id, func_info, func_info_rec_size and func_info_cnt
to userspace, so userspace can print out the function prototype
for each xlated function. The insn_offset in the returned
func_info corresponds to the insn offset for xlated functions.
With other jit related fields in bpf_prog_info, userspace can also
print out function prototypes for each jited function.
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-11-20 07:29:11 +08:00
|
|
|
err = bpf_prog_load(&attr, uattr);
|
2014-09-26 15:17:00 +08:00
|
|
|
break;
|
2015-10-29 21:58:09 +08:00
|
|
|
case BPF_OBJ_PIN:
|
|
|
|
err = bpf_obj_pin(&attr);
|
|
|
|
break;
|
|
|
|
case BPF_OBJ_GET:
|
|
|
|
err = bpf_obj_get(&attr);
|
|
|
|
break;
|
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 23:52:27 +08:00
|
|
|
case BPF_PROG_ATTACH:
|
|
|
|
err = bpf_prog_attach(&attr);
|
|
|
|
break;
|
|
|
|
case BPF_PROG_DETACH:
|
|
|
|
err = bpf_prog_detach(&attr);
|
|
|
|
break;
|
2017-10-03 13:50:22 +08:00
|
|
|
case BPF_PROG_QUERY:
|
|
|
|
err = bpf_prog_query(&attr, uattr);
|
|
|
|
break;
|
2017-03-31 12:45:38 +08:00
|
|
|
case BPF_PROG_TEST_RUN:
|
|
|
|
err = bpf_prog_test_run(&attr, uattr);
|
|
|
|
break;
|
2017-06-06 03:15:48 +08:00
|
|
|
case BPF_PROG_GET_NEXT_ID:
|
|
|
|
err = bpf_obj_get_next_id(&attr, uattr,
|
|
|
|
&prog_idr, &prog_idr_lock);
|
|
|
|
break;
|
|
|
|
case BPF_MAP_GET_NEXT_ID:
|
|
|
|
err = bpf_obj_get_next_id(&attr, uattr,
|
|
|
|
&map_idr, &map_idr_lock);
|
|
|
|
break;
|
2017-06-06 03:15:49 +08:00
|
|
|
case BPF_PROG_GET_FD_BY_ID:
|
|
|
|
err = bpf_prog_get_fd_by_id(&attr);
|
|
|
|
break;
|
2017-06-06 03:15:50 +08:00
|
|
|
case BPF_MAP_GET_FD_BY_ID:
|
|
|
|
err = bpf_map_get_fd_by_id(&attr);
|
|
|
|
break;
|
2017-06-06 03:15:52 +08:00
|
|
|
case BPF_OBJ_GET_INFO_BY_FD:
|
|
|
|
err = bpf_obj_get_info_by_fd(&attr, uattr);
|
|
|
|
break;
|
2018-03-29 03:05:37 +08:00
|
|
|
case BPF_RAW_TRACEPOINT_OPEN:
|
|
|
|
err = bpf_raw_tracepoint_open(&attr);
|
|
|
|
break;
|
2018-04-19 06:56:01 +08:00
|
|
|
case BPF_BTF_LOAD:
|
|
|
|
err = bpf_btf_load(&attr);
|
|
|
|
break;
|
2018-05-05 05:49:51 +08:00
|
|
|
case BPF_BTF_GET_FD_BY_ID:
|
|
|
|
err = bpf_btf_get_fd_by_id(&attr);
|
|
|
|
break;
|
bpf: introduce bpf subcommand BPF_TASK_FD_QUERY
Currently, suppose a userspace application has loaded a bpf program
and attached it to a tracepoint/kprobe/uprobe, and a bpf
introspection tool, e.g., bpftool, wants to show which bpf program
is attached to which tracepoint/kprobe/uprobe. Such attachment
information will be really useful to understand the overall bpf
deployment in the system.
There is a name field (16 bytes) for each program, which could
be used to encode the attachment point. There are some drawbacks
for this approaches. First, bpftool user (e.g., an admin) may not
really understand the association between the name and the
attachment point. Second, if one program is attached to multiple
places, encoding a proper name which can imply all these
attachments becomes difficult.
This patch introduces a new bpf subcommand BPF_TASK_FD_QUERY.
Given a pid and fd, if the <pid, fd> is associated with a
tracepoint/kprobe/uprobe perf event, BPF_TASK_FD_QUERY will return
. prog_id
. tracepoint name, or
. k[ret]probe funcname + offset or kernel addr, or
. u[ret]probe filename + offset
to the userspace.
The user can use "bpftool prog" to find more information about
bpf program itself with prog_id.
Acked-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-05-25 02:21:09 +08:00
|
|
|
case BPF_TASK_FD_QUERY:
|
|
|
|
err = bpf_task_fd_query(&attr, uattr);
|
|
|
|
break;
|
2018-10-18 21:16:30 +08:00
|
|
|
case BPF_MAP_LOOKUP_AND_DELETE_ELEM:
|
|
|
|
err = map_lookup_and_delete_elem(&attr);
|
|
|
|
break;
|
2014-09-26 15:16:57 +08:00
|
|
|
default:
|
|
|
|
err = -EINVAL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|