Re: [RFC][PATCH 3/4] lsm: Redefine LSM_HOOK() macro to add return value flags as argument

[Greg KH]

On Wed, Nov 16, 2022 at 05:04:05PM -0500, Paul Moore wrote:
> On Wed, Nov 16, 2022 at 3:11 AM Roberto Sassu
> <roberto.sassu@xxxxxxxxxxxxxxx> wrote:
> > On Tue, 2022-11-15 at 21:27 -0500, Paul Moore wrote:
> > > On Tue, Nov 15, 2022 at 12:58 PM Roberto Sassu
> > > <roberto.sassu@xxxxxxxxxxxxxxx> wrote:
> > > > From: Roberto Sassu <roberto.sassu@xxxxxxxxxx>
> > > >
> > > > Define four return value flags (LSM_RET_NEG, LSM_RET_ZERO, LSM_RET_ONE,
> > > > LSM_RET_GT_ONE), one for each interval of interest (< 0, = 0, = 1, > 1).
> > > >
> > > > Redefine the LSM_HOOK() macro to add return value flags as argument, and
> > > > set the correct flags for each LSM hook.
> > > >
> > > > Implementors of new LSM hooks should do the same as well.
> > > >
> > > > Cc: stable@xxxxxxxxxxxxxxx # 5.7.x
> > > > Fixes: 9d3fdea789c8 ("bpf: lsm: Provide attachment points for BPF LSM programs")
> > > > Signed-off-by: Roberto Sassu <roberto.sassu@xxxxxxxxxx>
> > > > ---
> > > >  include/linux/bpf_lsm.h       |   2 +-
> > > >  include/linux/lsm_hook_defs.h | 779 ++++++++++++++++++++--------------
> > > >  include/linux/lsm_hooks.h     |   9 +-
> > > >  kernel/bpf/bpf_lsm.c          |   5 +-
> > > >  security/bpf/hooks.c          |   2 +-
> > > >  security/security.c           |   4 +-
> > > >  6 files changed, 466 insertions(+), 335 deletions(-)
> > >
> > > Just a quick note here that even if we wanted to do something like
> > > this, it is absolutely not -stable kernel material.  No way.
> >
> > I was unsure about that. We need a proper fix for this issue that needs
> > to be backported to some kernels. I saw this more like a dependency.
> > But I agree with you that it would be unlikely that this patch is
> > applied to stable kernels.
> >
> > For stable kernels, what it would be the proper way? We still need to
> > maintain an allow list of functions that allow a positive return value,
> > at least. Should it be in the eBPF code only?
> 
> Ideally the fix for -stable is the same as what is done for Linus'
> kernel (ignoring backport fuzzing), so I would wait and see how that
> ends up first.  However, if the patchset for Linus' tree is
> particularly large and touches a lot of code, you may need to work on
> something a bit more targeted to the specific problem.  I tend to be
> more conservative than most kernel devs when it comes to -stable
> patches, but if you can't backport the main upstream patchset, smaller
> (both in terms of impact and lines changed) is almost always better.

No, the mainline patch (what is in Linus's tree), is almost always
better and preferred for stable backports.  When you diverge, bugs
happen, almost every time, and it makes later fixes harder to backport
as well.

But first work on solving the problem in Linus's tree.  Don't worry
about stable trees until after the correct solution is merged.

thanks,

greg k-h