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 5DF00C5475B for ; Fri, 8 Mar 2024 10:58:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E29346B0370; Fri, 8 Mar 2024 05:58:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DD9896B0371; Fri, 8 Mar 2024 05:58:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA1BB6B0372; Fri, 8 Mar 2024 05:58:30 -0500 (EST) 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 B9FBF6B0370 for ; Fri, 8 Mar 2024 05:58:30 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 6701A1C03DA for ; Fri, 8 Mar 2024 10:58:30 +0000 (UTC) X-FDA: 81873573180.30.4306ED3 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf29.hostedemail.com (Postfix) with ESMTP id 0B07C120005 for ; Fri, 8 Mar 2024 10:58:27 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="Nt/pTjjQ"; spf=pass (imf29.hostedemail.com: domain of brauner@kernel.org designates 145.40.73.55 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=1709895508; 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=K1VzP9oTrIqrxbrUxwMZdzhKfSLrsbCyLjFcrOCX6Nw=; b=dO6V4AXhcuHuwuR/bxMSGkb9nLCAX3sXURUjFqLCvfxwuQM2Lx41S0FiDUOYE3XANvMuGm tt4Kezy7Nnbgxq2MSYsN/f9Ly5c04SaFid0rHFBb3p4fndBD46QaYK6Supp1KVd3j0flqe 9YK5iBWCFqx4Jse6mVDy26z5UbSyjws= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709895508; a=rsa-sha256; cv=none; b=TqKJX9GqZ9vgU4zOmp0QBYITcXj4jxVaFYMklFT9hs6hFF2sZ/EVJ0oodOT2psXAQSdteT Mmab7FsFM3O+g0qMLCVmUi5cm1Tqj1DZRU6nD1rC9GepgkAWErTsa3Jtfv8oclJ0y6uXKe og3QCoRjPKotoR5+N9lgrxpIxXqm+Xw= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="Nt/pTjjQ"; spf=pass (imf29.hostedemail.com: domain of brauner@kernel.org designates 145.40.73.55 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 sin.source.kernel.org (Postfix) with ESMTP id A6B5ACE244D; Fri, 8 Mar 2024 10:58:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 13062C433F1; Fri, 8 Mar 2024 10:58:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709895503; bh=t+CUSuGz1oswbfA1pD8nv4aLnvXGsLe3pXT7Zvxm/o4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Nt/pTjjQU4/t3Ui9AfP/dhesu6bAiD8W7/miIsLlhrZSjAlXV7WqES8euFVx1uQD4 +FUUlqnKwoS70h1rnQLHKUE5PWZ+QNxd8mwh+EVmb51Nxl5mdwTs3ZvCTDRHw8jOMl iaRd79094+RZjPKhlT466/S49+7RXqxpvctoSDlLNMYYtrrXsl6uz5FMtdYa9Bp3BX UcNjbhTiTDzuoqDuEjGKXGg1DPuGZytR/4O1Lb0+lT1rmW+WU2sKy0tAwUREzm4+L/ Ad52rwEl00CILgMst32JlQY5LS83uve/k+lHCaFiM0Iq8f5oVITi1qkEYvt4MumUcr ItKmzldvPudgw== Date: Fri, 8 Mar 2024 11:58:17 +0100 From: Christian Brauner To: Alexei Starovoitov Cc: Paul Moore , Matt Bobrowski , bpf , Alexei Starovoitov , Andrii Nakryiko , KP Singh , Jann Horn , Jiri Olsa , Daniel Borkmann , Linus Torvalds , Linux-Fsdevel , Andrew Morton , linux-mm , LSM List Subject: Re: [PATCH v2 bpf-next 0/9] add new acquire/release BPF kfuncs Message-ID: <20240308-diese-kartbahn-7f87d054964b@brauner> References: <20240306-flach-tragbar-b2b3c531bf0d@brauner> <20240306-sandgrube-flora-a61409c2f10c@brauner> <20240307-phosphor-entnahmen-8ef28b782abf@brauner> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 0B07C120005 X-Rspam-User: X-Stat-Signature: 18z4k4z3kt1ic1mu3rb8ub3wi3azf8o6 X-Rspamd-Server: rspam03 X-HE-Tag: 1709895507-793740 X-HE-Meta: U2FsdGVkX1+Za3LlHvHu6VbLq4gQvpxUOI+46K/zP64wyv3uh4e8HhNPSjcABnL6aqMadMJAdty/GTGoO/UyF4T4h2pXSAMxkO7QDkaZzfRkyE+yS0kP9kuUZx8NM9VFN2lpjhVxdTtn8xYIxJ5gvUj0Z7mT5cHrJUV50Eh077BIpT3Dw/waDob9WwQO+KUqrL9D42GDtXFf85wRyLQES57vs2Q7FUc3vtRnTykYkLhyxiSwPpWN8rwCX6jgr1HvIGMtw3VIpKC27lfXT+sNOX4BaO8H47igEeTZVM2hrrcM+UbnaySmhDzgWPUE8uRek9IBWySjUJ7CxzZe6e6FIGJtNIWsOR715/0nZdOVrQzGW8Hu+5kwrgcG18/AVsENnJbUCU6VBnCLFiE9jlWhEWJvyeKnvqqmmlLOC29Z/kbWKg5O3Zv3PPsD9qczoDToeSZBofCRLrqTB1Dhw3mSTBI/P5aoc1IPu27LE7DdPyycb7tUKh6i2h1LYAkhiyuOLoSd3ku43Pqz3J2iNlb+8Zk8PQ5shu7BE6tz56EklONZXb+YdFqa+q2TiHtXaT3X8okAXwrB5WGErYdekWnyevqjaigcorHBswj8YQGbJ1ia0M/VEK7RFrOqONSjN6QAL9nC+50hSQ3KJ9u0nteWJ4fAGUy+LSHF6vQgp1sSxkZYPsfAJ70Hj2FpZHm9ZJqWeDcHlyCgx5vDHhE7Ui+XaAs2C0ar21okZzp4L+uihPJpcNLdCqY/VTTIxx6YKTRQhfGYsCNgRyggcfM/xqhqzWV8XI8ptWe3QcoG9J3mP+Y3XzMCBQAp982kluxsRElAL1sg/Klw0u+CfvJdflLPD6zBS9n/bAMHDVqoziJ0aM2G4kCYZbWnR712Kqd/7g6INJqxkKaZ2sK6yxCBDj1oHJFiMOvxjfxmSoOz4OiJ6DiUjawbAMUKn0mfW9RCIqed7Tznsza7ahGAOtAPO/d +Rehww1S 7d0/zGNoW6XJdHufIDUdOF8o7BvyMtqfg+oCEkSZkSApsWapS8IW//hPbP3eTf5zIIo59Bdu8XfGcbU80oLnjnC1KydJJw4mVrAnszUgvnu3rR9eFR2Zhg/4qhw+7NbSutfKNGYsZz+uxtKfOwqZx8q1DeTlwcYflhUyF8fPhh+VuKee1r2JAAEKSFLGmGe4JaqTnD+HrJmHLYjlbAE/nsFXbgzVUHOq//YwEdS4k+/MNlHT0n2Awc+uXzDoXH/Lygbt9V0Vi9qlgx+/7rCsH64oP5+Porq9pp7WZFwIw1kQBy9s40VpOrvNMzGILdzvSIk+mHyjxs77UnnnDRA9dQ9JDwNpatR2G0HX4aoCFhD3MeHprNFptFWHzkXCzqvNN+/CpOF7sLN5ONqiCUMg2IEkozQ== 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 Thu, Mar 07, 2024 at 07:25:05PM -0800, Alexei Starovoitov wrote: > On Thu, Mar 7, 2024 at 12:51 PM Paul Moore wrote: > > > > On Thu, Mar 7, 2024 at 4:55 AM Christian Brauner wrote: > > > > > > There's one fundamental question here that we'll need an official answer to: > > > > > > Is it ok for an out-of-tree BPF LSM program, that nobody has ever seen > > > to request access to various helpers in the kernel? > > > > Phrased in a slightly different way, and a bit more generalized: do we > > treat out-of-tree BPF programs the same as we do with out-of-tree > > kernel modules? I believe that's the real question, and if we answer > > that, we should also have our answer for the internal helper function > > question. > > From 10k ft view bpf programs may look like kernel modules, > but looking closely they are very different. > > Modules can read/write any data structure and can call any exported function. > All modules fall into two categories GPL or not. > While bpf progs are divided by program type. > Tracing progs can read any kernel memory safely via probe_read_kernel. > Networking prog can read/write packets, but cannot read kernel memory. > bpf_lsm programs can be called from lsm hooks and > call only kfuncs that were explicitly allowlisted to bpf_lsm prog type. > Furthermore kfuncs have acquire/release semantics enforced by > the verifier. > For example, bpf progs can do bpf_rcu_read_lock() which is > a wrapper around rcu_read_lock() and the verifier will make sure > that bpf_rcu_read_unlock() is called. > Under bpf_rcu_read_lock() bpf programs can dereference __rcu tagged > fields and the verifier will track them as rcu protected objects > until bpf_rcu_read_unlock(). > In other words the verifier is doing sparse-on-steroids analysis > and enforcing it. > Kernel modules are not subject to such enforcement. > > One more distinction: 99.9% of bpf features require a GPL-ed bpf program. > All kfuncs are GPL only. While these are certainly all very nice properties it doesn't change the core question. An out of-tree BPF LSM program is requesting us to add nine vfs helpers to the BPF kfunc api. That out-of-tree BPF LSM program is not even accessible to the public. There is no meaningful difference to an out-of-tree kernel module asking us to add nine functions to the export api. The safety properties don't matter for this. Clearly, they didn't prevent the previous bpf_d_path() stuff from happening. We need rules for how this is supposed to be handled. Unless those rules are clearly specified and make sense we shouldn't be adding BPF kfuncs based on requests from out-of-tree BPF LSMs that amount to "we need this".