Improved guidance for LSM submissions.

[Dr. Greg]

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

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.

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.

Best wishes for a productive New Year.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity
              https://github.com/Quixote-Project