#1036589 hw-detect: Investigate expanding virtualization detection

Package:
hw-detect
Source:
hw-detect
Submitter:
Cyril Brulebois
Date:
2024-12-25 07:06:01 UTC
Severity:
normal
#1036589#5
Date:
2023-05-23 04:50:04 UTC
From:
To:
Package: hw-detect

The hw-detect.finish-install.d/08hw-detect script was inspired by
systemd's detect_vm function, and that part was last touched in 2019.

There were many changes in systemd, and it might make sense to catch up.
Its dmi_vendor_table looks like this currently:

    { "KVM",                  VIRTUALIZATION_KVM       },
    { "OpenStack",            VIRTUALIZATION_KVM       }, /* Detect OpenStack instance as KVM in non x86 architecture */
    { "KubeVirt",             VIRTUALIZATION_KVM       }, /* Detect KubeVirt instance as KVM in non x86 architecture */
    { "Amazon EC2",           VIRTUALIZATION_AMAZON    },
    { "QEMU",                 VIRTUALIZATION_QEMU      },
    { "VMware",               VIRTUALIZATION_VMWARE    }, /* https://kb.vmware.com/s/article/1009458 */
    { "VMW",                  VIRTUALIZATION_VMWARE    },
    { "innotek GmbH",         VIRTUALIZATION_ORACLE    },
    { "VirtualBox",           VIRTUALIZATION_ORACLE    },
    { "Xen",                  VIRTUALIZATION_XEN       },
    { "Bochs",                VIRTUALIZATION_BOCHS     },
    { "Parallels",            VIRTUALIZATION_PARALLELS }, /* https://wiki.freebsd.org/bhyve */
    { "BHYVE",                VIRTUALIZATION_BHYVE     },
    { "Hyper-V",              VIRTUALIZATION_MICROSOFT },
    { "Apple Virtualization", VIRTUALIZATION_APPLE     },

This means a few additions compared to our detect_virt_dmi_entry()
function. That being said, we're talking about a finish-install script,
which tries to run systemd-detect-virt inside target, which is part of
systemd. So in the general case, we shouldn't have to rely on our
fallback…

Filing at normal severity accordingly.


Cheers,
#1036589#10
Date:
2023-05-23 05:11:16 UTC
From:
To:
Cyril Brulebois <kibi@debian.org> (2023-05-23):

Except I lost track of the reason why I was looking at this in the first
place: #1036523.

CPU microcode support is implemented via two steps:
 - detect whether installing is needed based on CPU information, queue
   installation and enable non-free-firmware accordingly (so that it
   can be picked up via apt-setup, so that we can install the queued
   package and its dependencies — see iucode stuff, we aren't talking
   about self-contained firmware packages here);
 - install the package via finish-install.

The finish-install script knows about virtualization so could skip the
queued installation, but in case there were no other reasons to enable
non-free-firmware, we would have still have that component active…

If we were to move virtualization code to some “shell library” that
could be used from both call sites, the former would be less likely (but
I didn't check at the moment) to have the relevant systemd bits in place
so the fallback mapping might be important.

Also, the current implementation mounts and unmounts some filesystems,
so this could have some side effects if we were to use that in the first
call site as well.

All of this reinforces my initial assessment: it seems safest to
investigate this once the trixie release cycle opens, then consider
backports via a point release if relevant.


Cheers,
#1036589#15
Date:
2024-12-25 04:37:01 UTC
From:
To:
Cyril Brulebois <kibi@debian.org> (2023-05-23):

Untested patch attached.

Perhaps Devuan and other non-systemd distros would use the fallback?

Thank you!
Daniel Lewart
Urbana, Illinois
#1036589#20
Date:
2024-12-25 07:03:00 UTC
From:
To:
I wrote:

An alternative patch with fewer quotation marks attached, also untested.

Thank you!
Daniel Lewart
Urbana, Illinois