NAK: [PATCH 0/7][RFC][LRM][Unstable] Build presigned iwlwifi dkms modules

Mon Apr 18 11:31:58 UTC 2022

On Thu, 14 Apr 2022 at 22:22, You-Sheng Yang <vicamo.yang at canonical.com> wrote:
>
> From: "You-Sheng Yang (vicamo)" <vicamo.yang at canonical.com>
>
> BugLink: https://bugs.launchpad.net/bugs/1962515
>
> [Impact]
>
> Intel AX211 iwlwifi -64 firmware may fail to init under reboot stress,
> and -67 is immune. FW API -64 supported by oem-5.14, and -67 in v5.16.
> Not reproducible on every platform with AX211 installed, and the chances
> of such failures vary from one to another.
>
> [Fix]
>
> A few solutions were considered. The very first one is to ask Intel to
> fix -64 firmware directly, and the answer is a solid no claimed -64 is
> not the planned production version of AX211.
>
> It's also possible to backport FW API from v5.16, but while iwlwifi FW
> API is more or less a black box to us and the new FW APIs also depends
> on updates on the wireless stack, this is going to be very risky and
> actually we had regressions before after such backports.
>
> The last viable solution is to run backport-iwlwifi-dkms >= rev 8580 on
> the effected platforms. This means oem-5.14 and its migration target,
> hwe-5.15 will not be able to drive this piece of hw flawlessly without
> backport-iwlwifi-dkms installed.
>
> However, while we need secureboot to be enabled on these platforms,
> backport-iwlwifi-dkms must also be signed somehow. There are two
> possible method to achieve this, too. One, to prebuild this dkms as zfs
> and v4l2loopback does. However, while backport-iwlwifi-dkms generates
> kernel modules with exactly the same name as the in-tree ones, when
> prebuilt, they'll be available directly from the linux-modules package

Our kernel source package can build multiple copies of the module and
ship it in distinct packages, such that one can install duplicate
module on an opt-in basis.
It was discussed previously, to package this duplicate module not into
linux-modules, and not into linux-modules-extra, but into a new third
modules package i.e. linux-modules-backport-iwlwifi-ABI

> and therefore overrides the in-tree ones always, turning the in-tree
> driver completely useless and risk the stability of all other generic
> installations.
>
> The second one is to build backport-iwlwifi-dkms as nvidia graphic
> drivers in the linux-restricted-modules source package. In this way,

This is not ok. linux-restricted-modules may only contain restricted /
license encumbered modules.

One can make linux-backports-modules (which we used to make years and
years ago), which has similarish packaging to LRM but using public
open source modules and built in main.

> affected platforms may install the corresponding packages when needed
> without interfering others.
>
> This changeset tries to parameterize a bit more in the control file,
> debian rules, etc., generation. They share almost the same mechanism
> except that the linux-objects-iwlwifi carries renamed unsigned kernel
> module binaries directly as there is no restriction on distributing this
> GPL licensed package.

The changes that generalise / parameterize things are nice.

But also note that LRM are built for a lot more kernel flavours than
those that will need this dkms module.

However, due to the first two mentioned comments overall this is a
NAK. A better path forward is to:
1) add backport-iwlwifi to kernel-versions
2) add packaging support in main linux kernel build to build backport-iwlwifi
3) add new control.d package snippet to add such a module
4) add new control.d package snippet in linux-meta to create meta's to
allow optint in to install backport-iwlwifi by default (i.e.
linux-modules-backport-iwlwifi-generic that depends on
linux-modules-backport-iwlwifi-ABI)

--
okurrr,

Dimitri

>
> [Test Case]
>
> While this involves signed package build process, only checked l-r-m
> builds and control file generation in l-r-g and l-r-s.
>
> [Where problems could occur]
>
> The transitional command in the package.config was extended with an
> additional parameter to identify which module, nvidia or iwlwifi, to be
> done.
>
> [Other Info]
>
> While no full tests have been executed to verify thoroughly, I'm using
> RFC instead of SRU to initiate a discuss first. Only Unstable is
> nominated currently, but oem-5.14/jammy/oem-5.17 shall be done once this
> is becoming mature and acceptable.
>
> You-Sheng Yang (vicamo) (7):
>   debian: rename variable nvidia_ignore to suppress
>   debian: rename deb-substvar nvk to a module neutral name
>   debian: rename rules target nvidia-* to targets-*
>   debian: add an additional module arg to transitional command
>   debian: generalize template generation for multiple modules
>   debian: move lrm debian/rules.gen generation to sed template
>   debian: build backport-iwlwifi-dkms
>
>  debian/dkms-versions                 |   1 +
>  debian/package.config                |   5 +-
>  debian/rules.in                      |   5 +-
>  debian/rules.in.iwlwifi              |  15 +++
>  debian/rules.in.nvidia               |  16 +++
>  debian/rules.lrg                     |   2 +-
>  debian/rules.lrs                     |   2 +-
>  debian/scripts/dkms-build--iwlwifi-N |  83 ++++++++++++++++
>  debian/scripts/gen-rules.lrg         |  42 +++++---
>  debian/scripts/gen-rules.lrm         | 142 +++++++++++++++------------
>  debian/scripts/gen-rules.lrs         |  39 ++++++--
>  debian/templates/iwlwifi.postinst.in |  44 +++++++++
>  debian/templates/iwlwifi.postrm.in   |  12 +++
>  debian/templates/iwlwifi.prerm.in    |  19 ++++
>  debian/templates/nvidia.postinst.in  |  14 +--
>  debian/templates/nvidia.prerm.in     |   4 +-
>  update-version                       |   1 +
>  17 files changed, 346 insertions(+), 100 deletions(-)
>  create mode 100644 debian/rules.in.iwlwifi
>  create mode 100644 debian/rules.in.nvidia
>  create mode 100755 debian/scripts/dkms-build--iwlwifi-N
>  create mode 100755 debian/templates/iwlwifi.postinst.in
>  create mode 100755 debian/templates/iwlwifi.postrm.in
>  create mode 100755 debian/templates/iwlwifi.prerm.in
>
> --
> 2.34.1
>
>
> --
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team