Reaching out to Greg KH for 6 year LTS kernel versions

Philip Prindeville philipp_subx at redfish-solutions.com
Fri Aug 12 13:36:37 PDT 2022



> On Aug 12, 2022, at 2:28 PM, Robert Marko <robimarko at gmail.com> wrote:
> 
> On Fri, 12 Aug 2022 at 21:45, Florian Fainelli <f.fainelli at gmail.com> wrote:
>> 
>> On 8/12/22 11:09, Robert Marko wrote:
>>> On Fri, 12 Aug 2022 at 19:54, Florian Fainelli <f.fainelli at gmail.com> wrote:
>>>> 
>>>> On 8/10/22 13:32, Robert Marko wrote:
>>>>> On Wed, 10 Aug 2022 at 22:30, Philip Prindeville
>>>>> <philipp at redfish-solutions.com> wrote:
>>>>>> 
>>>>>> Not to play the devil's advocate but... do we want old kernels hanging out that long?
>>>>>> 
>>>>>> Besides not encouraging people to update to new releases that mitigate discovered CVE's, we'd also not pick up David Taht's excellent improvements in Buffer Bloat.
>>>>> 
>>>>> I have to agree with this.
>>>>> What would be the benefit for OpenWrt with having LTS kernels
>>>>> supported for 6 years?
>>>> 
>>>> One aspect I could see is take for instance a device that is widely
>>>> popular amongst our user base as was TI's ar7 for instance a while back,
>>>> and for which we might have done a Linux 5.4, or 5.10 version at the
>>>> time but we do not wish to continue to maintain.
>>> 
>>> I dont see how this is related to LTS kernel support.
>> 
>> OK maybe I need to spell out my example more clearly. Let us say that we
>> have a release in 2019 of OpenWrt that supported TI AR7 based upon the
>> Linux 5.4 kernel.
>> 
>> Fast forward to 2022, we decide to abandon TI AR7 in master and we stop
>> supporting it entirely for future releases. A very bad Linux security
>> problem show up, and because we care about our users, we keep updating
>> the LTS kernel that was used in the 2019.x release up until, say the
>> said kernel stops being supported. If that support time frame was 6
>> years, then we would really be helping our users.
>> 
>> Maybe the wider discussion to be had, is:
>> 
>> - when and how do we decide to deprecate a given Linux port, I assume it
>> is when no more users show up or maybe more realistically when OpenWrt
>> developers just cannot keep up with updating those devices because they
>> no longer use those themselves
>> 
>> - how long do we want to keep supporting past OpenWrt releases with
>> kernel updates, 2 years, 3/4 years, 6 years to match the kernel
>> lifecycle they are based upon?
> 
> As an idea, I understand this, it would basically be an "LTS" OpenWrt
> release that
> would receive security-only updates.
> 
> However, we had a long discussion on the IRC today and the resources are spread
> rather thin even currently with 2 or 3 releases being supported.
> 
> If its gonna be a volunteer kind of no guarantees release, then maybe
> but I dont see
> how we can manage that as well.


Chiming in as a software security developer...  I think we're approaching this problem wrong.

We need to make regular software updates easier, which we've not focused on in the past.  Periodically "sysupgrade" gets damaged, and manages to brick devices.  This should never happen.  Ideally we should be moving towards unattended updates.

Would this [kernel support] be as much of a burden if we worked harder at getting our patches upstreamed?

And a 800lb gorilla is that companies like Netgear and D-Link don't arm-twist Mediatek to keep their SoC-specific patches upstreamed and their SoC's running more recent kernels.  How much of this problem would go away if MediaTek supported 5.10 or 5.15 on all of their current SoC's and SoC's released in the last 5-7 years?



>>>> 
>>>> Being able to continue to deliver stable kernel updates in a stable
>>>> OpenWrt branch could be a good way for users to pick up their next xDSL
>>>> router since there are not so many out there that can actually run
>>>> OpenWrt compared to pure Wired/Wi-Fi for instance.
>>> 
>>> I can agree with this.
>>> 
>>>> 
>>>>> Backporting stuff is already hard with only 2 LTS versions supported in OpenWrt.
>>>> 
>>>> That argument I am sympathetic with, and the sheer amount of out of tree
>>>> patches we have in OpenWrt is not helping, in fact it definitively makes
>>>> it harder to regularly test, but still somehow we managed to do it.
>>>> 
>>>> Since we will merge stable updates eventually, the point would be that
>>>> instead of testing those that are already released, we could try to test
>>>> the release candidates and report back anything we find?
>>> 
>>> This is a good idea, not sure how we can do it within OpenWrt though with
>>> the amount of patches we have that make it a pain to bump kernels.
>> 
>> Maybe we should give it a spin and see how painful that actually is and
>> then if we can sustain doing that over time it just becomes a thing a
>> group of volunteers can do?
>> 
>> After all, we do go through that exercise fairly frequently.
> 
> This looks similar to what we discussed to today on IRC, maybe having a more
> up-to-date development OpenWrt along longer lasting stable releases.


I've not had time to keep up with IRC (I'm getting ready to move homes), so apologies if I'm rehashing some of this...


> 
> As currently, OpenWrt is way out of date for kernel development but is moving
> too quickly for keeping the stable releases from regressing.


That would seem to be paradoxical...

-Philip


> 
> Regards,
> Robert
>> --
>> Florian




More information about the openwrt-devel mailing list