Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sun, 5 May 2019 15:52:23 +0000
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
Message-ID: <20190505155223.GA4976@localhost>
References: <20190502204958.7868-1-joel@joelfernandes.org>
 <20190503121234.6don256zuvfjtdg6@e107158-lin.cambridge.arm.com>
 <20190503134935.GA253329@google.com>
 <20190505110423.u7g3f2viovvgzbtn@e107158-lin.cambridge.arm.com>
 <20190505132949.GB3076@localhost>
 <20190505144608.u3vsxyz5huveuskx@e107158-lin.cambridge.arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190505144608.u3vsxyz5huveuskx@e107158-lin.cambridge.arm.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sun, May 05, 2019 at 03:46:08PM +0100, Qais Yousef wrote:
> On 05/05/19 13:29, Joel Fernandes wrote:
> > On Sun, May 05, 2019 at 12:04:24PM +0100, Qais Yousef wrote:
> > > On 05/03/19 09:49, Joel Fernandes wrote:
> > > > 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.
> > > 
> > > Yes I wasn't arguing against that. But the commit message is misleading or
> > > needs more explanation at least. I tried 4.9.y stable and arm64 worked on that
> > > too. Why do you think it's an arm64 problem?
> > 
> > Well it is broken on at least on at least one arm64 device and the patch I
> > sent fixes it. We know that the bpf is using wrong kernel API so why not fix
> > it? Are you saying we should not fix it like in this patch? Or do you have
> > another fix in mind?
> 
> Again I have no issue with the new API. But the claim that it's a fix for
> a broken arm64 is a big stretch. AFAICT you don't understand the root cause of
> why copy_to_user_inatomic() fails in your case. Given that Android 4.9 has
> its own patches on top of 4.9 stable, it might be something that was introduced
> in one of these patches that breaks opensnoop, and by making it use the new API
> you might be simply working around the problem. All I can see is that vanilla
> 4.9 stable works on arm64.

Agreed that commit message could be improved. I believe issue is something to
do with differences in 4.9 PAN emulation backports. AIUI PAN was introduced
in upstream only in 4.10 so 4.9 needed backports.

I did not root cause this completely because "doing the right thing" fixed
the issue. I will look more closely once I am home.

Thank you.


> So I am happy about introducing the new API but not happy with the commit
> message or the explanation given in it. Unless you can investigate the root
> cause and relate how this fixes it (and not workaround a problem you're
> specifically having) I think it's better to introduce this patch as a generic
> new API that is more robust to handle reading __user data in BPF and drop
> reference to opensnoop failures. They raise more questions and the real
> intention of this patch anyway is to provide the new correct way for BPF
> programs to read __user data regardless opensnoop fails or not AFAIU.
> 
> Cheers
> 
> --
> Qais Yousef