From: Joel Fernandes <joel@joelfernandes.org>
To: Qais Yousef <qais.yousef@arm.com>
Cc: linux-kernel@vger.kernel.org,
Michal Gregorczyk <michalgr@live.com>,
Adrian Ratiu <adrian.ratiu@collabora.com>,
Mohammad Husain <russoue@gmail.com>,
Srinivas Ramana <sramana@codeaurora.org>,
duyuchao <yuchao.du@unisoc.com>,
Manjo Raja Rao <linux@manojrajarao.com>,
Karim Yaghmour <karim.yaghmour@opersys.com>,
Tamir Carmeli <carmeli.tamir@gmail.com>,
Yonghong Song <yhs@fb.com>, Alexei Starovoitov <ast@kernel.org>,
Brendan Gregg <brendan.d.gregg@gmail.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
Peter Ziljstra <peterz@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
Kees Cook <keescook@chromium.org>,
kernel-team@android.com, Daniel Borkmann <daniel@iogearbox.net>,
Ingo Molnar <mingo@redhat.com>,
netdev@vger.kernel.org
Subject: Re: [PATCH RFC] bpf: Add support for reading user pointers
Date: Fri, 3 May 2019 09:49:35 -0400 [thread overview]
Message-ID: <20190503134935.GA253329@google.com> (raw)
In-Reply-To: <20190503121234.6don256zuvfjtdg6@e107158-lin.cambridge.arm.com>
On Fri, May 03, 2019 at 01:12:34PM +0100, Qais Yousef wrote:
> Hi Joel
>
> On 05/02/19 16:49, Joel Fernandes (Google) wrote:
> > The eBPF based opensnoop tool fails to read the file path string passed
> > to the do_sys_open function. This is because it is a pointer to
> > userspace address and causes an -EFAULT when read with
> > probe_kernel_read. This is not an issue when running the tool on x86 but
> > is an issue on arm64. This patch adds a new bpf function call based
>
> I just did an experiment and if I use Android 4.9 kernel I indeed fail to see
> PATH info when running opensnoop. But if I run on 5.1-rc7 opensnoop behaves
> correctly on arm64.
>
> My guess either a limitation that was fixed on later kernel versions or Android
> kernel has some strict option/modifications that make this fail?
Thanks a lot for checking, yes I was testing 4.9 kernel with this patch (pixel 3).
I am not sure what has changed since then, but I still think it is a good
idea to make the code more robust against such future issues anyway. In
particular, we learnt with extensive discussions that user/kernel pointers
are not necessarily distinguishable purely based on their address.
I hope agree this is an issue we need to fix.
See these discussions:
https://lkml.kernel.org/r/20190220171019.5e81a4946b56982f324f7c45@kernel.org
https://lore.kernel.org/lkml/20190220171019.5e81a4946b56982f324f7c45@kernel.org/T/#mf81816dbfe25ac5d0e96fbab029050e892f73af2
thanks,
- Joel
> root@buildroot:/# uname -a
> Linux buildroot 5.1.0-rc7-00164-ga00214620959-dirty #41 SMP PREEMPT Thu May 2 16:33:00 BST 2019 aarch64 GNU/Linux
> root@buildroot:/# opensnoop
> PID COMM FD ERR PATH
> 5180 default.script -1 2 /etc/ld.so.cache
> 5180 default.script -1 2 /lib/tls/v8l/neon/vfp/libresolv.so.2
> 5180 default.script -1 2 /lib/tls/v8l/neon/libresolv.so.2
> 5180 default.script -1 2 /lib/tls/v8l/vfp/libresolv.so.2
> 5180 default.script -1 2 /lib/tls/v8l/libresolv.so.2
> 5180 default.script -1 2 /lib/tls/neon/vfp/libresolv.so.2
> 5180 default.script -1 2 /lib/tls/neon/libresolv.so.2
> 5180 default.script -1 2 /lib/tls/vfp/libresolv.so.2
> 5180 default.script -1 2 /lib/tls/libresolv.so.2
> 5180 default.script -1 2 /lib/v8l/neon/vfp/libresolv.so.2
> 5180 default.script -1 2 /lib/v8l/neon/libresolv.so.2
> 5180 default.script -1 2 /lib/v8l/vfp/libresolv.so.2
> 5180 default.script -1 2 /lib/v8l/libresolv.so.2
> 5180 default.script -1 2 /lib/neon/vfp/libresolv.so.2
> 5180 default.script -1 2 /lib/neon/libresolv.so.2
> 5180 default.script -1 2 /lib/vfp/libresolv.so.2
> 5180 default.script 3 0 /lib/libresolv.so.2
> 5180 default.script 3 0 /lib/libc.so.6
> 5180 default.script 3 0 /usr/share/udhcpc/default.script
> 5180 default.script 3 0 /usr/share/udhcpc/default.script.d/
>
>
>
>
> --
> Qais Yousef
next prev parent reply other threads:[~2019-05-03 13:49 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-02 20:49 [PATCH RFC] bpf: Add support for reading user pointers Joel Fernandes (Google)
2019-05-03 12:12 ` Qais Yousef
2019-05-03 13:49 ` Joel Fernandes [this message]
2019-05-03 13:54 ` Peter Zijlstra
2019-05-03 15:09 ` Joel Fernandes
2019-05-05 11:04 ` Qais Yousef
2019-05-05 13:29 ` Joel Fernandes
2019-05-05 14:46 ` Qais Yousef
2019-05-05 15:52 ` Joel Fernandes
2019-05-05 18:03 ` Joel Fernandes
2019-05-05 18:51 ` Andrii Nakryiko
2019-05-06 0:01 ` Qais Yousef
2019-05-06 18:35 ` Will Deacon
2019-05-06 20:58 ` Joel Fernandes
2019-05-06 21:57 ` Qais Yousef
2019-05-07 9:52 ` Will Deacon
2019-05-08 2:00 ` Joel Fernandes
2019-05-05 7:19 ` Alexei Starovoitov
2019-05-05 13:33 ` Joel Fernandes
2019-05-06 14:47 ` Masami Hiramatsu
2019-05-06 16:14 ` Joel Fernandes
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=20190503134935.GA253329@google.com \
--to=joel@joelfernandes.org \
--cc=adrian.ratiu@collabora.com \
--cc=ast@kernel.org \
--cc=brendan.d.gregg@gmail.com \
--cc=carmeli.tamir@gmail.com \
--cc=daniel@iogearbox.net \
--cc=karim.yaghmour@opersys.com \
--cc=keescook@chromium.org \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@manojrajarao.com \
--cc=mhiramat@kernel.org \
--cc=michalgr@live.com \
--cc=mingo@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=qais.yousef@arm.com \
--cc=rostedt@goodmis.org \
--cc=russoue@gmail.com \
--cc=sramana@codeaurora.org \
--cc=yhs@fb.com \
--cc=yuchao.du@unisoc.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.