From: Florian Fainelli <f.fainelli@gmail.com> To: Willy Tarreau <w@1wt.eu>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Scott Branden <scott.branden@broadcom.com> Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>, LKML <linux-kernel@vger.kernel.org>, BCM Kernel Feedback <bcm-kernel-feedback-list@broadcom.com> Subject: Re: 5.10 LTS Kernel: 2 or 6 years? Date: Thu, 18 Feb 2021 09:16:34 -0800 [thread overview] Message-ID: <311de080-d9b7-4907-8d5b-3edc3c471932@gmail.com> (raw) In-Reply-To: <20210218113107.GA12547@1wt.eu> On 2/18/2021 3:31 AM, Willy Tarreau wrote: > On Thu, Feb 18, 2021 at 08:43:48AM +0100, Greg Kroah-Hartman wrote: >> On Wed, Feb 17, 2021 at 11:48:21AM -0800, Scott Branden wrote: >>> Other difficulty with the LTS version is the frequency it is updated. > > What a stange statement! So basically if fixes come in quickly so that > customers are not exposed too long to well-known issues, it's a difficulty ? > I guess by now every serious OS vendor provides at least weekly fixes, and > at an era where devices are all interconnected, it's really necessary > (unless of course you don't care about your customer's security). > >>> We would not >>> pickup the changes that frequently to test. A quarterly, bi-annually, or when a critical fix >>> is identified would be when we update and perform any meaningful testing when in maintainence. >> >> How are you "identifying" these "critical fixes"? We fix at least one >> known security issue a week, and probably multitudes of >> unknown-at-this-moment ones. How are you determining when you need to >> send a new base kernel update off to your customers? At such long >> intervals it feels like anyone using your kernel releases is woefully >> insecure. > > +1! It seems like this dangerous practice will never end :-( > > Let me explain a personal experience. When I took over 2.6.32 many years > ago, Greg asked me to adapt to the new maintenance process involving the > patch reviews. At first I feared that it would increase my amount of work. > And it did. But I also discovered how important these reviews were, because > I started to get lots of "don't take this one in this version" and more > importantly "if you merge this you'll need these ones as well". And very > quickly I discovered how bogus the branches I used to maintain before > had been, given the high feedback ratio! > > So based on this experience, I can assure anyone doing cherry-picks in > their garage from LTS kernels that they're doing crap and that they must > not distribute these kernels to anyone because THESE KERNELS ARE DANGEROUS. > It's even very easy to introduce vulnerabilities by doing this! Yes absolutely. > > The only set of fixes that can be trusted are the "official" stable > kernels, because they are the only ones that are approved by the patches > authors themselves. Well, let us say that the authors had a chance to review the backports being applied but given the volume maybe they did and silence means agreement, or maybe they did not get a chance to review those changes. Let us say that the trust level of the offical stable kernels is just the highest of all kernels that are out there? > Adding more stuff on top of stable kernels is fine > (and done at your own risk), but randomly dropping stuff from stable > kernels just because you don't think you need that is totally non-sense > and must not be done anymore! Yes, definitively not setting up for success. -- Florian
WARNING: multiple messages have this Message-ID (diff)
From: Florian Fainelli <f.fainelli@gmail.com> To: Willy Tarreau <w@1wt.eu>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Scott Branden <scott.branden@broadcom.com> Cc: BCM Kernel Feedback <bcm-kernel-feedback-list@broadcom.com>, LKML <linux-kernel@vger.kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org> Subject: Re: 5.10 LTS Kernel: 2 or 6 years? Date: Thu, 18 Feb 2021 09:16:34 -0800 [thread overview] Message-ID: <311de080-d9b7-4907-8d5b-3edc3c471932@gmail.com> (raw) In-Reply-To: <20210218113107.GA12547@1wt.eu> On 2/18/2021 3:31 AM, Willy Tarreau wrote: > On Thu, Feb 18, 2021 at 08:43:48AM +0100, Greg Kroah-Hartman wrote: >> On Wed, Feb 17, 2021 at 11:48:21AM -0800, Scott Branden wrote: >>> Other difficulty with the LTS version is the frequency it is updated. > > What a stange statement! So basically if fixes come in quickly so that > customers are not exposed too long to well-known issues, it's a difficulty ? > I guess by now every serious OS vendor provides at least weekly fixes, and > at an era where devices are all interconnected, it's really necessary > (unless of course you don't care about your customer's security). > >>> We would not >>> pickup the changes that frequently to test. A quarterly, bi-annually, or when a critical fix >>> is identified would be when we update and perform any meaningful testing when in maintainence. >> >> How are you "identifying" these "critical fixes"? We fix at least one >> known security issue a week, and probably multitudes of >> unknown-at-this-moment ones. How are you determining when you need to >> send a new base kernel update off to your customers? At such long >> intervals it feels like anyone using your kernel releases is woefully >> insecure. > > +1! It seems like this dangerous practice will never end :-( > > Let me explain a personal experience. When I took over 2.6.32 many years > ago, Greg asked me to adapt to the new maintenance process involving the > patch reviews. At first I feared that it would increase my amount of work. > And it did. But I also discovered how important these reviews were, because > I started to get lots of "don't take this one in this version" and more > importantly "if you merge this you'll need these ones as well". And very > quickly I discovered how bogus the branches I used to maintain before > had been, given the high feedback ratio! > > So based on this experience, I can assure anyone doing cherry-picks in > their garage from LTS kernels that they're doing crap and that they must > not distribute these kernels to anyone because THESE KERNELS ARE DANGEROUS. > It's even very easy to introduce vulnerabilities by doing this! Yes absolutely. > > The only set of fixes that can be trusted are the "official" stable > kernels, because they are the only ones that are approved by the patches > authors themselves. Well, let us say that the authors had a chance to review the backports being applied but given the volume maybe they did and silence means agreement, or maybe they did not get a chance to review those changes. Let us say that the trust level of the offical stable kernels is just the highest of all kernels that are out there? > Adding more stuff on top of stable kernels is fine > (and done at your own risk), but randomly dropping stuff from stable > kernels just because you don't think you need that is totally non-sense > and must not be done anymore! Yes, definitively not setting up for success. -- Florian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-02-18 18:58 UTC|newest] Thread overview: 133+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-25 19:55 5.10 LTS Kernel: 2 or 6 years? Scott Branden 2021-01-25 19:55 ` Scott Branden 2021-01-26 2:50 ` Adam Borowski 2021-01-26 2:50 ` Adam Borowski 2021-01-26 7:29 ` Greg Kroah-Hartman 2021-01-26 7:29 ` Greg Kroah-Hartman 2021-01-26 17:35 ` Florian Fainelli 2021-01-26 17:35 ` Florian Fainelli 2021-01-26 18:30 ` Scott Branden 2021-01-26 18:30 ` Scott Branden 2021-01-26 18:51 ` Greg Kroah-Hartman 2021-01-26 18:51 ` Greg Kroah-Hartman 2021-01-26 20:15 ` Willy Tarreau 2021-01-26 20:15 ` Willy Tarreau 2021-01-29 10:00 ` 10 years -- was " Pavel Machek 2021-02-17 9:40 ` Greg Kroah-Hartman 2021-02-17 9:40 ` Greg Kroah-Hartman 2021-02-17 19:48 ` Scott Branden 2021-02-17 19:48 ` Scott Branden 2021-02-18 7:43 ` Greg Kroah-Hartman 2021-02-18 7:43 ` Greg Kroah-Hartman 2021-02-18 11:31 ` Willy Tarreau 2021-02-18 11:31 ` Willy Tarreau 2021-02-18 14:15 ` Jari Ruusu 2021-02-18 14:15 ` Jari Ruusu 2021-02-18 14:29 ` Greg Kroah-Hartman 2021-02-18 14:29 ` Greg Kroah-Hartman 2021-02-18 20:55 ` Pavel Machek 2021-02-18 20:55 ` Pavel Machek 2021-02-18 22:43 ` Ondrej Zary 2021-02-18 22:43 ` Ondrej Zary 2021-02-19 8:00 ` Pavel Machek 2021-02-19 8:00 ` Pavel Machek 2021-02-19 8:30 ` Greg Kroah-Hartman 2021-02-19 8:30 ` Greg Kroah-Hartman 2021-02-18 14:33 ` Willy Tarreau 2021-02-18 14:33 ` Willy Tarreau 2021-02-18 17:19 ` Jari Ruusu 2021-02-18 17:19 ` Jari Ruusu 2021-02-18 17:22 ` Russell King - ARM Linux admin 2021-02-18 17:22 ` Russell King - ARM Linux admin 2021-02-18 17:44 ` Greg Kroah-Hartman 2021-02-18 17:44 ` Greg Kroah-Hartman 2021-02-19 7:10 ` Jari Ruusu 2021-02-19 7:10 ` Jari Ruusu 2021-02-19 8:22 ` Greg Kroah-Hartman 2021-02-19 8:22 ` Greg Kroah-Hartman 2021-02-19 10:31 ` Jari Ruusu 2021-02-19 10:31 ` Jari Ruusu 2021-02-19 10:37 ` Greg Kroah-Hartman 2021-02-19 10:37 ` Greg Kroah-Hartman 2021-02-19 10:57 ` Jari Ruusu 2021-02-19 10:57 ` Jari Ruusu 2021-02-19 11:16 ` Greg Kroah-Hartman 2021-02-19 11:16 ` Greg Kroah-Hartman 2021-02-19 15:23 ` Jari Ruusu 2021-02-19 15:23 ` Jari Ruusu 2021-02-20 13:29 ` Jari Ruusu 2021-02-20 13:29 ` Jari Ruusu 2021-02-20 16:05 ` Greg Kroah-Hartman 2021-02-20 16:05 ` Greg Kroah-Hartman 2021-02-20 17:06 ` Willy Tarreau 2021-02-20 17:06 ` Willy Tarreau 2021-02-21 11:38 ` Jari Ruusu 2021-02-21 11:38 ` Jari Ruusu 2021-02-19 16:50 ` Theodore Ts'o 2021-02-19 16:50 ` Theodore Ts'o 2021-02-18 17:16 ` Florian Fainelli [this message] 2021-02-18 17:16 ` Florian Fainelli 2021-02-18 12:51 ` Pavel Machek 2021-02-18 12:51 ` Pavel Machek 2021-02-18 16:51 ` Sasha Levin 2021-02-18 16:51 ` Sasha Levin 2021-02-18 17:21 ` Florian Fainelli 2021-02-18 17:21 ` Florian Fainelli 2021-02-18 17:53 ` Greg Kroah-Hartman 2021-02-18 17:53 ` Greg Kroah-Hartman 2021-02-18 17:57 ` Florian Fainelli 2021-02-18 17:57 ` Florian Fainelli 2021-02-18 18:20 ` Willy Tarreau 2021-02-18 18:20 ` Willy Tarreau 2021-02-18 18:36 ` Greg Kroah-Hartman 2021-02-18 18:36 ` Greg Kroah-Hartman 2021-02-18 20:16 ` Scott Branden 2021-02-18 20:16 ` Scott Branden 2021-02-18 21:00 ` Willy Tarreau 2021-02-18 21:00 ` Willy Tarreau 2021-02-18 22:38 ` Scott Branden 2021-02-18 22:38 ` Scott Branden 2021-02-18 21:39 ` Sasha Levin 2021-02-18 21:39 ` Sasha Levin 2021-02-18 22:00 ` Florian Fainelli 2021-02-18 22:00 ` Florian Fainelli 2021-02-18 22:26 ` Scott Branden 2021-02-18 22:26 ` Scott Branden 2021-02-19 8:25 ` Greg Kroah-Hartman 2021-02-19 8:25 ` Greg Kroah-Hartman 2021-02-19 15:05 ` Florian Fainelli 2021-02-19 15:05 ` Florian Fainelli 2021-02-19 15:53 ` Greg Kroah-Hartman 2021-02-19 15:53 ` Greg Kroah-Hartman 2021-02-19 17:44 ` Florian Fainelli 2021-02-19 17:44 ` Florian Fainelli 2021-02-22 14:17 ` Greg Kroah-Hartman 2021-02-22 14:17 ` Greg Kroah-Hartman 2021-02-18 17:42 ` Florian Fainelli 2021-02-18 17:42 ` Florian Fainelli 2021-02-18 18:13 ` Willy Tarreau 2021-02-18 18:13 ` Willy Tarreau 2021-02-18 10:04 ` Pavel Machek 2021-02-18 10:04 ` Pavel Machek 2021-01-29 9:49 ` Pavel Machek 2021-02-19 8:54 ` Hanjun Guo 2021-02-19 8:54 ` Hanjun Guo 2021-02-19 9:08 ` Greg Kroah-Hartman 2021-02-19 9:08 ` Greg Kroah-Hartman 2021-02-20 7:02 ` Hanjun Guo 2021-02-20 7:02 ` Hanjun Guo 2021-02-20 9:53 ` Greg Kroah-Hartman 2021-02-20 9:53 ` Greg Kroah-Hartman 2021-02-23 2:14 ` Hanjun Guo 2021-02-23 2:14 ` Hanjun Guo 2021-02-19 14:45 ` Nikolai Kondrashov 2021-02-19 14:45 ` Nikolai Kondrashov 2021-02-26 8:03 ` Hanjun Guo 2021-02-26 8:03 ` Hanjun Guo 2021-02-26 8:03 ` Hanjun Guo 2021-02-26 11:21 ` Nikolai Kondrashov 2021-02-26 11:21 ` Nikolai Kondrashov 2021-02-22 14:00 ` Nishanth Aravamudan 2021-02-22 14:00 ` Nishanth Aravamudan 2021-02-22 14:24 ` Greg Kroah-Hartman 2021-02-22 14:24 ` Greg Kroah-Hartman
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=311de080-d9b7-4907-8d5b-3edc3c471932@gmail.com \ --to=f.fainelli@gmail.com \ --cc=bcm-kernel-feedback-list@broadcom.com \ --cc=gregkh@linuxfoundation.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=scott.branden@broadcom.com \ --cc=w@1wt.eu \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.