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. ...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
