From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-170.mta0.migadu.com (out-170.mta0.migadu.com [91.218.175.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CE684185E7F for ; Fri, 30 May 2025 01:56:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748570172; cv=none; b=So8XabsyWR0d7XFAwlzlfKZU67a2QH+dwbwLa63HsmEkt20gl5MqbnZ6+XXkw+5E9/VbqHixIYM4yCeT+QIRxkCaxukeSiGEiE55zkIGvi25GjcOShbg/MOc8Pq0d6hSagoLPow9vbV7BXrZgjRbgQfkQO0ZgfhdR0KcMXTj07U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748570172; c=relaxed/simple; bh=u7VyUFhkpp3iahCut82BwLg3+2sCvnO38zqnNgASCpY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ppdBZf9dPtOdx5TY7uJpeUyFdi3DNDWZulIHX8CCq8Df/sCpHweEXePnRG/nHN4PYRksq149/j5UNeiHvJHwQOGUFTDJGnm4poG/VJmnU16XkY70sQJ/XymJJBE/U2bCF3uHcUph8ZAuGUfkRzv6u7PIYDXoOS6ocKRjrEoaanE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=MOqa+S2B; arc=none smtp.client-ip=91.218.175.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="MOqa+S2B" Message-ID: <599838d4-7faf-41ce-9a7f-6eebd5173db7@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1748570165; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=q9wJXvfCN3kwmaDp7fZIzUrWKt3creevaq+W6CDqyW4=; b=MOqa+S2BTvgi6QE6ogqD4uge/Rm/j4oBEMhrH97yjl3kSkpfGECd1sUEHG1E56arwPsoDu 0oaMn1mT2NjMCDm91Q8Re4F+tDZrG1JsHEzNfofBmLeEKu1yjg0QuFes2mLVodBqfdN2Tr HhKCuqZxxN57W6Kppw50A+vHDw+wGyE= Date: Thu, 29 May 2025 18:55:56 -0700 Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH bpf-next 1/2] bpf: Add bpf_task_cwd_from_pid() kfunc Content-Language: en-GB To: Rong Tao , Alexei Starovoitov Cc: Alexei Starovoitov , Daniel Borkmann , rongtao@cestc.cn, Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Mykola Lysenko , Shuah Khan , Juntong Deng , Amery Hung , Dave Marchevsky , Hou Tao , "open list:BPF [GENERAL] (Safe Dynamic Programs and Tools)" , open list , "open list:KERNEL SELFTEST FRAMEWORK" References: X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Yonghong Song In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 5/29/25 6:28 PM, Rong Tao wrote: > > On 5/29/25 13:44, Alexei Starovoitov wrote: >> On Wed, May 28, 2025 at 8:37 PM Rong Tao wrote: >>> From: Rong Tao >>> >>> It is a bit troublesome to get cwd based on pid in bpf program, such as >>> bpftrace example [1]. >>> >>> This patch therefore adds a new bpf_task_cwd_from_pid() kfunc which >>> allows BPF programs to get cwd from a pid. >>> >>> [1] https://github.com/bpftrace/bpftrace/issues/3314 >> Yes. This is cumbersome, but adding a very specific kfunc >> to the kernel is not a solution. >> This is tracing, no need for precise cwd. probe_read_kernel >> can do the job. bpftrace needs to have better C interop. >> Once that happens any kind of tracing extraction will be >> easy to write in C. Like this bpf_task_cwd_from_pid() >> can already be written as C bpf program. > Thanks for your reply, Yesterday I tried many ways to implement > the solution of getting cwd from pid/task, but all failed. The basic > idea is to rewrite the d_path() code, but in the bpf program, there > will be various memory security access problems, even if enough >  `if (!ptr)` are added, the program cannot be loaded successfully. > > https://github.com/Rtoax/bcc/commit/2ba7a2389fc1183264e5195ff26561d93038886c > > >     bcc/tools$ sudo ./opensnoop.py -F > >     ; if (dentry == vfsmnt->mnt_root || dentry == dentry->d_parent) { > @ main.c:174 >     109: (79) r2 = *(u64 *)(r7 +0) >     R7 invalid mem access 'scalar' I think you can use bpf_probe_read_kernel() helper to get r2? > > At the same time, bpf_d_path cannot be used because it can only be > applied to functions in btf_allowlist_d_path. Currently, it is > impossible to get cwd from pid/task in user mode. Any suggestions? > > In addition, I fully tested this patch yesterday and it performed well. > > Rong Tao > >