* Linux-specific kernel hardening @ 2020-09-29 17:14 Kees Cook 2020-09-29 19:25 ` Solar Designer 2020-10-07 15:16 ` Romain Perier 0 siblings, 2 replies; 14+ messages in thread From: Kees Cook @ 2020-09-29 17:14 UTC (permalink / raw) To: kernel-hardening, linux-hardening 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux-specific kernel hardening 2020-09-29 17:14 Linux-specific kernel hardening Kees Cook @ 2020-09-29 19:25 ` Solar Designer 2020-09-29 23:41 ` Kees Cook 2020-10-07 15:16 ` Romain Perier 1 sibling, 1 reply; 14+ messages in thread From: Solar Designer @ 2020-09-29 19:25 UTC (permalink / raw) To: Kees Cook; +Cc: kernel-hardening, linux-hardening 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux-specific kernel hardening 2020-09-29 19:25 ` Solar Designer @ 2020-09-29 23:41 ` Kees Cook 2020-09-30 9:02 ` Solar Designer 0 siblings, 1 reply; 14+ messages in thread From: Kees Cook @ 2020-09-29 23:41 UTC (permalink / raw) To: Solar Designer; +Cc: kernel-hardening, linux-hardening 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux-specific kernel hardening 2020-09-29 23:41 ` Kees Cook @ 2020-09-30 9:02 ` Solar Designer 2020-10-05 14:14 ` Solar Designer 0 siblings, 1 reply; 14+ messages in thread From: Solar Designer @ 2020-09-30 9:02 UTC (permalink / raw) To: Kees Cook; +Cc: kernel-hardening, linux-hardening 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux-specific kernel hardening 2020-09-30 9:02 ` Solar Designer @ 2020-10-05 14:14 ` Solar Designer 2020-10-05 16:02 ` Theodore Y. Ts'o 2020-10-05 22:23 ` Kees Cook 0 siblings, 2 replies; 14+ messages in thread From: Solar Designer @ 2020-10-05 14:14 UTC (permalink / raw) To: Kees Cook; +Cc: kernel-hardening, linux-hardening 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux-specific kernel hardening 2020-10-05 14:14 ` Solar Designer @ 2020-10-05 16:02 ` Theodore Y. Ts'o 2020-10-05 16:48 ` Solar Designer 2020-10-05 22:23 ` Kees Cook 1 sibling, 1 reply; 14+ messages in thread From: Theodore Y. Ts'o @ 2020-10-05 16:02 UTC (permalink / raw) To: Solar Designer; +Cc: Kees Cook, kernel-hardening, linux-hardening 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux-specific kernel hardening 2020-10-05 16:02 ` Theodore Y. Ts'o @ 2020-10-05 16:48 ` Solar Designer 2020-10-05 22:26 ` Jann Horn 0 siblings, 1 reply; 14+ messages in thread From: Solar Designer @ 2020-10-05 16:48 UTC (permalink / raw) To: Theodore Y. Ts'o; +Cc: Kees Cook, kernel-hardening, linux-hardening 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux-specific kernel hardening 2020-10-05 16:48 ` Solar Designer @ 2020-10-05 22:26 ` Jann Horn 0 siblings, 0 replies; 14+ messages in thread From: Jann Horn @ 2020-10-05 22:26 UTC (permalink / raw) To: Solar Designer Cc: Theodore Y. Ts'o, Kees Cook, Kernel Hardening, linux-hardening 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?) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux-specific kernel hardening @ 2020-10-05 22:26 ` Jann Horn 0 siblings, 0 replies; 14+ messages in thread From: Jann Horn @ 2020-10-05 22:26 UTC (permalink / raw) To: Solar Designer Cc: Theodore Y. Ts'o, Kees Cook, Kernel Hardening, linux-hardening 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?) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux-specific kernel hardening 2020-10-05 22:26 ` Jann Horn (?) @ 2020-10-05 22:39 ` Kees Cook 2020-10-06 14:21 ` Solar Designer -1 siblings, 1 reply; 14+ messages in thread From: Kees Cook @ 2020-10-05 22:39 UTC (permalink / raw) To: Jann Horn Cc: Solar Designer, Theodore Y. Ts'o, Kernel Hardening, linux-hardening 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux-specific kernel hardening 2020-10-05 22:39 ` Kees Cook @ 2020-10-06 14:21 ` Solar Designer 2020-10-07 7:05 ` Kees Cook 0 siblings, 1 reply; 14+ messages in thread From: Solar Designer @ 2020-10-06 14:21 UTC (permalink / raw) To: Kees Cook Cc: Jann Horn, Theodore Y. Ts'o, Kernel Hardening, linux-hardening 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux-specific kernel hardening 2020-10-06 14:21 ` Solar Designer @ 2020-10-07 7:05 ` Kees Cook 0 siblings, 0 replies; 14+ messages in thread From: Kees Cook @ 2020-10-07 7:05 UTC (permalink / raw) To: Solar Designer Cc: Jann Horn, Theodore Y. Ts'o, Kernel Hardening, linux-hardening 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux-specific kernel hardening 2020-10-05 14:14 ` Solar Designer 2020-10-05 16:02 ` Theodore Y. Ts'o @ 2020-10-05 22:23 ` Kees Cook 1 sibling, 0 replies; 14+ messages in thread From: Kees Cook @ 2020-10-05 22:23 UTC (permalink / raw) To: Solar Designer; +Cc: kernel-hardening, linux-hardening 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux-specific kernel hardening 2020-09-29 17:14 Linux-specific kernel hardening Kees Cook 2020-09-29 19:25 ` Solar Designer @ 2020-10-07 15:16 ` Romain Perier 1 sibling, 0 replies; 14+ messages in thread From: Romain Perier @ 2020-10-07 15:16 UTC (permalink / raw) To: Kees Cook; +Cc: Kernel Hardening, linux-hardening [-- Attachment #1: Type: text/plain, Size: 1762 bytes --] Hi, Great! Don't send anything else, we have the perfect amount of archived discussions already! ( that is currently* 42*) :P Regards, Romain Le mar. 29 sept. 2020 à 20:19, Kees Cook <keescook@chromium.org> a écrit : > 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 > [-- Attachment #2: Type: text/html, Size: 2962 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-10-07 15:16 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-09-29 17:14 Linux-specific kernel hardening Kees Cook 2020-09-29 19:25 ` Solar Designer 2020-09-29 23:41 ` Kees Cook 2020-09-30 9:02 ` Solar Designer 2020-10-05 14:14 ` Solar Designer 2020-10-05 16:02 ` Theodore Y. Ts'o 2020-10-05 16:48 ` Solar Designer 2020-10-05 22:26 ` Jann Horn 2020-10-05 22:26 ` Jann Horn 2020-10-05 22:39 ` Kees Cook 2020-10-06 14:21 ` Solar Designer 2020-10-07 7:05 ` Kees Cook 2020-10-05 22:23 ` Kees Cook 2020-10-07 15:16 ` Romain Perier
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.