Linux-specific kernel hardening

Linux-specific kernel hardening

[Kees Cook]

Hello!

The work of improving the Linux kernel's security is, of course,
and endless task. While many of the new features come through on the
kernel-hardening@lists.openwall.com list[1], there is a stated desire
to avoid "maintenance" topics[2] on the list, and that isn't compatible
with the on-going work done within the upstream Linux kernel development
community, which may need to discuss the nuances of performing that work.

As such there is now a new list, linux-hardening@vger.kernel.org[3],
which will take kernel-hardening's place in the Linux MAINTAINERS
file. New topics and on-going work will be discussed there, and I urge
anyone interested in Linux kernel hardening to join the new list. It's
my intention that all future upstream work can be CCed there, following
the standard conventions of the Linux development model, for better or
worse. ;)

For anyone discussing new topics or ideas, please continue to CC
kernel-hardening too, as there will likely be many people only subscribed
there. Hopefully this will get the desired split of topics between the
two lists.

Thanks and take care,

-Kees

[1] https://www.openwall.com/lists/kernel-hardening/
    https://lore.kernel.org/kernel-hardening/

[2] https://lore.kernel.org/kernel-hardening/20200902121604.GA10684@openwall.com/

[3] http://vger.kernel.org/vger-lists.html#linux-hardening
    https://lore.kernel.org/linux-hardening/

-- 
Kees Cook

Re: Linux-specific kernel hardening

[Solar Designer]

Hi Kees,

Ouch.  I wouldn't have suggested we do anything at all about that minor
problem if I knew you'd split the list in two as a result.  That's very
confusing.  Assuming that's what you already did anyway, some comments:

On Tue, Sep 29, 2020 at 10:14:03AM -0700, Kees Cook wrote:
> The work of improving the Linux kernel's security is, of course,
> and endless task. While many of the new features come through on the
> kernel-hardening@lists.openwall.com list[1], there is a stated desire
> to avoid "maintenance" topics[2] on the list, and that isn't compatible
> with the on-going work done within the upstream Linux kernel development
> community, which may need to discuss the nuances of performing that work.
> 
> As such there is now a new list, linux-hardening@vger.kernel.org[3],
> which will take kernel-hardening's place in the Linux MAINTAINERS
> file.

OK'ish so far.

> New topics and on-going work will be discussed there, and I urge
> anyone interested in Linux kernel hardening to join the new list. It's
> my intention that all future upstream work can be CCed there, following
> the standard conventions of the Linux development model, for better or
> worse. ;)
> 
> For anyone discussing new topics or ideas, please continue to CC
> kernel-hardening too, as there will likely be many people only subscribed
> there. Hopefully this will get the desired split of topics between the
> two lists.

I find this confusing.  Given that "new topics and on-going work will be
discussed" on the new linux-hardening list, what's left for the old
kernel-hardening list?  Just a legacy list to be CC'ed because people
are still subscribed to it?  If so, it looks like basically because of
my concern about a minor issue you chose to move the list from one place
to another without actually addressing my concern in any way but causing
lots of inconvenience.  That would be weird, so I hope I misunderstand.

To me, "new topics" are certainly desirable on kernel-hardening.  Ditto
for "on-going work" as long as it's work on kernel hardening per se
(patch review, etc.) rather than e.g. documentation formatting fixes for
former kernel hardening changes that are already accepted upstream and
are only CC'ed here because of a formality (link from MAINTAINERS)
rather than anyone's well-reasoned decision.

I suggested that a small minority of messages on kernel-hardening be
removed from here.  You're effectively replacing one list with another,
or if that's not what you're doing then you haven't described it well,
and I wouldn't expect to "get the desired split of topics".

Then there's also the lists' naming and the Subject on this message.
Are you suggesting that the kernel-hardening list be used for kernel
hardening that is not Linux specific?  That would be a reuse of an
abandoned list, if it would be, but I don't know whether there's demand
for that and it's probably incompatible with continuing to CC the list
on Linux-specific topics and it might not be well-received by all
current subscribers who assumed it was a Linux list, which it was.

Please clarify.

> [1] https://www.openwall.com/lists/kernel-hardening/
>     https://lore.kernel.org/kernel-hardening/
> 
> [2] https://lore.kernel.org/kernel-hardening/20200902121604.GA10684@openwall.com/
> 
> [3] http://vger.kernel.org/vger-lists.html#linux-hardening
>     https://lore.kernel.org/linux-hardening/

Alexander

Re: Linux-specific kernel hardening

[Kees Cook]

On Tue, Sep 29, 2020 at 09:25:17PM +0200, Solar Designer wrote:
> On Tue, Sep 29, 2020 at 10:14:03AM -0700, Kees Cook wrote:
> > New topics and on-going work will be discussed there, and I urge
> > anyone interested in Linux kernel hardening to join the new list. It's
> > my intention that all future upstream work can be CCed there, following
> > the standard conventions of the Linux development model, for better or
> > worse. ;)
> > 
> > For anyone discussing new topics or ideas, please continue to CC
> > kernel-hardening too, as there will likely be many people only subscribed
> > there. Hopefully this will get the desired split of topics between the
> > two lists.
> 
> I find this confusing.  Given that "new topics and on-going work will be
> discussed" on the new linux-hardening list, what's left for the old
> kernel-hardening list?  Just a legacy list to be CC'ed because people

My intention is to allow for linux-hardening@ to be the defacto place
for upstream Linux kernel hardening work. (And I include "upstream"
there again intentionally, and "work", which is larger than just
discussing new features.) Such a place must exist for the mechanical
and social processes inherent in the Linux kernel development model to
operate. Something needs to be listed in the MAINTAINERS file, and tools
direct email delivery much more commonly than individuals.

Since it is not part of the established Linux development processes to
_remove_ lists from CC when they're part of the maintainership chain or
git history, it's simply not possible for kernel-hardening@ to serve in
that role, given the constraints on topic applicability.

For stuff that IS a new topic, where people are explicitly choosing
what lists to send to, CCing both linux-hardening@ and kernel-hardening@
seems like the right thing to do to get that topic split.

> are still subscribed to it?  If so, it looks like basically because of
> my concern about a minor issue you chose to move the list from one place
> to another without actually addressing my concern in any way but causing
> lots of inconvenience.  That would be weird, so I hope I misunderstand.

I don't think the Linux kernel's (email) development model is compatible
with having a "strictly on-topic" mailing list as part of the standard
process. Your concerns are perfectly valid, but just not something that
I see a way to solving without significant effort (e.g. making the list
entirely moderated, etc). And moderation is actually another aspect of
the desire to move; emails are regularly auto-moderated which just
creates more manual work (for both of us).

> To me, "new topics" are certainly desirable on kernel-hardening.  Ditto
> for "on-going work" as long as it's work on kernel hardening per se
> (patch review, etc.) rather than e.g. documentation formatting fixes for
> former kernel hardening changes that are already accepted upstream and
> are only CC'ed here because of a formality (link from MAINTAINERS)
> rather than anyone's well-reasoned decision.

I don't want myself or anyone else to have to worry about where the line
is drawn. If kernel-hardening@ is on CC for new topics, we're all good.
With the MAINTAINERS file updated, and a .mailmap entry added to redirect
kernel-hardening@ to linux-hardening@, all the "mechanical" threads will
avoid kernel-hardening@, and we'll be close to what will work best for
the topic split.

> I suggested that a small minority of messages on kernel-hardening be
> removed from here.  You're effectively replacing one list with another,
> or if that's not what you're doing then you haven't described it well,
> and I wouldn't expect to "get the desired split of topics".

I understand what you mean, but I think the effort required to remove
those messages is too high. As an upstream Linux kernel maintainer, I
have different constraints on how I need a development discussion list
to operate. In the quoted thread[2] from earlier, I explained (perhaps
badly) those constraints, and you disagreed and additionally said
further discussion would hinder kernel-hardening@. It's your list and
list server, so I obviously can't make you agree to operate it the way
Linux kernel development lists are expected to work, so I didn't really
have any other choice but to start a new list. I recognize you've made a
lot of changes over the past several years (e.g. Subject prefixes, etc)
to adapt to those norms, but the list's acceptable "range of discussion"
seemed like a pretty fundamental difference that was unlikely to be
easily solved with a single list.

> Then there's also the lists' naming and the Subject on this message.
> Are you suggesting that the kernel-hardening list be used for kernel
> hardening that is not Linux specific?  That would be a reuse of an

The better distinction is between upstream and not. Another aspect driving
this change is the belief by people that the Linux Kernel Self-Protection
Project is somehow not upstream, which I think is somewhat reinforced
by the mailing list not living on vger.kernel.org. It's hardly a strong
enough reason to move (much like the auto-moderation hassles), but when
all are combined, I found the move sufficiently justified.

> abandoned list, if it would be, but I don't know whether there's demand
> for that and it's probably incompatible with continuing to CC the list
> on Linux-specific topics and it might not be well-received by all
> current subscribers who assumed it was a Linux list, which it was.

Agreed, I should have said "upstream-specific" in the Subject. That was
not clear there.

Hopefully this clears things up. I'm fundamentally seeking less
work/irritation for both of us, as well as for the folks doing upstream
work who find themselves CCing a development mailing list, and the folks
who want to just see the discussion of new features.

-Kees

> [2] https://lore.kernel.org/kernel-hardening/20200902121604.GA10684@openwall.com/

-- 
Kees Cook

Re: Linux-specific kernel hardening

[Solar Designer]

On Tue, Sep 29, 2020 at 04:41:45PM -0700, Kees Cook wrote:
> On Tue, Sep 29, 2020 at 09:25:17PM +0200, Solar Designer wrote:
> > On Tue, Sep 29, 2020 at 10:14:03AM -0700, Kees Cook wrote:
> > > New topics and on-going work will be discussed there, and I urge
> > > anyone interested in Linux kernel hardening to join the new list. It's
> > > my intention that all future upstream work can be CCed there, following
> > > the standard conventions of the Linux development model, for better or
> > > worse. ;)
> > > 
> > > For anyone discussing new topics or ideas, please continue to CC
> > > kernel-hardening too, as there will likely be many people only subscribed
> > > there. Hopefully this will get the desired split of topics between the
> > > two lists.
> > 
> > I find this confusing.  Given that "new topics and on-going work will be
> > discussed" on the new linux-hardening list, what's left for the old
> > kernel-hardening list?  Just a legacy list to be CC'ed because people
> 
> My intention is to allow for linux-hardening@ to be the defacto place
> for upstream Linux kernel hardening work. (And I include "upstream"
> there again intentionally, and "work", which is larger than just
> discussing new features.) Such a place must exist for the mechanical
> and social processes inherent in the Linux kernel development model to
> operate. Something needs to be listed in the MAINTAINERS file, and tools
> direct email delivery much more commonly than individuals.
> 
> Since it is not part of the established Linux development processes to
> _remove_ lists from CC when they're part of the maintainership chain or
> git history, it's simply not possible for kernel-hardening@ to serve in
> that role, given the constraints on topic applicability.

We could simply keep the constraints relaxed as necessary.  I didn't
even suggest removing the list from CC on messages sent per git history;
in fact, I don't recall that ever resulting in undesirable messages in
here.  I merely suggested removing the list from the MAINTAINERS file.
I don't see why that couldn't simply be done, but I didn't insist.  What
you're doing now is far worse than keeping the list in MAINTAINERS or
removing it from there, in my opinion.

> For stuff that IS a new topic, where people are explicitly choosing
> what lists to send to, CCing both linux-hardening@ and kernel-hardening@
> seems like the right thing to do to get that topic split.

I think this will most likely result in one of 3 things:

1. 90%+ of messages CC'ed to both lists.

2. Topics arbitrarily limited to just one of the two lists, with no
clear separation on what goes where, and some CC'ed to both lists.

3. Everything staying on/moving to just one of the two lists eventually,
after struggling with 1 or 2 above for a while.

It'll be really hard (almost unrealistic) for us to arrive at a
reasonable topic split between the lists now.  Moreover, I don't know of
such reasonable split even if we could somehow make it happen.

> > are still subscribed to it?  If so, it looks like basically because of
> > my concern about a minor issue you chose to move the list from one place
> > to another without actually addressing my concern in any way but causing
> > lots of inconvenience.  That would be weird, so I hope I misunderstand.
> 
> I don't think the Linux kernel's (email) development model is compatible
> with having a "strictly on-topic" mailing list as part of the standard
> process. Your concerns are perfectly valid, but just not something that
> I see a way to solving without significant effort (e.g. making the list
> entirely moderated, etc).

Removing the list from the MAINTAINERS file (maybe replacing it with the
new list as you suggest) wouldn't be significant effort.  If that is
somehow not suitable, we can live with the occasional noise that brings.

My concerns were not related to Openwall hosting the list.  They were
related to well-being of KSPP, no matter where the list is hosted.  So
by moving the list you have not addressed my concerns at all.  You've
only made things far worse.

> And moderation is actually another aspect of
> the desire to move; emails are regularly auto-moderated which just
> creates more manual work (for both of us).

Messages that are auto-approved don't create any work for either of us,
and that's the majority of them.  Messages that are held for moderation
(until I add the sender to moderation bypass) do involve some work, but
that's the only way to avoid spam on the list.  I think that amount of
work is small compared to all subscribers' time wasted on occasional
spam on the list.  If it's unacceptable for you, I can remove you from
list moderators and maybe add someone else as a co-moderator.  I think
it wouldn't be hard for us to find a volunteer.  Please let me know.

Besides, the split doesn't solve this problem for kernel-hardening@.

> > To me, "new topics" are certainly desirable on kernel-hardening.  Ditto
> > for "on-going work" as long as it's work on kernel hardening per se
> > (patch review, etc.) rather than e.g. documentation formatting fixes for
> > former kernel hardening changes that are already accepted upstream and
> > are only CC'ed here because of a formality (link from MAINTAINERS)
> > rather than anyone's well-reasoned decision.
> 
> I don't want myself or anyone else to have to worry about where the line
> is drawn. If kernel-hardening@ is on CC for new topics, we're all good.
> With the MAINTAINERS file updated, and a .mailmap entry added to redirect
> kernel-hardening@ to linux-hardening@, all the "mechanical" threads will
> avoid kernel-hardening@, and we'll be close to what will work best for
> the topic split.

OK, let's hope this will work, although I doubt it and I don't know what
topic split is desirable.

> > I suggested that a small minority of messages on kernel-hardening be
> > removed from here.  You're effectively replacing one list with another,
> > or if that's not what you're doing then you haven't described it well,
> > and I wouldn't expect to "get the desired split of topics".
> 
> I understand what you mean, but I think the effort required to remove
> those messages is too high. As an upstream Linux kernel maintainer, I
> have different constraints on how I need a development discussion list
> to operate. In the quoted thread[2] from earlier, I explained (perhaps
> badly) those constraints, and you disagreed and additionally said
> further discussion would hinder kernel-hardening@. It's your list and
> list server, so I obviously can't make you agree to operate it the way
> Linux kernel development lists are expected to work, so I didn't really
> have any other choice but to start a new list.

That's a major misunderstanding.  I cared primarily about the well-being
of KSPP, and not so much about hosting/administering a list with a
policy I disagree with in a minor way, which I accepted.  I didn't want
to continue that discussion "for very long" as it "hurts actual work",
not because I disagreed with you (although I did) and insisted on that
deciding list policy (I did not, and it did not).  BTW, now we're having
another such discussion that hurts actual work, so I am also not going
to continue it for very long.

If you didn't want to add to a thread given my comment about it hurting,
you could always e-mail me off-list, and I'd tell you that you certainly
did have other choices.

> I recognize you've made a
> lot of changes over the past several years (e.g. Subject prefixes, etc)
> to adapt to those norms, but the list's acceptable "range of discussion"
> seemed like a pretty fundamental difference that was unlikely to be
> easily solved with a single list.

Fair enough, although I only suggested excluding CC's resulting from
MAINTAINERS, which didn't feel fundamental enough to insist on it (so I
did not), let alone to split the list in two.

> > Then there's also the lists' naming and the Subject on this message.
> > Are you suggesting that the kernel-hardening list be used for kernel
> > hardening that is not Linux specific?  That would be a reuse of an
> 
> The better distinction is between upstream and not. Another aspect driving
> this change is the belief by people that the Linux Kernel Self-Protection
> Project is somehow not upstream, which I think is somewhat reinforced
> by the mailing list not living on vger.kernel.org. It's hardly a strong
> enough reason to move (much like the auto-moderation hassles), but when
> all are combined, I found the move sufficiently justified.

Actually, that feels like the only valid reason to me.

> > abandoned list, if it would be, but I don't know whether there's demand
> > for that and it's probably incompatible with continuing to CC the list
> > on Linux-specific topics and it might not be well-received by all
> > current subscribers who assumed it was a Linux list, which it was.
> 
> Agreed, I should have said "upstream-specific" in the Subject. That was
> not clear there.

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.

> Hopefully this clears things up. I'm fundamentally seeking less
> work/irritation for both of us, as well as for the folks doing upstream
> work who find themselves CCing a development mailing list, and the folks
> who want to just see the discussion of new features.

I currently don't expect this to work well, but let's see.

> > [2] https://lore.kernel.org/kernel-hardening/20200902121604.GA10684@openwall.com/

Alexander

Re: Linux-specific kernel hardening

[Solar Designer]

Hi Kees,

On Wed, Sep 30, 2020 at 11:02:32AM +0200, Solar Designer wrote:
> Messages that are auto-approved don't create any work for either of us,
> and that's the majority of them.  Messages that are held for moderation
> (until I add the sender to moderation bypass) do involve some work, but
> that's the only way to avoid spam on the list.  I think that amount of
> work is small compared to all subscribers' time wasted on occasional
> spam on the list.  If it's unacceptable for you, I can remove you from
> list moderators and maybe add someone else as a co-moderator.  I think
> it wouldn't be hard for us to find a volunteer.  Please let me know.

Someone has already volunteered.  I'd also like to hear from someone
possibly not as over-qualified and as busy as that person is. ;-)

Kees, if you'd like to step down as a co-moderator for kernel-hardening,
please let me know.  We'll add someone else (so that this doesn't depend
solely on me being around).

To avoid misinterpretation: I am not suggesting that you need to step
down, totally not.  I merely feel that you need to have the option since
you expressed unhappiness with having to spend effort on that.

> That's a major misunderstanding.  I cared primarily about the well-being
> of KSPP, and not so much about hosting/administering a list with a
> policy I disagree with in a minor way, which I accepted.  I didn't want
> to continue that discussion "for very long" as it "hurts actual work",
> not because I disagreed with you (although I did) and insisted on that
> deciding list policy (I did not, and it did not).  BTW, now we're having
> another such discussion that hurts actual work, so I am also not going
> to continue it for very long.

It is weird that I now feel I have to spell it out explicitly, but I do,
so: Kees, please don't use my saying that I don't want to continue this
bikeshed discussion "for very long" as an excuse for lack of
coordination on your part, again.  That's not a valid excuse, nor do you
need one.  You can always coordinate with me off-list if you prefer, but
I don't mind this thread continuing on the list for a little while.

> 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 paragraph
above, so at least you need to confirm whether my guesses are correct,
or correct me if they are not.

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

I think topics more desirable on kernel-hardening would be deciding on
such replacements in general (not patches for individual instances),
introduction of such helpers, etc.  Also summaries of work done (e.g.,
"this-many instances of that-thing were updated to new conventions in
the kernel over the last month as discussed in those threads seen in
that list archive").  I use examples from the past because that's what
we have, but I use them to illustrate roughly what kinds of things we
could possibly have on one list vs. the other in the future.

Thanks,

Alexander

Re: Linux-specific kernel hardening

[Theodore Y. Ts'o]

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?

If that is true, it's not something that moderation will fix by
somewhere, but it that traffic needs to go *somewhere*.

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

The challenge is whether we can get people to subscribe to two lists,
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.  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.)

Cheers,

					- Ted
 

Re: Linux-specific kernel hardening

[Solar Designer]

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

Re: Linux-specific kernel hardening

[Jann Horn]

On Mon, Oct 5, 2020 at 6:48 PM Solar Designer <solar@openwall.com> wrote:
> 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.

(if folks want to go that route, probably easier to subscribe the list
linux-hardening@ itself to kernel-hardening@ instead of syncing
subscriber lists?)

Re: Linux-specific kernel hardening

[Kees Cook]

On Tue, Oct 06, 2020 at 12:26:50AM +0200, Jann Horn wrote:
> On Mon, Oct 5, 2020 at 6:48 PM Solar Designer <solar@openwall.com> wrote:
> > 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.
> 
> (if folks want to go that route, probably easier to subscribe the list
> linux-hardening@ itself to kernel-hardening@ instead of syncing
> subscriber lists?)

Yeah, that would make things a bit simpler. Solar, would you be willing
to do that? (Then I can tweak the wiki instructions a bit more.)

-- 
Kees Cook

Re: Linux-specific kernel hardening

[Solar Designer]

On Mon, Oct 05, 2020 at 03:39:26PM -0700, Kees Cook wrote:
> On Tue, Oct 06, 2020 at 12:26:50AM +0200, Jann Horn wrote:
> > On Mon, Oct 5, 2020 at 6:48 PM Solar Designer <solar@openwall.com> wrote:
> > > 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.
> > 
> > (if folks want to go that route, probably easier to subscribe the list
> > linux-hardening@ itself to kernel-hardening@ instead of syncing
> > subscriber lists?)
> 
> Yeah, that would make things a bit simpler. Solar, would you be willing
> to do that? (Then I can tweak the wiki instructions a bit more.)

Sure, I can do that.  Should I?

Per http://vger.kernel.org/vger-lists.html#linux-hardening there are
currently 39 subscribers on the new list.  I guess most of those are
also on kernel-hardening, and would start receiving two copies of
messages that are posted to kernel-hardening.  I guess they would then
need to unsubscribe from kernel-hardening if they want to see the
content of both lists, or to unsubscribe from linux-hardening if they
changed their mind and only want the content of kernel-hardening.  I
think this is still not too many people, so this is reasonable; if we
were to do it later, we'd inconvenience more people.

Alexander

Re: Linux-specific kernel hardening

[Kees Cook]

On Tue, Oct 06, 2020 at 04:21:27PM +0200, Solar Designer wrote:
> On Mon, Oct 05, 2020 at 03:39:26PM -0700, Kees Cook wrote:
> > On Tue, Oct 06, 2020 at 12:26:50AM +0200, Jann Horn wrote:
> > > On Mon, Oct 5, 2020 at 6:48 PM Solar Designer <solar@openwall.com> wrote:
> > > > 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.
> > > 
> > > (if folks want to go that route, probably easier to subscribe the list
> > > linux-hardening@ itself to kernel-hardening@ instead of syncing
> > > subscriber lists?)
> > 
> > Yeah, that would make things a bit simpler. Solar, would you be willing
> > to do that? (Then I can tweak the wiki instructions a bit more.)
> 
> Sure, I can do that.  Should I?
> 
> Per http://vger.kernel.org/vger-lists.html#linux-hardening there are
> currently 39 subscribers on the new list.  I guess most of those are
> also on kernel-hardening, and would start receiving two copies of
> messages that are posted to kernel-hardening.  I guess they would then
> need to unsubscribe from kernel-hardening if they want to see the
> content of both lists, or to unsubscribe from linux-hardening if they
> changed their mind and only want the content of kernel-hardening.  I
> think this is still not too many people, so this is reasonable; if we
> were to do it later, we'd inconvenience more people.

Hm, I guess I was thinking about this only from the perspective of
Message-Id handling: the duplicates wouldn't be noticed -- but of course
I've been struggling with IMAP vs Gmail for so long I've almost
forgotten how actual email works. ;)

Yeah, the duplicate emails would be pretty bad. Let's not do this for
now, and if it becomes an actual issue we can change it then.

-- 
Kees Cook

Re: Linux-specific kernel hardening

[Kees Cook]

On Mon, Oct 05, 2020 at 04:14:56PM +0200, Solar Designer wrote:
> On Wed, Sep 30, 2020 at 11:02:32AM +0200, Solar Designer wrote:
> > Messages that are auto-approved don't create any work for either of us,
> > and that's the majority of them.  Messages that are held for moderation
> > (until I add the sender to moderation bypass) do involve some work, but
> > that's the only way to avoid spam on the list.  I think that amount of
> > work is small compared to all subscribers' time wasted on occasional
> > spam on the list.  If it's unacceptable for you, I can remove you from
> > list moderators and maybe add someone else as a co-moderator.  I think
> > it wouldn't be hard for us to find a volunteer.  Please let me know.
> 
> Someone has already volunteered.  I'd also like to hear from someone
> possibly not as over-qualified and as busy as that person is. ;-)
> 
> Kees, if you'd like to step down as a co-moderator for kernel-hardening,
> please let me know.  We'll add someone else (so that this doesn't depend
> solely on me being around).
> 
> To avoid misinterpretation: I am not suggesting that you need to step
> down, totally not.  I merely feel that you need to have the option since
> you expressed unhappiness with having to spend effort on that.

My complaint about moderation is about the list needing to be moderated
at all. (I would note that your own postings to kernel-hardening@ got
moderated...) While vger is certainly not perfect in its spam control,
it is usually fine, and behaves well enough for many other upstream
kernel lists.

> > 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 paragraph
> above, so at least you need to confirm whether my guesses are correct,
> or correct me if they are not.

My expectation would be that "new topic" RFCs/patches would be CCed to
both lists. Everything else would go to linux-hardening.

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

These threads are all on topic, as far as I'm concerned, but they easily
run the "risk" of turning into bike-shedding and nuance, etc. But those
are exactly the kinds of threads I want to have on linux-hardening@ (as
well as the "larger" topics).

> I think topics more desirable on kernel-hardening would be deciding on
> such replacements in general (not patches for individual instances),

Right -- and this is impossible to separate "by default" without a second
list. linux-hardening@ is the default now, as declared by MAINTAINERS
and mailmap. For folks wanting a wider audience for new/big topics,
kernel-hardening@ can be additionally CCed. I have clarified this in the
KSPP wiki now:

https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Get_Involved

> introduction of such helpers, etc.  Also summaries of work done (e.g.,
> "this-many instances of that-thing were updated to new conventions in
> the kernel over the last month as discussed in those threads seen in
> that list archive").  I use examples from the past because that's what
> we have, but I use them to illustrate roughly what kinds of things we
> could possibly have on one list vs. the other in the future.

Agreed.

-- 
Kees Cook