From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Sargun Dhillon <sargun@sargun.me>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Daniel Borkmann <daniel@iogearbox.net>
Subject: Re: [PATCH 1/1] tracing, bpf: Implement function bpf_probe_write
Date: Wed, 13 Jul 2016 10:08:51 -0700 [thread overview]
Message-ID: <20160713170849.GA76615@ast-mbp.thefacebook.com> (raw)
In-Reply-To: <CAMp4zn8ygXFg7kvjShm77zmK2dYVMY2zS8i2mUKwhbfXcyVyig@mail.gmail.com>
On Wed, Jul 13, 2016 at 03:36:11AM -0700, Sargun Dhillon wrote:
> Provides BPF programs, attached to kprobes a safe way to write to
> memory referenced by probes. This is done by making probe_kernel_write
> accessible to bpf functions via the bpf_probe_write helper.
not quite :)
> Signed-off-by: Sargun Dhillon <sargun@sargun.me>
> ---
> include/uapi/linux/bpf.h | 3 +++
> kernel/trace/bpf_trace.c | 20 ++++++++++++++++++++
> samples/bpf/bpf_helpers.h | 2 ++
> 3 files changed, 25 insertions(+)
>
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 406459b..355b565 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -313,6 +313,9 @@ enum bpf_func_id {
> */
> BPF_FUNC_skb_get_tunnel_opt,
> BPF_FUNC_skb_set_tunnel_opt,
> +
> + BPF_FUNC_probe_write, /* int bpf_probe_write(void *dst, void *src,
> int size) */
> +
the patch is against some old kernel.
Please always make the patch against net-next tree and cc netdev list.
> +static u64 bpf_probe_write(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
> +{
> + void *dst = (void *) (long) r1;
> + void *unsafe_ptr = (void *) (long) r2;
> + int size = (int) r3;
> +
> + return probe_kernel_write(dst, unsafe_ptr, size);
> +}
the patch is whitepsace mangled. Please see Documentation/networking/netdev-FAQ.txt
the main issue though that we cannot simply allow bpf to do probe_write,
since it may crash the kernel.
What might be ok is to allow writing into memory of current
user space process only. This way bpf prog will keep kernel safety guarantees,
yet it will be able to modify user process memory when necessary.
Since bpf+tracing is root only, it doesn't pose security risk.
next prev parent reply other threads:[~2016-07-13 17:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-13 10:36 Sargun Dhillon
2016-07-13 17:08 ` Alexei Starovoitov [this message]
2016-07-13 20:31 ` Sargun Dhillon
2016-07-15 5:40 ` Alexei Starovoitov
2016-07-16 2:16 ` Sargun Dhillon
2016-07-16 2:30 ` Alexei Starovoitov
2016-07-17 10:19 ` Sargun Dhillon
2016-07-18 4:11 ` Alexei Starovoitov
2016-07-18 10:57 ` Sargun Dhillon
2016-07-19 6:13 ` Alexei Starovoitov
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=20160713170849.GA76615@ast-mbp.thefacebook.com \
--to=alexei.starovoitov@gmail.com \
--cc=daniel@iogearbox.net \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sargun@sargun.me \
/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
all inboxes | Powered by JetHome®