On Wed, 23 Sep 2026 08:44:12 +0200 Christian Ehrhardt <christian.ehrhardt@canonical.com> wrote: > On Tue, Sep 22, 2026 at 8:22 AM Juerg Haefliger > <juerg.haefliger@canonical.com> wrote: > > > > On Mon, 21 Sep 2026 15:41:59 +0200 > > Christian Ehrhardt <christian.ehrhardt@canonical.com> wrote: > > > > > On Fri, Sep 11, 2026 at 1:41 PM Juerg Haefliger via ubuntu-devel > > > <ubuntu-devel@lists.ubuntu.com> wrote: > > > > > > > > All, > > > > > > > > Now that the linux-firmware split has landed in Noble, I'd like to tackle the > > > > next firmware issue: HWE backports. > > > > > > I like the general approach of matching firmware to kernels to ensure > > > each kernel has a compatible set. > > > > > > The first thought/concern (we chatted but you might outline your > > > answers here) is that I'd be afraid that the firmware is mostly blobs. > > > So when you split in linux-firmware[-hwe], you might end up: > > > > > > 1. linux-firmware-hwe gets all the updates. > > > > Yes, but only until the next LTS. At that point linux-firmware-hwe is no > > longer bulk updated, it only gets surgical updates for reported issues. > > > > > > > Because isolating changes > > > from blobs isn't reasonable, linux-firmware stays as-is and starts to > > > age and rot > > > > We do update individual blobs to fix reported issues. We just don't do bulk > > updates., except for the HWE backports which is what we're trying to avoid in > > because of all the issues. FTR [1] is the Noble HWE 7.0 backport update. It's > > massive, it took a lot of time to prepare, it broke GA users and it's > > missing loads of potentially required updates. > > > > So, GA kernel plus linux-firmware was current at release time and gets > > cherry-picked updates. Same for HWE. The HWE kernel is a GA kernel of a > > future release and HWE firmware is linux-firmware from that future release at > > release time. Same combination, current at release time, surgical updates to > > fix reported issues. If that makes any sense :-) > > > > The update strategy for both is the same: Cherry-picks to fix reported issues. > > > > > > > 2. On top of #1, every some months security might say "but we need > > > version X for a CVE, blobs have no patches to isolate which blocks us > > > from backporting so we bump it" and thereby forces to update the > > > linux-firmware packges to the latest (in which case the problem you > > > originally wanted to solve is happening again) > > > > That hasn't happened in the time since I'm the linux-firmware maintainer which > > is a couple of years now. I'm not aware of any CVEs reported against firmware > > and if, it would specify the blob and upstream commit that fixes it so we > > would cherry-pick that. I believe (and hope) security is aware that blindly > > bumping linux-firmware to a next release version would potentially wreck > > havoc :-) due to the tight coupling of firmware and kernel. > > > > Re CVEs, I believe most of them are in microcode which are completely separate > > packages anyways (intel-microcode and amd64-microcode) and not affected by > > this. > > > > > > > > Perhaps the firmware isn't as blob-heavy as I assumed? > > > How/Why do you think this scenario would not happen? > > > > The firmware package is just a collection of individual firmware blobs. In an > > ideal world, each kernel driver loads its firmware for a single device and > > one could update that blob without affecting any other kernel or device. > > Reality is different. There's no clean boundary and cherry-picking individual > > firmware updates always results in cross-contamination. Introducing > > linux-firmware-hwe gives us better separation to prevent that. > > > > Hope that answers your questions. > > It does, thank you! It looks like there's no objection so I'm moving forward with this. Not sure what the proper procedure is, please let me know. My plan is to land linux-firmware-hwe plus friends in Stonking (yes, it's late) and then backport to Resolute. The initial packages are just new metapackages that simply depend on the real linux-firmware packages. Later, linux-firmware-hwe in Resolute is updated to contain real firmwares (actually a backport of linux-firmware from Stonking) around the time the first HWE kernel lands in Resolute. Does that sound sensible? FWIW, a first set of linux-firmware-hwe metapackages for Stonking is available here [1] and the bug that tracks it is [2]. ...Juerg [1] https://launchpad.net/~juergh/+archive/ubuntu/linux-firmware-hwe [2] https://launchpad.net/bugs/2170922 > > ...Juerg > > > > [1] > > https://launchpad.net/ubuntu/+source/linux-firmware/20240318.git3b128b60-0ubuntu2.29 > > > > > > > > > > > Thanks > > > > ..Juerg > > > > -- > > > > ubuntu-devel mailing list > > > > ubuntu-devel@lists.ubuntu.com > > > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > > > > > > > > > > > > >
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
