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! > ...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 > > > > > > > -- Christian Ehrhardt Director of Engineering, Ubuntu Server Canonical Ltd -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
