bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: Alexei Starovoitov <ast@kernel.org>, bpf <bpf@vger.kernel.org>,
	Networking <netdev@vger.kernel.org>
Subject: Re: [PATCH bpf-next 1/5] uaccess: Add non-pagefault user-space write function
Date: Fri, 25 Oct 2019 14:53:07 -0700	[thread overview]
Message-ID: <CAEf4BzbTKeBabyb3C3Yj5iT8TQC7A7SeUAe=PafaKnqeA4zoVQ@mail.gmail.com> (raw)
In-Reply-To: <8e63f4005c7139d88c5c78e2a19f539b2a1ff988.1572010897.git.daniel@iogearbox.net>

On Fri, Oct 25, 2019 at 1:44 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> Commit 3d7081822f7f ("uaccess: Add non-pagefault user-space read functions")
> missed to add probe write function, therefore factor out a probe_write_common()
> helper with most logic of probe_kernel_write() except setting KERNEL_DS, and
> add a new probe_user_write() helper so it can be used from BPF side.
>
> Again, on some archs, the user address space and kernel address space can
> co-exist and be overlapping, so in such case, setting KERNEL_DS would mean
> that the given address is treated as being in kernel address space.
>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> ---

LGTM. See an EFAULT comment below, though.

Acked-by: Andrii Nakryiko <andriin@fb.com>

>  include/linux/uaccess.h | 12 +++++++++++
>  mm/maccess.c            | 45 +++++++++++++++++++++++++++++++++++++----
>  2 files changed, 53 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
> index e47d0522a1f4..86dcf2894672 100644
> --- a/include/linux/uaccess.h
> +++ b/include/linux/uaccess.h
> @@ -337,6 +337,18 @@ extern long __probe_user_read(void *dst, const void __user *src, size_t size);
>  extern long notrace probe_kernel_write(void *dst, const void *src, size_t size);
>  extern long notrace __probe_kernel_write(void *dst, const void *src, size_t size);
>
> +/*
> + * probe_user_write(): safely attempt to write to a location in user space
> + * @dst: address to write to
> + * @src: pointer to the data that shall be written
> + * @size: size of the data chunk
> + *
> + * Safely write to address @dst from the buffer at @src.  If a kernel fault
> + * happens, handle that and return -EFAULT.
> + */
> +extern long notrace probe_user_write(void __user *dst, const void *src, size_t size);
> +extern long notrace __probe_user_write(void __user *dst, const void *src, size_t size);
> +
>  extern long strncpy_from_unsafe(char *dst, const void *unsafe_addr, long count);
>  extern long strncpy_from_unsafe_user(char *dst, const void __user *unsafe_addr,
>                                      long count);
> diff --git a/mm/maccess.c b/mm/maccess.c
> index d065736f6b87..2d3c3d01064c 100644
> --- a/mm/maccess.c

[...]

>
> +/**
> + * probe_user_write(): safely attempt to write to a user-space location
> + * @dst: address to write to
> + * @src: pointer to the data that shall be written
> + * @size: size of the data chunk
> + *
> + * Safely write to address @dst from the buffer at @src.  If a kernel fault
> + * happens, handle that and return -EFAULT.
> + */
> +
> +long __weak probe_user_write(void __user *dst, const void *src, size_t size)
> +    __attribute__((alias("__probe_user_write")));

curious, why is there this dance of probe_user_write alias to
__probe_user_write (and for other pairs of functions as well)?

> +
> +long __probe_user_write(void __user *dst, const void *src, size_t size)
> +{
> +       long ret = -EFAULT;

This initialization is not necessary, is it? Similarly in
__probe_user_read higher in this file.

> +       mm_segment_t old_fs = get_fs();
> +
> +       set_fs(USER_DS);
> +       if (access_ok(dst, size))
> +               ret = probe_write_common(dst, src, size);
> +       set_fs(old_fs);
> +
> +       return ret;
> +}
> +EXPORT_SYMBOL_GPL(probe_user_write);
>
>  /**
>   * strncpy_from_unsafe: - Copy a NUL terminated string from unsafe address.
> --
> 2.21.0
>

  reply	other threads:[~2019-10-25 21:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-25 16:37 [PATCH bpf-next 0/5] Fix BPF probe memory helpers Daniel Borkmann
2019-10-25 16:37 ` [PATCH bpf-next 1/5] uaccess: Add non-pagefault user-space write function Daniel Borkmann
2019-10-25 21:53   ` Andrii Nakryiko [this message]
2019-10-25 22:15     ` Daniel Borkmann
2019-10-25 22:43       ` Andrii Nakryiko
2019-10-25 16:37 ` [PATCH bpf-next 2/5] bpf: Make use of probe_user_write in probe write helper Daniel Borkmann
2019-10-25 21:59   ` Andrii Nakryiko
2019-10-25 16:37 ` [PATCH bpf-next 3/5] bpf: Add probe_read_{user,kernel} and probe_read_str_{user,kernel} helpers Daniel Borkmann
2019-10-25 22:08   ` Andrii Nakryiko
2019-10-25 22:20     ` Daniel Borkmann
2019-10-25 16:37 ` [PATCH bpf-next 4/5] bpf, samples: Use bpf_probe_read_user where appropriate Daniel Borkmann
2019-10-25 22:08   ` Andrii Nakryiko
2019-10-25 16:37 ` [PATCH bpf-next 5/5] bpf, testing: Add selftest to read/write sockaddr from user space Daniel Borkmann
2019-10-25 22:14   ` Andrii Nakryiko
2019-10-25 22:38     ` Daniel Borkmann
2019-10-25 23:35       ` Andrii Nakryiko
2019-10-25 23:36   ` 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='CAEf4BzbTKeBabyb3C3Yj5iT8TQC7A7SeUAe=PafaKnqeA4zoVQ@mail.gmail.com' \
    --to=andrii.nakryiko@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --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).