From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 21C65CD128A for ; Tue, 9 Apr 2024 23:54:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AE7866B0099; Tue, 9 Apr 2024 19:54:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A974F6B009B; Tue, 9 Apr 2024 19:54:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 95F376B009C; Tue, 9 Apr 2024 19:54:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 76F0D6B0099 for ; Tue, 9 Apr 2024 19:54:41 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 0DC4B80153 for ; Tue, 9 Apr 2024 23:54:41 +0000 (UTC) X-FDA: 81991650762.15.52B229F Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf19.hostedemail.com (Postfix) with ESMTP id 8EBF01A000C for ; Tue, 9 Apr 2024 23:54:37 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=NwojOdW2; spf=pass (imf19.hostedemail.com: domain of mhiramat@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=mhiramat@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712706878; h=from:from:sender: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:dkim-signature; bh=eWJPFimcD1LFvR4R9EcfDpsxprCMH5/d7paQfWIfIz0=; b=bqPCeso4GHQ4BfRlk+zRWTx2cJO3VWDZ31J8Z6a1EUa3hyueTimI8xHvmNjcPRFDTta+qv gxIidifJLxxw52hBm6/rx+QxBeHyeyGYfRYph3gOR8+PfKG9wgkkuR9nmIk02IEOF9MOd4 fRWrPL5zihKS4PxqzhrtotbRQEg2iXY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712706878; a=rsa-sha256; cv=none; b=5mwAGbWp8jLuslkM6t5yljvwqoMFBYAbCW9/rK/UakNG2ddxGIhspJ7KqEaLVmdqmbDNeY Ns3iiFrA9/A5vvW4RZEUM1NBiQ8tD+kJu3sh+NC9LMHWjxpavk79KqQ/qqnVTa1rP8CiE3 CPviptJjiG+KdeevPMwVFFmZn7WEeCk= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=NwojOdW2; spf=pass (imf19.hostedemail.com: domain of mhiramat@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=mhiramat@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 6AD5CCE0B49; Tue, 9 Apr 2024 23:54:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6E1A9C433F1; Tue, 9 Apr 2024 23:54:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1712706873; bh=t1NhF4nrxdQhhoLefZQtEgoMWYKkMCdVLx8xtlo79Mw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=NwojOdW2AUtmiM4odkHOSUKtAmqdBkpXq4Sienw6hV91VcOgqBhaTkP76EaYBwmvm MBkGDAY6vmhV262dis86jOzkdodmqdQOnR2F23XwGnbtXO3VsZgxs5qTAFAHqp04uA zFyIk7eMTdtL4aGRMgDaBvjZzkourZhvpq0j8eSOAUwk9zdyMZZuhjkWzeC4TVyTMc 0YdNVxcu1YDvf3IxXdYZK9qX586ukiLZj9FwOM+I2YY8t/K9jUCK4bGIpvIEZ8P6zi TlOjbfmbpw23dA7/cVNp44QysvPU+TUeiWYqFr2b73mrRqrfsBQwB6ZdKdueiIl/AM 4pezmDgjCkQNw== Date: Wed, 10 Apr 2024 08:54:28 +0900 From: Masami Hiramatsu (Google) To: Marco Elver Cc: Steven Rostedt , Eric Biederman , Kees Cook , Alexander Viro , Christian Brauner , Jan Kara , Masami Hiramatsu , Mathieu Desnoyers , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, Dmitry Vyukov Subject: Re: [PATCH] tracing: Add new_exec tracepoint Message-Id: <20240410085428.53093333cf4d768d6b420a11@kernel.org> In-Reply-To: References: <20240408090205.3714934-1-elver@google.com> <20240409103327.7a9012fa@gandalf.local.home> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 8EBF01A000C X-Rspam-User: X-Stat-Signature: ow7ttw54uuytxcq93abxhcwzd1y5qgn7 X-Rspamd-Server: rspam03 X-HE-Tag: 1712706877-312916 X-HE-Meta: U2FsdGVkX18mz0DFOWvrJz4K5vt/f+2UqZgh8Nq4ipmsLVsQHCq1V/MS9THtQkh69DzsF5vOh89gpxjX4iNfFkSk5xUznoFGd0vZ1EMqVaG8mX5JD0uqKsgHNTNWH1c4fonMerJ7Sx/bAeqQKp98H3gpn1ajWoXl5cbgKURjUBP2gLyEyqnZzSJLm8wVMZ3OiCQSYzo/0ntKw3OR97vwicD+u3PEf1EMgc+8wRijP/t3Mys0jFopF5WVqGANMqn9acMt1Ig2qL9/Pn6YD+qItr+r0yQuyfKOJLIrInSTZRLPAYZBYw8wntQIF4YLZruRdZxc15x+IQpe0BvCTuLVSzdk85oJ4bx8UQR4ESsOLOolkrLyAjV6xYa/oNppKiBciSw1p/7PEng5yXSJpNH6zDokjZFEQGZtJWFVX5orDTVSqzEG3qHy3MJmmIqhL+p5j8TJJWWqQhFN31dY+dX3l1/PLijY2ZQCHvOjr75WcxHrl3O0dDbkg259XXx3lfRnz1v+YiHVgbB9HHFZlh0DauD0IoslD+l7TSEG8E2BKL7MeIwxhiHNXG/+JlENddRtXPi7ijhdqBc5uwWOG20cMrZQ6s/FPNqcwO84WYXetxbxYWKbLUAILIWFfamc7/pyx1+erBVi20j0/Ol/9rnOPdvyptslaFCRw0IeRRU1TzdvhUwBemcFFaer7swBZW/HhkgAWEzVPn6cR06xwa9QacJL2d3PN5Gb/CKmV2wfg7DTRcRdlKLQFqDmEs4gI/rX/kkXLsc9lF0gdMIXsLXHP28uudNs1/BPLW8iufNtjprh6gph+imZt17s3bA3dN+jh8qXK1YapPpHSE81l7e1z1J+iMJQyJaQzl91G4vjDKEniYY1xi0JrpBUA2osjot6shSBNmc6G8eZWM13uaGcp9DEHNNPfpaNJlJ+LpXY4hqv4S+SKxeq17D6dKLDP4Z9+40H9hBql86kAdgNWKT 0ZpPjP0d HbguMcgEXb4rg8ESFAmthLR/0fH8jZJOer1Qux19GlIxukP0ApkHsC9LoxAvGVu+SUyRAnHzDyg5H1SCDG6lDgxwRC1TckNEeWHA/GDJJULdW9u/ctVN65H79VTW/m6reIS3VDIWZZBL7DhKlxgGJ8W7Xlu0IHp4TTZls+c5bGQyRX5+Bf2nGD5k2bjt+9P27zC8DHp9sM2UXvdegfWej+ORsLds2m5LTOomIM8LWI5v4kk7AuzrS1V8T05lYMUtaOSJ3OA1kQ2O7OH5qiSklM5GUpw8u3IWLKN5Gn+cP4g9xT2qFeRxSXZ83fhl9rNi3c87zX4MUkPJY6kQ2U6zHz6LSxSAhaYjACMomI/er983BuCD8B25JxW8332ziUcmfuwDUy1rPT+fvJqRNKUQ3tECfsg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, 9 Apr 2024 16:45:47 +0200 Marco Elver wrote: > On Tue, 9 Apr 2024 at 16:31, Steven Rostedt wrote: > > > > On Mon, 8 Apr 2024 11:01:54 +0200 > > Marco Elver wrote: > > > > > Add "new_exec" tracepoint, which is run right after the point of no > > > return but before the current task assumes its new exec identity. > > > > > > Unlike the tracepoint "sched_process_exec", the "new_exec" tracepoint > > > runs before flushing the old exec, i.e. while the task still has the > > > original state (such as original MM), but when the new exec either > > > succeeds or crashes (but never returns to the original exec). > > > > > > Being able to trace this event can be helpful in a number of use cases: > > > > > > * allowing tracing eBPF programs access to the original MM on exec, > > > before current->mm is replaced; > > > * counting exec in the original task (via perf event); > > > * profiling flush time ("new_exec" to "sched_process_exec"). > > > > > > Example of tracing output ("new_exec" and "sched_process_exec"): > > > > How common is this? And can't you just do the same with adding a kprobe? > > Our main use case would be to use this in BPF programs to become > exec-aware, where using the sched_process_exec hook is too late. This > is particularly important where the BPF program must stop inspecting > the user space's VM when the task does exec to become a new process. Just out of curiousity, would you like to audit that the user-program is not malformed? (security tracepoint?) I think that is an interesting idea. What kind of information you need? > > kprobe (or BPF's fentry) is brittle here, because begin_new_exec()'s > permission check can still return an error which returns to the > original task without crashing. Only at the point of no return are we > guaranteed that the exec either succeeds, or the task is terminated on > failure. Just a note: That is BPF limitation, kprobe and kprobe events can put a probe in the function body, but that is not supported on BPF (I guess because it depends on kernel debuginfo.) You can add kprobe-event using "perf probe" tool. Thank you, > > I don't know if "common" is the right question here, because it's a > chicken-egg problem: no tracepoint, we give up; we have the > tracepoint, it unlocks a range of new use cases (that require robust > solution to make BPF programs exec-aware, and a tracepoint is the only > option IMHO). > > Thanks, > -- Marco -- Masami Hiramatsu (Google)