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 7A559CD1296 for ; Wed, 10 Apr 2024 07:55:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E22E86B0083; Wed, 10 Apr 2024 03:55:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DD2286B0085; Wed, 10 Apr 2024 03:55:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CC1586B0087; Wed, 10 Apr 2024 03:55:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id AF3FB6B0083 for ; Wed, 10 Apr 2024 03:55:31 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 404C54069E for ; Wed, 10 Apr 2024 07:55:31 +0000 (UTC) X-FDA: 81992862462.12.C5C865D Received: from mail-vk1-f178.google.com (mail-vk1-f178.google.com [209.85.221.178]) by imf16.hostedemail.com (Postfix) with ESMTP id 899E6180007 for ; Wed, 10 Apr 2024 07:55:29 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=rF9VPNtl; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of elver@google.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=elver@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712735729; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=uS3BUxF5qCtTkHZxGjFabw9iVy7E/k2BpkwDClQgffY=; b=3Z7OA/InH6YQedU2t+ADlBfpRvUG0lfs+8yLH+ipKhUJhXS8sMefZ0OTDBVCkFR/E/BOHr Eo73NR7KvYSxA53TMuZ80M8h91Sa1RBGruInnpIyNoQNlRN/MrTt7LCFOV/VcQ3SeHuOln rXzjhYCPXP9EsTt7Oge/INrDRtkbovE= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=rF9VPNtl; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of elver@google.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=elver@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712735729; a=rsa-sha256; cv=none; b=LhRUbZZdUFdCGPIXC6Md2Zr0vftELsaA3qwRgkB+jSexcQ1El7n4HvLR4uvZuSxy3OpKvk xfwYajooI+XBqu8/Gn6oG/T1cjXPM2KxsMs3iUFA4Iz41ZHm54u+jJLCmxA765UllVLhe7 lIGFz+1jfPw1t0iN1iDaMaelA5mcJck= Received: by mail-vk1-f178.google.com with SMTP id 71dfb90a1353d-4dac19aa9b5so1334600e0c.2 for ; Wed, 10 Apr 2024 00:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1712735728; x=1713340528; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=uS3BUxF5qCtTkHZxGjFabw9iVy7E/k2BpkwDClQgffY=; b=rF9VPNtlGWXH+dDh20pyuQd9awU07wiTr5udWPfUYZcc1uSBuMe+uHr0ICWHsREO8h 9wRjwl3llAyLrbcdKdK/23Y6UwPhxt8yEhltgg5+Z8ejJj1m5FtgRJk0TitG/yGnfMxf fGdE/u8SNCajsQcSiZzciLWx/jXorFaC5yjMdQ0NZrw/ki4bsM6u/pH6pRKA78C9bQC9 qujXyS5SvNovhGPoNMBo5dqbHCVIjKpbQYioJJeAxRvEzKv0wfQMrUhS1KUUnbDkhEIy GtBBXQhNTwvsdO6mzlLmvazv5ERW+kCp6+nrBmI+runP0p1NKS4hmRuYQ9ArdzXAF5Mr RD9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712735728; x=1713340528; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uS3BUxF5qCtTkHZxGjFabw9iVy7E/k2BpkwDClQgffY=; b=Df/vB9yXqsNnR4HYOA8XIM4jHOJPwcY1YwzMfflcyefXRkLNmSle6SdfqjhJ8dFYUo dMMdeiOjB2rysL2PkHwQ4IVdSmkk+0f8H4EHUfQGWKSMgO1lNC2ckeNKkzsOHkmi9O7i ZB7WhYql6PJyfx8UkLR3pLoGO/YmvDpdpTFey6XRU/hmZe1IUGI4gmqt3vINhbawFpwP k9hcmNNTyJuU5NRalE5Oju6o4JVUMDBa4xOTigLSs+oRl4EmndzVcJcU8tssTAmqlrHH e9vupKXDFkM0VBgntRApyi20uOCzqL/Z+peFUxwnx44ee3Ku/4WgEYXLjfZUip0sFQv4 Twww== X-Forwarded-Encrypted: i=1; AJvYcCXwmI00ZuezzZmCjr/wtI711GsyN+63KqqsmopyDpSH4l7YP1O8v7S7uMeFPv2y5wLRxRw0zq3EaAAVrIL/Y9/2Gjs= X-Gm-Message-State: AOJu0Yz6FgnnKQ3c7OPTGLeNOnO17bU8TDk+rGxLM3pkM8phTRTDA6wb 7d/oXoi9AXFs3wVFw5hgHhpSdJqUYd2hlNDd99OiXrNbEH9fY0JJg/YPgHN8G8CAmBtNWippmDQ er2eyF/M8Wx1kxhjzJpqHRj0riqSt3D/dLAUa X-Google-Smtp-Source: AGHT+IFzeD+gUEtV1nuDqVBhWDhR3c8rh+fHfgbCTEvNgaxLAeR6T5heeQ/A7dsx9xLWrUTVzlCnXl+91EEnZ3Eql3Q= X-Received: by 2002:a05:6122:251f:b0:4d8:7443:bca7 with SMTP id cl31-20020a056122251f00b004d87443bca7mr2070748vkb.6.1712735728391; Wed, 10 Apr 2024 00:55:28 -0700 (PDT) MIME-Version: 1.0 References: <20240408090205.3714934-1-elver@google.com> <20240409103327.7a9012fa@gandalf.local.home> <20240410085428.53093333cf4d768d6b420a11@kernel.org> In-Reply-To: <20240410085428.53093333cf4d768d6b420a11@kernel.org> From: Marco Elver Date: Wed, 10 Apr 2024 09:54:50 +0200 Message-ID: Subject: Re: [PATCH] tracing: Add new_exec tracepoint To: Masami Hiramatsu Cc: Steven Rostedt , Eric Biederman , Kees Cook , Alexander Viro , Christian Brauner , Jan Kara , Mathieu Desnoyers , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, Dmitry Vyukov Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 899E6180007 X-Stat-Signature: 71rq1q8zhb6xspgkp5514axm5trtwmje X-HE-Tag: 1712735729-830845 X-HE-Meta: U2FsdGVkX1/OwyZiNHYHUgjiae3mR0drHfo+wnwtaZMjUojwWY1goB2Tb7AyYf2JV3roDxBOoGGgbiYfNU5HkDVrNMd5zMBCpXt5s1OOwAnvqfHyPLzN1doQNMMi7rWanqKl5+rW9hPSnDSJ62KKabXwaJOkxcWsUOm2vgJrv/jnLUiO44YBCzZouuDDFOUfWSiNFJ2U6H1CmbiSqkSQGQxIKhxYrZ2jiRU8vTHiTxHp/lYxlwd7NeLA4FK3xNU/YlWFTBrSykyhbSZuvk7wbyekPLrUCUxMShUPkhnNXled/cG5l58M9vLsPRVT8AzkfR5iz4FpHuVS3RjG2gNfKLJTIoD/AYRitkyHjRtLGem+M7JafHb4rjs7eEq0lYSuVhTkzs9fPO9ti725x+WKLLxuJyyYsiBC4cKdpYEVX3cOW9pcAtEeOKOG1rp0dtrB43yo197e39Hw1GI1ab1UUhWl+SMLxkB6xhe8sfKdl6Bk8WFN10Bq7ZxzeGIFismjFTSrGqJ8+xQxv0LZ0i+wxZFlv0PruDDo8D5VQzKFsnS1jiwywRvhuwVPeKk8Uhyu0o7t70dFtus6ONdXwIAzOkphf9Cc+6OWp4s58G9WfbasNqsp1PpNejpxI/XZQ0FvrYQB4IbRxus042RrOZJ+HhL/PfeprM9ydKBWClrSGFlrt1kSet2xnFPvyFdIACh9YjxjUTSQaVcwwyk3XQggOT+bzBy5ghqBR08pQ63hTFsg6JAwWhHEGbyqVu3aMhnOXW1SxslDiHP13RUlAfVZbjCnNvQEHNpX/M81eE/y1qLBnKbDI0dY4RSWSuKehTIF07R/ltq9lQWZNVrV3VohKihDO09neNH0KkWmcsWmxcKf5J3i70iACo3WXNZFD9u5anVE5LH1Jau2Ur7o7guPqaA0/6KM+VmBG4prADJ1W6UOQO7U1NcpSCqTimblO/eUnfs+2VHKbbqBhErmcuH VzFrkWgB LdW1zQYalrC6Uge+SlacMsjpMFeSQYYuPsijD3aBYToj/hiqeqlK9KMV+dMV87fQ/RDe60lrVofiXek9o7WMguAwofZZPSxMwRxvzO6vl+DvXKokICVhcz0zHGopbBLKB4M8wWtvIobv5oergOwHFwkKoyA68bWRuxw2TWfZkMdvNwEOh44x8CzwrcJB+KAkkp1213v3P5RyZCtVv2htxQ3bmRysZnCw0guOXo8/C1wZMVTFi3ZblYRRjTxx8jWlgRp8jhMc9XmcQDeO+dFkUlnoysInYq+lo1gJSYuJvnEIqaXBUSVy5Vqp9H5nRThiSmlo3V92eUr1RTvUlyB+W04bsNUkcZXgV6mvy/0ry1pdXdUZWQPZxvSqsHMNBdOphv0eOVw++dRRbsk6dbbuBF+/jMA9WrJkXyPBd 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 Wed, 10 Apr 2024 at 01:54, Masami Hiramatsu wrote: > > 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? I didn't have that in mind. If the BPF program reads (or even writes) to user space memory, it must stop doing so before current->mm is switched, otherwise it will lead to random results or memory corruption. The new process may reallocate the memory that we want to inspect, but the user space process must explicitly opt in to being inspected or being manipulated. Just like the kernel "flushes" various old state on exec since it's becoming a new process, a BPF program that has per-process state needs to do the same.