From: Greg KH <gregkh@linuxfoundation.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Vegard Nossum <vegard.nossum@oracle.com>,
Jiri Kosina <jkosina@suse.cz>,
ksummit@lists.linux.dev
Subject: Re: [MAINTAINERS SUMMIT] Handling of embargoed security issues -- security@korg vs. linux-distros@
Date: Tue, 15 Aug 2023 17:51:24 +0200 [thread overview]
Message-ID: <2023081545-freezable-whiff-0cf3@gregkh> (raw)
In-Reply-To: <20230815110422.2366cc0b@gandalf.local.home>
On Tue, Aug 15, 2023 at 11:04:22AM -0400, Steven Rostedt wrote:
> On Tue, 15 Aug 2023 16:41:37 +0200
> Greg KH <gregkh@linuxfoundation.org> wrote:
>
> > Loads of companies/governments have been pestering us for access to
> > security@k.o for decades now, this isn't going to change for the obvious
> > reason that having such groups on the list is not going to help us fix
> > any problem, but instead, just give everyone early access to known
> > security problems.
> >
> > Same thing would happen for any potential distro@k.o list, remember who
> > some of the largest users of Linux is (i.e. governments) and many of
> > them have their own custom "distros" for their systems for valid
> > reasons.
> >
> > So no, we can't do that if you care about security overall, this would
> > make things insecure.
>
> Even if the only thing that is shown is a commit sha that should be taken?
I provide a list of all of those commit sha in every release today.
You sound like someone in a meeting I had many years ago at a "big chip
company", the conversation went something like:
Security Manager - "Just tell us which releases in every stable
release you make that fix a security bug."
Me - "I can't do that as that would imply we have audited every commit
to determine if they are, or are not, a security fix, and so you would
have a false sense of security if you don't take all of them."
SM - "But I don't care about any unknown security fixes, I only want
to know the known security fixes!"
Me - "You will then have insecure systems when it is determined later
that those other fixes were security fixes."
SM - "I don't care about future security issues, I only want to know
about known ones now!"
Me - "..."
Luckily a VP stepped in then and said, "The community is giving you a
set of known bugfixes for all issues that they know of at the moment,
for free, why are you refusing to take all of them and insisting that
they do more work for you for free so that you can have a more insecure
system?"
And yes, this company is not using a distro at all, they have their own
"releases" based on the kernel.org tree. And they are HUGE, one might
argue much bigger users of Linux than many of the "enterprise" distros
are on quantity of Linux systems in use.
So again, what's preventing you from just taking all published fixes?
Android does this, are your systems somehow more special than Android,
the largest user of Linux by far in the world? :)
Also, to further drive home this issue, a "big car manufacturer" a few
years ago told me, "we now have a team of developers that are going to
audit every stable kernel commit to determine if it is, or is not, a
security fix for our systems before we will take it." They did this for
about a year and came back saying "we could not keep up with the flow at
all, and everytime we guessed wrong, we put the security of our systems
at risk. It ended up being cheaper, and safer, to just take all of the
fixes." Which they now do.
So, why are you refusing to do the cheaper (from a business point of
view), and safer (from a security point of view) and not just take all
of the fixes we provide?
Again, the Google security team proved that taking the stable kernel
releases fixes 90%+ of all known security problems in their systems
BEFORE they are known! They analyzed all of the data on this for 2
years straight and published their results before they just gave in and
said "just take them all, to not do so is crazy".
(the 10% not fixed were attributed to out-of-tree code that was not
upstream yet, nothing we can do about that...)
And yes, I'm arguing strongly that the old model of the "enterprise
kernel releases" is wrong. So much so that I fail to understand that if
Android can provide a secure, up-to-date, internal ABI STABLE, kernel
based on the LTS releases, why can't these enterprise distros do the
same for their customers?
And I think Oracle does do this for their enterprise kernel releases,
which is nice to see. Yes, I'm saying more people need to be like
Oracle and Android, what is the world coming to... :)
thanks,
greg k-h
next prev parent reply other threads:[~2023-08-15 15:51 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-15 9:28 [MAINTAINERS SUMMIT] Handling of embargoed security issues -- security@korg vs. linux-distros@ Jiri Kosina
2023-08-15 10:17 ` Vegard Nossum
2023-08-15 10:34 ` Jiri Kosina
2023-08-15 11:23 ` Greg KH
2023-08-15 12:42 ` Steven Rostedt
2023-08-15 13:17 ` Daniel Borkmann
2023-08-15 14:19 ` Laurent Pinchart
2023-08-15 22:04 ` Jiri Kosina
2023-08-15 14:20 ` Catalin Marinas
2023-08-15 14:41 ` Greg KH
2023-08-15 15:04 ` Steven Rostedt
2023-08-15 15:51 ` Greg KH [this message]
2023-08-15 15:08 ` Greg KH
2023-08-15 18:46 ` Konrad Rzeszutek Wilk
2023-08-15 19:41 ` Greg KH
2023-08-15 22:13 ` Jiri Kosina
2023-08-15 22:31 ` Steven Rostedt
2023-08-16 14:55 ` Greg KH
2024-02-16 17:14 ` Michal Suchánek
2024-02-16 17:34 ` Greg KH
2024-02-16 18:13 ` Michal Suchánek
2024-02-16 18:16 ` Jiri Kosina
2023-08-15 22:17 ` Jiri Kosina
2023-08-16 14:57 ` Greg KH
2023-08-16 17:22 ` Jiri Kosina
2023-08-16 18:38 ` Vegard Nossum
2023-08-16 15:26 ` Solar Designer
2023-08-25 11:17 ` Donald Buczek
2023-08-29 8:46 ` Miroslav Benes
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=2023081545-freezable-whiff-0cf3@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=catalin.marinas@arm.com \
--cc=jkosina@suse.cz \
--cc=ksummit@lists.linux.dev \
--cc=rostedt@goodmis.org \
--cc=vegard.nossum@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).