Improved guidance for LSM submissions.

[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 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.
>> 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
>