Repository navigation
The hardware list: what a listing says, who may vouch, and a check that holds each row to its report - #207
Draft
DevomB wants to merge 79 commits into
Draft
The hardware list: what a listing says, who may vouch, and a check that holds each row to its report#207DevomB wants to merge 79 commits into
DevomB wants to merge 79 commits into
Conversation
…lacks for it: each device with the driver that took it, the firmware the kernel asked for and did not find as lines for firmware.list, the devices and disks that want a line in boot.fragment, and the kernel log, with serial numbers, hardware addresses and UUIDs struck
… one at the first match killed its writer, which pipefail reported as a script no service runs
… gets the report at boot, and kryptik-hwreport --save writes one from its root shell: a temporary file, fsynced, renamed, and the partition unmounted again. No other stick is written, and the installer leaves the reports on the stick
… unprepared stick stays byte for byte what it was, a prepared one gets whole reports on a clean filesystem, a write-protected one is told why it gets none, an install from it carries none over, and the command writes one from the root shell
…ger's mention of the service
… reported when it is whole, names its machine and holds no address, UUID or serial number; certified when it also comes from an installed release with Secure Boot on, the state partition in use, a display, a network path and nothing missing
…ames the net zone's interfaces by kind, with the one the default route leaves by and no address
…row say, who may vouch and how a row enters; the list starts empty and check-hardware.sh --list holds each row to its report
…medium's is reported, and the installed system's, taken under Secure Boot with a display and a network, is certified or short of it only as a dated build
…her filesystem under the stick's label, a link at the report's name would carry root's write to a disk of the machine
…her filesystem under the stick's label, a link at the report's name would carry root's write to a disk of the machine
… report from a virtual machine is refused, and so is a row whose day is not its report's; the page keeps to the one sentence on hardware testing
This was referenced Oct 9, 2026
run-ovmf.sh keeps main's second head and 4Kn disk beside the report's writable stick, and its help prints the whole header again (lines 2-40; main's range stopped two lines short). kryptik-install.sh drops both the report folder and slot b's medium kernel from the copied ESP.
… EDID serial, none of which may reach the report The tool reads an allowlist of DMI fields and a connector's state and modes, never its EDID; the fixture now plants each identifier a real machine has there and denies it in the report, and wants the panel named by connector, state and mode.
…hes, a zone's sched and ioprio calls refused, proxy-calls ending at a proxy's exit
…hes, a zone's sched and ioprio calls refused, proxy-calls ending at a proxy's exit # Conflicts: # tools/image/run-ovmf.sh
… themselves A USB device's manufacturer and product strings, DMI fields and an interface's name reach the report as their makers wrote them: the kernel filters no control characters from usb_string(), and an interface name may hold an ESC. A stick naming itself with an escape sequence would have it run on the terminal of whoever prints or reads the report. scrub(), which every line passes, now drops C0 controls but tab and newline, DEL, and C1 controls in UTF-8 (U+0080 to U+009F, CSI among them).
Since the laptop stack, 1.0 drives sound and suspend, so a certified row leaves them out because the report does not exercise them, not because nothing drives them; a camera is the same. Bluetooth is what 1.0 does not drive.
…devices say of themselves
…ay scale, exFAT), run-ovmf's --second-head refusal with --s3, proxy-calls traced alone, source mirrors # Conflicts: # build/stages/04-base-system.sh # tools/image/run-ovmf.sh
… hardware's time asleep A hardware time asleep of 0 says a sleep never reached the SoC's deepest state only where Intel's or AMD's power controller driver is bound to count it; elsewhere it says nothing. The laptop section's power controller line names intel_pmc_core or amd_pmc when bound, or none.
…ler driver counted it
…'s other lines do
…assthrough Groups whose type is identity translate nothing, so an IOMMU with no DMA or DMA-FQ group confines no device: the line says so instead of 'on'. Strict is the kernel's default here, so identity comes only from a command line or a quirk.
… for a VFIO or a detaching one
# Conflicts: # build/config/image-programs.txt
…stacks Where the kernel shows user_shstk, the CPU has shadow stacks and the kernel turns them on, and glibc then runs a program built for them with one, refusing it a library built without. The report listed user_shstk under "of note" only when present. A report from a machine without them said nothing either way, and a reader had to know the flag to see that the machine could not show that refusal. The cpu section gains "shadow stacks: yes|no". Checked: tools/tests/hwreport.sh wants "no" for its fixture, whose kernel shows no user_shstk, and "yes", with user_shstk in "of note", once the flag is added. Also one report run over a tree holding only a cpuinfo, with and without the flag.
…e, and a laptop's tries include Firefox A program built for shadow stacks runs with one only on a processor that has them (Intel's from Tiger Lake, AMD's from Zen 3), and the virtual machines that test each release have none. So only a real machine shows whether Firefox, built for them and loading libraries built without, starts there. check-hardware.sh's listing gains a shstk line from the report's "shadow stacks" line: yes, no, or not in this report. No level asks for it. docs/hardware.md says what the line means, and its "Trying a laptop" table gains a row: Firefox in untrusted from the menu, where a failure on a machine whose listing says yes names SHSTK. Checked: tools/tests/check-hardware.sh's report fixture, an i7-1165G7, says yes; varied to no, and with the line removed, the listing says each. The expected lines were held against fact()'s padding. bash -n on both scripts.
…sor too The report's soundwire() looked for a SoundWire controller only under an HD Audio controller, at Intel's _ADR 0x40000000. Some AMD laptops, from the coprocessor's 6.3 generation on, put their codecs on SoundWire behind the coprocessor. 6.18's sound/soc/amd/ps driver finds that controller at the coprocessor's ACPI child with _ADR 5 (ACP63_SDW_ADDR, for revisions 6.3 to 7.2). A report from such a laptop named the coprocessor and no parts, so it did not show why the laptop was silent. soundwire() takes the controller's address: 0x40000000 under an HD Audio controller, 5 under the coprocessor. The parts print as before, under the coprocessor's PCI address. Checked: tools/tests/hwreport.sh gains a coprocessor at revision 70, with the microphones' node at _ADR 2 and a controller at 5 holding a Realtek RT722 on link 0. It wants that part alone. The Intel case still wants its two parts under 0x40000000 and none elsewhere. Also one report run over a small tree holding both kinds. The full fixture suite runs in CI.
… to drive The report now lists SoundWire parts under AMD's coprocessor as well as under HD Audio. check-hardware's audio line credited every SoundWire part to SOF, Intel's driver, which does not drive AMD's. audio_of keeps the parts under HD Audio as SOF's. Parts under the coprocessor's PCI address join its own part of the line: "SoundWire PARTS behind AMD's coprocessor", driven or not as the coprocessor is. docs/hardware.md says a listing names both. Checked: tools/tests/check-hardware.sh gains amdsdw, a report whose audio is a revision 70 coprocessor with an RT722 on its SoundWire, and wants "AMD's coprocessor (rev 70) with no microphones its ACPI names; SoundWire 025d:0722 behind AMD's coprocessor, not driven". audio_of was also run on that report and on an Intel SoundWire one, which still says "SoundWire 025d:1316, not driven". bash -n on both scripts.
… built-in SD reader and a USB headset Four changes made for laptops can only be shown on one, so the "Trying a laptop" table names each, with what should happen: - a charger too weak for the machine, where the Power line says on battery though plugged in and the warnings come; - on an AMD laptop that sleeps to idle, a two-minute sleep that wakes to the lock rather than a reset, as the watchdog no longer feeds AMD's TCO timer there; - an SD card in the laptop's own reader, which opens the window that asks which zone gets it; - a USB headset, which plays a zone's sound and records once granted. Docs only.
…er it reset the last boot On an AMD laptop that sleeps to idle, the feeder now leaves AMD's TCO timer unfed, as the timer would count through the sleep. A report could not show that, nor that a watchdog had reset the boot before, which is what a laptop that rebooted asleep would show. firmware() gains a line for each watchdog under /sys/class/watchdog: its identity, its timeout, its state (active once something feeds it), and ", reset the last boot" where bootstatus has WDIOF_CARDRESET (32), which sp5100_tco sets when its timer fired. Checked against 6.18's watchdog_dev.c for the formats (bootstatus and timeout decimal, state active or inactive). tools/tests/hwreport.sh wants an SP5100 timer that is inactive and reset the last boot, and a software watchdog that is active. Also one report run over a tree holding only the two.
The report now lists each watchdog, whether it is fed and whether it reset the boot before. The page's account of a report names them, and the AMD laptop's sleep row says the report's line for AMD's TCO timer reads inactive there. Docs only.
dwl draws with pixman into dumb buffers, without Mesa. On a laptop whose external ports hang off a second GPU, an AMD one beside the built-in, those outputs show the desktop only through wlroots copying each frame between the GPUs. QEMU has one card, so nothing tests it. The "Trying a laptop" table gains the row; a dark monitor's note names both GPUs, as the listing's display line does. NVIDIA's ports have no driver at all, which decisions.md already says. Docs only.
…in keyboard 1.0 builds no Thunderbolt or USB4 driver, so a Thunderbolt or USB4 dock's own USB ports and Ethernet stay dark, while a monitor over USB-C shows where the laptop drives the port itself. The state passphrase is asked before any module loads, so a built-in keyboard on I2C types nothing there. The "Trying a laptop" table gains a row for each. The DMA paragraph says a listing names Thunderbolt's level only on a build with its driver. Docs only.
No driver here takes NVIDIA's graphics. On a laptop with an NVIDIA chip beside Intel's or AMD's, that chip stays in D0, drawing power, unless runtime PM is allowed it and the port above it then sleeps. The PCI core forbids that by default for a device nothing drives. The report said nothing of it, so October's reports could not tell what that costs a battery. The display section gains a gpu line per PCI display controller: its address, ids, driver, power state, and runtime PM's status and control. These are values the kernel keeps, so reading them wakes nothing. Checked: the report run on a tree of two GPUs, Intel's driven and let sleep and NVIDIA's with no driver, prints both lines as the suite's two new checks want them. sh -n and bash -n pass. CI runs the suite.
…ocking shut The hardware list says what a listing's gpu lines give: each graphics controller's power state. An NVIDIA chip that nothing here drives stays in D0 beside Intel's or AMD's, and only such a laptop shows what that costs its battery. Two rows join "Trying a laptop". On a laptop with NVIDIA's graphics beside the built-in, the desktop shows on the built-in screen, a port the NVIDIA chip drives stays dark, and the gpu line says whether the chip stayed powered. A laptop closed on its dock sleeps within seconds of the dock being unplugged, which the compositor's undock check does. Checked: check-hardware.sh reads only the display section's card lines, so the report's new gpu lines leave every listing as it was.
The mixer now moves a playing stream to a USB card plugged in under it (#604), so the try for a USB headset plugs it in while a zone plays: it takes the sound within a second, then records once granted. A headset plugged in during a call is how the guide says calls work.
The laptop section gave a battery's charge and status but not its power, so a report could not show what a laptop costs to run idle, or what an NVIDIA chip left in D0 adds. Each battery now gets a line of its own with its power in milliwatts. That is power_now where the battery reports it, otherwise current_now times voltage_now, which are the two ways ACPI batteries report it. A value that is not a whole number gives no line. The battery's own line keeps its format, and check-hardware.sh reads only that one. Checked: the report run on a tree of two batteries, one with power_now and one with current and voltage, and a device's battery with a malformed value, prints 7213 mW and 17100 mW and nothing for the third, as the suite's three new checks want. sh -n and bash -n pass.
A report's battery lines give each battery's power, so a listing of a laptop with an NVIDIA chip beside the built-in one shows what the chip left in D0 costs it. check-hardware.sh reads only the power_supply lines, so every listing stays as it was.
The launch daemon ends a camera grant when udev removes the granted node (#596). The virtual machines show that with vivid unloaded, and a real camera pulled out takes the USB path instead. The row asks for both halves: the grant ends at once, and the camera plugged back in waits for k again.
…ktop runs The tries had a monitor only on a laptop with two GPUs. The common case is one port on the laptop's own GPU: plugged in while the desktop runs, the desktop reaches it, and kryptik display lists it with its scale, which the session's display watcher sets as the user chose.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The hardware list: which machines Kryptik has been run on, who ran it, and what each run showed. Stacked on #180, whose commits are the first four here; the list is built on its report.
The page,
docs/hardware.md, says what a report is and the two ways to take one, what a row of each level says, who may vouch, and how a row enters the list. The list itself,docs/hardware/list.tsv, starts empty, with one report beside it per row once the hardware tests planned for October 2026 bring some.Two levels, each defined by what the report shows, so a row cannot claim more than its evidence:
reported: the report is whole, names its machine, release and kernel, and holds no hardware address, UUID or serial number. It says what the machine has and what the image lacks for it.certified: all of that on an installed system: a release and not a dated build, booted by UEFI with Secure Boot on and lockdown in confidentiality, the encrypted state partition in use, a DRM device with an output connected, the default route leaving by a wired or wireless interface that has a carrier, and nothing undermissing.The check,
tools/check-hardware.sh: given reports, it prints what each shows and the level it carries, with every reason it falls short ofcertified; with--listit holds each row to its report, refuses a report that holds an identifier (naming the line, never its content) and a report without a row.tools/tests/check-hardware.shcovers each criterion and each refusal, and ends on the tree's own list, so CI runs the real check with no workflow change.The report gains what a listing needs and it did not say:
state:in its system section, and the net zone's interfaces by kind (wired, wireless, virtual) with the one the default route leaves by; no address is printed. The reporter's fixture suite now feeds its report to the checker, so the two cannot drift apart.The sound in a listing. The check reads the report's
audiosection into oneaudioline, by the kinds of docs/design/laptop-audio.md: the HD Audio codecs, the graphics' HDMI ones left out, then any microphones on Intel's DSP, SoundWire parts, microphones on AMD's coprocessor and amplifiers, each with what drives it or "not driven". No level asks for any of it, and a report from before the section says so and keeps its level. The checker's suite tests the good report's line, the same report driven by SOF and one with no section; the reporter's suite gives each of its five kinds the listing it carries.A laptop in a listing. Four more lines read the report's
laptop,usbandinputsections, and no level asks for any of them:laptop: each backlight and its kind, the machine's own batteries (a mouse's or a headset's, scope Device, is not counted), mains, and the lid switch; a desktop says it has none of them.sleep: what a sleep to memory is, deep or s2idle, and the other kinds offered, or that there is none.camera: a USB video device by its IDs and what drives it, and a MIPI camera's parts: Intel's image processing unit and what drives it, and its sensors, behind a Visual Sensing Controller where there is one.bluetooth: each controller on USB (e0/01/01) and what drives it.dma: what confines a device's DMA: on, with the IOMMUs and their groups by how they translate, or none, then each Thunderbolt domain's security level.shstk: whether a program built for shadow stacks runs with one there (yes, no, or not in this report), from the report'sshadow stacksline. The VMs that test each release have none.A report from before the laptop section says so on its three lines and keeps its level. The checker's suite gives its laptop a USB camera, an unbound Bluetooth controller, a laptop section and a lid switch, then varies each: a device's battery, a two-word status, a desktop, s2idle alone, no mem, a MIPI camera, no camera, btusb bound, no Bluetooth, and no section.
Trying a laptop. The levels speak for installing, Secure Boot, the display and the network. The page adds a table of what to try on a laptop beyond the report and what each should do: the lid, the power key and
kryptik suspend, the brightness, volume, mute and microphone keys, sound from the speakers, the mains coming and going, a camera granted withk, and Firefox inuntrusted, whose start with shadow stacks on only a machine whoseshstkline says yes can show (a failure names SHSTK). The row's note names what did not work. A laptop that wakes from the lid and fromkryptik suspendis the proof the idle sleep waits for.docs/status.mdgains a row for the report and the list, saying which of its lines wait for the laptops.In acceptance, the
hardware-reportitem holds the reports it takes to the listing they carry: the medium's isreported; and the installed disk, booted with the medium's certificate enrolled, a display and a network, takes a report that must becertified, or on a dated build short of it in that one thing.Open, for when the first laptop reports come: whether
certifiedshould also ask for the IOMMU on, since the kernel's DMA protection rests on it. Thedmaline shows it either way.For whoever merges the docs changes that are open: the README's documentation list and the roadmap's Version 2 line on a hardware certification list can point at
docs/hardware.md. Not to be merged before #180, nor before v1.0.0 is tagged.