* [PATCH v7 bpf-next 06/14] bpf/verifier: introduce BPF_PTR_TO_MAP_VALUE
From: Roman Gushchin @ 2018-08-02 21:27 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel-team, Roman Gushchin, Alexei Starovoitov,
Daniel Borkmann
In-Reply-To: <20180802212730.18579-1-guro@fb.com>
BPF_MAP_TYPE_CGROUP_STORAGE maps are special in a way
that the access from the bpf program side is lookup-free.
That means the result is guaranteed to be a valid
pointer to the cgroup storage; no NULL-check is required.
This patch introduces BPF_PTR_TO_MAP_VALUE return type,
which is required to cause the verifier accept programs,
which are not checking the map value pointer for being NULL.
Signed-off-by: Roman Gushchin <guro@fb.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Martin KaFai Lau <kafai@fb.com>
---
include/linux/bpf.h | 1 +
kernel/bpf/verifier.c | 8 ++++++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 16be67888c30..ca4ac2a39def 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -155,6 +155,7 @@ enum bpf_arg_type {
enum bpf_return_type {
RET_INTEGER, /* function returns integer */
RET_VOID, /* function doesn't return anything */
+ RET_PTR_TO_MAP_VALUE, /* returns a pointer to map elem value */
RET_PTR_TO_MAP_VALUE_OR_NULL, /* returns a pointer to map elem value or NULL */
};
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 7e75434a9e54..1ede16c8bb40 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -2545,8 +2545,12 @@ static int check_helper_call(struct bpf_verifier_env *env, int func_id, int insn
mark_reg_unknown(env, regs, BPF_REG_0);
} else if (fn->ret_type == RET_VOID) {
regs[BPF_REG_0].type = NOT_INIT;
- } else if (fn->ret_type == RET_PTR_TO_MAP_VALUE_OR_NULL) {
- regs[BPF_REG_0].type = PTR_TO_MAP_VALUE_OR_NULL;
+ } else if (fn->ret_type == RET_PTR_TO_MAP_VALUE_OR_NULL ||
+ fn->ret_type == RET_PTR_TO_MAP_VALUE) {
+ if (fn->ret_type == RET_PTR_TO_MAP_VALUE)
+ regs[BPF_REG_0].type = PTR_TO_MAP_VALUE;
+ else
+ regs[BPF_REG_0].type = PTR_TO_MAP_VALUE_OR_NULL;
/* There is no offset yet applied, variable or fixed */
mark_reg_known_zero(env, regs, BPF_REG_0);
regs[BPF_REG_0].off = 0;
--
2.14.4
^ permalink raw reply related
* [PATCH v7 bpf-next 04/14] bpf: allocate cgroup storage entries on attaching bpf programs
From: Roman Gushchin @ 2018-08-02 21:27 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel-team, Roman Gushchin, Alexei Starovoitov,
Daniel Borkmann
In-Reply-To: <20180802212730.18579-1-guro@fb.com>
If a bpf program is using cgroup local storage, allocate
a bpf_cgroup_storage structure automatically on attaching the program
to a cgroup and save the pointer into the corresponding bpf_prog_list
entry.
Analogically, release the cgroup local storage on detaching
of the bpf program.
Signed-off-by: Roman Gushchin <guro@fb.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Martin KaFai Lau <kafai@fb.com>
---
include/linux/bpf-cgroup.h | 1 +
kernel/bpf/cgroup.c | 35 +++++++++++++++++++++++++++++++----
2 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/include/linux/bpf-cgroup.h b/include/linux/bpf-cgroup.h
index 9a144ddbbc8f..f91b0f8ff3a9 100644
--- a/include/linux/bpf-cgroup.h
+++ b/include/linux/bpf-cgroup.h
@@ -43,6 +43,7 @@ struct bpf_cgroup_storage {
struct bpf_prog_list {
struct list_head node;
struct bpf_prog *prog;
+ struct bpf_cgroup_storage *storage;
};
struct bpf_prog_array;
diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
index badabb0b435c..935274c86bfe 100644
--- a/kernel/bpf/cgroup.c
+++ b/kernel/bpf/cgroup.c
@@ -34,6 +34,8 @@ void cgroup_bpf_put(struct cgroup *cgrp)
list_for_each_entry_safe(pl, tmp, progs, node) {
list_del(&pl->node);
bpf_prog_put(pl->prog);
+ bpf_cgroup_storage_unlink(pl->storage);
+ bpf_cgroup_storage_free(pl->storage);
kfree(pl);
static_branch_dec(&cgroup_bpf_enabled_key);
}
@@ -188,6 +190,7 @@ int __cgroup_bpf_attach(struct cgroup *cgrp, struct bpf_prog *prog,
{
struct list_head *progs = &cgrp->bpf.progs[type];
struct bpf_prog *old_prog = NULL;
+ struct bpf_cgroup_storage *storage, *old_storage = NULL;
struct cgroup_subsys_state *css;
struct bpf_prog_list *pl;
bool pl_was_allocated;
@@ -210,31 +213,47 @@ int __cgroup_bpf_attach(struct cgroup *cgrp, struct bpf_prog *prog,
if (prog_list_length(progs) >= BPF_CGROUP_MAX_PROGS)
return -E2BIG;
+ storage = bpf_cgroup_storage_alloc(prog);
+ if (IS_ERR(storage))
+ return -ENOMEM;
+
if (flags & BPF_F_ALLOW_MULTI) {
- list_for_each_entry(pl, progs, node)
- if (pl->prog == prog)
+ list_for_each_entry(pl, progs, node) {
+ if (pl->prog == prog) {
/* disallow attaching the same prog twice */
+ bpf_cgroup_storage_free(storage);
return -EINVAL;
+ }
+ }
pl = kmalloc(sizeof(*pl), GFP_KERNEL);
- if (!pl)
+ if (!pl) {
+ bpf_cgroup_storage_free(storage);
return -ENOMEM;
+ }
+
pl_was_allocated = true;
pl->prog = prog;
+ pl->storage = storage;
list_add_tail(&pl->node, progs);
} else {
if (list_empty(progs)) {
pl = kmalloc(sizeof(*pl), GFP_KERNEL);
- if (!pl)
+ if (!pl) {
+ bpf_cgroup_storage_free(storage);
return -ENOMEM;
+ }
pl_was_allocated = true;
list_add_tail(&pl->node, progs);
} else {
pl = list_first_entry(progs, typeof(*pl), node);
old_prog = pl->prog;
+ old_storage = pl->storage;
+ bpf_cgroup_storage_unlink(old_storage);
pl_was_allocated = false;
}
pl->prog = prog;
+ pl->storage = storage;
}
cgrp->bpf.flags[type] = flags;
@@ -257,10 +276,13 @@ int __cgroup_bpf_attach(struct cgroup *cgrp, struct bpf_prog *prog,
}
static_branch_inc(&cgroup_bpf_enabled_key);
+ if (old_storage)
+ bpf_cgroup_storage_free(old_storage);
if (old_prog) {
bpf_prog_put(old_prog);
static_branch_dec(&cgroup_bpf_enabled_key);
}
+ bpf_cgroup_storage_link(storage, cgrp, type);
return 0;
cleanup:
@@ -276,6 +298,9 @@ int __cgroup_bpf_attach(struct cgroup *cgrp, struct bpf_prog *prog,
/* and cleanup the prog list */
pl->prog = old_prog;
+ bpf_cgroup_storage_free(pl->storage);
+ pl->storage = old_storage;
+ bpf_cgroup_storage_link(old_storage, cgrp, type);
if (pl_was_allocated) {
list_del(&pl->node);
kfree(pl);
@@ -356,6 +381,8 @@ int __cgroup_bpf_detach(struct cgroup *cgrp, struct bpf_prog *prog,
/* now can actually delete it from this cgroup list */
list_del(&pl->node);
+ bpf_cgroup_storage_unlink(pl->storage);
+ bpf_cgroup_storage_free(pl->storage);
kfree(pl);
if (list_empty(progs))
/* last program was detached, reset flags to zero */
--
2.14.4
^ permalink raw reply related
* [PATCH v7 bpf-next 03/14] bpf: pass a pointer to a cgroup storage using pcpu variable
From: Roman Gushchin @ 2018-08-02 21:27 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel-team, Roman Gushchin, Alexei Starovoitov,
Daniel Borkmann
In-Reply-To: <20180802212730.18579-1-guro@fb.com>
This commit introduces the bpf_cgroup_storage_set() helper,
which will be used to pass a pointer to a cgroup storage
to the bpf helper.
Signed-off-by: Roman Gushchin <guro@fb.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Martin KaFai Lau <kafai@fb.com>
---
include/linux/bpf-cgroup.h | 15 +++++++++++++++
kernel/bpf/local_storage.c | 2 ++
2 files changed, 17 insertions(+)
diff --git a/include/linux/bpf-cgroup.h b/include/linux/bpf-cgroup.h
index 7d00d58869ed..9a144ddbbc8f 100644
--- a/include/linux/bpf-cgroup.h
+++ b/include/linux/bpf-cgroup.h
@@ -4,6 +4,7 @@
#include <linux/errno.h>
#include <linux/jump_label.h>
+#include <linux/percpu.h>
#include <linux/rbtree.h>
#include <uapi/linux/bpf.h>
@@ -21,6 +22,8 @@ struct bpf_cgroup_storage;
extern struct static_key_false cgroup_bpf_enabled_key;
#define cgroup_bpf_enabled static_branch_unlikely(&cgroup_bpf_enabled_key)
+DECLARE_PER_CPU(void*, bpf_cgroup_storage);
+
struct bpf_cgroup_storage_map;
struct bpf_storage_buffer {
@@ -97,6 +100,17 @@ int __cgroup_bpf_run_filter_sock_ops(struct sock *sk,
int __cgroup_bpf_check_dev_permission(short dev_type, u32 major, u32 minor,
short access, enum bpf_attach_type type);
+static inline void bpf_cgroup_storage_set(struct bpf_cgroup_storage *storage)
+{
+ struct bpf_storage_buffer *buf;
+
+ if (!storage)
+ return;
+
+ buf = READ_ONCE(storage->buf);
+ this_cpu_write(bpf_cgroup_storage, &buf->data[0]);
+}
+
struct bpf_cgroup_storage *bpf_cgroup_storage_alloc(struct bpf_prog *prog);
void bpf_cgroup_storage_free(struct bpf_cgroup_storage *storage);
void bpf_cgroup_storage_link(struct bpf_cgroup_storage *storage,
@@ -250,6 +264,7 @@ static inline int cgroup_bpf_prog_query(const union bpf_attr *attr,
return -EINVAL;
}
+static inline void bpf_cgroup_storage_set(struct bpf_cgroup_storage *storage) {}
static inline int bpf_cgroup_storage_assign(struct bpf_prog *prog,
struct bpf_map *map) { return 0; }
static inline void bpf_cgroup_storage_release(struct bpf_prog *prog,
diff --git a/kernel/bpf/local_storage.c b/kernel/bpf/local_storage.c
index f23d3fdeba23..fc4e37f68f2a 100644
--- a/kernel/bpf/local_storage.c
+++ b/kernel/bpf/local_storage.c
@@ -7,6 +7,8 @@
#include <linux/rbtree.h>
#include <linux/slab.h>
+DEFINE_PER_CPU(void*, bpf_cgroup_storage);
+
#ifdef CONFIG_CGROUP_BPF
#define LOCAL_STORAGE_CREATE_FLAG_MASK \
--
2.14.4
^ permalink raw reply related
* [PATCH v7 bpf-next 02/14] bpf: introduce cgroup storage maps
From: Roman Gushchin @ 2018-08-02 21:27 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel-team, Roman Gushchin, Alexei Starovoitov,
Daniel Borkmann
In-Reply-To: <20180802212730.18579-1-guro@fb.com>
This commit introduces BPF_MAP_TYPE_CGROUP_STORAGE maps:
a special type of maps which are implementing the cgroup storage.
>From the userspace point of view it's almost a generic
hash map with the (cgroup inode id, attachment type) pair
used as a key.
The only difference is that some operations are restricted:
1) a user can't create new entries,
2) a user can't remove existing entries.
The lookup from userspace is o(log(n)).
Signed-off-by: Roman Gushchin <guro@fb.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Martin KaFai Lau <kafai@fb.com>
---
include/linux/bpf-cgroup.h | 38 +++++
include/linux/bpf.h | 1 +
include/linux/bpf_types.h | 3 +
include/uapi/linux/bpf.h | 6 +
kernel/bpf/Makefile | 1 +
kernel/bpf/local_storage.c | 376 +++++++++++++++++++++++++++++++++++++++++++++
kernel/bpf/syscall.c | 3 +
kernel/bpf/verifier.c | 12 ++
8 files changed, 440 insertions(+)
create mode 100644 kernel/bpf/local_storage.c
diff --git a/include/linux/bpf-cgroup.h b/include/linux/bpf-cgroup.h
index d50c2f0a655a..7d00d58869ed 100644
--- a/include/linux/bpf-cgroup.h
+++ b/include/linux/bpf-cgroup.h
@@ -4,19 +4,39 @@
#include <linux/errno.h>
#include <linux/jump_label.h>
+#include <linux/rbtree.h>
#include <uapi/linux/bpf.h>
struct sock;
struct sockaddr;
struct cgroup;
struct sk_buff;
+struct bpf_map;
+struct bpf_prog;
struct bpf_sock_ops_kern;
+struct bpf_cgroup_storage;
#ifdef CONFIG_CGROUP_BPF
extern struct static_key_false cgroup_bpf_enabled_key;
#define cgroup_bpf_enabled static_branch_unlikely(&cgroup_bpf_enabled_key)
+struct bpf_cgroup_storage_map;
+
+struct bpf_storage_buffer {
+ struct rcu_head rcu;
+ char data[0];
+};
+
+struct bpf_cgroup_storage {
+ struct bpf_storage_buffer *buf;
+ struct bpf_cgroup_storage_map *map;
+ struct bpf_cgroup_storage_key key;
+ struct list_head list;
+ struct rb_node node;
+ struct rcu_head rcu;
+};
+
struct bpf_prog_list {
struct list_head node;
struct bpf_prog *prog;
@@ -77,6 +97,15 @@ int __cgroup_bpf_run_filter_sock_ops(struct sock *sk,
int __cgroup_bpf_check_dev_permission(short dev_type, u32 major, u32 minor,
short access, enum bpf_attach_type type);
+struct bpf_cgroup_storage *bpf_cgroup_storage_alloc(struct bpf_prog *prog);
+void bpf_cgroup_storage_free(struct bpf_cgroup_storage *storage);
+void bpf_cgroup_storage_link(struct bpf_cgroup_storage *storage,
+ struct cgroup *cgroup,
+ enum bpf_attach_type type);
+void bpf_cgroup_storage_unlink(struct bpf_cgroup_storage *storage);
+int bpf_cgroup_storage_assign(struct bpf_prog *prog, struct bpf_map *map);
+void bpf_cgroup_storage_release(struct bpf_prog *prog, struct bpf_map *map);
+
/* Wrappers for __cgroup_bpf_run_filter_skb() guarded by cgroup_bpf_enabled. */
#define BPF_CGROUP_RUN_PROG_INET_INGRESS(sk, skb) \
({ \
@@ -221,6 +250,15 @@ static inline int cgroup_bpf_prog_query(const union bpf_attr *attr,
return -EINVAL;
}
+static inline int bpf_cgroup_storage_assign(struct bpf_prog *prog,
+ struct bpf_map *map) { return 0; }
+static inline void bpf_cgroup_storage_release(struct bpf_prog *prog,
+ struct bpf_map *map) {}
+static inline struct bpf_cgroup_storage *bpf_cgroup_storage_alloc(
+ struct bpf_prog *prog) { return 0; }
+static inline void bpf_cgroup_storage_free(
+ struct bpf_cgroup_storage *storage) {}
+
#define cgroup_bpf_enabled (0)
#define BPF_CGROUP_PRE_CONNECT_ENABLED(sk) (0)
#define BPF_CGROUP_RUN_PROG_INET_INGRESS(sk,skb) ({ 0; })
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 5a4a256473c3..9d1e4727495e 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -282,6 +282,7 @@ struct bpf_prog_aux {
struct bpf_prog *prog;
struct user_struct *user;
u64 load_time; /* ns since boottime */
+ struct bpf_map *cgroup_storage;
char name[BPF_OBJ_NAME_LEN];
#ifdef CONFIG_SECURITY
void *security;
diff --git a/include/linux/bpf_types.h b/include/linux/bpf_types.h
index c5700c2d5549..add08be53b6f 100644
--- a/include/linux/bpf_types.h
+++ b/include/linux/bpf_types.h
@@ -37,6 +37,9 @@ BPF_MAP_TYPE(BPF_MAP_TYPE_PERF_EVENT_ARRAY, perf_event_array_map_ops)
#ifdef CONFIG_CGROUPS
BPF_MAP_TYPE(BPF_MAP_TYPE_CGROUP_ARRAY, cgroup_array_map_ops)
#endif
+#ifdef CONFIG_CGROUP_BPF
+BPF_MAP_TYPE(BPF_MAP_TYPE_CGROUP_STORAGE, cgroup_storage_map_ops)
+#endif
BPF_MAP_TYPE(BPF_MAP_TYPE_HASH, htab_map_ops)
BPF_MAP_TYPE(BPF_MAP_TYPE_PERCPU_HASH, htab_percpu_map_ops)
BPF_MAP_TYPE(BPF_MAP_TYPE_LRU_HASH, htab_lru_map_ops)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 0ebaaf7f3568..b10118ee5afe 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -75,6 +75,11 @@ struct bpf_lpm_trie_key {
__u8 data[0]; /* Arbitrary size */
};
+struct bpf_cgroup_storage_key {
+ __u64 cgroup_inode_id; /* cgroup inode id */
+ __u32 attach_type; /* program attach type */
+};
+
/* BPF syscall commands, see bpf(2) man-page for details. */
enum bpf_cmd {
BPF_MAP_CREATE,
@@ -120,6 +125,7 @@ enum bpf_map_type {
BPF_MAP_TYPE_CPUMAP,
BPF_MAP_TYPE_XSKMAP,
BPF_MAP_TYPE_SOCKHASH,
+ BPF_MAP_TYPE_CGROUP_STORAGE,
};
enum bpf_prog_type {
diff --git a/kernel/bpf/Makefile b/kernel/bpf/Makefile
index f27f5496d6fe..e8906cbad81f 100644
--- a/kernel/bpf/Makefile
+++ b/kernel/bpf/Makefile
@@ -3,6 +3,7 @@ obj-y := core.o
obj-$(CONFIG_BPF_SYSCALL) += syscall.o verifier.o inode.o helpers.o tnum.o
obj-$(CONFIG_BPF_SYSCALL) += hashtab.o arraymap.o percpu_freelist.o bpf_lru_list.o lpm_trie.o map_in_map.o
+obj-$(CONFIG_BPF_SYSCALL) += local_storage.o
obj-$(CONFIG_BPF_SYSCALL) += disasm.o
obj-$(CONFIG_BPF_SYSCALL) += btf.o
ifeq ($(CONFIG_NET),y)
diff --git a/kernel/bpf/local_storage.c b/kernel/bpf/local_storage.c
new file mode 100644
index 000000000000..f23d3fdeba23
--- /dev/null
+++ b/kernel/bpf/local_storage.c
@@ -0,0 +1,376 @@
+//SPDX-License-Identifier: GPL-2.0
+#include <linux/bpf-cgroup.h>
+#include <linux/bpf.h>
+#include <linux/bug.h>
+#include <linux/filter.h>
+#include <linux/mm.h>
+#include <linux/rbtree.h>
+#include <linux/slab.h>
+
+#ifdef CONFIG_CGROUP_BPF
+
+#define LOCAL_STORAGE_CREATE_FLAG_MASK \
+ (BPF_F_NUMA_NODE | BPF_F_RDONLY | BPF_F_WRONLY)
+
+struct bpf_cgroup_storage_map {
+ struct bpf_map map;
+
+ spinlock_t lock;
+ struct bpf_prog *prog;
+ struct rb_root root;
+ struct list_head list;
+};
+
+static struct bpf_cgroup_storage_map *map_to_storage(struct bpf_map *map)
+{
+ return container_of(map, struct bpf_cgroup_storage_map, map);
+}
+
+static int bpf_cgroup_storage_key_cmp(
+ const struct bpf_cgroup_storage_key *key1,
+ const struct bpf_cgroup_storage_key *key2)
+{
+ if (key1->cgroup_inode_id < key2->cgroup_inode_id)
+ return -1;
+ else if (key1->cgroup_inode_id > key2->cgroup_inode_id)
+ return 1;
+ else if (key1->attach_type < key2->attach_type)
+ return -1;
+ else if (key1->attach_type > key2->attach_type)
+ return 1;
+ return 0;
+}
+
+static struct bpf_cgroup_storage *cgroup_storage_lookup(
+ struct bpf_cgroup_storage_map *map, struct bpf_cgroup_storage_key *key,
+ bool locked)
+{
+ struct rb_root *root = &map->root;
+ struct rb_node *node;
+
+ if (!locked)
+ spin_lock_bh(&map->lock);
+
+ node = root->rb_node;
+ while (node) {
+ struct bpf_cgroup_storage *storage;
+
+ storage = container_of(node, struct bpf_cgroup_storage, node);
+
+ switch (bpf_cgroup_storage_key_cmp(key, &storage->key)) {
+ case -1:
+ node = node->rb_left;
+ break;
+ case 1:
+ node = node->rb_right;
+ break;
+ default:
+ if (!locked)
+ spin_unlock_bh(&map->lock);
+ return storage;
+ }
+ }
+
+ if (!locked)
+ spin_unlock_bh(&map->lock);
+
+ return NULL;
+}
+
+static int cgroup_storage_insert(struct bpf_cgroup_storage_map *map,
+ struct bpf_cgroup_storage *storage)
+{
+ struct rb_root *root = &map->root;
+ struct rb_node **new = &(root->rb_node), *parent = NULL;
+
+ while (*new) {
+ struct bpf_cgroup_storage *this;
+
+ this = container_of(*new, struct bpf_cgroup_storage, node);
+
+ parent = *new;
+ switch (bpf_cgroup_storage_key_cmp(&storage->key, &this->key)) {
+ case -1:
+ new = &((*new)->rb_left);
+ break;
+ case 1:
+ new = &((*new)->rb_right);
+ break;
+ default:
+ return -EEXIST;
+ }
+ }
+
+ rb_link_node(&storage->node, parent, new);
+ rb_insert_color(&storage->node, root);
+
+ return 0;
+}
+
+static void *cgroup_storage_lookup_elem(struct bpf_map *_map, void *_key)
+{
+ struct bpf_cgroup_storage_map *map = map_to_storage(_map);
+ struct bpf_cgroup_storage_key *key = _key;
+ struct bpf_cgroup_storage *storage;
+
+ storage = cgroup_storage_lookup(map, key, false);
+ if (!storage)
+ return NULL;
+
+ return &READ_ONCE(storage->buf)->data[0];
+}
+
+static int cgroup_storage_update_elem(struct bpf_map *map, void *_key,
+ void *value, u64 flags)
+{
+ struct bpf_cgroup_storage_key *key = _key;
+ struct bpf_cgroup_storage *storage;
+ struct bpf_storage_buffer *new;
+
+ if (flags & BPF_NOEXIST)
+ return -EINVAL;
+
+ storage = cgroup_storage_lookup((struct bpf_cgroup_storage_map *)map,
+ key, false);
+ if (!storage)
+ return -ENOENT;
+
+ new = kmalloc_node(sizeof(struct bpf_storage_buffer) +
+ map->value_size, __GFP_ZERO | GFP_USER,
+ map->numa_node);
+ if (!new)
+ return -ENOMEM;
+
+ memcpy(&new->data[0], value, map->value_size);
+
+ new = xchg(&storage->buf, new);
+ kfree_rcu(new, rcu);
+
+ return 0;
+}
+
+static int cgroup_storage_get_next_key(struct bpf_map *_map, void *_key,
+ void *_next_key)
+{
+ struct bpf_cgroup_storage_map *map = map_to_storage(_map);
+ struct bpf_cgroup_storage_key *key = _key;
+ struct bpf_cgroup_storage_key *next = _next_key;
+ struct bpf_cgroup_storage *storage;
+
+ spin_lock_bh(&map->lock);
+
+ if (list_empty(&map->list))
+ goto enoent;
+
+ if (key) {
+ storage = cgroup_storage_lookup(map, key, true);
+ if (!storage)
+ goto enoent;
+
+ storage = list_next_entry(storage, list);
+ if (!storage)
+ goto enoent;
+ } else {
+ storage = list_first_entry(&map->list,
+ struct bpf_cgroup_storage, list);
+ }
+
+ spin_unlock_bh(&map->lock);
+ next->attach_type = storage->key.attach_type;
+ next->cgroup_inode_id = storage->key.cgroup_inode_id;
+ return 0;
+
+enoent:
+ spin_unlock_bh(&map->lock);
+ return -ENOENT;
+}
+
+static struct bpf_map *cgroup_storage_map_alloc(union bpf_attr *attr)
+{
+ int numa_node = bpf_map_attr_numa_node(attr);
+ struct bpf_cgroup_storage_map *map;
+
+ if (attr->key_size != sizeof(struct bpf_cgroup_storage_key))
+ return ERR_PTR(-EINVAL);
+
+ if (attr->value_size > PAGE_SIZE)
+ return ERR_PTR(-E2BIG);
+
+ if (attr->map_flags & ~LOCAL_STORAGE_CREATE_FLAG_MASK)
+ /* reserved bits should not be used */
+ return ERR_PTR(-EINVAL);
+
+ if (attr->max_entries)
+ /* max_entries is not used and enforced to be 0 */
+ return ERR_PTR(-EINVAL);
+
+ map = kmalloc_node(sizeof(struct bpf_cgroup_storage_map),
+ __GFP_ZERO | GFP_USER, numa_node);
+ if (!map)
+ return ERR_PTR(-ENOMEM);
+
+ map->map.pages = round_up(sizeof(struct bpf_cgroup_storage_map),
+ PAGE_SIZE) >> PAGE_SHIFT;
+
+ /* copy mandatory map attributes */
+ bpf_map_init_from_attr(&map->map, attr);
+
+ spin_lock_init(&map->lock);
+ map->root = RB_ROOT;
+ INIT_LIST_HEAD(&map->list);
+
+ return &map->map;
+}
+
+static void cgroup_storage_map_free(struct bpf_map *_map)
+{
+ struct bpf_cgroup_storage_map *map = map_to_storage(_map);
+
+ WARN_ON(!RB_EMPTY_ROOT(&map->root));
+ WARN_ON(!list_empty(&map->list));
+
+ kfree(map);
+}
+
+static int cgroup_storage_delete_elem(struct bpf_map *map, void *key)
+{
+ return -EINVAL;
+}
+
+const struct bpf_map_ops cgroup_storage_map_ops = {
+ .map_alloc = cgroup_storage_map_alloc,
+ .map_free = cgroup_storage_map_free,
+ .map_get_next_key = cgroup_storage_get_next_key,
+ .map_lookup_elem = cgroup_storage_lookup_elem,
+ .map_update_elem = cgroup_storage_update_elem,
+ .map_delete_elem = cgroup_storage_delete_elem,
+};
+
+int bpf_cgroup_storage_assign(struct bpf_prog *prog, struct bpf_map *_map)
+{
+ struct bpf_cgroup_storage_map *map = map_to_storage(_map);
+ int ret = -EBUSY;
+
+ spin_lock_bh(&map->lock);
+
+ if (map->prog && map->prog != prog)
+ goto unlock;
+ if (prog->aux->cgroup_storage && prog->aux->cgroup_storage != _map)
+ goto unlock;
+
+ map->prog = prog;
+ prog->aux->cgroup_storage = _map;
+ ret = 0;
+unlock:
+ spin_unlock_bh(&map->lock);
+
+ return ret;
+}
+
+void bpf_cgroup_storage_release(struct bpf_prog *prog, struct bpf_map *_map)
+{
+ struct bpf_cgroup_storage_map *map = map_to_storage(_map);
+
+ spin_lock_bh(&map->lock);
+ if (map->prog == prog) {
+ WARN_ON(prog->aux->cgroup_storage != _map);
+ map->prog = NULL;
+ prog->aux->cgroup_storage = NULL;
+ }
+ spin_unlock_bh(&map->lock);
+}
+
+struct bpf_cgroup_storage *bpf_cgroup_storage_alloc(struct bpf_prog *prog)
+{
+ struct bpf_cgroup_storage *storage;
+ struct bpf_map *map;
+ u32 pages;
+
+ map = prog->aux->cgroup_storage;
+ if (!map)
+ return NULL;
+
+ pages = round_up(sizeof(struct bpf_cgroup_storage) +
+ sizeof(struct bpf_storage_buffer) +
+ map->value_size, PAGE_SIZE) >> PAGE_SHIFT;
+ if (bpf_map_charge_memlock(map, pages))
+ return ERR_PTR(-EPERM);
+
+ storage = kmalloc_node(sizeof(struct bpf_cgroup_storage),
+ __GFP_ZERO | GFP_USER, map->numa_node);
+ if (!storage) {
+ bpf_map_uncharge_memlock(map, pages);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ storage->buf = kmalloc_node(sizeof(struct bpf_storage_buffer) +
+ map->value_size, __GFP_ZERO | GFP_USER,
+ map->numa_node);
+ if (!storage->buf) {
+ bpf_map_uncharge_memlock(map, pages);
+ kfree(storage);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ storage->map = (struct bpf_cgroup_storage_map *)map;
+
+ return storage;
+}
+
+void bpf_cgroup_storage_free(struct bpf_cgroup_storage *storage)
+{
+ u32 pages;
+ struct bpf_map *map;
+
+ if (!storage)
+ return;
+
+ map = &storage->map->map;
+ pages = round_up(sizeof(struct bpf_cgroup_storage) +
+ sizeof(struct bpf_storage_buffer) +
+ map->value_size, PAGE_SIZE) >> PAGE_SHIFT;
+ bpf_map_uncharge_memlock(map, pages);
+
+ kfree_rcu(storage->buf, rcu);
+ kfree_rcu(storage, rcu);
+}
+
+void bpf_cgroup_storage_link(struct bpf_cgroup_storage *storage,
+ struct cgroup *cgroup,
+ enum bpf_attach_type type)
+{
+ struct bpf_cgroup_storage_map *map;
+
+ if (!storage)
+ return;
+
+ storage->key.attach_type = type;
+ storage->key.cgroup_inode_id = cgroup->kn->id.id;
+
+ map = storage->map;
+
+ spin_lock_bh(&map->lock);
+ WARN_ON(cgroup_storage_insert(map, storage));
+ list_add(&storage->list, &map->list);
+ spin_unlock_bh(&map->lock);
+}
+
+void bpf_cgroup_storage_unlink(struct bpf_cgroup_storage *storage)
+{
+ struct bpf_cgroup_storage_map *map;
+ struct rb_root *root;
+
+ if (!storage)
+ return;
+
+ map = storage->map;
+
+ spin_lock_bh(&map->lock);
+ root = &map->root;
+ rb_erase(&storage->node, root);
+
+ list_del(&storage->list);
+ spin_unlock_bh(&map->lock);
+}
+
+#endif
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 7958252a4d29..5af4e9e2722d 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -957,6 +957,9 @@ static void free_used_maps(struct bpf_prog_aux *aux)
{
int i;
+ if (aux->cgroup_storage)
+ bpf_cgroup_storage_release(aux->prog, aux->cgroup_storage);
+
for (i = 0; i < aux->used_map_cnt; i++)
bpf_map_put(aux->used_maps[i]);
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index e948303a0ea8..7e75434a9e54 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -5154,6 +5154,14 @@ static int replace_map_fd_with_map_ptr(struct bpf_verifier_env *env)
}
env->used_maps[env->used_map_cnt++] = map;
+ if (map->map_type == BPF_MAP_TYPE_CGROUP_STORAGE &&
+ bpf_cgroup_storage_assign(env->prog, map)) {
+ verbose(env,
+ "only one cgroup storage is allowed\n");
+ fdput(f);
+ return -EBUSY;
+ }
+
fdput(f);
next_insn:
insn++;
@@ -5180,6 +5188,10 @@ static void release_maps(struct bpf_verifier_env *env)
{
int i;
+ if (env->prog->aux->cgroup_storage)
+ bpf_cgroup_storage_release(env->prog,
+ env->prog->aux->cgroup_storage);
+
for (i = 0; i < env->used_map_cnt; i++)
bpf_map_put(env->used_maps[i]);
}
--
2.14.4
^ permalink raw reply related
* [PATCH v7 bpf-next 01/14] bpf: add ability to charge bpf maps memory dynamically
From: Roman Gushchin @ 2018-08-02 21:27 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel-team, Roman Gushchin, Alexei Starovoitov,
Daniel Borkmann
In-Reply-To: <20180802212730.18579-1-guro@fb.com>
This commits extends existing bpf maps memory charging API
to support dynamic charging/uncharging.
This is required to account memory used by maps,
if all entries are created dynamically after
the map initialization.
Signed-off-by: Roman Gushchin <guro@fb.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Martin KaFai Lau <kafai@fb.com>
---
include/linux/bpf.h | 2 ++
kernel/bpf/syscall.c | 58 ++++++++++++++++++++++++++++++++++++++--------------
2 files changed, 45 insertions(+), 15 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 5b5ad95cf339..5a4a256473c3 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -435,6 +435,8 @@ struct bpf_map * __must_check bpf_map_inc(struct bpf_map *map, bool uref);
void bpf_map_put_with_uref(struct bpf_map *map);
void bpf_map_put(struct bpf_map *map);
int bpf_map_precharge_memlock(u32 pages);
+int bpf_map_charge_memlock(struct bpf_map *map, u32 pages);
+void bpf_map_uncharge_memlock(struct bpf_map *map, u32 pages);
void *bpf_map_area_alloc(size_t size, int numa_node);
void bpf_map_area_free(void *base);
void bpf_map_init_from_attr(struct bpf_map *map, union bpf_attr *attr);
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index a31a1ba0f8ea..7958252a4d29 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -181,32 +181,60 @@ int bpf_map_precharge_memlock(u32 pages)
return 0;
}
-static int bpf_map_charge_memlock(struct bpf_map *map)
+static int bpf_charge_memlock(struct user_struct *user, u32 pages)
{
- struct user_struct *user = get_current_user();
- unsigned long memlock_limit;
+ unsigned long memlock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
- memlock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
+ if (atomic_long_add_return(pages, &user->locked_vm) > memlock_limit) {
+ atomic_long_sub(pages, &user->locked_vm);
+ return -EPERM;
+ }
+ return 0;
+}
- atomic_long_add(map->pages, &user->locked_vm);
+static void bpf_uncharge_memlock(struct user_struct *user, u32 pages)
+{
+ atomic_long_sub(pages, &user->locked_vm);
+}
+
+static int bpf_map_init_memlock(struct bpf_map *map)
+{
+ struct user_struct *user = get_current_user();
+ int ret;
- if (atomic_long_read(&user->locked_vm) > memlock_limit) {
- atomic_long_sub(map->pages, &user->locked_vm);
+ ret = bpf_charge_memlock(user, map->pages);
+ if (ret) {
free_uid(user);
- return -EPERM;
+ return ret;
}
map->user = user;
- return 0;
+ return ret;
}
-static void bpf_map_uncharge_memlock(struct bpf_map *map)
+static void bpf_map_release_memlock(struct bpf_map *map)
{
struct user_struct *user = map->user;
-
- atomic_long_sub(map->pages, &user->locked_vm);
+ bpf_uncharge_memlock(user, map->pages);
free_uid(user);
}
+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;
+}
+
static int bpf_map_alloc_id(struct bpf_map *map)
{
int id;
@@ -256,7 +284,7 @@ static void bpf_map_free_deferred(struct work_struct *work)
{
struct bpf_map *map = container_of(work, struct bpf_map, work);
- bpf_map_uncharge_memlock(map);
+ bpf_map_release_memlock(map);
security_bpf_map_free(map);
/* implementation dependent freeing */
map->ops->map_free(map);
@@ -492,7 +520,7 @@ static int map_create(union bpf_attr *attr)
if (err)
goto free_map_nouncharge;
- err = bpf_map_charge_memlock(map);
+ err = bpf_map_init_memlock(map);
if (err)
goto free_map_sec;
@@ -515,7 +543,7 @@ static int map_create(union bpf_attr *attr)
return err;
free_map:
- bpf_map_uncharge_memlock(map);
+ bpf_map_release_memlock(map);
free_map_sec:
security_bpf_map_free(map);
free_map_nouncharge:
--
2.14.4
^ permalink raw reply related
* [PATCH v7 bpf-next 00/14] bpf: cgroup local storage
From: Roman Gushchin @ 2018-08-02 21:27 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel-team, Roman Gushchin, Alexei Starovoitov,
Martin KaFai Lau
This patchset implements cgroup local storage for bpf programs.
The main idea is to provide a fast accessible memory for storing
various per-cgroup data, e.g. number of transmitted packets.
Cgroup local storage looks as a special type of map for userspace,
and is accessible using generic bpf maps API for reading and
updating of the data. The (cgroup inode id, attachment type) pair
is used as a map key.
A user can't create new entries or destroy existing entries;
it happens automatically when a user attaches/detaches a bpf program
to a cgroup.
>From a bpf program's point of view, cgroup storage is accessible
without lookup using the special get_local_storage() helper function.
It takes a map fd as an argument. It always returns a valid pointer
to the corresponding memory area.
To implement such a lookup-free access a pointer to the cgroup
storage is saved for an attachment of a bpf program to a cgroup,
if required by the program. Before running the program, it's saved
in a special global per-cpu variable, which is accessible from the
get_local_storage() helper.
This patchset implement only cgroup local storage, however the API
is intentionally made extensible to support other local storage types
further: e.g. thread local storage, socket local storage, etc.
v7->v6:
- fixed a use-after-free bug, caused by not clearing
prog->aux->cgroup_storage pointer after releasing the map
v6->v5:
- fixed an error with returning -EINVAL instead of a pointer
v5->v4:
- fixed an issue in verifier (test that flags == 0 properly)
- added a corresponding test
- added a note about synchronization, sync docs to tools/uapi/...
- switched the cgroup test to use XADD
- added a check for attr->max_entries to be 0, and atter->max_flags
to be sane
- use bpf_uncharge_memlock() in bpf_uncharge_memlock()
- rebased to bpf-next
v4->v3:
- fixed a leak in cgroup attachment code (discovered by Daniel)
- cgroup storage map will be released if the corresponding
bpf program failed to load by any reason
- introduced bpf_uncharge_memlock() helper
v3->v2:
- fixed more build and sparse issues
- rebased to bpf-next
v2->v1:
- fixed build issues
- removed explicit rlimit calls in patch 14
- rebased to bpf-next
Signed-off-by: Roman Gushchin <guro@fb.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Martin KaFai Lau <kafai@fb.com>
Roman Gushchin (14):
bpf: add ability to charge bpf maps memory dynamically
bpf: introduce cgroup storage maps
bpf: pass a pointer to a cgroup storage using pcpu variable
bpf: allocate cgroup storage entries on attaching bpf programs
bpf: extend bpf_prog_array to store pointers to the cgroup storage
bpf/verifier: introduce BPF_PTR_TO_MAP_VALUE
bpf: don't allow create maps of cgroup local storages
bpf: introduce the bpf_get_local_storage() helper function
bpf: sync bpf.h to tools/
bpftool: add support for CGROUP_STORAGE maps
bpf/test_run: support cgroup local storage
selftests/bpf: add verifier cgroup storage tests
selftests/bpf: add a cgroup storage test
samples/bpf: extend test_cgrp2_attach2 test to use cgroup storage
drivers/media/rc/bpf-lirc.c | 10 +-
include/linux/bpf-cgroup.h | 54 ++++
include/linux/bpf.h | 25 +-
include/linux/bpf_types.h | 3 +
include/uapi/linux/bpf.h | 27 +-
kernel/bpf/Makefile | 1 +
kernel/bpf/cgroup.c | 58 +++-
kernel/bpf/core.c | 77 ++---
kernel/bpf/helpers.c | 20 ++
kernel/bpf/local_storage.c | 378 ++++++++++++++++++++++
kernel/bpf/map_in_map.c | 3 +-
kernel/bpf/syscall.c | 61 +++-
kernel/bpf/verifier.c | 38 ++-
net/bpf/test_run.c | 13 +-
net/core/filter.c | 23 +-
samples/bpf/test_cgrp2_attach2.c | 21 +-
tools/bpf/bpftool/map.c | 1 +
tools/include/uapi/linux/bpf.h | 27 +-
tools/testing/selftests/bpf/Makefile | 3 +-
tools/testing/selftests/bpf/bpf_helpers.h | 2 +
tools/testing/selftests/bpf/test_cgroup_storage.c | 130 ++++++++
tools/testing/selftests/bpf/test_verifier.c | 140 +++++++-
22 files changed, 1029 insertions(+), 86 deletions(-)
create mode 100644 kernel/bpf/local_storage.c
create mode 100644 tools/testing/selftests/bpf/test_cgroup_storage.c
--
2.14.4
^ permalink raw reply
* Re: KASAN: use-after-free Read in bpf_cgroup_storage_release
From: Roman Gushchin @ 2018-08-02 21:25 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: syzbot, ast, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <1b3dde38-549e-43ed-d3f6-18b451444d2f@iogearbox.net>
On Thu, Aug 02, 2018 at 09:23:00PM +0200, Daniel Borkmann wrote:
> [ +Roman ]
>
> On 08/02/2018 07:59 PM, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: fc2a3b5dd618 Merge branch 'bpf-cgroup-local-storage'
> > git tree: bpf-next
> > console output: https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_log.txt-3Fx-3D17a6a1c8400000&d=DwIDaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=jJYgtDM7QT-W-Fz_d29HYQ&m=EDSyTXUjQWi0Wr-pal_Z622tnk3UnxrZ318k9Tct4wQ&s=kNpA8CkCvXgMPDNNfqgkqDlGShzYMrSvH1AWBdBslJo&e=
> > kernel config: https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_.config-3Fx-3D3bfcc1651962483&d=DwIDaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=jJYgtDM7QT-W-Fz_d29HYQ&m=EDSyTXUjQWi0Wr-pal_Z622tnk3UnxrZ318k9Tct4wQ&s=PYjD3Jqpwgzv3cBV64k8EAbXwdolWkrrrcanCfJU6KQ&e=
> > dashboard link: https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_bug-3Fextid-3D25554ab865a12b51c66f&d=DwIDaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=jJYgtDM7QT-W-Fz_d29HYQ&m=EDSyTXUjQWi0Wr-pal_Z622tnk3UnxrZ318k9Tct4wQ&s=FQHY4B4Ok0SJh_C-lkToT7mX_Ehj3NSHe6Fe1UiL--Y&e=
> > compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> > syzkaller repro:https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_repro.syz-3Fx-3D12c4b9b4400000&d=DwIDaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=jJYgtDM7QT-W-Fz_d29HYQ&m=EDSyTXUjQWi0Wr-pal_Z622tnk3UnxrZ318k9Tct4wQ&s=38j2eoBTEgFiU2FlYHK86YXiVNEjxV6n3ug4tlAZ3MQ&e=
> > C reproducer: https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_repro.c-3Fx-3D13e9d6f0400000&d=DwIDaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=jJYgtDM7QT-W-Fz_d29HYQ&m=EDSyTXUjQWi0Wr-pal_Z622tnk3UnxrZ318k9Tct4wQ&s=R75neIjoG9ODJgTDAUAfWqORwwOVX0k_cz7NsKyF6qw&e=
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+25554ab865a12b51c66f@syzkaller.appspotmail.com
> >
> > ==================================================================
> > BUG: KASAN: use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline]
> > BUG: KASAN: use-after-free in do_raw_spin_lock+0x1c0/0x200 kernel/locking/spinlock_debug.c:112
> > Read of size 4 at addr ffff8801c4723644 by task syz-executor865/9746
> >
> > CPU: 0 PID: 9746 Comm: syz-executor865 Not tainted 4.18.0-rc5+ #68
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> > Call Trace:
> > __dump_stack lib/dump_stack.c:77 [inline]
> > dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
> > print_address_description+0x6c/0x20b mm/kasan/report.c:256
> > kasan_report_error mm/kasan/report.c:354 [inline]
> > kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
> > __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
> > debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline]
> > do_raw_spin_lock+0x1c0/0x200 kernel/locking/spinlock_debug.c:112
> > __raw_spin_lock_bh include/linux/spinlock_api_smp.h:136 [inline]
> > _raw_spin_lock_bh+0x39/0x40 kernel/locking/spinlock.c:168
> > spin_lock_bh include/linux/spinlock.h:315 [inline]
> > bpf_cgroup_storage_release+0x2c/0x110 kernel/bpf/local_storage.c:276
> > free_used_maps+0x81/0x200 kernel/bpf/syscall.c:961
> > bpf_prog_load+0x17ba/0x1c90 kernel/bpf/syscall.c:1414
> > __do_sys_bpf kernel/bpf/syscall.c:2338 [inline]
> > __se_sys_bpf kernel/bpf/syscall.c:2300 [inline]
> > __x64_sys_bpf+0x36c/0x510 kernel/bpf/syscall.c:2300
> > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
So, it looks like we drop the last refcount on local storage map
from release_maps() and schedule bpf_map_free_deferred(), which
runs prior to bpf_cgroup_storage_release() in free_used_maps().
If so, here is the fix:
diff --git a/kernel/bpf/local_storage.c b/kernel/bpf/local_storage.c
index cd0b115c2395..fc4e37f68f2a 100644
--- a/kernel/bpf/local_storage.c
+++ b/kernel/bpf/local_storage.c
@@ -277,6 +277,7 @@ void bpf_cgroup_storage_release(struct bpf_prog *prog, struct bpf_map *_map)
if (map->prog == prog) {
WARN_ON(prog->aux->cgroup_storage != _map);
map->prog = NULL;
+ prog->aux->cgroup_storage = NULL;
}
spin_unlock_bh(&map->lock);
}
--
I'll post an updated version (v7) in few minutes.
Thanks to syzbot team for the report!
^ permalink raw reply related
* Re: linux-next: Tree for Aug 2 (netfilter: tproxy)
From: Máté Eckl @ 2018-08-02 19:05 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, Linux-Next Mailing List,
Linux Kernel Mailing List, netdev@vger.kernel.org,
netfilter-devel, coreteam, pablo
In-Reply-To: <0185f82e-4bf5-6c6c-a131-ba2c0197c9a0@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 627 bytes --]
Hi Randy,
Thanks for reporting!
Please find the patch attached.
Regards,
Mate
On Thu, Aug 02, 2018 at 09:28:16AM -0700, Randy Dunlap wrote:
> On 08/02/2018 02:31 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20180801:
> >
>
> on i386:
>
> ../net/netfilter/nft_tproxy.c: In function 'nft_tproxy_init':
> ../net/netfilter/nft_tproxy.c:237:3: error: implicit declaration of function 'nf_defrag_ipv6_enable' [-Werror=implicit-function-declaration]
> err = nf_defrag_ipv6_enable(ctx->net);
>
>
> Full randconfig file is attached.
>
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
>
> --
> ~Randy
[-- Attachment #2: 0001-netfilter-nft_tproxy-Add-missing-config-check.patch --]
[-- Type: text/plain, Size: 1560 bytes --]
>From 2c3a7d3209ed5e539ecd69192fc0f4186fdc7d99 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?M=C3=A1t=C3=A9=20Eckl?= <ecklm94@gmail.com>
Date: Thu, 2 Aug 2018 20:46:13 +0200
Subject: [PATCH] netfilter: nft_tproxy: Add missing config check
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
A config check was missing form the code when using
nf_defrag_ipv6_enable with NFT_TPROXY != n and NF_DEFRAG_IPV6 = n and
this caused the following error in case of :
../net/netfilter/nft_tproxy.c: In function 'nft_tproxy_init':
../net/netfilter/nft_tproxy.c:237:3: error: implicit declaration of function
+'nf_defrag_ipv6_enable' [-Werror=implicit-function-declaration]
err = nf_defrag_ipv6_enable(ctx->net);
This patch adds a check for NF_TABLES_IPV6 when NF_DEFRAG_IPV6 is
selected by Kconfig.
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Fixes: 4ed8eb6570a4 ("netfilter: nf_tables: Add native tproxy support")
Signed-off-by: Máté Eckl <ecklm94@gmail.com>
---
net/netfilter/nft_tproxy.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/netfilter/nft_tproxy.c b/net/netfilter/nft_tproxy.c
index c6845f7baa08..eff99dffc842 100644
--- a/net/netfilter/nft_tproxy.c
+++ b/net/netfilter/nft_tproxy.c
@@ -234,9 +234,11 @@ static int nft_tproxy_init(const struct nft_ctx *ctx,
err = nf_defrag_ipv4_enable(ctx->net);
if (err)
return err;
+#if IS_ENABLED(CONFIG_NF_TABLES_IPV6)
err = nf_defrag_ipv6_enable(ctx->net);
if (err)
return err;
+#endif
break;
default:
return -EOPNOTSUPP;
--
ecklm
^ permalink raw reply related
* RE: Microsoft Ignite - 2018
From: Lisa Parker @ 2018-08-02 18:52 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]
Hello,
I hope you're doing well!
I am following up with you on the below since I have not heard back from
you. Please let me know if you would like to get more information on the
same.
Looking forward to hearing from you.
Best Wishes,
Lisa
From: Lisa Parker [mailto:lisa.parker@pre-conferencelist.com]
Sent: 30 July 2018 13:15
To: 'netdev@vger.kernel.org'
Subject: Microsoft Ignite - 2018
Hi,
I hope you and your team must be well prepared for the event Microsoft
Ignite - held on 09/24/2018 - 09/28/2018.
I am checking in, if you would like to drive more traffic to your booth? If
yes, we can help you with the current registered attendee list with the
complete contact information (including emails and phone numbers).
Please feel free to get back to me if you are interested in getting more
information on the total count and pricing options.
Best Wishes,
Lisa Parker
Events Specialist
If you are no longer interested, please replay back with "unsubscribe" as
sub line
[-- Attachment #2: Type: text/html, Size: 5597 bytes --]
^ permalink raw reply
* Re: [pull request][net-next 00/10] Mellanox, mlx5 and devlink updates 2018-07-31
From: David Miller @ 2018-08-02 18:04 UTC (permalink / raw)
To: jakub.kicinski; +Cc: petrm, saeedm, netdev, jiri, alexander.duyck, helgaas
In-Reply-To: <20180802101112.78b1df4b@cakuba.netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Thu, 2 Aug 2018 10:11:12 -0700
> On Thu, 02 Aug 2018 11:29:12 +0300, Petr Machata wrote:
>> Could you please clarify your remark?
>
> Oh, I think David meant the patches I was objecting to a while ago,
> which were doing buffer configuration via the DCB API.
Exactly.
^ permalink raw reply
* KASAN: use-after-free Read in bpf_cgroup_storage_release
From: syzbot @ 2018-08-02 17:59 UTC (permalink / raw)
To: ast, daniel, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: fc2a3b5dd618 Merge branch 'bpf-cgroup-local-storage'
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=17a6a1c8400000
kernel config: https://syzkaller.appspot.com/x/.config?x=3bfcc1651962483
dashboard link: https://syzkaller.appspot.com/bug?extid=25554ab865a12b51c66f
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=12c4b9b4400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13e9d6f0400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+25554ab865a12b51c66f@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in debug_spin_lock_before
kernel/locking/spinlock_debug.c:83 [inline]
BUG: KASAN: use-after-free in do_raw_spin_lock+0x1c0/0x200
kernel/locking/spinlock_debug.c:112
Read of size 4 at addr ffff8801c4723644 by task syz-executor865/9746
CPU: 0 PID: 9746 Comm: syz-executor865 Not tainted 4.18.0-rc5+ #68
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
__asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline]
do_raw_spin_lock+0x1c0/0x200 kernel/locking/spinlock_debug.c:112
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:136 [inline]
_raw_spin_lock_bh+0x39/0x40 kernel/locking/spinlock.c:168
spin_lock_bh include/linux/spinlock.h:315 [inline]
bpf_cgroup_storage_release+0x2c/0x110 kernel/bpf/local_storage.c:276
free_used_maps+0x81/0x200 kernel/bpf/syscall.c:961
bpf_prog_load+0x17ba/0x1c90 kernel/bpf/syscall.c:1414
__do_sys_bpf kernel/bpf/syscall.c:2338 [inline]
__se_sys_bpf kernel/bpf/syscall.c:2300 [inline]
__x64_sys_bpf+0x36c/0x510 kernel/bpf/syscall.c:2300
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4490d9
Code: e8 8c bb 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 4b 00 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f6096d1ace8 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
RAX: ffffffffffffffda RBX: 00000000006e5a08 RCX: 00000000004490d9
RDX: 0000000000000048 RSI: 000000002001a840 RDI: 0000000000000005
RBP: 00000000006e5a00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006e5a0c
R13: 00007fffd579e24f R14: 00007f6096d1b9c0 R15: 0000000000000019
Allocated by task 9746:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
kmem_cache_alloc_node_trace+0x150/0x770 mm/slab.c:3663
kmalloc_node include/linux/slab.h:551 [inline]
cgroup_storage_map_alloc+0x26d/0x400 kernel/bpf/local_storage.c:209
find_and_alloc_map kernel/bpf/syscall.c:129 [inline]
map_create+0x37f/0xe20 kernel/bpf/syscall.c:481
__do_sys_bpf kernel/bpf/syscall.c:2323 [inline]
__se_sys_bpf kernel/bpf/syscall.c:2300 [inline]
__x64_sys_bpf+0x303/0x510 kernel/bpf/syscall.c:2300
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 19:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xd9/0x260 mm/slab.c:3813
cgroup_storage_map_free+0x16e/0x210 kernel/bpf/local_storage.c:234
bpf_map_free_deferred+0xba/0xf0 kernel/bpf/syscall.c:290
process_one_work+0xc73/0x1ba0 kernel/workqueue.c:2153
worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
kthread+0x345/0x410 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
The buggy address belongs to the object at ffff8801c4723540
which belongs to the cache kmalloc-512 of size 512
The buggy address is located 260 bytes inside of
512-byte region [ffff8801c4723540, ffff8801c4723740)
The buggy address belongs to the page:
page:ffffea000711c8c0 count:1 mapcount:0 mapping:ffff8801dac00940
index:0xffff8801c4723a40
flags: 0x2fffc0000000100(slab)
raw: 02fffc0000000100 ffffea0007299088 ffffea00072247c8 ffff8801dac00940
raw: ffff8801c4723a40 ffff8801c4723040 0000000100000004 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801c4723500: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
ffff8801c4723580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8801c4723600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8801c4723680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801c4723700: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: KASAN: use-after-free Read in bpf_cgroup_storage_release
From: Daniel Borkmann @ 2018-08-02 19:23 UTC (permalink / raw)
To: syzbot, ast, linux-kernel, netdev, syzkaller-bugs, guro
In-Reply-To: <000000000000f3b1570572779079@google.com>
[ +Roman ]
On 08/02/2018 07:59 PM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: fc2a3b5dd618 Merge branch 'bpf-cgroup-local-storage'
> git tree: bpf-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=17a6a1c8400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=3bfcc1651962483
> dashboard link: https://syzkaller.appspot.com/bug?extid=25554ab865a12b51c66f
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=12c4b9b4400000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13e9d6f0400000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+25554ab865a12b51c66f@syzkaller.appspotmail.com
>
> ==================================================================
> BUG: KASAN: use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline]
> BUG: KASAN: use-after-free in do_raw_spin_lock+0x1c0/0x200 kernel/locking/spinlock_debug.c:112
> Read of size 4 at addr ffff8801c4723644 by task syz-executor865/9746
>
> CPU: 0 PID: 9746 Comm: syz-executor865 Not tainted 4.18.0-rc5+ #68
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
> print_address_description+0x6c/0x20b mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
> __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
> debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline]
> do_raw_spin_lock+0x1c0/0x200 kernel/locking/spinlock_debug.c:112
> __raw_spin_lock_bh include/linux/spinlock_api_smp.h:136 [inline]
> _raw_spin_lock_bh+0x39/0x40 kernel/locking/spinlock.c:168
> spin_lock_bh include/linux/spinlock.h:315 [inline]
> bpf_cgroup_storage_release+0x2c/0x110 kernel/bpf/local_storage.c:276
> free_used_maps+0x81/0x200 kernel/bpf/syscall.c:961
> bpf_prog_load+0x17ba/0x1c90 kernel/bpf/syscall.c:1414
> __do_sys_bpf kernel/bpf/syscall.c:2338 [inline]
> __se_sys_bpf kernel/bpf/syscall.c:2300 [inline]
> __x64_sys_bpf+0x36c/0x510 kernel/bpf/syscall.c:2300
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x4490d9
> Code: e8 8c bb 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 4b 00 fc ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007f6096d1ace8 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
> RAX: ffffffffffffffda RBX: 00000000006e5a08 RCX: 00000000004490d9
> RDX: 0000000000000048 RSI: 000000002001a840 RDI: 0000000000000005
> RBP: 00000000006e5a00 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006e5a0c
> R13: 00007fffd579e24f R14: 00007f6096d1b9c0 R15: 0000000000000019
>
> Allocated by task 9746:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
> kmem_cache_alloc_node_trace+0x150/0x770 mm/slab.c:3663
> kmalloc_node include/linux/slab.h:551 [inline]
> cgroup_storage_map_alloc+0x26d/0x400 kernel/bpf/local_storage.c:209
> find_and_alloc_map kernel/bpf/syscall.c:129 [inline]
> map_create+0x37f/0xe20 kernel/bpf/syscall.c:481
> __do_sys_bpf kernel/bpf/syscall.c:2323 [inline]
> __se_sys_bpf kernel/bpf/syscall.c:2300 [inline]
> __x64_sys_bpf+0x303/0x510 kernel/bpf/syscall.c:2300
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Freed by task 19:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
> kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
> __cache_free mm/slab.c:3498 [inline]
> kfree+0xd9/0x260 mm/slab.c:3813
> cgroup_storage_map_free+0x16e/0x210 kernel/bpf/local_storage.c:234
> bpf_map_free_deferred+0xba/0xf0 kernel/bpf/syscall.c:290
> process_one_work+0xc73/0x1ba0 kernel/workqueue.c:2153
> worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
> kthread+0x345/0x410 kernel/kthread.c:246
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
>
> The buggy address belongs to the object at ffff8801c4723540
> which belongs to the cache kmalloc-512 of size 512
> The buggy address is located 260 bytes inside of
> 512-byte region [ffff8801c4723540, ffff8801c4723740)
> The buggy address belongs to the page:
> page:ffffea000711c8c0 count:1 mapcount:0 mapping:ffff8801dac00940 index:0xffff8801c4723a40
> flags: 0x2fffc0000000100(slab)
> raw: 02fffc0000000100 ffffea0007299088 ffffea00072247c8 ffff8801dac00940
> raw: ffff8801c4723a40 ffff8801c4723040 0000000100000004 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8801c4723500: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
> ffff8801c4723580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ffff8801c4723600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff8801c4723680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8801c4723700: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
> ==================================================================
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH net-next] net: Fix coding style in skb_push()
From: David Miller @ 2018-08-02 17:30 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, arjun
In-Reply-To: <1533204292-10428-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Thu, 2 Aug 2018 15:34:52 +0530
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied.
^ permalink raw reply
* RE: Security enhancement proposal for kernel TLS
From: Vakul Garg @ 2018-08-02 17:23 UTC (permalink / raw)
To: Dave Watson; +Cc: netdev@vger.kernel.org, Peter Doliwa, Boris Pismenny
In-Reply-To: <20180801204647.GA6180@davejwatson-mba.dhcp.thefacebook.com>
> -----Original Message-----
> From: Dave Watson [mailto:davejwatson@fb.com]
> Sent: Thursday, August 2, 2018 2:17 AM
> To: Vakul Garg <vakul.garg@nxp.com>
> Cc: netdev@vger.kernel.org; Peter Doliwa <peter.doliwa@nxp.com>; Boris
> Pismenny <borisp@mellanox.com>
> Subject: Re: Security enhancement proposal for kernel TLS
>
> On 07/31/18 10:45 AM, Vakul Garg wrote:
> > > > IIUC, with the upstream implementation of tls record layer in
> > > > kernel, the decryption of tls FINISHED message happens in kernel.
> > > > Therefore the keys are already being sent to kernel tls socket
> > > > before handshake is
> > > completed.
> > >
> > > This is incorrect.
> >
> > Let us first reach a common ground on this.
> >
> > The kernel TLS implementation can decrypt only after setting the keys on
> the socket.
> > The TLS message 'finished' (which is encrypted) is received after receiving
> 'CCS'
> > message. After the user space TLS library receives CCS message, it
> > sets the keys on kernel TLS socket. Therefore, the next message in the
> > socket receive queue which is TLS finished gets decrypted in kernel only.
> >
> > Please refer to following Boris's patch on openssl. The commit log says:
> > " We choose to set this option at the earliest - just after CCS is complete".
>
> I agree that Boris' patch does what you say it does - it sets keys immediately
> after CCS instead of after FINISHED message. I disagree that the kernel tls
> implementation currently requires that specific ordering, nor do I think that it
> should require that ordering.
The current kernel implementation assumes record sequence number to start from '0'.
If keys have to be set after FINISHED message, then record sequence number need to
be communicated from user space TLS stack to kernel. IIRC, sequence number is not
part of the interface through which key is transferred.
^ permalink raw reply
* RE: [PATCH net-next] net/tls: Mark the end in scatterlist table
From: Vakul Garg @ 2018-08-02 17:23 UTC (permalink / raw)
To: Dave Watson
Cc: netdev@vger.kernel.org, borisp@mellanox.com, aviadye@mellanox.com,
davem@davemloft.net
In-Reply-To: <20180802171710.GA71279@sharrissfo-mbp.dhcp.thefacebook.com>
> -----Original Message-----
> From: Dave Watson [mailto:davejwatson@fb.com]
> Sent: Thursday, August 2, 2018 10:47 PM
> To: Vakul Garg <vakul.garg@nxp.com>
> Cc: netdev@vger.kernel.org; borisp@mellanox.com;
> aviadye@mellanox.com; davem@davemloft.net
> Subject: Re: [PATCH net-next] net/tls: Mark the end in scatterlist table
>
> On 08/02/18 05:05 PM, Vakul Garg wrote:
> > In case zerocopy_from_iter() fails, 'end' won't get marked.
> > So fallback path is fine.
> >
> > > Which codepath is calling sg_nents()?
> >
> > While testing my WIP implementation of combined dynamic memory
> > allocation for (aead_req || sgin || sgout || aad || iv), I was getting
> random kernel crashes.
> > To debug it I had inserted sg_nents() in my code. The KASAN then
> > immediately complained that sg_nents() went beyond the allocated
> memory for scatterlist.
> > This led me to find that scatterlist table end has not been marked.
> >
>
> If this isn't causing KASAN issues for the existing code, it probably makes
> more sense to put in a future series with that WIP work then.
Isn't using a sgtable with unmarked end already bad and should be fixed?
Crypto hardware accelerator drivers could be broken while using sg lists with
unmarked end.
^ permalink raw reply
* Re: linux-next: Tree for Aug 2 (netfilter: tproxy)
From: Pablo Neira Ayuso @ 2018-08-02 19:12 UTC (permalink / raw)
To: Máté Eckl
Cc: Randy Dunlap, Stephen Rothwell, Linux-Next Mailing List,
Linux Kernel Mailing List, netdev@vger.kernel.org,
netfilter-devel, coreteam
In-Reply-To: <20180802191011.ibm2lknbzwm7zjoc@sch.bme.hu>
On Thu, Aug 02, 2018 at 09:10:11PM +0200, Máté Eckl wrote:
> On Thu, Aug 02, 2018 at 09:05:57PM +0200, Máté Eckl wrote:
> > Hi Randy,
> >
> > Thanks for reporting!
> >
> > Please find the patch attached.
>
> Sorry I made an error in the commit message... See the fix below.
Please, resubmit using git-send-mail so we make sure patchwork catches
this patch.
Cc'ing Randy when sending this to nf-devel, who has reported this,
that should sufficient unless he or Stephen say otherwise.
Thanks.
^ permalink raw reply
* Re: linux-next: Tree for Aug 2 (netfilter: tproxy)
From: Máté Eckl @ 2018-08-02 19:10 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, Linux-Next Mailing List,
Linux Kernel Mailing List, netdev@vger.kernel.org,
netfilter-devel, coreteam, pablo
In-Reply-To: <20180802190557.sha6wer6gkdgrd6i@sch.bme.hu>
On Thu, Aug 02, 2018 at 09:05:57PM +0200, Máté Eckl wrote:
> Hi Randy,
>
> Thanks for reporting!
>
> Please find the patch attached.
Sorry I made an error in the commit message... See the fix below.
>
> Regards,
> Mate
>
> On Thu, Aug 02, 2018 at 09:28:16AM -0700, Randy Dunlap wrote:
> > On 08/02/2018 02:31 AM, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Changes since 20180801:
> > >
> >
> > on i386:
> >
> > ../net/netfilter/nft_tproxy.c: In function 'nft_tproxy_init':
> > ../net/netfilter/nft_tproxy.c:237:3: error: implicit declaration of function 'nf_defrag_ipv6_enable' [-Werror=implicit-function-declaration]
> > err = nf_defrag_ipv6_enable(ctx->net);
> >
> >
> > Full randconfig file is attached.
> >
> > Reported-by: Randy Dunlap <rdunlap@infradead.org>
> >
> > --
> > ~Randy
> From 2c3a7d3209ed5e539ecd69192fc0f4186fdc7d99 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?M=C3=A1t=C3=A9=20Eckl?= <ecklm94@gmail.com>
> Date: Thu, 2 Aug 2018 20:46:13 +0200
> Subject: [PATCH] netfilter: nft_tproxy: Add missing config check
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> A config check was missing form the code when using
> nf_defrag_ipv6_enable with NFT_TPROXY != n and NF_DEFRAG_IPV6 = n and
> this caused the following error in case of :
Please change the last line to:
this caused the following error:
>
> ../net/netfilter/nft_tproxy.c: In function 'nft_tproxy_init':
> ../net/netfilter/nft_tproxy.c:237:3: error: implicit declaration of function
> +'nf_defrag_ipv6_enable' [-Werror=implicit-function-declaration]
> err = nf_defrag_ipv6_enable(ctx->net);
>
> This patch adds a check for NF_TABLES_IPV6 when NF_DEFRAG_IPV6 is
> selected by Kconfig.
>
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Fixes: 4ed8eb6570a4 ("netfilter: nf_tables: Add native tproxy support")
> Signed-off-by: Máté Eckl <ecklm94@gmail.com>
> ---
> net/netfilter/nft_tproxy.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/netfilter/nft_tproxy.c b/net/netfilter/nft_tproxy.c
> index c6845f7baa08..eff99dffc842 100644
> --- a/net/netfilter/nft_tproxy.c
> +++ b/net/netfilter/nft_tproxy.c
> @@ -234,9 +234,11 @@ static int nft_tproxy_init(const struct nft_ctx *ctx,
> err = nf_defrag_ipv4_enable(ctx->net);
> if (err)
> return err;
> +#if IS_ENABLED(CONFIG_NF_TABLES_IPV6)
> err = nf_defrag_ipv6_enable(ctx->net);
> if (err)
> return err;
> +#endif
> break;
> default:
> return -EOPNOTSUPP;
> --
> ecklm
>
^ permalink raw reply
* Re: [PATCH net-next] net/tls: Mark the end in scatterlist table
From: Dave Watson @ 2018-08-02 17:17 UTC (permalink / raw)
To: Vakul Garg
Cc: netdev@vger.kernel.org, borisp@mellanox.com, aviadye@mellanox.com,
davem@davemloft.net
In-Reply-To: <DB7PR04MB42527E9FB192076FE7B1881D8B2C0@DB7PR04MB4252.eurprd04.prod.outlook.com>
On 08/02/18 05:05 PM, Vakul Garg wrote:
> In case zerocopy_from_iter() fails, 'end' won't get marked.
> So fallback path is fine.
>
> > Which codepath is calling sg_nents()?
>
> While testing my WIP implementation of combined dynamic memory allocation for
> (aead_req || sgin || sgout || aad || iv), I was getting random kernel crashes.
> To debug it I had inserted sg_nents() in my code. The KASAN then immediately
> complained that sg_nents() went beyond the allocated memory for scatterlist.
> This led me to find that scatterlist table end has not been marked.
>
If this isn't causing KASAN issues for the existing code, it probably
makes more sense to put in a future series with that WIP work then.
^ permalink raw reply
* Re: [pull request][net-next 00/10] Mellanox, mlx5 and devlink updates 2018-07-31
From: Jakub Kicinski @ 2018-08-02 17:11 UTC (permalink / raw)
To: Petr Machata; +Cc: David Miller, saeedm, netdev, jiri, alexander.duyck, helgaas
In-Reply-To: <wihtvodxjc7.fsf@dev-r-vrt-156.mtr.labs.mlnx>
On Thu, 02 Aug 2018 11:29:12 +0300, Petr Machata wrote:
> David Miller <davem@davemloft.net> writes:
>
> > From: Jakub Kicinski <jakub.kicinski@netronome.com>
> > Date: Wed, 1 Aug 2018 17:00:47 -0700
> >
> >> On Wed, 1 Aug 2018 14:52:45 -0700, Saeed Mahameed wrote:
> >>> - According to the discussion outcome, we are keeping the congestion control
> >>> setting as mlx5 device specific for the current HW generation.
> >>
> >> I still see queuing and marking based on queue level. You want to add
> >> a Qdisc that will mirror your HW's behaviour to offload, if you really
> >> believe this is not a subset of RED, why not... But devlink params?
> >
> > I totally agree, devlink seems like absolutely to wrong level and set
> > of interfaces to be doing this stuff.
> >
> > I will not pull these changes in and I probably should have not
> > accepted the DCB changes from the other day and they were sneakily
> > leading up to this crap.
>
> Are you talking about the recent additions of DCB helpers
> dcb_ieee_getapp_prio_dscp_mask_map() etc.?
>
> If yes, I can assure there were no sneaky intentions at all. I'm at a
> loss to understand the relation to mlx5 team's decision to use devlink
> for congestion control configuration.
>
> Could you please clarify your remark?
Oh, I think David meant the patches I was objecting to a while ago,
which were doing buffer configuration via the DCB API.
^ permalink raw reply
* Re: [PATCH] inet/connection_sock: prefer _THIS_IP_ to current_text_addr
From: Nick Desaulniers @ 2018-08-02 17:07 UTC (permalink / raw)
To: David S. Miller; +Cc: Nathan Chancellor, netdev, LKML
In-Reply-To: <20180801.184208.776886134692058469.davem@davemloft.net>
On Wed, Aug 1, 2018 at 6:42 PM David Miller <davem@davemloft.net> wrote:
>
> From: Nick Desaulniers <ndesaulniers@google.com>
> Date: Wed, 1 Aug 2018 14:57:59 -0700
>
> > - sk, what, when, current_text_addr());
> > + sk, what, when, (void *)_THIS_IP_);
>
> Is a fugly macro in all caps really better than a function()?
>
> I'm really surprised that _THIS_IP_ is being chosen over
> current_text_addr(), seriously.
See: https://lkml.org/lkml/2018/8/1/1689
I'm happy to rename it on your suggestion, after we've consolidated them.
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* RE: [PATCH net-next] net/tls: Mark the end in scatterlist table
From: Vakul Garg @ 2018-08-02 17:05 UTC (permalink / raw)
To: Dave Watson
Cc: netdev@vger.kernel.org, borisp@mellanox.com, aviadye@mellanox.com,
davem@davemloft.net
In-Reply-To: <20180802164633.GA66257@sharrissfo-mbp.dhcp.thefacebook.com>
> -----Original Message-----
> From: Dave Watson [mailto:davejwatson@fb.com]
> Sent: Thursday, August 2, 2018 10:17 PM
> To: Vakul Garg <vakul.garg@nxp.com>
> Cc: netdev@vger.kernel.org; borisp@mellanox.com;
> aviadye@mellanox.com; davem@davemloft.net
> Subject: Re: [PATCH net-next] net/tls: Mark the end in scatterlist table
>
> On 08/02/18 08:43 PM, Vakul Garg wrote:
> > Function zerocopy_from_iter() unmarks the 'end' in input sgtable while
> > adding new entries in it. The last entry in sgtable remained unmarked.
> > This results in KASAN error report on using apis like sg_nents().
> > Before returning, the function needs to mark the 'end' in the last
> > entry it adds.
> >
> > Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
>
> Looks good to me, it looks like the fallback path should unmark the end
> appropriately.
>
In case zerocopy_from_iter() fails, 'end' won't get marked.
So fallback path is fine.
> Which codepath is calling sg_nents()?
While testing my WIP implementation of combined dynamic memory allocation for
(aead_req || sgin || sgout || aad || iv), I was getting random kernel crashes.
To debug it I had inserted sg_nents() in my code. The KASAN then immediately
complained that sg_nents() went beyond the allocated memory for scatterlist.
This led me to find that scatterlist table end has not been marked.
> Acked-by: Dave Watson <davejwatson@fb.com>
^ permalink raw reply
* Re: [PATCH net-next] net/tls: Always get number of sg entries for skb to be decrypted
From: Dave Watson @ 2018-08-02 16:50 UTC (permalink / raw)
To: Vakul Garg; +Cc: netdev, borisp, aviadye, davem
In-Reply-To: <20180802162032.14689-1-vakul.garg@nxp.com>
On 08/02/18 09:50 PM, Vakul Garg wrote:
> Function decrypt_skb() made a bad assumption that number of sg entries
> required for mapping skb to be decrypted would always be less than
> MAX_SKB_FRAGS. The required count of sg entries for skb should always be
> calculated. If they cannot fit in local array sgin_arr[], allocate them
> from heap irrespective whether it is zero-copy case or otherwise. The
> change also benefits the non-zero copy case as we could use sgin_arr[]
> instead of always allocating sg entries from heap.
>
> Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
Looks great, thanks.
Reviewed-by: Dave Waston <davejwatson@fb.com>
^ permalink raw reply
* Re: [PATCH net-next] net/tls: Mark the end in scatterlist table
From: Dave Watson @ 2018-08-02 16:46 UTC (permalink / raw)
To: Vakul Garg; +Cc: netdev, borisp, aviadye, davem
In-Reply-To: <20180802151310.9007-1-vakul.garg@nxp.com>
On 08/02/18 08:43 PM, Vakul Garg wrote:
> Function zerocopy_from_iter() unmarks the 'end' in input sgtable while
> adding new entries in it. The last entry in sgtable remained unmarked.
> This results in KASAN error report on using apis like sg_nents(). Before
> returning, the function needs to mark the 'end' in the last entry it
> adds.
>
> Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
Looks good to me, it looks like the fallback path should unmark the
end appropriately.
Which codepath is calling sg_nents()?
Acked-by: Dave Watson <davejwatson@fb.com>
^ permalink raw reply
* Re: [Query]: DSA Understanding
From: Florian Fainelli @ 2018-08-02 16:24 UTC (permalink / raw)
To: Andrew Lunn, Lad, Prabhakar; +Cc: netdev
In-Reply-To: <20180802160539.GL19257@lunn.ch>
On 08/02/2018 09:05 AM, Andrew Lunn wrote:
>> I dont see any Reply's on the PC with tcpdump on PC
>
> So try ethool -S on the PC. Any packets dropped because of errors?
>
> Try turning off hardware checksums on the switch. ethtool -K.
Also make sure that cpsw is properly sending 64 bytes (including FCS)
packets to the switch, some switches will just discard packets when
packets are RUNT
--
Florian
^ permalink raw reply
* [PATCH net-next] net/socket: remove duplicated init code
From: Matthieu Baerts @ 2018-08-02 16:14 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Matthieu Baerts
This refactoring work has been started by David Howells in cdfbabfb2f0c
(net: Work around lockdep limitation in sockets that use sockets) but
the exact same day in 581319c58600 (net/socket: use per af lockdep
classes for sk queues), Paolo Abeni added new classes.
This reduces the amount of (nearly) duplicated code and eases the
addition of new socket types.
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
---
net/core/sock.c | 51 +++----------------------------------------------
1 file changed, 3 insertions(+), 48 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index 9c6ebbdfebf3..e31233f5ba39 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -250,58 +250,13 @@ static const char *const af_family_kern_clock_key_strings[AF_MAX+1] = {
_sock_locks("k-clock-")
};
static const char *const af_family_rlock_key_strings[AF_MAX+1] = {
- "rlock-AF_UNSPEC", "rlock-AF_UNIX" , "rlock-AF_INET" ,
- "rlock-AF_AX25" , "rlock-AF_IPX" , "rlock-AF_APPLETALK",
- "rlock-AF_NETROM", "rlock-AF_BRIDGE" , "rlock-AF_ATMPVC" ,
- "rlock-AF_X25" , "rlock-AF_INET6" , "rlock-AF_ROSE" ,
- "rlock-AF_DECnet", "rlock-AF_NETBEUI" , "rlock-AF_SECURITY" ,
- "rlock-AF_KEY" , "rlock-AF_NETLINK" , "rlock-AF_PACKET" ,
- "rlock-AF_ASH" , "rlock-AF_ECONET" , "rlock-AF_ATMSVC" ,
- "rlock-AF_RDS" , "rlock-AF_SNA" , "rlock-AF_IRDA" ,
- "rlock-AF_PPPOX" , "rlock-AF_WANPIPE" , "rlock-AF_LLC" ,
- "rlock-27" , "rlock-28" , "rlock-AF_CAN" ,
- "rlock-AF_TIPC" , "rlock-AF_BLUETOOTH", "rlock-AF_IUCV" ,
- "rlock-AF_RXRPC" , "rlock-AF_ISDN" , "rlock-AF_PHONET" ,
- "rlock-AF_IEEE802154", "rlock-AF_CAIF" , "rlock-AF_ALG" ,
- "rlock-AF_NFC" , "rlock-AF_VSOCK" , "rlock-AF_KCM" ,
- "rlock-AF_QIPCRTR", "rlock-AF_SMC" , "rlock-AF_XDP" ,
- "rlock-AF_MAX"
+ _sock_locks("rlock-")
};
static const char *const af_family_wlock_key_strings[AF_MAX+1] = {
- "wlock-AF_UNSPEC", "wlock-AF_UNIX" , "wlock-AF_INET" ,
- "wlock-AF_AX25" , "wlock-AF_IPX" , "wlock-AF_APPLETALK",
- "wlock-AF_NETROM", "wlock-AF_BRIDGE" , "wlock-AF_ATMPVC" ,
- "wlock-AF_X25" , "wlock-AF_INET6" , "wlock-AF_ROSE" ,
- "wlock-AF_DECnet", "wlock-AF_NETBEUI" , "wlock-AF_SECURITY" ,
- "wlock-AF_KEY" , "wlock-AF_NETLINK" , "wlock-AF_PACKET" ,
- "wlock-AF_ASH" , "wlock-AF_ECONET" , "wlock-AF_ATMSVC" ,
- "wlock-AF_RDS" , "wlock-AF_SNA" , "wlock-AF_IRDA" ,
- "wlock-AF_PPPOX" , "wlock-AF_WANPIPE" , "wlock-AF_LLC" ,
- "wlock-27" , "wlock-28" , "wlock-AF_CAN" ,
- "wlock-AF_TIPC" , "wlock-AF_BLUETOOTH", "wlock-AF_IUCV" ,
- "wlock-AF_RXRPC" , "wlock-AF_ISDN" , "wlock-AF_PHONET" ,
- "wlock-AF_IEEE802154", "wlock-AF_CAIF" , "wlock-AF_ALG" ,
- "wlock-AF_NFC" , "wlock-AF_VSOCK" , "wlock-AF_KCM" ,
- "wlock-AF_QIPCRTR", "wlock-AF_SMC" , "wlock-AF_XDP" ,
- "wlock-AF_MAX"
+ _sock_locks("wlock-")
};
static const char *const af_family_elock_key_strings[AF_MAX+1] = {
- "elock-AF_UNSPEC", "elock-AF_UNIX" , "elock-AF_INET" ,
- "elock-AF_AX25" , "elock-AF_IPX" , "elock-AF_APPLETALK",
- "elock-AF_NETROM", "elock-AF_BRIDGE" , "elock-AF_ATMPVC" ,
- "elock-AF_X25" , "elock-AF_INET6" , "elock-AF_ROSE" ,
- "elock-AF_DECnet", "elock-AF_NETBEUI" , "elock-AF_SECURITY" ,
- "elock-AF_KEY" , "elock-AF_NETLINK" , "elock-AF_PACKET" ,
- "elock-AF_ASH" , "elock-AF_ECONET" , "elock-AF_ATMSVC" ,
- "elock-AF_RDS" , "elock-AF_SNA" , "elock-AF_IRDA" ,
- "elock-AF_PPPOX" , "elock-AF_WANPIPE" , "elock-AF_LLC" ,
- "elock-27" , "elock-28" , "elock-AF_CAN" ,
- "elock-AF_TIPC" , "elock-AF_BLUETOOTH", "elock-AF_IUCV" ,
- "elock-AF_RXRPC" , "elock-AF_ISDN" , "elock-AF_PHONET" ,
- "elock-AF_IEEE802154", "elock-AF_CAIF" , "elock-AF_ALG" ,
- "elock-AF_NFC" , "elock-AF_VSOCK" , "elock-AF_KCM" ,
- "elock-AF_QIPCRTR", "elock-AF_SMC" , "elock-AF_XDP" ,
- "elock-AF_MAX"
+ _sock_locks("elock-")
};
/*
--
2.17.1
--
DISCLAIMER.
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify the
system manager. This message contains confidential information and is
intended only for the individual named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail. Please notify
the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited.
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox