From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr2-f0.google.com (mail-wr2-f0.google.com [74.125.225.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0AEAA3BFAD4 for ; Fri, 31 Jul 2026 19:20:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.225.64 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785525654; cv=none; b=PcMOBpIm+jrHjq2dujPWRJGzS0u3Q0LdzcmPoXRy24RS6U+TK5EiB0ybZl3CHm7/vEI80xuW/ItSalQkZ4awBXbqhWsHKIGCf96vkC0M7G2ecVRDAyCB2lUEzcK9hZjePywsPFwLlH2ahoBYK4P6d31e/nvioz2k6XWn0yipbWU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785525654; c=relaxed/simple; bh=W/cQazly5+ZSmwW+vMYjDeAOiE27Kjc1Cr7JvjQ9jfs=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:From:To:Cc: References:In-Reply-To; b=D9RmRa2pOtzYrvjSjGe4Io50lDnuXy8EjzMCV1xtGi5cbnSLY52UQpzX42zKne8SAcQa8XE0iVprcJgEi7C6yR7LXmtu+umfyvTubic2aoOpFiUt9ukN/a/Z+khlBXVKFqS+e2Yc6C3QPwRCw48dOWSoKJK0Gf9nPHJAPxG3kOw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=nhAFGLhV; arc=none smtp.client-ip=74.125.225.64 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="nhAFGLhV" Received: by mail-wr2-f0.google.com with SMTP id ffacd0b85a97d-47528970fbdso646811f8f.1 for ; Fri, 31 Jul 2026 12:20:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785525651; x=1786130451; darn=vger.kernel.org; h=in-reply-to:references:cc:to:from:subject:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=3/Y6YcDM4/zvWNQ6LoR9jhMZHzjhOIbqHOCYPbHDmdw=; b=nhAFGLhVLCPf3TVFJtApTCWIQHVQvV9MPsEf6fHLya8JT19sY+BBoWI8P2L631IEIJ JIkv0qRStiFochcRnso74FFbiEfM/zttVtvwqSjkUbHlVPAeIAYxgorGBqyGf2MlJ6Ns ytLz0mKTS35yftkeGpuJ+kqpCzkq6UjL1Rl0VaszcxCHb61UAIvcd/ADrkHlbSKM5uyk AHjkndgGbiaAlzFO8cM0IHpd4pxrKvRZUkari1tm7Q1M8zoC5MO5t2ioOxxnfyNtiapG /zuGi/w7A7XStv38XKLTDte6pi/D36FArcTi/C/rsmrow9rW5NNV6udYKSzDpjoXZfyB aJSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785525651; x=1786130451; h=in-reply-to:references:cc:to:from:subject:message-id:date :content-type:content-transfer-encoding:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=3/Y6YcDM4/zvWNQ6LoR9jhMZHzjhOIbqHOCYPbHDmdw=; b=nXvm9KHiKsdFZ59+H3rlRrZLtKIYRZ1wCxoHKBHdRl1DhyIE8nOxHIE1IP1LUxq90n uID7mA5qCkxm3CAsqH/ZdqmL4nfclH0hiIYL5W2Rq+4jv6q4jQFPtDQgFpbnr3A2nocf eml73iDCI2Bk/LVXFmW0DhEhwI+mxUNqGFT6/OwbGQY6Abno5Ixde5oTsxYrrdVpeYfc IgRD5Ae43oFb6AQ+8vykERa6kPGOi1qUMD4jDcqNH4NZwSgkrbvBI+VhUjh3nMBaBjMf gTaki7BSddRG0RwiTa3uFOI5xFFHXgiX1Q0fdQ6HwL68fXL98xqFP5Wt4BBGV55/nCdk ApkA== X-Forwarded-Encrypted: i=1; AHgh+RqV047votvRLuk0ZUW3kxpTOtT8MRBwfYQuzFwbNYzhh52JN0VQlT+Jf47e2Zr70/1o6ZCkdSCmvblcI30=@vger.kernel.org X-Gm-Message-State: AOJu0YxHDSt3X2ba8B2LtT1A9kCVvwQc821LtnvICbe/w3DU/oE0iiGg IT2I52ABPPfozKbLhnjTtDr+kGvrhNZ1QkxUIjt5ND8IKcbC2bynJwzk X-Gm-Gg: AR+sD136btib8NjaFTDNMLJU303vap/Dmr/l8ut6n2HWFOhlbWHcdp49+1kcoM9CzoI n/u6o0gSsEX63UZsGsguH20/MRsgldwXe96NWVyVn5mwOxldddYK12qhF8RUYPyEVvXyA2pOMZ1 mQxH//nufCkZ8E5xHLdqFD0R8T8vg6sX5IbmkM+8uR9PVj02yhzPL/0FK7RtE1THekaisD2ZGS8 W1KG+1I8n6QvG6OQM1L4ajmyDU0LtL6CtVH2PYAHMFDNGo4ZtpVIs6ywxUdtnJ9Ew8ZNCVJCpym xzdkC9/qy5qkGEFiuQoinJ7kxCbY9SFSN64kNA8NPwwIuhZZ9WQk2n79B6nDB1pAXSBJbO4yYFW CSNZRgCVRdNBBDPowMmLfiL4lAqeGHWf6QhdC6PhimibmHOFuvzWseWSjDyiar/uuIqjMEDE5S3 bq4Y4nbYk+ERS/nNvaJNAtGodzmquDHWm/qRO+p+e40gg6AxVCyaOeFe1bX+9TniWYUudzlq8SO xbBIBmsjCBhwqiv5UGH5yvZ8M5aYR1DOT/CG1TTfYgfmdYavfSx8HCVxHorZbHBLxrXJ3CYnZpt HzjIQ1a/869WgX8FrS8tsPeD/go= X-Received: by 2002:adf:eac3:0:b0:47d:dfc6:b28b with SMTP id ffacd0b85a97d-47fd72e1887mr1421938f8f.30.1785525651097; Fri, 31 Jul 2026 12:20:51 -0700 (PDT) Received: from localhost (nat-icclus-192-26-29-3.epfl.ch. [192.26.29.3]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47fd456a6cbsm7789645f8f.23.2026.07.31.12.20.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Jul 2026 12:20:50 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 31 Jul 2026 21:20:50 +0200 Message-Id: Subject: Re: [PATCH v6 bpf-next 3/4] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling From: "Kumar Kartikeya Dwivedi" To: "Paul Moore" Cc: "David Windsor" , "Alexei Starovoitov" , "Daniel Borkmann" , "Andrii Nakryiko" , "Martin KaFai Lau" , "Eduard Zingerman" , "Song Liu" , "Yonghong Song" , "John Fastabend" , "KP Singh" , "Jiri Olsa" , "Emil Tsalapatis" , "Matt Bobrowski" , "James Morris" , "Serge E . Hallyn" , "Casey Schaufler" , "Stephen Smalley" , "Ondrej Mosnacek" , "Mimi Zohar" , "Roberto Sassu" , "Dmitry Kasatkin" , "Eric Snowberg" , "Alexander Viro" , "Christian Brauner" , "Jan Kara" , "Shuah Khan" , , , , , , , X-Mailer: aerc 0.21.0 References: <20260730234533.1912709-1-dwindsor@gmail.com> <20260730234533.1912709-4-dwindsor@gmail.com> In-Reply-To: On Fri Jul 31, 2026 at 9:05 PM CEST, Paul Moore wrote: > On Fri, Jul 31, 2026 at 2:50=E2=80=AFPM Kumar Kartikeya Dwivedi > wrote: >> On Fri Jul 31, 2026 at 8:42 PM CEST, Paul Moore wrote: >> > On Fri, Jul 31, 2026 at 2:18=E2=80=AFPM Kumar Kartikeya Dwivedi >> > wrote: >> >> On Fri Jul 31, 2026 at 6:59 PM CEST, Paul Moore wrote: >> >> > On Fri, Jul 31, 2026 at 12:32=E2=80=AFPM Kumar Kartikeya Dwivedi >> >> > wrote: >> >> >> On Fri Jul 31, 2026 at 6:02 PM CEST, Paul Moore wrote: >> >> >> > On Fri, Jul 31, 2026 at 11:44=E2=80=AFAM Kumar Kartikeya Dwivedi >> >> >> > wrote: >> >> >> >> On Fri Jul 31, 2026 at 5:30 PM CEST, David Windsor wrote: >> >> >> >> > On Fri, Jul 31, 2026 at 11:17=E2=80=AFAM Paul Moore wrote: >> > >> > ... >> > >> >> Yes, I understand you feel it should be placed under security/. You a= re entitled >> >> to your opinion. >> >> >> >> No, I do not think the newly added kfunc is a big enough layering vio= lation such >> >> that we need to do it ASAP, disregarding everything else outlined abo= ve. I am >> >> sure you see that too. There are several other instances of similar k= funcs. >> >> >> >> Therefore, please attempt to meet me halfway here. >> > >> > I'm happy to work with you, and/or anyone else, who wants to work on >> > finding a way to test kfuncs that live in security/bpf_lsm_kfuncs.c. >> >> Right, and for that file to exist, you need to get everyone (FS, BPF fol= ks) to >> agree on whether placing all such kfuncs there makes sense. It is not fo= r both >> of us to decide on our own. So let's revisit this whole topic once you'v= e done >> that exercise. > > The kfunc that David has proposed must be located in > security/bpf_lsm_kfuncs.c, similar to the VFS kfuncs and > fs/bpf_fs_kfuncs.c. If you read David's bpf_init_inode_xattr() kfunc Sigh. I now went and read the archives, and Christian already told you no before = [0], which I missed in my first read. So two people whom this code affects alrea= dy objected to your proposal. [0]: https://lore.kernel.org/bpf/20260625-schnabel-rennmaschine-parieren-= bcb352c3cf59@brauner > you will notice there is nothing in the function relating to the VFS, > well other than the "inode" and "xattr" in the name of the function; I can also read it the other way. There is only one "security_lsmxattr_add(= )" call that is LSM related, and the rest is VFS or BPF specific stuff. There would be no xattr support in LSM code without filesystems implementin= g them. Please avoid making absurd and non-sensical arguments. If we went by this logic, we would have to move the entirety of the kernel = under security/, since anything that calls into LSM code becomes eligible to go t= here. > this is purely a LSM kfunc and I stand by my previous comments. The > BPF maintainers have seen fit to decide quite a few things LSM related > solely on their own, I see no reason why requiring a LSM kfunc be > located in security/bpf_lsm_kfuncs.c is unreasonable given our current > situation. > > As I said earlier, I'm happy to work with you, David, or anyone else > on ensuring security/bpf_lsm_kfuncs.c has the proper test coverage, > but I'm not going to continue to go back and forth about the location > of the bpf_init_inode_xattr() kfunc that is proposed in this patchset. > If you, or any of the other BPF maintainers, are not able to live with > that location then David will need to find another way. Yeah, I think we've spilled enough ink on this. We'll figure out a way to m= ove things forward. Since VFS people disagree too, the kfunc should stay where= it is in this series. I am always open to revisiting all this once you can convince others by mak= ing useful arguments, instead of imposing your will onto them and throwing a ta= ntrum.