#1036523 should not enable non-free-firmware on virtualized systems

Package:
src:hw-detect
Source:
src:hw-detect
Submitter:
Marco d'Itri
Date:
2024-12-27 11:15:01 UTC
Severity:
normal
Tags:
#1036523#5
Date:
2023-05-21 22:31:21 UTC
From:
To:
When bookworm is installed on a virtualized system, the non-free-firmware
component will be enabled even if this is not needed: firmwares cannot
be loaded on virtualized systems because guests usually lack direct
access to the hardware.

As a workaround I had to preseed:

  d-i hw-detect/firmware-lookup string never

As discussed on IRC with kibi, this is caused by hw-detect trying to
install the microcode packages. This is the relevant code:

https://salsa.debian.org/installer-team/hw-detect/-/blob/master/hw-detect.post-base-installer.d/50install-firmware#L51
https://salsa.debian.org/installer-team/hw-detect/-/blob/master/hw-detect.finish-install.d/08hw-detect

microcode packages should not be installed on virtualized systems
because guests never have the privileges required to update the CPU
microcode.
Otherwise guests could influence the whole system and possibly undermine
its security.
#1036523#10
Date:
2023-05-22 05:55:26 UTC
From:
To:
Hi,

Marco d'Itri <md@linux.it> (2023-05-22):
firmware requests, (2) available hardware matches modalias information, (3)
CPU matches one with microcode.

(1) and (2) definitely make sense in a virtualized system as well: you can
have whatever passthrough configuration to access hardware from the host,
e.g. some USB Wi-Fi adapter (that's how I've tested many changes before
switching to baremetal for final tests).

I'm willing to consider tweaking (3), making it conditional.

Is that true for absolutely all virtualization systems detected by the file
linked to above? Your latest message on IRC suggests we might have to pick
and choose?

This issue doesn't seem as clear-cut as it seemed when you first raised it.
Since it's filed at severity normal I think I'll stick to my initial
assessment which was: djust hw-detect during the Trixie release cycle, and
consider cherry-picks for Bookworm, once we get a better picture.


Cheers,
#1036523#15
Date:
2023-05-22 20:23:44 UTC
From:
To:
Fair enough: if somebody is exposing the hardware devices to the guest
OS then they can surely deal with the consequences.
Did it? I am not aware of any scenario in which it would make sense for
an hypervisor to allow guests to change the CPU microcode.

I am not familiar with HyperV, but from what I remember from the my Xen
times the dom0 is for most practical purposes the host, not a guest, so
I am not sure that it is useful al all to report it do d-i as
a virtualized environment.
#1036523#20
Date:
2023-05-23 05:17:34 UTC
From:
To:
Cyril Brulebois <kibi@debian.org> (2023-05-22):

[…]

Given the first follow-up to #1036589, I'm even more convinced trying to
rush something for 12.0 would be a bad idea.

Having an extra component enabled and an extra package installed in some
environments doesn't really justify trying to get an immediate fix,
which could jeopardize all other installation scenarios.


Cheers,
#1036523#25
Date:
2023-05-23 05:18:57 UTC
From:
To:
Cyril Brulebois <kibi@debian.org> (2023-05-22):

Also updating title to match what this bug report is really about.


Cheers,
#1036523#32
Date:
2024-12-25 04:27:00 UTC
From:
To:
Cyril Brulebois <kibi@debian.org> (2023-05-23):

I hope this can be resolved for Trixie.

Patch attached.  Tested with QEMU.

Thank you!
Daniel Lewart
Urbana, Illinois
#1036523#37
Date:
2024-12-25 07:32:11 UTC
From:
To:
Daniel Lewart <lewart3@gmail.com> (2024-12-24):

Thanks, but that doesn't look appropriate: this disables not just CPU
microcode but also modalias-based firmware lookup entirely…


Cheers,
#1036523#42
Date:
2024-12-27 11:10:00 UTC
From:
To:
Revised patch attached.

Thank you!
Daniel Lewart
Urbana, Illinois