openSUSE 16.1: Warum kein neuer Kernel?

[Der Nippeser]

Ich traue mich einmal das zu fragen: Warum ist der Kernel in der openSUSE 16.1 immer noch auf Basis der Version 6.12?
Hintergrund der Frage ist ein Artikel, den Thorsten Leemhuis schon 2021 in der c't veröffentlicht hat. Hier weist er darauf hin, dass nicht immer alle Sicherheitspatches in älteren Kernelversionen landen, die in neueren Versionen vorhanden sind, einfach weil die Entwickler mitunter nicht alle Änderungen dokumentieren.
Daher wäre es doch durchaus sinnvoll, eine neuere Version die in Tumbleweed schon erprobt ist in die neue Version zu übernehmen, damit sie vielleicht auch später den Weg in SUSE Enterprise Linux findet.
Oder bin ich da zu blauäugig?

Viele Grüße aus Köln
Harald

 

[susejunky]

Warum ist der Kernel in der openSUSE 16.1 immer noch auf Basis der Version 6.12?

Im kommerziellen Bereich (z.B. Rechenzentrumsbetreiber) liegt der Hauptaugenmerk auf stabilen, möglichst über einen langen Zeitraum unveränderten Kerneln (Fehler- und CVE-Behebungen ausgenommen), da die Installation neuer Kernel immer mit einem Ausfallrisiko verbunden ist. Oft müssen Kernel in kommerziell eingesetzten Betriebssystemen sogar einen aufwändigen Zertifizierungsprozess durchlaufen, damit sie für bestimmte Anwendungen (z.B. SAP Hana) eingesetzt werden dürfen. Daher ist man bestrebt, an diesen Kerneln nur die notwendigsten Änderungen (z.B. Fehler- und CVE-Behebungen) vorzunehmen.

Und da openSUSE Leap den SUSE Linux Enterprise Kernel nutzt ...

Hintergrund der Frage ist ein Artikel, den Thorsten Leemhuis schon 2021 in der c't veröffentlicht hat. Hier weist er darauf hin, dass nicht immer alle Sicherheitspatches in älteren Kernelversionen landen, die in neueren Versionen vorhanden sind, einfach weil die Entwickler mitunter nicht alle Änderungen dokumentieren.

Bezieht sich die Aussage des Herrn Leemhuis auf kommerziell eingesetzte Kernel-Versionen?

Meines Wissens erhalten die (open)SUSE-Kernel, die sich noch im Wartungsfenster befinden, alle erforderlichen Fehler- und CVE-Behebungen. Allerdings keine funktionalen Erweiterungen, wobei diese für den openSUSE Leap Kernel doch manchmal zurückportiert werden.

 

[Sauerland]

Meines Wissens erhalten die (open)SUSE-Kernel, die sich noch im Wartungsfenster befinden, alle erforderlichen Fehler- und CVE-Behebungen. Allerdings keine funktionalen Erweiterungen, wobei diese für den openSUSE Leap Kernel doch manchmal zurückportiert werden.

Der Kernel 6.12 aus Leap 16.0 hat Funktionen eines Kernel 6.15 und kleiner mit eingebaut.
Der Kernel 6.12 aus Leap 16.1 hat Funktionen eines Kernel 6.17 und kleiner mit eingebaut.

Ich muß daher oftmals Treiber, die ich baue, patchen.....

 

[susejunky]

Der Kernel 6.12 aus Leap 16.0 hat Funktionen eines Kernel 6.15 und kleiner mit eingebaut.
Der Kernel 6.12 aus Leap 16.1 hat Funktionen eines Kernel 6.17 und kleiner mit eingebaut.

Werden die SUSE Linux Enterprise Kernel auch funktional "aufgepäppelt" oder sind die auf den funktionalen Versionsumfang von 6.12 festgelegt?

 

[Sauerland]

Das kann ich nicht sagen, ich kann keine kmps dafür bauen, wird im OBS abgelehnt...........

 

[marce]

Bezieht sich die Aussage des Herrn Leemhuis auf kommerziell eingesetzte Kernel-Versionen?

Meines Wissens erhalten die (open)SUSE-Kernel, die sich noch im Wartungsfenster befinden, alle erforderlichen Fehler- und CVE-Behebungen. Allerdings keine funktionalen Erweiterungen, wobei diese für den openSUSE Leap Kernel doch manchmal zurückportiert werden.

das ist ein Grundproblem von Backports. Irgendwie muss der Maintainer eines Paketes ja entscheiden, was an Änderungen im Code er zurück porten muss und was nicht.
"Standard" ist erst mal, dass man alles zurück ported, was als Security-relevant markiert ist. Das passiert meist, indem man schaut, welche CVEs es gibt.
Da fängt das Problem schon an - nimmt man jede CVE mit oder nur welche mit Score > x?
Dann gibt es auch heute immer noch Sec-Fixes im aktuellen Code, die kein CVE bekommen - ob und wie diese behandelt werden - kommt immer drauf an...
Dann gibt es noch Sec-Fixes in neuem Code, der im alten gar nicht vorhanden ist. Kann ein Problem sein, muss es aber nicht - muss man also prüfen.
Dann gibt es Sec-Fixes in neuem Code, den man zurückgeported hat - sei es Feature oder Sec / Bugfix
...

Passiert ja auch nicht zum ersten mal, dass ein Maintainer eines Paketes sagt "Bug XY trifft uns nicht" um dann ein paar Tage später sehr spontan zurückrudern muss und spontan doch noch einen Fix nachreichen muss. Und je mehr Pfade man pflegen muss - desto gruseliger.

Deswegen sind pinned-versions mit backports immer kritisch zu betrachten. Der Aufwand, das gut zu machen ist (fast?) genau so groß, wie die aktuelle Weiterentwicklung der Software selbst - es ist einfach extrem komplex zu entscheiden, welche Code-Änderung im latest-Pfad wie zurückgeported werden muss - weil 1:1 geht das auch nicht immer...

Im Kernel läuft das sogar einigermaßen entspannt, da den Entwicklern dort das Problem bewusst und bekannt ist. Dass im Kernel inzwischen für jeden Pups eine CVE vergeben wird macht es da sogar noch einfach...
Andere Pakete sind da je nach Distri weniger gut dran - da bist Du je nach Workflow des Distri-Paketes und und je nach den Launen der Vanilla-Version manchmal irgendwas zwischen "auf verlorenem Posten" und "angearscht".

So gesehen ist eine Bleeding-Edge-Distri mit maximalem Vanilla-Anteil eigentlich das, was man haben will. Nur hast Du damit im Enterprise-Umfeld und bei Zertifizierungen einfach komplett verloren.