public inbox for linux-security-module@vger.kernel.org
 help / color / mirror / Atom feed
From: "Dr. Greg" <greg@enjellic.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: Paul Moore <paul@paul-moore.com>, linux-security-module@vger.kernel.org
Subject: Re: Improved guidance for LSM submissions.
Date: Thu, 15 Jan 2026 09:55:55 -0600	[thread overview]
Message-ID: <20260115155555.GA18668@wind.enjellic.com> (raw)
In-Reply-To: <2ea2e67e-8fcd-43d8-8cda-7df8d678d2b0@schaufler-ca.com>

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

  reply	other threads:[~2026-01-15 15:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-08 15:46 Improved guidance for LSM submissions Dr. Greg
2026-01-09 18:51 ` Paul Moore
2026-01-09 19:58   ` Casey Schaufler
2026-01-15 15:55     ` Dr. Greg [this message]
2026-01-15 17:49       ` Paul Moore
2026-01-15 18:24       ` Casey Schaufler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260115155555.GA18668@wind.enjellic.com \
    --to=greg@enjellic.com \
    --cc=casey@schaufler-ca.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox