* Re: Improved guidance for LSM submissions.
2026-01-15 15:55 ` Dr. Greg
@ 2026-01-15 17:49 ` Paul Moore
2026-01-15 18:24 ` Casey Schaufler
1 sibling, 0 replies; 6+ messages in thread
From: Paul Moore @ 2026-01-15 17:49 UTC (permalink / raw)
To: Dr. Greg; +Cc: Casey Schaufler, linux-security-module
On Thu, Jan 15, 2026 at 10:56 AM Dr. Greg <greg@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@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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Improved guidance for LSM submissions.
2026-01-15 15:55 ` Dr. Greg
2026-01-15 17:49 ` Paul Moore
@ 2026-01-15 18:24 ` Casey Schaufler
1 sibling, 0 replies; 6+ messages in thread
From: Casey Schaufler @ 2026-01-15 18:24 UTC (permalink / raw)
To: Dr. Greg; +Cc: Paul Moore, linux-security-module, Casey Schaufler
On 1/15/2026 7:55 AM, Dr. Greg 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@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.
>> Good day Greg, I hope you are well.
> Hi Casey, thank you, I hope your week has been going well.
>
>> 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.
>
> 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,
In January of 2019 (oh so long ago) I gave a talk at Linux Conference Australia
about the amazing popularity of Linux kernel security. At the end of the talk,
someone asked how long I expected it to last. Without hesitation, I replied
"18 months". Operating system security has never been on a major vendor's
priority list for more than about 2 years. Even the "C2 in '92" era was of
seriously limited duration. *We don't whinge about the limits of Microsoft's
support. We revel in it's continuation.*
https://www.youtube.com/watch?v=GFGJ3e3oj2c
> 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
>
> Paul notes the 'separate your changes' section as his only specific
> recommendation for the submission of new code, that section recommends
> that each patch represent a logical change.
>
> A careful read of the document suggests that our submission did not
> violate what is the 'official' guidance for virgin code submissions.
I'm sorry that you have come to that conclusion. You're wrong.
> Absent the utility of specific guidance, Paul recommends reviewing the
> mailing list for community norms and expectations, so we did.
>
> The following URL provides a full reference to Microsoft's submission
> of their IPE LSM:
>
> https://lwn.net/Articles/969749/
>
> Their strategy mirrored ours with respect to submitting each major
> functional unit as a single patch, a strategy that was sufficient for
> the review of Microsoft's submission, 16 separate times.
>
> You take exception with a single include file containing structures
> referenced by every compilation unit, indicating that a structure
> should be introduced with the code that uses it.
Indeed. You have identified a problem with your submission. You are
encouraged to fix your submission.
> For the good of the community, it would be helpful to have
> clarification as to how you do that without including all of the
> compilation units in a single patch, which would clearly be rejected
> as an inappropriate submission.
Sure it would. Sometimes you have to work it out for yourself.
I have work that's been in flight for 15 years now, not because it's
a bad idea, but because staging it in an acceptable way isn't easy
or obvious.
> Best wishes for a productive New Year.
And the same to you.
>
> As always,
> Dr. Greg
>
> The Quixote Project - Flailing at the Travails of Cybersecurity
> https://github.com/Quixote-Project
>
^ permalink raw reply [flat|nested] 6+ messages in thread