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 0A2B5C5475B for ; Wed, 6 Mar 2024 11:51:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1BA9C6B0074; Wed, 6 Mar 2024 06:51:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 16B2E6B0075; Wed, 6 Mar 2024 06:51:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0325C6B0078; Wed, 6 Mar 2024 06:51:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id E21756B0074 for ; Wed, 6 Mar 2024 06:51:04 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 95AF840E35 for ; Wed, 6 Mar 2024 11:51:04 +0000 (UTC) X-FDA: 81866448048.27.21C71C8 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf15.hostedemail.com (Postfix) with ESMTP id 1F6DFA0005 for ; Wed, 6 Mar 2024 11:51:01 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=QodlTD1K; spf=pass (imf15.hostedemail.com: domain of brauner@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=brauner@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=1709725862; 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=pkCGPEbfGj2qtVBXoVAOsd5fY8BxJSJk8jNbZNrF1yY=; b=MDVAG71m8ORG4yjgKENHpz0h56qvY6vpc2WOStrldPf/leQyHSgJGqNWLM5qrNG19hid0r 8fAUbYH7P5pakrJ5s+wNojtEG/VY407WRr7lgQK3gntqPKwi4lJKgsGMLyxVnrYEZlkxL5 GWIsDqmse8atZFQu/tXdcDMGNU842vM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709725862; a=rsa-sha256; cv=none; b=hmMEq460KnNfBlYzGJ54A6mVWIv8QQTcISjUiX1hP99lGQS7Omc1lWY5scWNf9XJyHcbCy IXLte6mVYryn6c+NRAWgsvrlKD6F31YL9tVo12ygx5m8nrYP0/dU6RkBTULvL1dxXJlGx+ 7dTV6lYpBKg5e7t8ysbBWyk4/VTax/4= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=QodlTD1K; spf=pass (imf15.hostedemail.com: domain of brauner@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 17149614CB; Wed, 6 Mar 2024 11:51:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A3EBAC433C7; Wed, 6 Mar 2024 11:50:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709725860; bh=vwrURXpIMj1jqcUglQsFMJ0otRAl9PCvcW29Elk4VQg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QodlTD1Kw4nB7/LLPdSYcRLIGU/ZePWrRHbgEtEgSdttv6euDxc5emr0NfD4Po0nr ST19Od/uUf0dps9orl7afeZ+Ke6bNByCLYmYpM9jJeyNhPMuBSblkKh2gkgxhzgdeZ /J+abL6OcwN1B4WWuvRUCnziOiia84akv9V5/phNQ1ys0BS5YjZ75fQHz83AkycC/H yiyi3rPwUo9+TKJ6N4gWbeYs0UjdmqCtPulPxKGoQbA8+vIqVNd0MFjKJkL2oJshoP W3JSs/wRO1l2+G0oF8gee6TSWFZ+flOxvQm5ZSDFQX4S3U+u+xp26f3p+1HhBM+KXd a3Ag7DxmX+wPA== Date: Wed, 6 Mar 2024 12:50:54 +0100 From: Christian Brauner To: Matt Bobrowski , linux-mm@kvack.org Cc: bpf@vger.kernel.org, ast@kernel.org, andrii@kernel.org, kpsingh@google.com, jannh@google.com, jolsa@kernel.org, daniel@iogearbox.net, torvalds@linux-foundation.org, linux-fsdevel@vger.kernel.org, Andrew Morton Subject: Re: [PATCH v2 bpf-next 2/9] bpf: add new acquire/release BPF kfuncs for mm_struct Message-ID: <20240306-plazieren-schaben-e086ab1b92ef@brauner> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 1F6DFA0005 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: hzyqb7u3xsob51z8srek6p3t83hyzc6i X-HE-Tag: 1709725861-491268 X-HE-Meta: U2FsdGVkX1/+iZKlcG9c9isbM5T/VL/qA+bJlfD1HS5LzTb6fsZIO6rs3UhnawxbifnLe+A/cl+Fooxa5ms2uomyOCy8tu7b1ezpn6YrOP1gvxEO2/EvwzC4GpwNoRgOkRoQdkEAxYwrwQABM94YV2wuPMAMeWZCkXV16Bw9NosHk0ml1vns9hmauK55PFB5y9ThGYUu7oLU1rMFGO7OhxRwPPTmPfBN7sArZK9Ie96g7a6DWkKz1wug3czqDckjruGkSMm/ZEd233h63lb6CuwwnRzIRzzTvcaXe2gis2sB88blLRjYhX8KDbHDug7YB1YOjkvHYViHckfxBWGGR2BFB3TP179f6fS4Wrxi08YcxESuJGhj0VQ32NrNLMpTwNovqr9z38BDX2qLBcxku2AbEYZ51RMF6PVEeWBkaUNbnTdnZy/E8lOiRQNJUEUFfBY2vemsOlX7RgPIxfy23segGvd/wW8B2l4hYLssuEdOm+u0z4zqPIMIhyXOrKY/5pWqBB+CCKbS0TcfOARuOqgGL+i2VxLLGD/NcMJzFv3fdJ2fi3QRuTf6Nh1MGFQSozfBbzPcEqHZV96yrz1deObQghh+Xocwequ+DFJhxXkOwxc+YdVFMi6i9ZWBHgFb8dt8tLqjZHcGYR1mshOW1J+tGFDW4yHCTG9h633OShpqBq0M7VG7hhaXniUmIHhz43KrO9E8Llp3K9oPw+K1r1zs32TBVI9140jsJlGUTLHr0blSzShKVoNTk0VsiS9ji0WxXJvs6p6U7uvGWqZlayaDpIs2G7enrYHBTf/+6jDoG4VrUm7UlDrDz6kNVlBenZ/U+5Ue3/P0ot7zjN6Oo/uJSR7pViAoIg2Noy5CqC8TrFU/JP55LOrxm0n5i3Pm2LpqGhzelTBB9rWM72d/O+tGewo3V7ZObW6FkTY3FefdWFA9+zOCWQ== 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, Mar 06, 2024 at 07:39:31AM +0000, Matt Bobrowski wrote: > A BPF LSM program will at times introspect the mm_struct that is > nested within a given task_struct. Such introspection performed by a > BPF LSM program may involve reading virtual addresses out from fields > like arg_start/arg_end and env_start/env_end, or reading fields > directly out from the backing exe_file. In order to perform reliable > reads against fields contained within mm_struct, we need to introduce > a new set of BPF kfuncs that have the ability to acquire and release > references on the mm_struct that is nested within a task_struct. > > The following BPF kfuncs have been added in order to support this > capability: > > struct mm_struct *bpf_task_mm_grab(struct task_struct *task); > void bpf_mm_drop(struct mm_struct *mm); > > These new BPF kfuncs are pretty self-explanatory, but in kernel terms > bpf_task_mm_grab() effectively allows you to get a reference on the > mm_struct nested within a supplied task_struct. Whereas, bpf_mm_drop() > allows you put a reference on a previously gotten mm_struct > reference. Both BPF kfuncs are also backed by BPF's respective > KF_ACQUIRE/KF_RELEASE semantics, ensuring that the BPF program behaves > in accordance to the constraints enforced upon it when operating on > reference counted in-kernel data structures. > > Notably, these newly added BPF kfuncs are simple wrappers around the > mmgrab() and mmdrop() in-kernel helpers. Both mmgrab() and mmdrop() > are used in favour of their somewhat similar counterparts mmget() and > mmput() as they're considered to be the more lightweight variants in > comparison, and there's no requirement to also pin the underlying > address spaces just yet. > > Signed-off-by: Matt Bobrowski > --- That's not something I can in any way ACK or NAK. That's clearly mm. And same question as in the other mail. What's the user of this? I find it extremly strange that the justification is "some LSM program" needs this. This is really an annoying justification when we can't even see the users. With LSMs we can at least see what they're doing with this in their hooks. > kernel/trace/bpf_trace.c | 47 ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 47 insertions(+) > > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c > index f639663ac339..801808b6efb0 100644 > --- a/kernel/trace/bpf_trace.c > +++ b/kernel/trace/bpf_trace.c > @@ -1473,10 +1473,57 @@ __bpf_kfunc int bpf_get_file_xattr(struct file *file, const char *name__str, > return __vfs_getxattr(dentry, dentry->d_inode, name__str, value, value_len); > } > > +/** > + * bpf_task_mm_grab - get a reference on the mm_struct nested within the > + * supplied task_struct > + * @task: task_struct nesting the mm_struct that is to be referenced > + * > + * Grab a reference on the mm_struct that is nested within the supplied > + * *task*. This kfunc will return NULL for threads that do not possess a valid > + * mm_struct. For example, those that are flagged as PF_KTHREAD. A reference on > + * a mm_struct acquired by this kfunc must be released using bpf_mm_drop(). > + * > + * This helper only pins the mm_struct and not necessarily the address space > + * associated with the referenced mm_struct that is returned from this > + * kfunc. Internally, this kfunc leans on mmgrab(), such that calling > + * bpf_task_mm_grab() would be analogous to calling mmgrab() outside of BPF > + * program context. > + * > + * Return: A referenced pointer to the mm_struct nested within the supplied > + * *task*, or NULL. > + */ > +__bpf_kfunc struct mm_struct *bpf_task_mm_grab(struct task_struct *task) > +{ > + struct mm_struct *mm; > + > + task_lock(task); > + mm = task->mm; > + if (likely(mm)) > + mmgrab(mm); > + task_unlock(task); > + > + return mm; > +} > + > +/** > + * bpf_mm_drop - put a reference on the supplied mm_struct > + * @mm: mm_struct of which to put a reference on > + * > + * Put a reference on the supplied *mm*. This kfunc internally leans on > + * mmdrop(), such that calling bpf_mm_drop() would be analogous to calling > + * mmdrop() outside of BPF program context. > + */ > +__bpf_kfunc void bpf_mm_drop(struct mm_struct *mm) > +{ > + mmdrop(mm); > +} > + > __bpf_kfunc_end_defs(); > > BTF_KFUNCS_START(lsm_kfunc_set_ids) > BTF_ID_FLAGS(func, bpf_get_file_xattr, KF_SLEEPABLE | KF_TRUSTED_ARGS) > +BTF_ID_FLAGS(func, bpf_task_mm_grab, KF_ACQUIRE | KF_TRUSTED_ARGS | KF_RET_NULL); > +BTF_ID_FLAGS(func, bpf_mm_drop, KF_RELEASE); > BTF_KFUNCS_END(lsm_kfunc_set_ids) > > static int bpf_lsm_kfunc_filter(const struct bpf_prog *prog, u32 kfunc_id) > -- > 2.44.0.278.ge034bb2e1d-goog > > /M