Re: Linux-specific kernel hardening

[Solar Designer <solar@openwall.com>]

On Mon, Oct 05, 2020 at 12:02:55PM -0400, Theodore Y. Ts'o wrote:
> On Mon, Oct 05, 2020 at 04:14:56PM +0200, Solar Designer wrote:
> > > So your suggested use of kernel-hardening@ is for discussions of Linux
> > > kernel hardening projects or work-in-progress that isn't to be submitted
> > > upstream or isn't yet submitted upstream.  If, and as soon as, a patch
> > > series is sent upstream, that should go on the new linux-hardening@
> > > list?  And only in there or also CC'ed to kernel-hardening@?  I'm just
> > > trying to understand.
> > 
> > We need you to comment on the above.  I hope you did have some idea of
> > how the topics would be split between the two lists, but you haven't
> > really specified that yet.  I tried to make guesses in the paragrapht
> > above, so at least you need to confirm whether my guesses are correct,
> > or correct me if they are not.
> 
> Perhaps this would be a helpful way of framing the issue.  The list
> specified in the MAINTAINERS list is the one that is going to be
> automatically returned by the scripts/get_maintainer_pl script.  This
> gets used by kernel newbies who send things like white space fixes and
> spelling corrections to said developer's list.  For most
> vger.kernel.org lists, we mix high-level architectural discussions
> with things like trivial patches.  It sounds like you don't want these
> sorts of administrivia messages sent to the openwall list.  Is that
> correct?

I don't care much whether it's "to the Openwall list" or not, but I do
feel that actual kernel hardening discussions are hampered by the
administrivia, no matter where they occur.  I suggested an easy way to
remove a small portion of the administrivia (by far not all of it, but
a portion that's the easiest to remove): drop the list from MAINTAINERS.
Unfortunately, this contributed to the split of the list in two, which
I'm concerned might not work well.  If I knew where this would lead, I
wouldn't have suggested that.

> If that is true, it's not something that moderation will fix by
> somewhere,

Sure.  I never suggested we could fix that with moderation.

> but it that traffic needs to go *somewhere*.

I thought it wasn't an absolute requirement to have a mailing list
specified for every entry in MAINTAINERS, but if it is then I'm fine
with replacing the two mentions of kernel-hardening in MAINTAINERS with
another list, and I'm also fine with keeping kernel-hardening in there
if the alternative is even worse.

> > I see there are already a few threads on linux-hardening, and those are
> > not CC'ed to kernel-hardening.  I am pleasantly surprised that those
> > threads are about rather minor changes, which while acceptable to have
> > on kernel-hardening as well IMO do not add much value to discussions
> > desirable on kernel-hardening: "Replace one-element array with
> > flexible-array member", "Use flex_array_size() helper", "Use
> > array_size() helper", "Replace one-element array and save heap space",
> > "Use fallthrough pseudo-keyword".
> 
> Exactly, that's the sort of thing that needs its own mailing list, and
> moderation won't fix.

Right, but like you say this is challenging.  It's a surprise to me it
worked OK for a few days, and I doubt that will always be the case.

> The challenge is whether we can get people to subscribe to two lists,

If 100% of the topics on linux-hardening are supposed to be a subset of
what was on kernel-hardening, I think it'd be OK for me to provide the
subscriber list to a vger admin, who would subscribe those people to
linux-hardening.  However, after that point the subscriber lists will
start to differ, and that's actually what we should want if we want a
split of topics at all.  If the same sets of people were on both lists
at all times, then there's obviously no point in the split.

> and redirect messages to the right list when the topic changes.
> Sometimes what starts off as a seemingly trivial patch fix turns intot
> an arhitectural discussion.

This also happens the other way around - an architectural discussion can
result in many administrivia sub-threads resulting from patch review.

> Expecting people to change the mailing
> list name when the scope of the discussion changes is probably not
> realistic --- not to mention that when such a change *does* happen,
> there may be missing context that will be lost since the original
> message started out on "administrivia" list.  (Which is why we
> generally don't separate out those two buckets on the standard kernel
> subsystem lists on vger.)

Right, and this is also why I wouldn't have suggested splitting the
kernel-hardening list, and found this so problematic.  I just felt the
two mentions in MAINTAINERS were unlikely to result in such problems (if
removed or re-pointed to elsewhere), based on what I saw directed to
kernel-hardening via those so far (although I admit I have no reliable
way to determine why exactly a thread was CC'ed to kernel-hardening).

Alexander