From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: mariusz.dudek@gmail.com
Cc: "Magnus Karlsson" <magnus.karlsson@intel.com>,
"Björn Töpel" <bjorn.topel@intel.com>,
"Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
Networking <netdev@vger.kernel.org>,
"Jonathan Lemon" <jonathan.lemon@gmail.com>,
bpf <bpf@vger.kernel.org>,
"Mariusz Dudek" <mariuszx.dudek@intel.com>
Subject: Re: [PATCH v5 bpf-next 0/2] libbpf: add support for privileged/unprivileged control separation
Date: Tue, 1 Dec 2020 17:14:58 -0800 [thread overview]
Message-ID: <CAEf4Bzby86qiQWiC5T4uK4dL2dGG0nEaQx4L2Rcjm2ZD-LTcjw@mail.gmail.com> (raw)
In-Reply-To: <20201127082601.4762-1-mariuszx.dudek@intel.com>
On Fri, Nov 27, 2020 at 12:26 AM <mariusz.dudek@gmail.com> wrote:
>
> 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 - loads the built in XDP program. 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, int *xsks_map_fd)
>
> 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 830382e4ccb5
> (Merge branch 'bpf: remove bpf_load loader completely')
>
> Since v4
> - sample/bpf/Makefile issues fixed
>
> Since v3:
> - force_set_map flag removed
> - leaking of xsk struct fixed
> - unified function error returning policy implemented
>
> Since v2:
> - new APIs moved itto LIBBPF_0.3.0 section
> - struct bpf_prog_cfg_opts removed
> - loading own eBPF program via xsk_setup_xdp_prog functionality removed
>
> 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 | 187 ++++++++++++++++++++++++++++++++
> samples/bpf/xdpsock_user.c | 146 +++++++++++++++++++++++--
> tools/lib/bpf/libbpf.map | 2 +
> tools/lib/bpf/xsk.c | 92 ++++++++++++++--
> tools/lib/bpf/xsk.h | 5 +
> 7 files changed, 425 insertions(+), 19 deletions(-)
> create mode 100644 samples/bpf/xdpsock_ctrl_proc.c
>
This doesn't apply cleanly to bpf-next, can you please rebase and resend?
> --
> 2.20.1
>
prev parent reply other threads:[~2020-12-02 1:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-27 8:25 [PATCH v5 bpf-next 0/2] libbpf: add support for privileged/unprivileged control separation mariusz.dudek
2020-11-27 8:26 ` [PATCH v5 bpf-next 1/2] libbpf: separate XDP program load with xsk socket creation mariusz.dudek
2020-11-27 9:06 ` Magnus Karlsson
2020-11-27 8:26 ` [PATCH v5 bpf-next 2/2] samples/bpf: sample application for eBPF load and socket creation split mariusz.dudek
2020-11-27 9:07 ` Magnus Karlsson
2020-12-02 1:14 ` Andrii Nakryiko [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAEf4Bzby86qiQWiC5T4uK4dL2dGG0nEaQx4L2Rcjm2ZD-LTcjw@mail.gmail.com \
--to=andrii.nakryiko@gmail.com \
--cc=ast@kernel.org \
--cc=bjorn.topel@intel.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=jonathan.lemon@gmail.com \
--cc=magnus.karlsson@intel.com \
--cc=mariusz.dudek@gmail.com \
--cc=mariuszx.dudek@intel.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).