On Thu, Jun 1, 2023 at 11:51 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> On Thu, Jun 01, 2023 at 10:56:24AM -0400, Paul Moore wrote:
> > On Thu, Jun 1, 2023 at 9:20 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > > On Thu, Jun 01, 2023 at 09:13:21AM -0400, Luiz Capitulino wrote:
> >
> > ...
> >
> > > > Yes. I'm reporting this here because I'm more concerned with -stable kernels since
> > > > they're more likely to be running on older user-space.
> > >
> > > Yeah, we are bug-compatible! :)
> >
> > While I really don't want to go back into the old arguments about what
> > does, and does not, get backported to -stable, I do want to ask if
> > there is some way to signal to the -stable maintainers that a patch
> > should not be backported? Anything coming from the LSM, SELinux, or
> > audit trees that I believe should be backported is explicitly marked
> > with a stable@vger CC, as documented in stable-kernel-rules.rst,
> > however it is generally my experience that patches with a 'Fixes:' tag
> > are generally pulled into the -stable releases as well.
>
> Really?
Yes, really.
> Right now we HAVE to pick up the Fixes: tagged commits in those
> subsystems as you are missing lots of real fixes.
This starts to bring us back to the old argument about what is
appropriate for -stable, but I've been sticking as close as possible
to what is documented in stable-kernel-rules.rst which (ignoring
things like HW enablement) advises that only patches which fix build
issues or "serious issues" should be considered for -stable. I
consider every bug fix that goes into the LSM, SELinux, and audit
trees to see if it meets those criteria, if it does I mark it with a
-stable tag, if not I leave the -stable tag and ensure it carries a
'Fixes:' tag if it makes sense and an appropriate root-cause commit is
identified.
We definitely have different opinions on where the -stable bug fix
threshold lies. I am of the opinion that every -stable backport
carries risk, and I consider that when deciding if a commit should be
marked for -stable. I do not believe that every bug fix, or every
commit with a 'Fixes:' tag, should be backported to -stable.
> I just quick looked
> and noticed 8cf0a1bc1287 ("capabilities: fix potential memleak on error
> path from vfs_getxattr_alloc()") which you should have tagged, right?
Nope. That's a memleak for a weird corner case that isn't really
going to be triggered in practice; it was found only by code
inspection and requires code modification to exercise. See the
discussion around the original revision for more information:
https://lore.kernel.org/linux-security-module/20221025104544.2298829-1-cuigaosheng1@xxxxxxxxxx/
Can you explain why you HAD to pick up that commit?
> In fact, I've considered most of the LSM code as a "we never tag
> anything for stable so we rely on the Fixes: pickup to clean up after
> us" subsystem. We have many of those in the kernel, so you are in good
> company :)
That would be amusing if it were correct, but your use of absolutes
betrays you. Looking at code under security/ from v5.10 to current on
I see 71 -stable tags as of today. It looks like the last one I
marked was from October of 2022. We could deep dive more on this, but
I think that's a waste of everyone's time.
> > I could start dropping the 'Fixes:' tag from non-stable tagged
> > commits, but that's a step backwards in my opinion.
>
> If a commit has fixes: why wouldn't it be ok for stable trees? That
> feels very odd to me.
Backports have risk, and in my opinion not every bug fix rises to the
level of severity to sufficiently counter that risk. The -stable
kernel documentation seems to support that; if you believe every bug
fix should be backported to the -stable kernels I would suggest you
update the documentation.
> Anyway, if you really want, yes, we can add you to the "list of
> subsystems we do not pick anything for except by explicit cc: stable
> marking" that we have, but note, that feels wrong to me based on the
> very low number of patches being tagged for these directories over time.
That's great, I didn't know you maintained such a list. Please add
the LSM, SELinux, and audit trees to the subsystems which are only
backported when there is an explicit -stable tag. It is worth noting
that this should not affect the -stable backport policy for other
LSMs, e.g. AppArmor, although I can mention this list to the other LSM
maintainers as they may want to be added.
--
paul-moore.com
