[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAHC9VhTPrrgRh7v-H7qpizbxHNcW-V1qj-=24+Z8at2w4Co4uw@mail.gmail.com>
Date: Thu, 7 Aug 2025 13:21:02 -0400
From: Paul Moore <paul@...l-moore.com>
To: Blaise Boscaccy <bboscaccy@...ux.microsoft.com>
Cc: James Morris <jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>,
Stephen Smalley <stephen.smalley.work@...il.com>, Ondrej Mosnacek <omosnace@...hat.com>,
Casey Schaufler <casey@...aufler-ca.com>, John Johansen <john.johansen@...onical.com>,
Christian Göttsche <cgzones@...glemail.com>,
Song Liu <song@...nel.org>, linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org, selinux@...r.kernel.org
Subject: Re: [PATCH v2] lsm,selinux: Add LSM blob support for BPF objects
On Thu, Aug 7, 2025 at 11:09 AM Blaise Boscaccy
<bboscaccy@...ux.microsoft.com> wrote:
> Paul Moore <paul@...l-moore.com> writes:
>
> > On Jul 22, 2025 Blaise Boscaccy <bboscaccy@...ux.microsoft.com> wrote:
> >>
> >> This patch introduces LSM blob support for BPF maps, programs, and
> >> tokens to enable LSM stacking and multiplexing of LSM modules that
> >> govern BPF objects. Additionally, the existing BPF hooks used by
> >> SELinux have been updated to utilize the new blob infrastructure,
> >> removing the assumption of exclusive ownership of the security
> >> pointer.
> >>
> >> Signed-off-by: Blaise Boscaccy <bboscaccy@...ux.microsoft.com>
> >> ---
> >> v2:
> >> - Use lsm_blob_alloc
> >> - Remove unneded null check
> >> - ifdef guard bpf alloc helpers
> >> ---
> >> include/linux/lsm_hooks.h | 3 ++
> >> security/security.c | 86 +++++++++++++++++++++++++++++--
> >> security/selinux/hooks.c | 56 ++++----------------
> >> security/selinux/include/objsec.h | 17 ++++++
> >> 4 files changed, 113 insertions(+), 49 deletions(-)
> >
> > This looks good to me, one nit/question below ...
> >
> >> @@ -5684,7 +5731,16 @@ int security_bpf_prog(struct bpf_prog *prog)
> >> int security_bpf_map_create(struct bpf_map *map, union bpf_attr *attr,
> >> struct bpf_token *token, bool kernel)
> >> {
> >> - return call_int_hook(bpf_map_create, map, attr, token, kernel);
> >> + int rc = 0;
> >
> > I understand the motivation behind initializing @rc to zero, but to be
> > honest it is redundant and will surely result in a follow on patch from
> > someone to remove the initialization.
> >
> > Do you have any objection to me removing the initialization during the
> > merge? This would obviously apply to the other two as well.
> >
>
> No objections on my end. Thanks.
Okay, merged to lsm/dev-staging with plans to move it to lsm/dev once
the merge window closes.
--
paul-moore.com
Powered by blists - more mailing lists