ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@amacapital.net>
To: Jiri Kosina <jikos@kernel.org>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Handling of embargoed security issues
Date: Fri, 7 Sep 2018 21:21:27 -0700	[thread overview]
Message-ID: <CALCETrWsWGbo0B7=_AAOinJVCLrZbhJ75W2eUPxLCyo2BspBxA@mail.gmail.com> (raw)
In-Reply-To: <nycvar.YFH.7.76.1809062054450.15880@cbobk.fhfr.pm>

On Thu, Sep 6, 2018 at 12:18 PM, Jiri Kosina <jikos@kernel.org> wrote:
> I believe we have reasonably well-established process for handling
> security issues that are a matter of a single, reasonably self-contained
> fixup.
>
> Past experiences with Meltdown, Spectre and L1TF have shown that we're not
> really ready to handle that in a reasonably sane way yet.
>

To a large extend, I think that the problems we had with Meltdown and
Spectre weren't the fault of our processes so much as the fact that we
weren't allowed to have a sane process.  As far as I know, the number
of upstream-focused non-Intel-employed Linux developers who were told
about Meltdown and Spectre in a timely manner can be counted on a very
small number of fingers on one hand.  Those people had no channel to
communicate with any of the distro people involved in a timely manner.
This situation was not good.

Perhaps the Linux community could have a small team that handles
coordination of severe incidents along with a documented process for
what happens when the process is invoked.  It would need to be
designed in such a way that vendors would be willing to use it when
needed and that it gave the Linux world enough flexibility to actually
handle the issue.  At the very least, the relevant maintainers and
perhaps some relevant upstream reviewers would get notified, and the
people working on the issue for distros could actually communicate
with the upstream folks.  The total set of people involved would be
small.  It could be useful to try to get the process to work similarly
to whatever Microsoft and Apple do.

(There was another CVE that got much less press that I was involved,
and it didn't get much attention in Linux land because Linux was only
minimally affected.  Despite being an Intel/AMD issue, all of the
coordination was done by Microsoft, and it was done remarkably well
once the process actually got started.)

  parent reply	other threads:[~2018-09-08  4:21 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-06 19:18 Jiri Kosina
2018-09-06 20:56 ` Linus Torvalds
2018-09-06 21:14   ` Jiri Kosina
2018-09-06 22:51     ` Eduardo Valentin
2018-09-07  9:17   ` Jani Nikula
2018-09-07 14:43   ` David Woodhouse
2018-09-06 22:55 ` Eduardo Valentin
2018-09-07  8:21   ` Geert Uytterhoeven
2018-09-10 23:26     ` Eduardo Valentin
2018-09-11  8:45       ` Greg KH
2018-09-11 17:10         ` Dave Hansen
2018-09-11 18:28           ` Greg KH
2018-09-11 18:44           ` Thomas Gleixner
2018-09-07 13:30   ` Jiri Kosina
2018-09-09 12:55     ` Greg KH
2018-09-09 19:48       ` Jiri Kosina
2018-09-10  4:04         ` Eduardo Valentin
2018-09-12  7:03           ` Greg KH
2018-09-10  4:12       ` Eduardo Valentin
2018-09-10 11:10       ` Mark Brown
2018-09-12  4:22   ` Balbir Singh
2018-09-08  4:21 ` Andy Lutomirski [this message]
2018-09-08  8:56   ` Thomas Gleixner
2018-09-08 11:21     ` Mauro Carvalho Chehab
2018-09-08 11:34       ` Greg KH
2018-09-08 14:20         ` Andy Lutomirski
2018-09-08 15:29           ` Greg KH
2018-09-08 15:00         ` James Bottomley
2018-09-08 15:32           ` Greg KH
2018-09-08 15:54             ` James Bottomley
2018-09-08 19:49               ` Linus Torvalds
2018-09-08 21:24                 ` James Bottomley
2018-09-08 22:33                   ` Andy Lutomirski
2018-09-09 12:18                     ` Mauro Carvalho Chehab
2018-09-10 22:59                 ` Dave Hansen
2018-09-11  8:48                   ` Greg KH
2018-09-09 12:51               ` Greg KH
2018-09-09 14:20                 ` Linus Torvalds
2018-09-09 14:38                   ` James Bottomley
2018-09-09 14:51                     ` Andy Lutomirski
2018-09-09 17:20                       ` Theodore Y. Ts'o
2018-09-09 17:48                         ` David Woodhouse
2018-09-09 18:17                         ` Andy Lutomirski
2018-09-09 18:56                           ` Theodore Y. Ts'o
2018-09-09 19:19                             ` Andy Lutomirski
2018-09-09 20:20                             ` Jiri Kosina
2018-09-09 21:36                               ` James Bottomley
2018-09-10  9:25                             ` Thomas Gleixner
2018-09-10 14:40                               ` James Bottomley
2018-09-11  8:20                               ` Jiri Kosina
2018-09-11  9:03                                 ` Thomas Gleixner
2018-09-09 19:41                   ` Jiri Kosina
2018-09-08 19:26           ` Jiri Kosina
2018-09-08 19:47             ` James Bottomley

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to='CALCETrWsWGbo0B7=_AAOinJVCLrZbhJ75W2eUPxLCyo2BspBxA@mail.gmail.com' \
    --to=luto@amacapital.net \
    --cc=jikos@kernel.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

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

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