From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C2A19C433DB for ; Thu, 18 Feb 2021 13:29:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 76FE864E28 for ; Thu, 18 Feb 2021 13:29:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233570AbhBRN3a (ORCPT ); Thu, 18 Feb 2021 08:29:30 -0500 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:49851 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230218AbhBRLq0 (ORCPT ); Thu, 18 Feb 2021 06:46:26 -0500 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 11IBV7Lt013142; Thu, 18 Feb 2021 12:31:07 +0100 Date: Thu, 18 Feb 2021 12:31:07 +0100 From: Willy Tarreau To: Greg Kroah-Hartman , Scott Branden Cc: Linux ARM , LKML , BCM Kernel Feedback Subject: Re: 5.10 LTS Kernel: 2 or 6 years? Message-ID: <20210218113107.GA12547@1wt.eu> References: <8cf503db-ac4c-a546-13c0-aac6da5c073b@broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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! 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. 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! Willy From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 07F97C433DB for ; Thu, 18 Feb 2021 11:33:00 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 904EA60C41 for ; Thu, 18 Feb 2021 11:32:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 904EA60C41 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=1wt.eu Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=LB7WJAldVc5w0z3dYiaxL4lRjdSZ0HUDbJoK+v+IIpU=; b=3kAdyJIqOLkMXKRNnq7fsSzPP hQaAvrX9GSCgT65JM8Pv3EL/wwLAWjI09XiYJV9V66+gZnlixKQOkg8yGxXPZMWTzjQOIVO7k959j gRve2BjBCpAmILgVyy+Ev5A8KNcx6JyRU5bM7HogrfJImdmFiike7/otNfA0tOE9f9cixqlioK5Bt rDk5YMGGRn4n/HN7X4yeLJv7ABYBlrlhWfH48LzhfBB2pYltICNguWWCX3vbNwbz+jPbBYhA0oFXr /wHoNopzqbUQSdT1Q7OURpv7O8vdToCvftAk4WtcRy5m6CK1Rv/9KGVTmUJgtfW4B9ANds/9QF6Iz oD1nQ8r+Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lChWy-0000v6-5x; Thu, 18 Feb 2021 11:31:36 +0000 Received: from wtarreau.pck.nerim.net ([62.212.114.60] helo=1wt.eu) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lChWw-0000tt-7B for linux-arm-kernel@lists.infradead.org; Thu, 18 Feb 2021 11:31:35 +0000 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 11IBV7Lt013142; Thu, 18 Feb 2021 12:31:07 +0100 Date: Thu, 18 Feb 2021 12:31:07 +0100 From: Willy Tarreau To: Greg Kroah-Hartman , Scott Branden Subject: Re: 5.10 LTS Kernel: 2 or 6 years? Message-ID: <20210218113107.GA12547@1wt.eu> References: <8cf503db-ac4c-a546-13c0-aac6da5c073b@broadcom.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210218_063134_544359_BD0AA7B4 X-CRM114-Status: GOOD ( 13.56 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: BCM Kernel Feedback , LKML , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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! 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. 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! Willy _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel