lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 5 May 2019 12:04:24 +0100
From:   Qais Yousef <>
To:     Joel Fernandes <>
        Michal Gregorczyk <>,
        Adrian Ratiu <>,
        Mohammad Husain <>,
        Srinivas Ramana <>,
        duyuchao <>,
        Manjo Raja Rao <>,
        Karim Yaghmour <>,
        Tamir Carmeli <>,
        Yonghong Song <>,
        Alexei Starovoitov <>,
        Brendan Gregg <>,
        Masami Hiramatsu <>,
        Peter Ziljstra <>,
        Steven Rostedt <>,
        Kees Cook <>,,
        Daniel Borkmann <>,
        Ingo Molnar <>,
Subject: Re: [PATCH RFC] bpf: Add support for reading user pointers

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?

Qais Yousef

Powered by blists - more mailing lists