netdev - Re: [RFC 0/3] bpf: Add d

lists.openwall.net		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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200406090918.GA3035739@krava>
Date:   Mon, 6 Apr 2020 11:09:18 +0200
From:   Jiri Olsa <jolsa@...hat.com>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Jiri Olsa <jolsa@...nel.org>, Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>, netdev@...r.kernel.org,
        bpf@...r.kernel.org, Yonghong Song <yhs@...com>,
        Martin KaFai Lau <kafai@...com>,
        David Miller <davem@...hat.com>,
        John Fastabend <john.fastabend@...il.com>,
        Jesper Dangaard Brouer <hawk@...nel.org>,
        Wenbo Zhang <ethercflow@...il.com>,
        KP Singh <kpsingh@...omium.org>,
        Andrii Nakryiko <andriin@...com>, bgregg@...flix.com
Subject: Re: [RFC 0/3] bpf: Add d_path helper

On Mon, Apr 06, 2020 at 04:16:02AM +0100, Al Viro wrote:
> On Fri, Apr 03, 2020 at 11:08:28AM +0200, Jiri Olsa wrote:
> 
> > if we limit it just to task context I think it would still be
> > helpful for us:
> > 
> >   if (in_task())
> > 	d_path..
> > 
> > perhaps even create a d_path version without d_dname callback
> > if that'd be still a problem, because it seems to be there mainly
> > for special filesystems..?
> 
> IDGI...
> 	1) d_path(), by definition, is dependent upon the
> process' root - the same <mount,dentry> pair will yield
> different strings if caller is chrooted.  You *can't* just
> use a random process' root
> 	2) we are *NOT* making rename_lock and mount_lock
> disable interrupts.  Not happening.
> 
> So it has to be process-synchronous anyway.  Could you describe
> where that thing is going to be callable?

it could be called as bpf helper from any place we could put
the trampoline probe on.. so most of the kernel functions
(at entry or exit) .. we can make checks, like for context
before we allow to call it

is there any way we could have d_path functionality (even
reduced and not working for all cases) that could be used
or called like that?

thanks,
jirka