bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
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: Sat, 26 Oct 2019 00:15:30 +0200	[thread overview]
Message-ID: <20191025221530.GD14547@pc-63.home> (raw)
In-Reply-To: <CAEf4BzbTKeBabyb3C3Yj5iT8TQC7A7SeUAe=PafaKnqeA4zoVQ@mail.gmail.com>

On Fri, Oct 25, 2019 at 02:53:07PM -0700, Andrii Nakryiko wrote:
> 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>
> 
> [...]
> 
> > +/**
> > + * 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)?

Seems done by convention to allow archs to override the __weak marked
functions in order to add additional checks and being able to then call
into the __ prefixed variant.

> > +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.

Not entirely sure what you mean. In both there's access_ok() check before
invoking the common helper.

> > +       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 22:15 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
2019-10-25 22:15     ` Daniel Borkmann [this message]
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=20191025221530.GD14547@pc-63.home \
    --to=daniel@iogearbox.net \
    --cc=andrii.nakryiko@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --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).