Date:   Sun, 5 May 2019 14:03:13 -0400
From:   Joel Fernandes <joel@...lfernandes.org>
To:     Qais Yousef <qais.yousef@....com>
Cc:     linux-kernel@...r.kernel.org,
        Michal Gregorczyk <michalgr@...e.com>,
        Adrian Ratiu <adrian.ratiu@...labora.com>,
        Mohammad Husain <russoue@...il.com>,
        Srinivas Ramana <sramana@...eaurora.org>,
        duyuchao <yuchao.du@...soc.com>,
        Manjo Raja Rao <linux@...ojrajarao.com>,
        Karim Yaghmour <karim.yaghmour@...rsys.com>,
        Tamir Carmeli <carmeli.tamir@...il.com>,
        Yonghong Song <yhs@...com>,
        Alexei Starovoitov <ast@...nel.org>,
        Brendan Gregg <brendan.d.gregg@...il.com>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Peter Ziljstra <peterz@...radead.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Kees Cook <keescook@...omium.org>, kernel-team@...roid.com,
        Daniel Borkmann <daniel@...earbox.net>,
        Ingo Molnar <mingo@...hat.com>, netdev@...r.kernel.org,
        Mark Rutland <mark.rutland@....com>,
        Will Deacon <will.deacon@....com>
Subject: Re: [PATCH RFC] bpf: Add support for reading user pointers

On Sun, May 05, 2019 at 03:52:23PM +0000, Joel Fernandes wrote:
> 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.

+Mark, Will since discussion is about arm64 arch code.

The difference between observing the bug and everything just working seems to
be the set_fs(USER_DS) as done by Masami's patch that this patch is based on.
The following diff shows 'ret' as 255 when set_fs(KERN_DS) is used, and then
after we retry with set_fs(USER_DS), the read succeeds.

diff --git a/mm/maccess.c b/mm/maccess.c
index 78f9274dd49d..d3e01a33c712 100644
--- a/mm/maccess.c
+++ b/mm/maccess.c
@@ -32,9 +32,20 @@ long __probe_kernel_read(void *dst, const void *src, size_t size)
 	pagefault_disable();
 	ret = __copy_from_user_inatomic(dst,
 			(__force const void __user *)src, size);
+	trace_printk("KERNEL_DS: __copy_from_user_inatomic: ret=%d\n", ret);
 	pagefault_enable();
 	set_fs(old_fs);
 
+	if (ret) {
+	set_fs(USER_DS);
+	pagefault_disable();
+	ret = __copy_from_user_inatomic(dst,
+			(__force const void __user *)src, size);
+	trace_printk("RETRY WITH USER_DS: __copy_from_user_inatomic: ret=%d\n", ret);
+	pagefault_enable();
+	set_fs(old_fs);
+	}
+
 	return ret ? -EFAULT : 0;
 }
 EXPORT_SYMBOL_GPL(probe_kernel_read);

In initially thought this was because of the addr_limit pointer masking done
by this patch from Mark Rutland "arm64: Use pointer masking to limit uaccess
speculation"

However removing this masking still makes it fail with KERNEL_DS.

Fwiw, I am still curious which other paths in arm64 check the addr_limit
which might make the __copy_from_user_inatomic fail if the set_fs is not
setup correctly.

Either way, I will resubmit the patch with the commit message fixed correctly
as we agreed and also address Alexei's comments.

Thank you!

 - Joel

-- 
2.21.0.1020.gf2820cf01a-goog

Powered by blists - more mailing lists