Skip to content

The hardware report says whose certificates db holds, the amplifiers' tuning files, and every device's name - #664

Draft
DevomB wants to merge 2 commits into
mainfrom
hwreport-db-amp-tuning
Draft

DevomB wants to merge 2 commits into
mainfrom
hwreport-db-amp-tuning

Conversation

@DevomB

@DevomB DevomB commented Oct 29, 2026

Copy link
Copy Markdown
Owner

The audit's tpm-report:3, :4 and :7: three things the owner's first hardware report could not say.

  • Whose certificates db and KEK hold (firmware()): db holds microsoft's certificates: yes|no|-, and the same for KEK.
    • The image has no efi-readvar, sbctl or mokutil.
    • Booting with Secure Boot on shows only that Kryptik's own certificate is in db. After key work in HP's firmware, this says whether what Microsoft signs, Windows among it, still starts.
    • Every Microsoft CA names Microsoft in its subject. Only yes or no is printed, never a certificate.
  • The amplifiers' tuning files (audio()): for a CSC3554, CSC3556 or CSC3557, a line amplifier-tuning CSC3554:00 cirrus/cs35l54-*-dsp1-misc-<codec subsystem>*.
    • The files are named by the Realtek codec's subsystem ID, and cs35l56-hda asks with firmware_request_nowarn, logging no name, so nothing else in the report gives firmware.list its line.
    • It is a line of its own, because check-hardware.sh reads every field after an amplifier line's third as a driver.
  • PCI names (pci_named()): it read /usr/share/hwdata/pci.ids, which image-excludes.txt leaves out, so every line on a real machine carried IDs only.
    • Without that file, pci_hwdb() asks udev's hwdb (/usr/lib/udev/hwdb.bin, built by eudev.sh) by each device's modalias.
    • It prints the same | class | vendor model form.

Checks:

  • tools/tests/hwreport.sh:
    • a db naming Microsoft and a KEK that doesn't;
    • a CS35L54 machine (codec 10ec0245, subsystem 103c8e19) whose pattern carries that subsystem, while check-hardware.sh still lists "amplifiers CSC3554, not driven";
    • no pattern for the existing CS35L41 case;
    • a run with pci.ids moved away and a stand-in udevadm that knows only the radio. The radio is named, and a device it doesn't know has no names.
  • The new checks were run here and pass. The test's other failures here are Windows symlink artefacts (drivers read as -), which CI's Linux run doesn't have.
  • tools/image/hwreport-test.sh wants the xHCI controller's line to carry names from the medium's own hwdb.

The report runs only when asked, on the medium. Base: zbook-batch-4 (#656). Tectonix: 5808 → 5808, no violations.

… tuning files, and every device's name

Three things the owner's first report could not say:
- Whether db and KEK still hold Microsoft's certificates after work in
  the firmware's key settings. The image has no efi-readvar, sbctl or
  mokutil, and booting with Secure Boot on shows only that Kryptik's own
  is there. Every Microsoft CA names Microsoft in its subject, so a line
  each says yes or no.
- Which tuning files a Cirrus CS35L54, CS35L56 or CS35L57 asks for. They
  are named by the codec's subsystem ID, and cs35l56-hda asks without
  logging a name, so nothing in the report gave firmware.list its line.
  It goes on a line of its own, amplifier-tuning, as check-hardware.sh
  reads every field after an amplifier's third as a driver.
- The names of PCI devices. pci_named read hwdata's pci.ids, which
  image-excludes.txt leaves out, so on a real machine every line carried
  IDs only. Without it the names come from udev's hwdb, which the image
  builds, asked by each device's modalias, in the same form.

Checks: tools/tests/hwreport.sh gains a db naming Microsoft and a KEK that
does not, a CS35L54 machine whose pattern carries its codec's subsystem
while its listing still reads "amplifiers CSC3554", no pattern for a
CS35L41, and a run with pci.ids away and a stand-in hwdb. The VM run wants
the xHCI controller's names from the medium's own hwdb.
The audit's tpm-report:9: the report's ACPI sensor list held only the
IDs Intel's ipu-bridge knows, so the OmniVision sensor amdgpu's ISP looks
for (OMNI5C10, in HP's ZBook Ultra G1a) showed as an unnamed device with
no driver. OMNI* joins the sensors; check-hardware.sh lists it as it does
the others.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant