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  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:   Thu, 17 Sep 2020 10:25:16 +0200
From:   Jiri Olsa <jolsa@...hat.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     Jiri Olsa <jolsa@...nel.org>, Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andriin@...com>, netdev@...r.kernel.org,
        bpf@...r.kernel.org, Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...omium.org>
Subject: Re: [PATCH bpf-next] selftests/bpf: Fix stat probe in d_path test

On Wed, Sep 16, 2020 at 06:45:31PM -0700, Alexei Starovoitov wrote:
> On Wed, Sep 16, 2020 at 01:24:16PM +0200, Jiri Olsa wrote:
> > Some kernels builds might inline vfs_getattr call within fstat
> > syscall code path, so fentry/vfs_getattr trampoline is not called.
> > 
> > Alexei suggested [1] we should use security_inode_getattr instead,
> > because it's less likely to get inlined.
> > 
> > Adding security_inode_getattr to the d_path allowed list and
> > switching the stat trampoline to security_inode_getattr.
> > 
> > Adding flags that indicate trampolines were called and failing
> > the test if any of them got missed, so it's easier to identify
> > the issue next time.
> > 
> > [1] https://lore.kernel.org/bpf/CAADnVQJ0FchoPqNWm+dEppyij-MOvvEG_trEfyrHdabtcEuZGg@mail.gmail.com/
> > Fixes: e4d1af4b16f8 ("selftests/bpf: Add test for d_path helper")
> > Signed-off-by: Jiri Olsa <jolsa@...hat.com>
> > ---
> >  kernel/trace/bpf_trace.c                        | 1 +
> >  tools/testing/selftests/bpf/prog_tests/d_path.c | 6 ++++++
> >  tools/testing/selftests/bpf/progs/test_d_path.c | 9 ++++++++-
> >  3 files changed, 15 insertions(+), 1 deletion(-)
> > 
> > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> > index b2a5380eb187..1001c053ebb3 100644
> > --- a/kernel/trace/bpf_trace.c
> > +++ b/kernel/trace/bpf_trace.c
> > @@ -1122,6 +1122,7 @@ BTF_ID(func, vfs_truncate)
> >  BTF_ID(func, vfs_fallocate)
> >  BTF_ID(func, dentry_open)
> >  BTF_ID(func, vfs_getattr)
> > +BTF_ID(func, security_inode_getattr)
> >  BTF_ID(func, filp_close)
> >  BTF_SET_END(btf_allowlist_d_path)
> 
> I think it's concealing the problem instead of fixing it.
> bpf is difficult to use for many reasons. Let's not make it harder.
> The users will have a very hard time debugging why vfs_getattr bpf probe
> is not called in all cases.
> Let's replace:
> vfs_truncate -> security_path_truncate
> vfs_fallocate -> security_file_permission
> vfs_getattr -> security_inode_getattr
> 
> For dentry_open also add security_file_open.
> dentry_open and filp_close are in its own files,
> so unlikely to be inlined.

ok

> Ideally resolve_btfids would parse dwarf info and check
> whether any of the funcs in allowlist were inlined.
> That would be more reliable, but not pretty to drag libdw
> dependency into resolve_btfids.

hm, we could add some check to perf|bpftrace that would 
show you all the places where function is called from and
if it was inlined or is a regular call.. so user is aware
what probe calls to expect

> 
> >  
> > diff --git a/tools/testing/selftests/bpf/prog_tests/d_path.c b/tools/testing/selftests/bpf/prog_tests/d_path.c
> > index fc12e0d445ff..f507f1a6fa3a 100644
> > --- a/tools/testing/selftests/bpf/prog_tests/d_path.c
> > +++ b/tools/testing/selftests/bpf/prog_tests/d_path.c
> > @@ -120,6 +120,12 @@ void test_d_path(void)
> >  	if (err < 0)
> >  		goto cleanup;
> >  
> > +	if (CHECK(!bss->called_stat || !bss->called_close,
> 
> +1 to KP's comment.

ok

thanks,
jirka

Powered by blists - more mailing lists