Skip to contentSkip to conversation

Introduce bpf ID

PATCH Superseded Martin KaFai Lau 5 participants 23 messages May 31, 2017 – Jun 3, 2017

Subsystems (17)

v2 of 3 Superseded Latest is v3 →

lore
Share & tools
lore
#0 lore raw

v2 cover Introduce bpf ID

This patch series:
1) Introduce ID for both bpf_prog and bpf_map.
2) Add bpf commands to iterate the prog IDs and map IDs of the system.
3) Add bpf commands to get a prog/map fd from an ID
4) Add bpf command to get prog/map info from a fd. The prog/map info is a jump start in this patchset and it is not meant to be a complete list. They can be extended in the future patches.

v2:
Compiler warning fixes:
- Remove lockdep_is_held() usage. Add comment
to explain the lock situation instead.
- Add static for idr related variables
- Add __user to the uattr param in bpf_prog_get_info_by_fd() and bpf_map_get_info_by_fd().

Martin KaFai Lau (8):
bpf: Introduce bpf_prog ID
bpf: Introduce bpf_map ID
bpf: Add BPF_(PROG|MAP)_GET_NEXT_ID command
bpf: Add BPF_PROG_GET_FD_BY_ID
bpf: Add BPF_MAP_GET_FD_BY_ID
bpf: Add jited_len to struct bpf_prog
bpf: Add BPF_OBJ_GET_INFO_BY_FD
bpf: Test for bpf ID

 arch/arm64/net/bpf_jit_comp.c             |   1 +
 arch/powerpc/net/bpf_jit_comp64.c         |   1 +
 arch/s390/net/bpf_jit_comp.c              |   1 +
 arch/sparc/net/bpf_jit_comp_64.c          |   1 +
 arch/x86/net/bpf_jit_comp.c               |   1 +
 include/linux/bpf.h                       |   2 +
 include/linux/filter.h                    |   3 +-
 include/uapi/linux/bpf.h                  |  41 +++
 kernel/bpf/syscall.c                      | 433 ++++++++++++++++++++++++++++--
 tools/include/uapi/linux/bpf.h            |  41 +++
 tools/lib/bpf/bpf.c                       |  68 +++++
 tools/lib/bpf/bpf.h                       |   5 +
 tools/testing/selftests/bpf/Makefile      |   2 +-
 tools/testing/selftests/bpf/test_obj_id.c |  35 +++
 tools/testing/selftests/bpf/test_progs.c  | 191 +++++++++++++
 15 files changed, 798 insertions(+), 28 deletions(-)
 create mode 100644 tools/testing/selftests/bpf/test_obj_id.c
Signature · 1 line
2.9.3
#1 lore raw

PATCH v2 1/8 bpf: Introduce bpf_prog ID

This patch generates an unique ID for each BPF_PROG_LOAD-ed prog. It is worth to note that each BPF_PROG_LOAD-ed prog will have a different ID even they have the same bpf instructions.

The ID is generated by the existing idr_alloc_cyclic().
The ID is ranged from [1, INT_MAX). It is allocated in cyclic manner, so an ID will get reused every 2 billion BPF_PROG_LOAD.

The bpf_prog_alloc_id() is done after bpf_prog_select_runtime() because the jit process may have allocated a new prog. Hence, we need to ensure the value of pointer 'prog' will not be changed any more before storing the prog to the prog_idr.

After bpf_prog_select_runtime(), the prog is read-only. Hence, the id is stored in 'struct bpf_prog_aux'.

---
 include/linux/bpf.h  |  1 +
 kernel/bpf/syscall.c | 40 +++++++++++++++++++++++++++++++++++++++-
 2 files changed, 40 insertions(+), 1 deletion(-)
include/linux/bpf.h +1 -0
index 6bb38d76faf4..c2793a732edc 100644
@@ -171,6 +171,7 @@ struct bpf_prog_aux {
 	atomic_t refcnt;
 	u32 used_map_cnt;
 	u32 max_ctx_offset;
+	u32 id;
 	struct latch_tree_node ksym_tnode;
 	struct list_head ksym_lnode;
 	const struct bpf_verifier_ops *ops;
kernel/bpf/syscall.c +39 -1
index 265a0d854e33..4a936b08a4b0 100644
@@ -22,8 +22,11 @@
 #include <linux/filter.h>
 #include <linux/version.h>
 #include <linux/kernel.h>
+#include <linux/idr.h>
 
 DEFINE_PER_CPU(int, bpf_prog_active);
+static DEFINE_IDR(prog_idr);
+static DEFINE_SPINLOCK(prog_idr_lock);
 
 int sysctl_unprivileged_bpf_disabled __read_mostly;
 
@@ -650,6 +653,34 @@ static void bpf_prog_uncharge_memlock(struct bpf_prog *prog)
 	free_uid(user);
 }
 
+static int bpf_prog_alloc_id(struct bpf_prog *prog)
+{
+	int id;
+
+	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);
+
+	/* id is in [1, INT_MAX) */
+	if (WARN_ON_ONCE(!id))
+		return -ENOSPC;
+
+	return id > 0 ? 0 : id;
+}
+
+static void bpf_prog_free_id(struct bpf_prog *prog)
+{
+	/* cBPF to eBPF migrations are currently not in the idr store. */
+	if (!prog->aux->id)
+		return;
+
+	spin_lock_bh(&prog_idr_lock);
+	idr_remove(&prog_idr, prog->aux->id);
+	spin_unlock_bh(&prog_idr_lock);
+}
+
 static void __bpf_prog_put_rcu(struct rcu_head *rcu)
 {
 	struct bpf_prog_aux *aux = container_of(rcu, struct bpf_prog_aux, rcu);
@@ -663,6 +694,7 @@ void bpf_prog_put(struct bpf_prog *prog)
 {
 	if (atomic_dec_and_test(&prog->aux->refcnt)) {
 		trace_bpf_prog_put_rcu(prog);
+		bpf_prog_free_id(prog);
 		bpf_prog_kallsyms_del(prog);
 		call_rcu(&prog->aux->rcu, __bpf_prog_put_rcu);
 	}
@@ -855,15 +887,21 @@ static int bpf_prog_load(union bpf_attr *attr)
 	if (err < 0)
 		goto free_used_maps;
 
+	err = bpf_prog_alloc_id(prog);
+	if (err)
+		goto free_used_maps;
+
 	err = bpf_prog_new_fd(prog);
 	if (err < 0)
 		/* failed to allocate fd */
-		goto free_used_maps;
+		goto free_id;
 
 	bpf_prog_kallsyms_add(prog);
 	trace_bpf_prog_load(prog, err);
 	return err;
 
+free_id:
+	bpf_prog_free_id(prog);
 free_used_maps:
 	free_used_maps(prog->aux);
 free_prog:
Signature · 1 line
2.9.3
#2 lore raw

PATCH v2 2/8 bpf: Introduce bpf_map ID

In reply to Martin KaFai Lau

This patch generates an unique ID for each created bpf_map. The approach is similar to the earlier patch for bpf_prog ID.

It is worth to note that the bpf_map's ID and bpf_prog's ID are in two independent ID spaces and both have the same valid range:
[1, INT_MAX).

---
 include/linux/bpf.h  |  1 +
 kernel/bpf/syscall.c | 34 +++++++++++++++++++++++++++++++++-
 2 files changed, 34 insertions(+), 1 deletion(-)
include/linux/bpf.h +1 -0
index c2793a732edc..ea78d87cbc3e 100644
@@ -46,6 +46,7 @@ struct bpf_map {
 	u32 max_entries;
 	u32 map_flags;
 	u32 pages;
+	u32 id;
 	struct user_struct *user;
 	const struct bpf_map_ops *ops;
 	struct work_struct work;
kernel/bpf/syscall.c +33 -1
index 4a936b08a4b0..20f392d64f49 100644
@@ -27,6 +27,8 @@
 DEFINE_PER_CPU(int, bpf_prog_active);
 static DEFINE_IDR(prog_idr);
 static DEFINE_SPINLOCK(prog_idr_lock);
+static DEFINE_IDR(map_idr);
+static DEFINE_SPINLOCK(map_idr_lock);
 
 int sysctl_unprivileged_bpf_disabled __read_mostly;
 
@@ -117,6 +119,29 @@ static void bpf_map_uncharge_memlock(struct bpf_map *map)
 	free_uid(user);
 }
 
+static int bpf_map_alloc_id(struct bpf_map *map)
+{
+	int id;
+
+	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);
+
+	if (WARN_ON_ONCE(!id))
+		return -ENOSPC;
+
+	return id > 0 ? 0 : id;
+}
+
+static void bpf_map_free_id(struct bpf_map *map)
+{
+	spin_lock_bh(&map_idr_lock);
+	idr_remove(&map_idr, map->id);
+	spin_unlock_bh(&map_idr_lock);
+}
+
 /* called from workqueue */
 static void bpf_map_free_deferred(struct work_struct *work)
 {
@@ -141,6 +166,7 @@ static void bpf_map_put_uref(struct bpf_map *map)
 void bpf_map_put(struct bpf_map *map)
 {
 	if (atomic_dec_and_test(&map->refcnt)) {
+		bpf_map_free_id(map);
 		INIT_WORK(&map->work, bpf_map_free_deferred);
 		schedule_work(&map->work);
 	}
@@ -239,14 +265,20 @@ static int map_create(union bpf_attr *attr)
 	if (err)
 		goto free_map_nouncharge;
 
+	err = bpf_map_alloc_id(map);
+	if (err)
+		goto free_map;
+
 	err = bpf_map_new_fd(map);
 	if (err < 0)
 		/* failed to allocate fd */
-		goto free_map;
+		goto free_id;
 
 	trace_bpf_map_create(map, err);
 	return err;
 
+free_id:
+	bpf_map_free_id(map);
 free_map:
 	bpf_map_uncharge_memlock(map);
 free_map_nouncharge:
Signature · 1 line
2.9.3
#3 lore raw

PATCH v2 3/8 bpf: Add BPF_(PROG|MAP)_GET_NEXT_ID command

In reply to Martin KaFai Lau

This patch adds BPF_PROG_GET_NEXT_ID and BPF_MAP_GET_NEXT_ID to allow userspace to iterate all bpf_prog IDs and bpf_map IDs.

The API is trying to be consistent with the existing BPF_MAP_GET_NEXT_KEY.

It is currently limited to CAP_SYS_ADMIN which we can consider to lift it in followup patches.

---
 include/uapi/linux/bpf.h |  7 +++++++
 kernel/bpf/syscall.c     | 38 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 45 insertions(+)
include/uapi/linux/bpf.h +7 -0
index 94dfa9def355..e5c88f39bdc3 100644
@@ -82,6 +82,8 @@ enum bpf_cmd {
 	BPF_PROG_ATTACH,
 	BPF_PROG_DETACH,
 	BPF_PROG_TEST_RUN,
+	BPF_PROG_GET_NEXT_ID,
+	BPF_MAP_GET_NEXT_ID,
 };
 
 enum bpf_map_type {
@@ -209,6 +211,11 @@ union bpf_attr {
 		__u32		repeat;
 		__u32		duration;
 	} test;
+
+	struct { /* anonymous struct used by BPF_*_GET_NEXT_ID */
+		__u32		start_id;
+		__u32		next_id;
+	};
 } __attribute__((aligned(8)));
 
 /* BPF helper function descriptions:
kernel/bpf/syscall.c +38 -0
index 20f392d64f49..68a73d453d70 100644
@@ -166,6 +166,7 @@ static void bpf_map_put_uref(struct bpf_map *map)
 void bpf_map_put(struct bpf_map *map)
 {
 	if (atomic_dec_and_test(&map->refcnt)) {
+		/* bpf_map_free_id() must be called first */
 		bpf_map_free_id(map);
 		INIT_WORK(&map->work, bpf_map_free_deferred);
 		schedule_work(&map->work);
@@ -726,6 +727,7 @@ void bpf_prog_put(struct bpf_prog *prog)
 {
 	if (atomic_dec_and_test(&prog->aux->refcnt)) {
 		trace_bpf_prog_put_rcu(prog);
+		/* bpf_prog_free_id() must be called first */
 		bpf_prog_free_id(prog);
 		bpf_prog_kallsyms_del(prog);
 		call_rcu(&prog->aux->rcu, __bpf_prog_put_rcu);
@@ -1067,6 +1069,34 @@ static int bpf_prog_test_run(const union bpf_attr *attr,
 	return ret;
 }
 
+#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;
+}
+
 SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr __user *, uattr, unsigned int, size)
 {
 	union bpf_attr attr = {};
@@ -1144,6 +1174,14 @@ SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr __user *, uattr, unsigned int, siz
 	case BPF_PROG_TEST_RUN:
 		err = bpf_prog_test_run(&attr, uattr);
 		break;
+	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;
 	default:
 		err = -EINVAL;
 		break;
Signature · 1 line
2.9.3
#4 lore raw

PATCH v2 4/8 bpf: Add BPF_PROG_GET_FD_BY_ID

In reply to Martin KaFai Lau

Add BPF_PROG_GET_FD_BY_ID command to allow user to get a fd from a bpf_prog's ID.

bpf_prog_inc_not_zero() is added and is called with prog_idr_lock held.

__bpf_prog_put() is also added which has the 'bool do_idr_lock' param to decide if the prog_idr_lock should be acquired when freeing the prog->id.

In the error path of bpf_prog_inc_not_zero(), it may have to call __bpf_prog_put(map, false) which does not need to take the prog_idr_lock when freeing the prog->id.

It is currently limited to CAP_SYS_ADMIN which we can consider to lift it in followup patches.

---
 include/uapi/linux/bpf.h |  8 +++--
 kernel/bpf/syscall.c     | 91 ++++++++++++++++++++++++++++++++++++++++++------
 2 files changed, 87 insertions(+), 12 deletions(-)
include/uapi/linux/bpf.h +6 -2
index e5c88f39bdc3..6d4e1cc5bd18 100644
@@ -84,6 +84,7 @@ enum bpf_cmd {
 	BPF_PROG_TEST_RUN,
 	BPF_PROG_GET_NEXT_ID,
 	BPF_MAP_GET_NEXT_ID,
+	BPF_PROG_GET_FD_BY_ID,
 };
 
 enum bpf_map_type {
@@ -212,8 +213,11 @@ union bpf_attr {
 		__u32		duration;
 	} test;
 
-	struct { /* anonymous struct used by BPF_*_GET_NEXT_ID */
-		__u32		start_id;
+	struct { /* anonymous struct used by BPF_*_GET_*_ID */
+		union {
+			__u32		start_id;
+			__u32		prog_id;
+		};
 		__u32		next_id;
 	};
 } __attribute__((aligned(8)));
kernel/bpf/syscall.c +81 -10

146 lines not on this page · raw message

Signature · 1 line
2.9.3
#5 lore raw

PATCH v2 5/8 bpf: Add BPF_MAP_GET_FD_BY_ID

In reply to Martin KaFai Lau

Add BPF_MAP_GET_FD_BY_ID command to allow user to get a fd from a bpf_map's ID.

bpf_map_inc_not_zero() is added and is called with map_idr_lock held.

__bpf_map_put() is also added which has the 'bool do_idr_lock' param to decide if the map_idr_lock should be acquired when freeing the map->id.

In the error path of bpf_map_inc_not_zero(), it may have to call __bpf_map_put(map, false) which does not need to take the map_idr_lock when freeing the map->id.

It is currently limited to CAP_SYS_ADMIN which we can consider to lift it in followup patches.

---
 include/uapi/linux/bpf.h |  2 +
 kernel/bpf/syscall.c     | 95 +++++++++++++++++++++++++++++++++++++++++++-----
 2 files changed, 87 insertions(+), 10 deletions(-)
include/uapi/linux/bpf.h +2 -0
index 6d4e1cc5bd18..cf704e8b6e65 100644
@@ -85,6 +85,7 @@ enum bpf_cmd {
 	BPF_PROG_GET_NEXT_ID,
 	BPF_MAP_GET_NEXT_ID,
 	BPF_PROG_GET_FD_BY_ID,
+	BPF_MAP_GET_FD_BY_ID,
 };
 
 enum bpf_map_type {
@@ -217,6 +218,7 @@ union bpf_attr {
 		union {
 			__u32		start_id;
 			__u32		prog_id;
+			__u32		map_id;
 		};
 		__u32		next_id;
 	};
kernel/bpf/syscall.c +85 -10

145 lines not on this page · raw message

Signature · 1 line
2.9.3
#6 lore raw

PATCH v2 6/8 bpf: Add jited_len to struct bpf_prog

In reply to Martin KaFai Lau

Add jited_len to struct bpf_prog. It will be useful for the struct bpf_prog_info which will be added in the later patch.

---
 arch/arm64/net/bpf_jit_comp.c     | 1 +
 arch/powerpc/net/bpf_jit_comp64.c | 1 +
 arch/s390/net/bpf_jit_comp.c      | 1 +
 arch/sparc/net/bpf_jit_comp_64.c  | 1 +
 arch/x86/net/bpf_jit_comp.c       | 1 +
 include/linux/filter.h            | 1 +
 6 files changed, 6 insertions(+)
arch/arm64/net/bpf_jit_comp.c +1 -0
index 71f930501ade..6b21dccf01e8 100644
@@ -900,6 +900,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
 	bpf_jit_binary_lock_ro(header);
 	prog->bpf_func = (void *)ctx.image;
 	prog->jited = 1;
+	prog->jited_len = image_size;
 
 out_off:
 	kfree(ctx.offset);
arch/powerpc/net/bpf_jit_comp64.c +1 -0
index aee2bb817ac6..a3f904cd8b1e 100644
@@ -1052,6 +1052,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
 
 	fp->bpf_func = (void *)image;
 	fp->jited = 1;
+	fp->jited_len = alloclen;
 
 	bpf_flush_icache(bpf_hdr, (u8 *)bpf_hdr + (bpf_hdr->pages * PAGE_SIZE));
 
arch/s390/net/bpf_jit_comp.c +1 -0
index 6e97a2e3fd8d..76b7e9d5d591 100644
@@ -1329,6 +1329,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
 	bpf_jit_binary_lock_ro(header);
 	fp->bpf_func = (void *) jit.prg_buf;
 	fp->jited = 1;
+	fp->jited_len = jit.size;
 free_addrs:
 	kfree(jit.addrs);
 out:
arch/sparc/net/bpf_jit_comp_64.c +1 -0
index 21de77419f48..beb46b14fbbc 100644
@@ -1555,6 +1555,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
 
 	prog->bpf_func = (void *)ctx.image;
 	prog->jited = 1;
+	prog->jited_len = image_size;
 
 out_off:
 	kfree(ctx.offset);
arch/x86/net/bpf_jit_comp.c +1 -0
index f58939393eef..9341030133ae 100644
@@ -1162,6 +1162,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
 		bpf_jit_binary_lock_ro(header);
 		prog->bpf_func = (void *)image;
 		prog->jited = 1;
+		prog->jited_len = proglen;
 	} else {
 		prog = orig_prog;
 	}
include/linux/filter.h +1 -0
index 62d948f80730..a322a41f394b 100644
@@ -429,6 +429,7 @@ struct bpf_prog {
 	kmemcheck_bitfield_end(meta);
 	enum bpf_prog_type	type;		/* Type of BPF program */
 	u32			len;		/* Number of filter blocks */
+	u32			jited_len;	/* Size of jited insns in bytes */
 	u8			tag[BPF_TAG_SIZE];
 	struct bpf_prog_aux	*aux;		/* Auxiliary fields */
 	struct sock_fprog_kern	*orig_prog;	/* Original BPF program */
Signature · 1 line
2.9.3
#7 lore raw

PATCH v2 7/8 bpf: Add BPF_OBJ_GET_INFO_BY_FD

In reply to Martin KaFai Lau

A single BPF_OBJ_GET_INFO_BY_FD cmd is used to obtain the info for both bpf_prog and bpf_map. The kernel can figure out the fd is associated with a bpf_prog or bpf_map.

The suggested struct bpf_prog_info and struct bpf_map_info are not meant to be a complete list and it is not the goal of this patch. New fields can be added in the future patch.

The focus of this patch is to create the interface, BPF_OBJ_GET_INFO_BY_FD cmd for exposing the bpf_prog's and bpf_map's info.

The obj's info, which will be extended (and get bigger) over time, is separated from the bpf_attr to avoid bloating the bpf_attr.

---
 include/linux/filter.h   |   2 -
 include/uapi/linux/bpf.h |  28 ++++++++
 kernel/bpf/syscall.c     | 163 ++++++++++++++++++++++++++++++++++++++++++-----
 3 files changed, 174 insertions(+), 19 deletions(-)
include/linux/filter.h +0 -2
index a322a41f394b..46274f23f127 100644
@@ -66,8 +66,6 @@ struct bpf_prog_aux;
 /* BPF program can access up to 512 bytes of stack space. */
 #define MAX_BPF_STACK	512
 
-#define BPF_TAG_SIZE	8
-
 /* Helper macros for filter block array initializers. */
 
 /* ALU ops on registers, bpf_add|sub|...: dst_reg += src_reg */
include/uapi/linux/bpf.h +28 -0
index cf704e8b6e65..677b570da8ec 100644
@@ -86,6 +86,7 @@ enum bpf_cmd {
 	BPF_MAP_GET_NEXT_ID,
 	BPF_PROG_GET_FD_BY_ID,
 	BPF_MAP_GET_FD_BY_ID,
+	BPF_OBJ_GET_INFO_BY_FD,
 };
 
 enum bpf_map_type {
@@ -222,6 +223,12 @@ union bpf_attr {
 		};
 		__u32		next_id;
 	};
+
+	struct { /* anonymous struct used by BPF_OBJ_GET_INFO_BY_FD */
+		__u32		bpf_fd;
+		__u32		info_len;
+		__aligned_u64	info;
+	} info;
 } __attribute__((aligned(8)));
 
 /* BPF helper function descriptions:
@@ -683,4 +690,25 @@ struct xdp_md {
 	__u32 data_end;
 };
 
+#define BPF_TAG_SIZE	8
+
+struct bpf_prog_info {
+	__u32 type;
+	__u32 id;
+	__u8  tag[BPF_TAG_SIZE];
+	__u32 jited_prog_len;
+	__u32 xlated_prog_len;
+	__aligned_u64 jited_prog_insns;
+	__aligned_u64 xlated_prog_insns;
+} __attribute__((aligned(8)));
+
+struct bpf_map_info {
+	__u32 type;
+	__u32 id;
+	__u32 key_size;
+	__u32 value_size;
+	__u32 max_entries;
+	__u32 map_flags;
+} __attribute__((aligned(8)));
+
 #endif /* _UAPI__LINUX_BPF_H__ */
kernel/bpf/syscall.c +146 -17

181 lines not on this page · raw message

Signature · 1 line
2.9.3
#8 lore raw

PATCH v2 8/8 bpf: Test for bpf ID

In reply to Martin KaFai Lau

Add test to exercise the bpf_prog/map id generation, bpf_(prog|map)_get_next_id(), bpf_(prog|map)_get_fd_by_id() and bpf_get_obj_info_by_fd().

---
 tools/include/uapi/linux/bpf.h            |  41 +++++++
 tools/lib/bpf/bpf.c                       |  68 +++++++++++
 tools/lib/bpf/bpf.h                       |   5 +
 tools/testing/selftests/bpf/Makefile      |   2 +-
 tools/testing/selftests/bpf/test_obj_id.c |  35 ++++++
 tools/testing/selftests/bpf/test_progs.c  | 191 ++++++++++++++++++++++++++++++
 6 files changed, 341 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/bpf/test_obj_id.c
tools/include/uapi/linux/bpf.h +41 -0
index 94dfa9def355..677b570da8ec 100644
@@ -82,6 +82,11 @@ enum bpf_cmd {
 	BPF_PROG_ATTACH,
 	BPF_PROG_DETACH,
 	BPF_PROG_TEST_RUN,
+	BPF_PROG_GET_NEXT_ID,
+	BPF_MAP_GET_NEXT_ID,
+	BPF_PROG_GET_FD_BY_ID,
+	BPF_MAP_GET_FD_BY_ID,
+	BPF_OBJ_GET_INFO_BY_FD,
 };
 
 enum bpf_map_type {
@@ -209,6 +214,21 @@ union bpf_attr {
 		__u32		repeat;
 		__u32		duration;
 	} test;
+
+	struct { /* anonymous struct used by BPF_*_GET_*_ID */
+		union {
+			__u32		start_id;
+			__u32		prog_id;
+			__u32		map_id;
+		};
+		__u32		next_id;
+	};
+
+	struct { /* anonymous struct used by BPF_OBJ_GET_INFO_BY_FD */
+		__u32		bpf_fd;
+		__u32		info_len;
+		__aligned_u64	info;
+	} info;
 } __attribute__((aligned(8)));
 
 /* BPF helper function descriptions:
@@ -670,4 +690,25 @@ struct xdp_md {
 	__u32 data_end;
 };
 
+#define BPF_TAG_SIZE	8
+
+struct bpf_prog_info {
+	__u32 type;
+	__u32 id;
+	__u8  tag[BPF_TAG_SIZE];
+	__u32 jited_prog_len;
+	__u32 xlated_prog_len;
+	__aligned_u64 jited_prog_insns;
+	__aligned_u64 xlated_prog_insns;
+} __attribute__((aligned(8)));
+
+struct bpf_map_info {
+	__u32 type;
+	__u32 id;
+	__u32 key_size;
+	__u32 value_size;
+	__u32 max_entries;
+	__u32 map_flags;
+} __attribute__((aligned(8)));
+
 #endif /* _UAPI__LINUX_BPF_H__ */
tools/lib/bpf/bpf.c +68 -0

71 lines not on this page · raw message

tools/lib/bpf/bpf.h +5 -0
index 972bd8333eb7..16de44a14b48 100644
@@ -54,5 +54,10 @@ int bpf_prog_detach(int attachable_fd, enum bpf_attach_type type);
 int bpf_prog_test_run(int prog_fd, int repeat, void *data, __u32 size,
 		      void *data_out, __u32 *size_out, __u32 *retval,
 		      __u32 *duration);
+int bpf_prog_get_next_id(__u32 start_id, __u32 *next_id);
+int bpf_map_get_next_id(__u32 start_id, __u32 *next_id);
+int bpf_prog_get_fd_by_id(__u32 id);
+int bpf_map_get_fd_by_id(__u32 id);
+int bpf_obj_get_info_by_fd(int prog_fd, void *info, __u32 *info_len);
 
 #endif
tools/testing/selftests/bpf/Makefile +1 -1
index f389b02d43a0..9f0e07ba5334 100644
@@ -14,7 +14,7 @@ LDLIBS += -lcap -lelf
 TEST_GEN_PROGS = test_verifier test_tag test_maps test_lru_map test_lpm_map test_progs \
 	test_align
 
-TEST_GEN_FILES = test_pkt_access.o test_xdp.o test_l4lb.o test_tcp_estats.o
+TEST_GEN_FILES = test_pkt_access.o test_xdp.o test_l4lb.o test_tcp_estats.o test_obj_id.o
 
 TEST_PROGS := test_kmod.sh
 
tools/testing/selftests/bpf/test_obj_id.c new file +35 -0
new file mode 100644
index 000000000000..d8723aaf827a
@@ -0,0 +1,35 @@
+/* Copyright (c) 2017 Facebook
+ *
+ * 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.
+ */
+#include <stddef.h>
+#include <linux/bpf.h>
+#include <linux/pkt_cls.h>
+#include "bpf_helpers.h"
+
+/* It is a dumb bpf program such that it must have no
+ * issue to be loaded since testing the verifier is
+ * not the focus here.
+ */
+
+int _version SEC("version") = 1;
+
+struct bpf_map_def SEC("maps") test_map_id = {
+	.type = BPF_MAP_TYPE_ARRAY,
+	.key_size = sizeof(__u32),
+	.value_size = sizeof(__u64),
+	.max_entries = 1,
+};
+
+SEC("test_prog_id")
+int test_prog_id(struct __sk_buff *skb)
+{
+	__u32 key = 0;
+	__u64 *value;
+
+	value = bpf_map_lookup_elem(&test_map_id, &key);
+
+	return TC_ACT_OK;
+}
tools/testing/selftests/bpf/test_progs.c +191 -0

215 lines not on this page · raw message

Signature · 1 line
2.9.3
maintainer
#9 lore raw
In reply to Martin KaFai Lau

From: Martin KaFai Lau <[email protected]>
Date: Wed, 31 May 2017 11:58:54 -0700

Quoted 10 lines

This patch series:
1) Introduce ID for both bpf_prog and bpf_map.
2) Add bpf commands to iterate the prog IDs and map IDs of the system.
3) Add bpf commands to get a prog/map fd from an ID
4) Add bpf command to get prog/map info from a fd. The prog/map info is a jump start in this patchset and it is not meant to be a complete list. They can be extended in the future patches.

Quoted 7 lines

v2:
Compiler warning fixes:
- Remove lockdep_is_held() usage. Add comment
to explain the lock situation instead.
- Add static for idr related variables
- Add __user to the uattr param in bpf_prog_get_info_by_fd() and bpf_map_get_info_by_fd().

Series applied, thanks Martin.

#10 lore raw
Quoted 21 lines · David Miller

From: Martin KaFai Lau <[email protected]>
Date: Wed, 31 May 2017 11:58:54 -0700

Quoted 10 lines

This patch series:
1) Introduce ID for both bpf_prog and bpf_map.
2) Add bpf commands to iterate the prog IDs and map IDs of the system.
3) Add bpf commands to get a prog/map fd from an ID
4) Add bpf command to get prog/map info from a fd. The prog/map info is a jump start in this patchset and it is not meant to be a complete list. They can be extended in the future patches.

Quoted 7 lines

v2:
Compiler warning fixes:
- Remove lockdep_is_held() usage. Add comment
to explain the lock situation instead.
- Add static for idr related variables
- Add __user to the uattr param in bpf_prog_get_info_by_fd() and bpf_map_get_info_by_fd().

Quoted 1 line

Series applied, thanks Martin.

Patch 1 may not apply cleanly due to another newly added field in 'struct bpf_prog_aux' on May 31.

Should I respin?

#11 lore raw
In reply to Martin KaFai Lau
Quoted 9 lines · Martin KaFai Lau

This patch series:
1) Introduce ID for both bpf_prog and bpf_map.
2) Add bpf commands to iterate the prog IDs and map IDs of the system.
3) Add bpf commands to get a prog/map fd from an ID
4) Add bpf command to get prog/map info from a fd. The prog/map info is a jump start in this patchset and it is not meant to be a complete list. They can be extended in the future patches.

Hi! IIUC there were plans at some point to store the BPF byte code in the kernel, the way it was loaded from the user space and before it went through the verifier. Are you still planning on implementing that? It would be handy for offloads to have the original byte code, things like call inlining make translations of maps calls a bit challenging, since we try to run through the verifier again..

#12 lore raw
Quoted 11 lines · Jakub Kicinski
Quoted 9 lines · Martin KaFai Lau

This patch series:
1) Introduce ID for both bpf_prog and bpf_map.
2) Add bpf commands to iterate the prog IDs and map IDs of the system.
3) Add bpf commands to get a prog/map fd from an ID
4) Add bpf command to get prog/map info from a fd. The prog/map info is a jump start in this patchset and it is not meant to be a complete list. They can be extended in the future patches.

Quoted 7 lines

Hi! IIUC there were plans at some point to store the BPF byte code in the kernel, the way it was loaded from the user space and before it went through the verifier. Are you still planning on implementing that? It would be handy for offloads to have the original byte code, things like call inlining make translations of maps calls a bit challenging, since we try to run through the verifier again..

Save the instructions:
https://github.com/dsahern/linux/commit/5315578db7b0886a3e8e3bef6a56e828ae2bd2c4

Let userspace read it back:
https://github.com/dsahern/linux/commit/619982064b9b582fc5d4a504feffca1730610c4e

One more in between in the branch:
https://github.com/dsahern/linux/tree/bpf/retrieve-bpf-wip

Now that the id code is in, it needs to be returned on link dumps, route dumps, etc and accessible via fdinfo. The id can be turned into an fd and the fd read using the above patches.

#13 lore raw
Quoted 26 lines · David Ahern
Quoted 11 lines · Jakub Kicinski
Quoted 9 lines · Martin KaFai Lau

This patch series:
1) Introduce ID for both bpf_prog and bpf_map.
2) Add bpf commands to iterate the prog IDs and map IDs of the system.
3) Add bpf commands to get a prog/map fd from an ID
4) Add bpf command to get prog/map info from a fd. The prog/map info is a jump start in this patchset and it is not meant to be a complete list. They can be extended in the future patches.

Quoted 7 lines

Hi! IIUC there were plans at some point to store the BPF byte code in the kernel, the way it was loaded from the user space and before it went through the verifier. Are you still planning on implementing that? It would be handy for offloads to have the original byte code, things like call inlining make translations of maps calls a bit challenging, since we try to run through the verifier again..

Save the instructions:
https://github.com/dsahern/linux/commit/5315578db7b0886a3e8e3bef6a56e828ae2bd2c4

Let userspace read it back:
https://github.com/dsahern/linux/commit/619982064b9b582fc5d4a504feffca1730610c4e

Quoted 6 lines

One more in between in the branch:
https://github.com/dsahern/linux/tree/bpf/retrieve-bpf-wip

Now that the id code is in, it needs to be returned on link dumps, route dumps, etc and accessible via fdinfo. The id can be turned into an fd and the fd read using the above patches.

what problem are we trying to solve?
If we don't agree on the problem, we won't be able to agree on the solution.

Sounds to me that Jakub wants to translate lookup/update helper calls for JITing and it's difficult due to inlining optimization. In such case isn't the easiest solution to disable inlining when JIT to NFP is on?

Dave's case is to be able to retrieve a cgroup_sock program used for vrf. Such prog doesn't have any maps and I don't see why returning real insns is not enough.
As Martin said there is work in progress patches that return IDs for programs attached to everything: cgroup_sock hook, xdp, etc. The user can get prog ID, convert to FD and dump all insns. Why this is not enough for VRF introspection?

#14 lore raw
Quoted 4 lines · Alexei Starovoitov

what problem are we trying to solve?
If we don't agree on the problem, we won't be able to agree on the solution.

I want the ability to retrieve the BPF instructions pushed to the kernel. Not just for cgroups and VRF, but everywhere - cgroups, sockets, xdp, filters, etc. I have this stated many times, including to you at netconf in April. From that discussion and the discussion on the RFC patch I sent in February, I thought we had an agreement that saving the instructions was the first step.

Quentin at 6wind has expressed a similar interest for cls_bpf and act_bpf code.

I read Jakub's email as wanting the same but for XDP.

The patches I referenced earlier save the original instructions and enable them to be read by userspace from an fd return by the bpf syscall. Combine that with the ID and we have a solution.

#15 lore raw
Quoted 13 lines · David Ahern
Quoted 4 lines · Alexei Starovoitov

what problem are we trying to solve?
If we don't agree on the problem, we won't be able to agree on the solution.

I want the ability to retrieve the BPF instructions pushed to the kernel. Not just for cgroups and VRF, but everywhere - cgroups, sockets, xdp, filters, etc. I have this stated many times, including to you at netconf in April. From that discussion and the discussion on the RFC patch I sent in February, I thought we had an agreement that saving the instructions was the first step.

Quoted 8 lines

Quentin at 6wind has expressed a similar interest for cls_bpf and act_bpf code.

I read Jakub's email as wanting the same but for XDP.

The patches I referenced earlier save the original instructions and enable them to be read by userspace from an fd return by the bpf syscall. Combine that with the ID and we have a solution.

Please explain the problem instead of pushing for 'solution'. In this case I do not see a problem that saving original instructions will solve.

'I want to retrieve original instructions' is not a problem. It's a push for 'solution'. Explaining 'why' you want to see original instructions would describe the actual problem.
If you're trying to debug something you're interested in original source code and in the instructions that kernel is running. To correlate to source code we have prog_tag (that was computed over original insns).
To see kernel instructions in the interpreter and JITed assembler we have this set of patches.
Original instructions are not useful for debugging, since they have map_fds which can be long gone when program is running, therefore to solve introspection problem we need to look into real kernel instructions.

My understanding that 6wind wants to see original instructions to accelerate them somehow using out of tree technology. I'm not interested to help that cause. I also suspect that retrieving kernel instructions will not be much different from that point of view, but at least returning kernel insns is solving introspection problem for everyone.

Returning kernel insns also doesn't burn unnecessary memory, whereas original insns will be there as dead weight. Hence before we add them we need to be absolutely clear that there is no cheaper alternative possible.

maintainer
#16 lore raw

From: Alexei Starovoitov <[email protected]>
Date: Thu, 1 Jun 2017 11:27:56 -0700

Quoted 4 lines

Original instructions are not useful for debugging, since they have map_fds which can be long gone when program is running, therefore to solve introspection problem we need to look into real kernel instructions.

The only possible legitimate use I see for the original instructions is checkpoint/restart.

If 6wind wants this for "external acceleration" or whatever, like Alexei I am not interested in facilitating that at all.

#17 lore raw
Quoted 8 lines · David Miller

From: Alexei Starovoitov <[email protected]>
Date: Thu, 1 Jun 2017 11:27:56 -0700

Quoted 4 lines

Original instructions are not useful for debugging, since they have map_fds which can be long gone when program is running, therefore to solve introspection problem we need to look into real kernel instructions.

Quoted 5 lines

The only possible legitimate use I see for the original instructions is checkpoint/restart.

If 6wind wants this for "external acceleration" or whatever, like Alexei I am not interested in facilitating that at all.

+1

I will try disabling the inlining then.

#18 lore raw
In reply to Alexei Starovoitov
Quoted 3 lines · Alexei Starovoitov

'I want to retrieve original instructions' is not a problem. It's a push for 'solution'. Explaining 'why' you want to see original instructions would describe the actual problem.

I have explained this.

You are creating this hyper-complex almost completely invisible infrastructure. You are enabling binary blobs that can bypass the network stack and modify packets with almost no introspection on what is happening. BPF code can from a variety of sources -- OS vendors, upstream repos, 3rd party vendors (eg., H/W vendors), and "in-house" development. Each will swear to the end that any observed problem is not with their code. In my experience, it falls on to the OS and kernel experts to figure out why Linux is breaking something. To do that we need tools to look at what code is running where and something that can be used in production environments not requiring a disruption to the service that the box is providing.

maintainer
#19 lore raw

From: David Ahern <[email protected]>
Date: Thu, 1 Jun 2017 12:52:28 -0600

Quoted 7 lines · Alexei Starovoitov
Quoted 3 lines

'I want to retrieve original instructions' is not a problem. It's a push for 'solution'. Explaining 'why' you want to see original instructions would describe the actual problem.

I have explained this.

Quoted 11 lines

You are creating this hyper-complex almost completely invisible infrastructure. You are enabling binary blobs that can bypass the network stack and modify packets with almost no introspection on what is happening. BPF code can from a variety of sources -- OS vendors, upstream repos, 3rd party vendors (eg., H/W vendors), and "in-house" development. Each will swear to the end that any observed problem is not with their code. In my experience, it falls on to the OS and kernel experts to figure out why Linux is breaking something. To do that we need tools to look at what code is running where and something that can be used in production environments not requiring a disruption to the service that the box is providing.

I'm not convinced that the verifier processed instruction stream cannot provide that facility properly.

In fact, because of how the maps and tail calls work, you can only figure out what is really executing by looking at the final processed instruction stream.

#20 lore raw
In reply to David Ahern
Quoted 7 lines · David Ahern
Quoted 3 lines · Alexei Starovoitov

'I want to retrieve original instructions' is not a problem. It's a push for 'solution'. Explaining 'why' you want to see original instructions would describe the actual problem.

I have explained this.

Quoted 11 lines

You are creating this hyper-complex almost completely invisible infrastructure. You are enabling binary blobs that can bypass the network stack and modify packets with almost no introspection on what is happening. BPF code can from a variety of sources -- OS vendors, upstream repos, 3rd party vendors (eg., H/W vendors), and "in-house" development. Each will swear to the end that any observed problem is not with their code. In my experience, it falls on to the OS and kernel experts to figure out why Linux is breaking something. To do that we need tools to look at what code is running where and something that can be used in production environments not requiring a disruption to the service that the box is providing.

Forgive my ignorance, but is it possible to dump code of a loaded module out of the kernel?

#21 lore raw
In reply to David Ahern
Quoted 7 lines · David Ahern
Quoted 3 lines · Alexei Starovoitov

'I want to retrieve original instructions' is not a problem. It's a push for 'solution'. Explaining 'why' you want to see original instructions would describe the actual problem.

I have explained this.

Quoted 11 lines

You are creating this hyper-complex almost completely invisible infrastructure. You are enabling binary blobs that can bypass the network stack and modify packets with almost no introspection on what is happening. BPF code can from a variety of sources -- OS vendors, upstream repos, 3rd party vendors (eg., H/W vendors), and "in-house" development. Each will swear to the end that any observed problem is not with their code. In my experience, it falls on to the OS and kernel experts to figure out why Linux is breaking something. To do that we need tools to look at what code is running where and something that can be used in production environments not requiring a disruption to the service that the box is providing.

You saw patch 7/8, right?
since I'm not following what exactly you're concerned about.
This patch set provided a way to retrieve post-verifier, post-blinding
instruction stream that gives users a way to know exactly what is running. Original instruction stream is not the one that is executed. It's merely an interface between kernel and user space.
Before that stage the clang/llvm did many code transformations and
optimizations on original source code and after that verifier,
context rewriter, inliner, constant blinding did transformations on
these insns as well.

If there is a bug somewhere in all these transformations it can be anywhere in clang, llvm optimizer, llvm codegen, elf or bcc loader and in kernel side transformations. Yes. There can be bugs, but we cannot keep all these stages in the kernel. I don't mind dumping insn stream for debugging while doing these stages (just like llvm has -print-before-all flag), but keeping all the intermediate stages don't make sense to me. In that sense 'original instruction stream' to me is one of the intermediate stages where source code in C crossed user->kernel boundary.
I'd rather store more information about original C code than this user->kernel instruction stream. That's where CTF is heading. To provide info about types, names, etc. For both progs and maps.

I don't mind storing even that 'original instruction stream' _if_ there is a solid reason. I just didn't hear one so far.
I can imagine somebody saying that there is a bug in context rewriter and xlated_prog_insns are accessing wrong field. That's bad, but how keeping original_prog_insns will help such case?
And how such bug is different from llvm generating wrong code ? If there is a bug anywhere in that transformation pipeline I'd want to give original source code and final outcome to support people. In practice everything is more complex, since maps are dynamic, tail_calls are dynamic, the code flow changes. Debugging is not easy and this patch set is the first step toward better debuggability. I'm all for it, but statements like "without original insns it's not debuggable" are concerning, since we either don't explain the APIs well enough or understanding of the use case is missing on our side.

#22 lore raw
Quoted 1 line · Alexei Starovoitov

You saw patch 7/8, right?

Apparently, not close enough. Nothing in the commit message mentioned returning instructions. I skimmed the patch and filled in that GET_INFO was returning just the meta-data.