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
| ||
|
Date: Sat, 23 Nov 2019 05:35:14 +0000 From: Al Viro <viro@...iv.linux.org.uk> To: Alexei Starovoitov <alexei.starovoitov@...il.com> Cc: Wenbo Zhang <ethercflow@...il.com>, bpf@...r.kernel.org, ast@...nel.org.com, daniel@...earbox.net, yhs@...com, andrii.nakryiko@...il.com, netdev@...r.kernel.org, linux-fsdevel@...r.kernel.org Subject: Re: [PATCH bpf-next v10 1/2] bpf: add new helper get_file_path for mapping a file descriptor to a pathname On Fri, Nov 22, 2019 at 09:19:21PM -0800, Alexei Starovoitov wrote: > hard to tell. It will be run out of bpf prog that attaches to kprobe or > tracepoint. What is the concern about locking? > d_path() doesn't take any locks and doesn't depend on any locks. Above 'if' > checks that plain d_path() is used and not some specilized callback with > unknown logic. It sure as hell does. It might end up taking rename_lock and/or mount_lock spinlock components. It'll try not to, but if the first pass ends up with seqlock mismatch, it will just grab the spinlock the second time around. > > with this number; quite possibly never before that function had been called > > _and_ not once after it has returned. > > Right. TOCTOU is not a concern here. It's tracing. It's ok for full path to be > 'one time deal'. It might very well be a full path of something completely unrelated to what the syscall ends up operating upon. It's not that the file might've been moved; it might be a different file. IOW, results of that tracing might be misleading.
Powered by blists - more mailing lists