Improved guidance for LSM submissions.

[Paul Moore]

On Thu, Jan 15, 2026 at 10:56 AM Dr. Greg <greg at enjellic.com> wrote:
> On Fri, Jan 09, 2026 at 11:58:39AM -0800, Casey Schaufler wrote:
> > On 1/9/2026 10:51 AM, Paul Moore wrote:
> > > On Thu, Jan 8, 2026 at 11:08???AM Dr. Greg <greg at enjellic.com> wrote:
> > >> What is not clear in these guidelines is how a virgin LSM should be
> > >> structured for initial submission.  Moving forward, we believe the
> > >> community would benefit from having clear guidance on this issue.
> > >>
> > >> It would be helpful if the guidance covers a submission of 10-15 KLOC
> > >> of code and 5-8 compilation units, which seems to cover the average
> > >> range of sizes for LSM's that have significant coverage of the event
> > >> handlers/hooks.

...

> > If you would review the comments I made in 2023 regarding how to
> > make your submission reviewable you might find that you don't need
> > a "formal" statement of policy. Remember that you are not submitting
> > your code to a chartered organization, but to a collection of system
> > developers who are enthusiastic about security. Many are overworked,
> > some are hobbyists, but all treat their time as valuable. If you can't
> > heed the advice you've already been given, there's no incentive for
> > anyone to spend their limited resources to provide it in another
> > format.
>
> As Paul noted in the following:
>
> https://lore.kernel.org/linux-security-module/20230608191304.253977-2-paul@paul-moore.com/
>
> Microsoft employs him to maintain the Linux security sub-system, and
> related infrastructure, secondary to Microsoft's concern over the long
> term health of the Linux community ...

You've brought this up before, which I thought was a bit odd, but I
largely skipped over it because I thought it might simply be you
working your way through learning how the upstream kernel community
works.  We've all been there at one time or another, and we all learn
differently, so no harm in that.  However, you've chosen to bring this
up again, which strikes me as more than just an oddity, but in hopes
that your email is due to an honest lack of understanding, let me try
to provide some background.

I don't have concrete numbers to provide you, but the majority of the
substantial Linux kernel subsystems are maintained by individuals that
are employed, at least in part, to support the upstream Linux kernel.
Personally, I've been responsible for the upkeep of at least one
upstream kernel subsystem for over (checks notes ...) 18 years,
spanning a number of companies with varying levels of employer
support.  Considering the number of people that rely on the subsystems
I maintain, and the trust placed in me by the community, I take my
upstream responsibilities very seriously; I've pushed back against
employers when I've felt their wants would have been detrimental
upstream, and I've left employers when my job duties have become
incompatible with my upstream responsibilities.

I obviously don't want to speak for the other kernel maintainers, but
I believe you will hear similar stories from many others, if not all.
I will say that in my experience the different individual LSM
maintainers have demonstrated the same level of stewardship and
concern for upstream that I've tried to model over the course of my
career.  In my opinion we have a good community here, and our failings
are much more likely due to human time limits than any malice or
intentional constraints.

> Given that, it is disappointing that Microsoft isn't providing
> sufficient resources to enable him to provide guidance to the
> community they desire to support ...

Continuing what I said above, there is no reason to disparage my
current employer, I can assure you my limits are entirely due to how
much time I can spend in front of a computer dealing with difficult
problems, both technical and social, before I burn out for the day.
Of course you are free to make whatever comments you like, but if you
want me to take you seriously, you should give some more thoughtful
consideration before speaking incorrectly about matters you know
little to nothing about (e.g. my relationship with my employer, my
work/life balance, etc.).

Deciding how to prioritize work is a difficult thing, and subject to
revision over the course of a month, week, or even day.  Like many of
us, there are a number of considerations that go into prioritization,
far too many to describe them all here, but one of the criteria is
simply an understanding of how many people will benefit from the work.
While an exhaustive document describing how to submit new LSMs would
surely have value, we've seen a number of LSMs submitted, and merged,
over the years that have been able to do so with the guidance we have
now, if not less.  With that in mind, at this point in time I'm
choosing to focus my efforts on other, more impactful tasks.

> ... regardless of that, we now have
> 'official' guidance as to the requirements for submitting a virgin
> body of LSM code:
>
> https://docs.kernel.org/process/submitting-patches.html

I would encourage a more careful reading of my comments before
repeating.  I "suggested" the document above, I did not say it was
"official guidance":

  "I would suggest looking at the existing Linux kernel documentation
   on submitting patches, a link is provided below."
  (copied from my first reply in this thread)

As Casey pointed out, you've received quite a bit of feedback on your
prior LSM submissions, I would suggest using those comments as a
learning tool to help guide any future submissions.  Just as with
other aspects of life, there are no guarantees here, try to learn from
your experiences and move forward.

Another bit of advice that I think might be helpful in your particular
case: focus on being a constructive member of the LSM community, not a
distraction.  While disruption has been seen as a trendy idea among
the "move fast and break things" crowd, when it comes to core platform
security "break things" can result in significant losses, up to and
including people's lives.

-- 
paul-moore.com