public inbox for bpf@vger.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <olsajiri@gmail.com>
To: Andrii Nakryiko <andrii@kernel.org>
Cc: bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
	martin.lau@kernel.org, cyphar@cyphar.com, brauner@kernel.org,
	lennart@poettering.net
Subject: Re: [PATCH bpf-next 1/3] bpf: support O_PATH FDs in BPF_OBJ_PIN and BPF_OBJ_GET commands
Date: Tue, 16 May 2023 10:52:20 +0200	[thread overview]
Message-ID: <ZGNERLZH65QgGGEE@krava> (raw)
In-Reply-To: <20230516001348.286414-2-andrii@kernel.org>

On Mon, May 15, 2023 at 05:13:46PM -0700, Andrii Nakryiko wrote:
> Current UAPI of BPF_OBJ_PIN and BPF_OBJ_GET commands of bpf() syscall
> forces users to specify pinning location as a string-based absolute or
> relative (to current working directory) path. This has various
> implications related to security (e.g., symlink-based attacks), forces
> BPF FS to be exposed in the file system, which can cause races with
> other applications.
> 
> One of the feedbacks we got from folks working with containers heavily
> was that inability to use purely FD-based location specification was an
> unfortunate limitation and hindrance for BPF_OBJ_PIN and BPF_OBJ_GET
> commands. This patch closes this oversight, adding path_fd field to
> BPF_OBJ_PIN and BPF_OBJ_GET UAPI, following conventions established by
> *at() syscalls for dirfd + pathname combinations.
> 
> This now allows interesting possibilities like working with detached BPF
> FS mount (e.g., to perform multiple pinnings without running a risk of
> someone interfering with them), and generally making pinning/getting
> more secure and not prone to any races and/or security attacks.
> 
> This is demonstrated by a selftest added in subsequent patch that takes
> advantage of new mount APIs (fsopen, fsconfig, fsmount) to demonstrate
> creating detached BPF FS mount, pinning, and then getting BPF map out of
> it, all while never exposing this private instance of BPF FS to outside
> worlds.
> 
> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
> ---
>  include/linux/bpf.h            |  4 ++--
>  include/uapi/linux/bpf.h       |  5 +++++
>  kernel/bpf/inode.c             | 16 ++++++++--------
>  kernel/bpf/syscall.c           |  8 +++++---
>  tools/include/uapi/linux/bpf.h |  5 +++++
>  5 files changed, 25 insertions(+), 13 deletions(-)
> 
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index 36e4b2d8cca2..f58895830ada 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -2077,8 +2077,8 @@ struct file *bpf_link_new_file(struct bpf_link *link, int *reserved_fd);
>  struct bpf_link *bpf_link_get_from_fd(u32 ufd);
>  struct bpf_link *bpf_link_get_curr_or_next(u32 *id);
>  
> -int bpf_obj_pin_user(u32 ufd, const char __user *pathname);
> -int bpf_obj_get_user(const char __user *pathname, int flags);
> +int bpf_obj_pin_user(u32 ufd, int path_fd, const char __user *pathname);
> +int bpf_obj_get_user(int path_fd, const char __user *pathname, int flags);
>  
>  #define BPF_ITER_FUNC_PREFIX "bpf_iter_"
>  #define DEFINE_BPF_ITER_FUNC(target, args...)			\
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 1bb11a6ee667..db2870a52ce0 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -1420,6 +1420,11 @@ union bpf_attr {
>  		__aligned_u64	pathname;
>  		__u32		bpf_fd;
>  		__u32		file_flags;
> +		/* same as dirfd in openat() syscall; see openat(2)
> +		 * manpage for details of dirfd/path_fd and pathname semantics;
> +		 * zero path_fd implies AT_FDCWD behavior
> +		 */
> +		__u32		path_fd;

I'd probably call it dir_fd to emphasize the similarity,
but I don't mind path_fd as well

I have a note that you suggested to introduce this for uprobe
multi link as well, so I'll do something similar

lgtm

Acked-by: Jiri Olsa <jolsa@kernel.org>

jirka

>  	};
>  
>  	struct { /* anonymous struct used by BPF_PROG_ATTACH/DETACH commands */
> diff --git a/kernel/bpf/inode.c b/kernel/bpf/inode.c
> index 9948b542a470..13bb54f6bd17 100644
> --- a/kernel/bpf/inode.c
> +++ b/kernel/bpf/inode.c
> @@ -435,7 +435,7 @@ static int bpf_iter_link_pin_kernel(struct dentry *parent,
>  	return ret;
>  }
>  
> -static int bpf_obj_do_pin(const char __user *pathname, void *raw,
> +static int bpf_obj_do_pin(int path_fd, const char __user *pathname, void *raw,
>  			  enum bpf_type type)
>  {
>  	struct dentry *dentry;
> @@ -444,7 +444,7 @@ static int bpf_obj_do_pin(const char __user *pathname, void *raw,
>  	umode_t mode;
>  	int ret;
>  
> -	dentry = user_path_create(AT_FDCWD, pathname, &path, 0);
> +	dentry = user_path_create(path_fd, pathname, &path, 0);
>  	if (IS_ERR(dentry))
>  		return PTR_ERR(dentry);
>  
> @@ -478,7 +478,7 @@ static int bpf_obj_do_pin(const char __user *pathname, void *raw,
>  	return ret;
>  }
>  
> -int bpf_obj_pin_user(u32 ufd, const char __user *pathname)
> +int bpf_obj_pin_user(u32 ufd, int path_fd, const char __user *pathname)
>  {
>  	enum bpf_type type;
>  	void *raw;
> @@ -488,14 +488,14 @@ int bpf_obj_pin_user(u32 ufd, const char __user *pathname)
>  	if (IS_ERR(raw))
>  		return PTR_ERR(raw);
>  
> -	ret = bpf_obj_do_pin(pathname, raw, type);
> +	ret = bpf_obj_do_pin(path_fd, pathname, raw, type);
>  	if (ret != 0)
>  		bpf_any_put(raw, type);
>  
>  	return ret;
>  }
>  
> -static void *bpf_obj_do_get(const char __user *pathname,
> +static void *bpf_obj_do_get(int path_fd, const char __user *pathname,
>  			    enum bpf_type *type, int flags)
>  {
>  	struct inode *inode;
> @@ -503,7 +503,7 @@ static void *bpf_obj_do_get(const char __user *pathname,
>  	void *raw;
>  	int ret;
>  
> -	ret = user_path_at(AT_FDCWD, pathname, LOOKUP_FOLLOW, &path);
> +	ret = user_path_at(path_fd, pathname, LOOKUP_FOLLOW, &path);
>  	if (ret)
>  		return ERR_PTR(ret);
>  
> @@ -527,7 +527,7 @@ static void *bpf_obj_do_get(const char __user *pathname,
>  	return ERR_PTR(ret);
>  }
>  
> -int bpf_obj_get_user(const char __user *pathname, int flags)
> +int bpf_obj_get_user(int path_fd, const char __user *pathname, int flags)
>  {
>  	enum bpf_type type = BPF_TYPE_UNSPEC;
>  	int f_flags;
> @@ -538,7 +538,7 @@ int bpf_obj_get_user(const char __user *pathname, int flags)
>  	if (f_flags < 0)
>  		return f_flags;
>  
> -	raw = bpf_obj_do_get(pathname, &type, f_flags);
> +	raw = bpf_obj_do_get(path_fd, pathname, &type, f_flags);
>  	if (IS_ERR(raw))
>  		return PTR_ERR(raw);
>  
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 909c112ef537..65a46f6d4be0 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -2697,14 +2697,15 @@ static int bpf_prog_load(union bpf_attr *attr, bpfptr_t uattr, u32 uattr_size)
>  	return err;
>  }
>  
> -#define BPF_OBJ_LAST_FIELD file_flags
> +#define BPF_OBJ_LAST_FIELD path_fd
>  
>  static int bpf_obj_pin(const union bpf_attr *attr)
>  {
>  	if (CHECK_ATTR(BPF_OBJ) || attr->file_flags != 0)
>  		return -EINVAL;
>  
> -	return bpf_obj_pin_user(attr->bpf_fd, u64_to_user_ptr(attr->pathname));
> +	return bpf_obj_pin_user(attr->bpf_fd, attr->path_fd ?: AT_FDCWD,
> +				u64_to_user_ptr(attr->pathname));
>  }
>  
>  static int bpf_obj_get(const union bpf_attr *attr)
> @@ -2713,7 +2714,8 @@ static int bpf_obj_get(const union bpf_attr *attr)
>  	    attr->file_flags & ~BPF_OBJ_FLAG_MASK)
>  		return -EINVAL;
>  
> -	return bpf_obj_get_user(u64_to_user_ptr(attr->pathname),
> +	return bpf_obj_get_user(attr->path_fd ?: AT_FDCWD,
> +				u64_to_user_ptr(attr->pathname),
>  				attr->file_flags);
>  }
>  
> diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
> index 1bb11a6ee667..db2870a52ce0 100644
> --- a/tools/include/uapi/linux/bpf.h
> +++ b/tools/include/uapi/linux/bpf.h
> @@ -1420,6 +1420,11 @@ union bpf_attr {
>  		__aligned_u64	pathname;
>  		__u32		bpf_fd;
>  		__u32		file_flags;
> +		/* same as dirfd in openat() syscall; see openat(2)
> +		 * manpage for details of dirfd/path_fd and pathname semantics;
> +		 * zero path_fd implies AT_FDCWD behavior
> +		 */
> +		__u32		path_fd;
>  	};
>  
>  	struct { /* anonymous struct used by BPF_PROG_ATTACH/DETACH commands */
> -- 
> 2.34.1
> 
> 

  reply	other threads:[~2023-05-16  8:52 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-16  0:13 [PATCH bpf-next 0/3] Add O_PATH-based BPF_OBJ_PIN and BPF_OBJ_GET support Andrii Nakryiko
2023-05-16  0:13 ` [PATCH bpf-next 1/3] bpf: support O_PATH FDs in BPF_OBJ_PIN and BPF_OBJ_GET commands Andrii Nakryiko
2023-05-16  8:52   ` Jiri Olsa [this message]
2023-05-16 18:02     ` Andrii Nakryiko
2023-05-16  9:07   ` Christian Brauner
2023-05-16 18:02     ` Andrii Nakryiko
2023-05-17  9:11       ` fd == 0 means AT_FDCWD " Christian Brauner
2023-05-17 12:05         ` Christoph Hellwig
2023-05-17 16:17           ` Alexei Starovoitov
2023-05-17 21:48             ` Alexei Starovoitov
2023-05-18  8:38             ` Christian Brauner
2023-05-18 14:30               ` Theodore Ts'o
2023-05-18 16:25               ` Alexei Starovoitov
2023-05-18 16:33                 ` Matthew Wilcox
2023-05-18 17:22                   ` Christian Brauner
2023-05-18 17:20                 ` Christian Brauner
2023-05-18 17:33                   ` Linus Torvalds
2023-05-18 18:21                     ` Christian Brauner
2023-05-18 18:26                   ` Alexei Starovoitov
2023-05-18 18:57                     ` Linus Torvalds
2023-05-19  4:44                       ` Alexei Starovoitov
2023-05-19  8:13                         ` Christian Brauner
2023-05-19 14:27                           ` Theodore Ts'o
2023-05-19 17:51                         ` Linus Torvalds
2023-05-23  7:49                         ` Lennart Poettering
2023-05-23 17:25                           ` Andrii Nakryiko
2023-08-26  4:27                         ` Al Viro
2023-05-18 21:56         ` Andrii Nakryiko
2023-05-16  0:13 ` [PATCH bpf-next 2/3] libbpf: add opts-based bpf_obj_pin() API and add support for path_fd Andrii Nakryiko
2023-05-16  0:13 ` [PATCH bpf-next 3/3] selftests/bpf: add path_fd-based BPF_OBJ_PIN and BPF_OBJ_GET tests Andrii Nakryiko

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=ZGNERLZH65QgGGEE@krava \
    --to=olsajiri@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brauner@kernel.org \
    --cc=cyphar@cyphar.com \
    --cc=daniel@iogearbox.net \
    --cc=lennart@poettering.net \
    --cc=martin.lau@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