Messages in this thread | | | From | Andrii Nakryiko <> | Date | Sun, 5 May 2019 11:51:40 -0700 | Subject | Re: [PATCH RFC] bpf: Add support for reading user pointers |
| |
On Sun, May 5, 2019 at 11:08 AM Joel Fernandes <joel@joelfernandes.org> wrote: > > 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.
Can you please also split the sync of tools/include/uapi/linux/bpf.h into separate commit. Having it along the other changes causes issues when syncing libbpf code (and headers it depends on) to a github mirror (github.com/libbpf/libbpf). Thanks!
> > Thank you! > > - Joel > > -- > 2.21.0.1020.gf2820cf01a-goog >
| |