From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) (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 5B393E555 for ; Tue, 24 Feb 2026 00:15:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771892118; cv=none; b=szKJaoZZxnTaORJlkiiQQuYz86Okk7wHFiewnXgs7ANTsPBGfJ0Ho8/SNSQ6woLh+YxJZSIbJo8kynIvMwTvzmyLOhqCDZVJc88V6KZ3D/FJXT/JAvcgL6PccfXoeY5Lzc0v2c1zRPOc27Hzlu6ksYOMMcurw0WxGNfwPWBPBZk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771892118; c=relaxed/simple; bh=IHU4YKQY5PYWHmXFzacaJDDgnkLmppJAryXMXDRIZlI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=jeP8jSCag4oomQ+T+sv6V4e0ihZ9YUOHJ9FUe7526nl9gCmcbTeOmjWRd8K8KXTz8V9bskKP5oibqMG2Yz03pXHTQ7ekgN7BYD5mtI21GqQEHdsYmQpz2pT1tAS80ozKgucsk7oVKOtQSgi3ksLryMGR11d02hiuKfOS9TcFcHI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=0166C+uV; arc=none smtp.client-ip=209.85.218.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="0166C+uV" Received: by mail-ej1-f52.google.com with SMTP id a640c23a62f3a-b886fc047d5so785260566b.3 for ; Mon, 23 Feb 2026 16:15:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1771892115; x=1772496915; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=0GMn/JpPA8zh6a0TMK+ntturbLwCrYg/Xc9jl0GDdTI=; b=0166C+uVmueaBxWX5gd2/2oYJu9cgqHbEdb4yr/Oll3oT7/4Pp5z7qsQoxNSHElrk0 9/bQAVUjqmDkzoZ7/vuPd1NRmUwAAUUzdMtozRyc9wVB0ZjRs2OCIBE5yRNhrlufdc6H ck3WRdBgfo3hg6VNk1C/vLBRDDHzhhmXWRy0W9VIEFj8HPlTEBPPtIdZKCHPvSQ2BJQL LJxOivwfojIOSRldHyeCelhvAY7TKDCC5zN7Sjo6tZNDX5RnGTm1nmbWSSI4djoDLp6H DxnlVjhD1p5G4BdpfdaDB7YOnPFOIlDOvg2idH/6a8vXpDDs0WlIu1IVanGVidrBu+iV f3kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771892115; x=1772496915; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0GMn/JpPA8zh6a0TMK+ntturbLwCrYg/Xc9jl0GDdTI=; b=WQc02ScwaPLay51NEL5OIJavO1FySMk58izWGgH15Ccj37us3eAJfI8FHfuJTl+0a3 UROae+vytMy88R1nsAHxZIyAPJ6nRDgj6xOKnMeduVRXOBQ4IgNZz9jVxW2OtH3JLnQI glFTE4g/OGfCDMbbQxBsu1o71YaVov/wzW7yi/n7HyuHTWz6Zrf0oowRqeKz32unk6/O ApbQmPpvye8nCNI4CKwBfNjtsR3ngoggxzacpY4G+SzvfYqm/FlKjNW5VHMelDtMnH4X krFcF5JncpMVS0HSNMhPyklpp4gXcMrWHd/SUfhE7UHCRZMc6e4poCnNCxbGFeO7m7LT arGw== X-Forwarded-Encrypted: i=1; AJvYcCW9TYKYPDMFIqsfajXJXl6/5x2Mw7SbONKg7URb/YFUYGJN4RHUxNX1c4JFbbFuYFrAmFksaFTeJU+kDCU=@vger.kernel.org X-Gm-Message-State: AOJu0YzQcuDG96YFfq4/PV1rQRaN94FITUWSMA+q898c2MgfMOrtg6cE KCTWjpw3kil7r6KZLDSbMNsSrbJuBWVQV/Zl477RIDC2gTQLq1OcrRYxzlfZIdUnwg== X-Gm-Gg: AZuq6aJa7Q/MbwNKIEKF6tY+X6UxH2ViwGWqYQsk1TDQbkspqEBKtUjZ3MoU9V+mI+D c3Dlz3j14D9SSmZS0NZ0xMQLxaAmRiSWLDW5oOEf/VwImnAj4pbGMlkmFE4G2PxX3TdSHrF0hA7 V8+iv/Hb9Slbphz2F1Jzpqsx/VDwLtBFQ9tOX7ft6DJtxhE+B3TOh8yz27MERo4hSgNjZ8OrVjl yE9Z0l5YxEXuYKx4ti3EcVcuvGbIN/iJNG2auESzd6eRQ8noinv4WjXPwvwNQYdyb4Ch8jafHxy bzft+Mjbcxlc9V1e9hXtfBgTTpzTXrPUgQIgK6gP2FPI1vdWgQ8r+sbHNyIkhoGJ5RXrLdid3iC U3VnDwo45Ct1bQtREPxgQaQGE1Oe5mou98YjBlQkwomSuPSeyd5CgKSO3zshNSjLy+CxRh31PCY b96D2ipzHptdTJGRykG0KauNyXeVM2EbxVQUQyp29WjiIPpu5oGDoE9c9TRYHnn+c= X-Received: by 2002:a17:906:66d4:b0:b8e:fb1d:9eba with SMTP id a640c23a62f3a-b9081c1c4c5mr467058766b.54.1771892114268; Mon, 23 Feb 2026 16:15:14 -0800 (PST) Received: from google.com (93.50.90.34.bc.googleusercontent.com. [34.90.50.93]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b9084e4be53sm382403166b.31.2026.02.23.16.15.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Feb 2026 16:15:13 -0800 (PST) Date: Tue, 24 Feb 2026 00:15:10 +0000 From: Matt Bobrowski To: Christian Brauner Cc: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Tejun Heo , KP Singh , bpf@vger.kernel.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, Lennart Poettering Subject: Re: [PATCH 1/4] ns: add bpf hooks Message-ID: References: <20260220-work-bpf-namespace-v1-0-866207db7b83@kernel.org> <20260220-work-bpf-namespace-v1-1-866207db7b83@kernel.org> <20260223-ewigkeit-zwieback-4350eb90a616@brauner> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260223-ewigkeit-zwieback-4350eb90a616@brauner> On Mon, Feb 23, 2026 at 12:12:28PM +0100, Christian Brauner wrote: > On Mon, Feb 23, 2026 at 10:36:19AM +0000, Matt Bobrowski wrote: > > On Fri, Feb 20, 2026 at 01:38:29AM +0100, Christian Brauner wrote: > > > Add the three namespace lifecycle hooks and make them available to bpf > > > lsm program types. This allows bpf to supervise namespace creation. I'm > > > in the process of adding various "universal truth" bpf programs to > > > systemd that will make use of this. This e.g., allows to lock in a > > > program into a given set of namespaces. > > > > > > Signed-off-by: Christian Brauner > > > --- > > > include/linux/bpf_lsm.h | 21 +++++++++++++++++++++ > > > kernel/bpf/bpf_lsm.c | 25 +++++++++++++++++++++++++ > > > kernel/nscommon.c | 9 ++++++++- > > > kernel/nsproxy.c | 7 +++++++ > > > 4 files changed, 61 insertions(+), 1 deletion(-) > > > > > > diff --git a/include/linux/bpf_lsm.h b/include/linux/bpf_lsm.h > > > index 643809cc78c3..5ae438fdf567 100644 > > > --- a/include/linux/bpf_lsm.h > > > +++ b/include/linux/bpf_lsm.h > > > @@ -12,6 +12,9 @@ > > > #include > > > #include > > > > > > +struct ns_common; > > > +struct nsset; > > > + > > > #ifdef CONFIG_BPF_LSM > > > > > > #define LSM_HOOK(RET, DEFAULT, NAME, ...) \ > > > @@ -48,6 +51,11 @@ void bpf_lsm_find_cgroup_shim(const struct bpf_prog *prog, bpf_func_t *bpf_func) > > > > > > int bpf_lsm_get_retval_range(const struct bpf_prog *prog, > > > struct bpf_retval_range *range); > > > + > > > +int bpf_lsm_namespace_alloc(struct ns_common *ns); > > > +void bpf_lsm_namespace_free(struct ns_common *ns); > > > +int bpf_lsm_namespace_install(struct nsset *nsset, struct ns_common *ns); > > > + > > > int bpf_set_dentry_xattr_locked(struct dentry *dentry, const char *name__str, > > > const struct bpf_dynptr *value_p, int flags); > > > int bpf_remove_dentry_xattr_locked(struct dentry *dentry, const char *name__str); > > > @@ -104,6 +112,19 @@ static inline bool bpf_lsm_has_d_inode_locked(const struct bpf_prog *prog) > > > { > > > return false; > > > } > > > + > > > +static inline int bpf_lsm_namespace_alloc(struct ns_common *ns) > > > +{ > > > + return 0; > > > +} > > > +static inline void bpf_lsm_namespace_free(struct ns_common *ns) > > > +{ > > > +} > > > +static inline int bpf_lsm_namespace_install(struct nsset *nsset, > > > + struct ns_common *ns) > > > +{ > > > + return 0; > > > +} > > > #endif /* CONFIG_BPF_LSM */ > > > > > > #endif /* _LINUX_BPF_LSM_H */ > > > diff --git a/kernel/bpf/bpf_lsm.c b/kernel/bpf/bpf_lsm.c > > > index 0c4a0c8e6f70..f6378db46220 100644 > > > --- a/kernel/bpf/bpf_lsm.c > > > +++ b/kernel/bpf/bpf_lsm.c > > > @@ -30,10 +30,32 @@ __weak noinline RET bpf_lsm_##NAME(__VA_ARGS__) \ > > > #include > > > #undef LSM_HOOK > > > > > > +__bpf_hook_start(); > > > + > > > +__weak noinline int bpf_lsm_namespace_alloc(struct ns_common *ns) > > > +{ > > > + return 0; > > > +} > > > + > > > +__weak noinline void bpf_lsm_namespace_free(struct ns_common *ns) > > > +{ > > > +} > > > + > > > +__weak noinline int bpf_lsm_namespace_install(struct nsset *nsset, > > > + struct ns_common *ns) > > > +{ > > > + return 0; > > > +} > > > + > > > +__bpf_hook_end(); > > > + > > > #define LSM_HOOK(RET, DEFAULT, NAME, ...) BTF_ID(func, bpf_lsm_##NAME) > > > BTF_SET_START(bpf_lsm_hooks) > > > #include > > > #undef LSM_HOOK > > > +BTF_ID(func, bpf_lsm_namespace_alloc) > > > +BTF_ID(func, bpf_lsm_namespace_free) > > > +BTF_ID(func, bpf_lsm_namespace_install) > > > BTF_SET_END(bpf_lsm_hooks) > > > > > > BTF_SET_START(bpf_lsm_disabled_hooks) > > > @@ -383,6 +405,8 @@ BTF_ID(func, bpf_lsm_task_prctl) > > > BTF_ID(func, bpf_lsm_task_setscheduler) > > > BTF_ID(func, bpf_lsm_task_to_inode) > > > BTF_ID(func, bpf_lsm_userns_create) > > > +BTF_ID(func, bpf_lsm_namespace_alloc) > > > +BTF_ID(func, bpf_lsm_namespace_install) > > > BTF_SET_END(sleepable_lsm_hooks) > > > > > > BTF_SET_START(untrusted_lsm_hooks) > > > @@ -395,6 +419,7 @@ BTF_ID(func, bpf_lsm_sk_alloc_security) > > > BTF_ID(func, bpf_lsm_sk_free_security) > > > #endif /* CONFIG_SECURITY_NETWORK */ > > > BTF_ID(func, bpf_lsm_task_free) > > > +BTF_ID(func, bpf_lsm_namespace_free) > > > BTF_SET_END(untrusted_lsm_hooks) > > > > > > bool bpf_lsm_is_sleepable_hook(u32 btf_id) > > > diff --git a/kernel/nscommon.c b/kernel/nscommon.c > > > index bdc3c86231d3..c3613cab3d41 100644 > > > --- a/kernel/nscommon.c > > > +++ b/kernel/nscommon.c > > > @@ -1,6 +1,7 @@ > > > // SPDX-License-Identifier: GPL-2.0-only > > > /* Copyright (c) 2025 Christian Brauner */ > > > > > > +#include > > > #include > > > #include > > > #include > > > @@ -77,6 +78,7 @@ int __ns_common_init(struct ns_common *ns, u32 ns_type, const struct proc_ns_ope > > > ret = proc_alloc_inum(&ns->inum); > > > if (ret) > > > return ret; > > > + > > > /* > > > * Tree ref starts at 0. It's incremented when namespace enters > > > * active use (installed in nsproxy) and decremented when all > > > @@ -86,11 +88,16 @@ int __ns_common_init(struct ns_common *ns, u32 ns_type, const struct proc_ns_ope > > > atomic_set(&ns->__ns_ref_active, 1); > > > else > > > atomic_set(&ns->__ns_ref_active, 0); > > > - return 0; > > > + > > > + ret = bpf_lsm_namespace_alloc(ns); > > > + if (ret && !inum) > > > + proc_free_inum(ns->inum); > > > + return ret; > > > } > > > > > > void __ns_common_free(struct ns_common *ns) > > > { > > > + bpf_lsm_namespace_free(ns); > > > proc_free_inum(ns->inum); > > > } > > > > > > diff --git a/kernel/nsproxy.c b/kernel/nsproxy.c > > > index 259c4b4f1eeb..5742f9664dbb 100644 > > > --- a/kernel/nsproxy.c > > > +++ b/kernel/nsproxy.c > > > @@ -9,6 +9,7 @@ > > > * Pavel Emelianov > > > */ > > > > > > +#include > > > #include > > > #include > > > #include > > > @@ -379,6 +380,12 @@ static int prepare_nsset(unsigned flags, struct nsset *nsset) > > > > > > static inline int validate_ns(struct nsset *nsset, struct ns_common *ns) > > > { > > > + int ret; > > > + > > > + ret = bpf_lsm_namespace_install(nsset, ns); > > > + if (ret) > > > + return ret; > > > + > > > return ns->ops->install(nsset, ns); > > > } > > > > What's the reason for not adding these new hook points to the generic > > set of hooks that are currently being exposed directly by the LSM > > framework? Honestly, it seems a little odd to be providing > > declarations/definitions for a set of new hook points which are to be > > exclusively siloed to BPF LSM implementations only. I'd argue that > > some other LSM implementations could very well find namespace > > lifecycle events possibly interesting. > > The LSM layer is of the opinion that adding new security hooks is only > acceptable if an implementation for an in-tree LSM is provided alongside > it (cf. [1]). IOW, your bpf lsm needs are not sufficient justification > for adding new security hooks. So if you want to add security hooks that > a bpf lsm makes use of then you need to come up with an implementation > for another in-tree LSM. I apologize. I didn't realize that adding these as new generic LSM hooks points had already been proposed and discussed with the LSM maintainers. I just wanted to make sure that we weren't unintentionally side-stepping. > However, a subsystem is free to add as much bpf support as it wants: > none, some, flamethrower mode. Cgroupfs has traditionally been very bpf > friendly. I maintain namespaces and rewrote the infra allowing me to > manage them uniformly now. bpf literally just needs an attach point. I > could also just add fmodret tracepoints and achieve the same result. > > The same way you add bpf kfuncs to support access to functionality that > put you way past what an in-tree use would be able do. The question is > whether you want such capabilities to be bounded by in-tree users as > well. > > Either a bpf lsm is an inextensible fixture bound to the scope of > security_* or you allow subsystems open to it to add functionality just > like adding a kfuncs is. Adding these dedicated BPF LSM hooks is OK with me, especially knowing that I have agreement from you that you'll also be maintaining their call sites.