[PATCH v2 bpf-next 0/2] libbpf: add support for privileged/unprivileged control separation

* [PATCH v2 bpf-next 0/2] libbpf: add support for privileged/unprivileged control separation
@ 2020-11-12  8:58 mariusz.dudek
  2020-11-12  8:58 ` [PATCH v2 bpf-next 1/2] libbpf: separate XDP program load with xsk socket creation mariusz.dudek
  2020-11-12  8:58 ` [PATCH v2 bpf-next 2/2] samples/bpf: sample application for eBPF load and socket creation split mariusz.dudek
  0 siblings, 2 replies; 5+ messages in thread
From: mariusz.dudek @ 2020-11-12  8:58 UTC (permalink / raw)
  To: andrii.nakryiko, magnus.karlsson, bjorn.topel, ast, daniel,
	netdev, jonathan.lemon
  Cc: bpf, Mariusz Dudek

From: Mariusz Dudek <mariuszx.dudek@intel.com>

This patch series adds support for separation of eBPF program
load and xsk socket creation. In for example a Kubernetes
environment you can have an AF_XDP CNI or daemonset that is 
responsible for launching pods that execute an application 
using AF_XDP sockets. It is desirable that the pod runs with
as low privileges as possible, CAP_NET_RAW in this case, 
and that all operations that require privileges are contained
in the CNI or daemonset.

In this case, you have to be able separate ePBF program load from
xsk socket creation.

Currently, this will not work with the xsk_socket__create APIs
because you need to have CAP_NET_ADMIN privileges to load eBPF
program and CAP_SYS_ADMIN privileges to create update xsk_bpf_maps.
To be exact xsk_set_bpf_maps does not need those privileges but
it takes the prog_fd and xsks_map_fd and those are known only to
process that was loading eBPF program. The api bpf_prog_get_fd_by_id
that looks up the fd of the prog using an prog_id and
bpf_map_get_fd_by_id that looks for xsks_map_fd usinb map_id both
requires CAP_SYS_ADMIN.

With this patch, the pod can be run with CAP_NET_RAW capability
only. In case your umem is larger or equal process limit for
MEMLOCK you need either increase the limit or CAP_IPC_LOCK capability. 
Without this patch in case of insufficient rights ENOPERM is
returned by xsk_socket__create.

To resolve this privileges issue two new APIs are introduced:
- xsk_setup_xdp_prog - prepares bpf program if given and
loads it on a selected network interface or loads the built in
XDP program, if no XDP program is supplied. It can also return
xsks_map_fd which is needed by unprivileged process to update
xsks_map with AF_XDP socket "fd"
- xsk_sokcet__update_xskmap - inserts an AF_XDP socket into an
xskmap for a particular xsk_socket

Usage example:
int xsk_setup_xdp_prog(int ifindex, struct bpf_prog_cfg *cfg,
		int *xsks_map_fd)

if cfg == NULL, then the default program is loaded.

Instead of NULL user can pass pointer to struct
bpf_prog_cfg and provide own bpf program. 

int xsk_socket__update_xskmap(struct xsk_socket *xsk, int xsks_map_fd);

Inserts AF_XDP socket "fd" into the xskmap.

The first patch introduces the new APIs. The second patch provides
a new sample applications working as control and modification to
existing xdpsock application to work with less privileges.

This patch set is based on bpf-next commit 09a3dac7b579
("bpf: Fix NULL dereference in bpf_task_storage")

Since v1:
- struct bpf_prog_cfg improved for backward/forward compatibility
- API xsk_update_xskmap renamed to xsk_socket__update_xskmap
- commit message formatting fixed

Mariusz Dudek (2):
  libbpf: separate XDP program load with xsk socket creation
  samples/bpf: sample application for eBPF load and socket creation
    split

 samples/bpf/Makefile            |   4 +-
 samples/bpf/xdpsock.h           |   8 ++
 samples/bpf/xdpsock_ctrl_proc.c | 184 ++++++++++++++++++++++++++++++++
 samples/bpf/xdpsock_user.c      | 146 +++++++++++++++++++++++--
 tools/lib/bpf/libbpf.map        |   2 +
 tools/lib/bpf/xsk.c             | 160 ++++++++++++++++++++++-----
 tools/lib/bpf/xsk.h             |  15 +++
 7 files changed, 483 insertions(+), 36 deletions(-)
 create mode 100644 samples/bpf/xdpsock_ctrl_proc.c

-- 
2.20.1

^ permalink raw reply	[flat|nested] 5+ messages in thread