Skip to content
The record
Report30 September 20264 min read

Telling a firmware-locked RAID drive apart from an unreachable one

A drive hidden behind a RAID/Intel RST controller is raised to "Inaccessible - locked" only when a BIOS password is established as set, because an unestablished lock keeps the ordinary set-AHCI guidance and guessing LOCKED from an unread state would be a false absence with extra steps.

hardware-testingsystemsmethod

Status

Shipped (software), 30 September 2026.. First slice of the design in 2026-09-30-bios-locked-hardware-audit.md.

Not yet proven on hardware. The logic is fully unit-tested; the final disabled-vs-dead confirmation needs a RAID machine with a locked BIOS on the bench. Until then this is reasoned and tested, not proven on metal.

The problem

A drive hidden behind a RAID/Intel RST controller is already detected (the hidden() function in hardware-audit.sh, via remapped_nvme or PCI class 0x0104) and already reported: "Not measurable — behind a RAID/Intel RST controller. Set the storage mode to AHCI in the BIOS, then press Rescan."

That remedy requires entering firmware setup. A BIOS password locks setup. So on a locked machine the instruction is impossible, and the report sends the operator to do something they cannot do — while the drive itself is very likely a working one. For a machine bound for parts harvest that is the exact mistake the design set out to remove: a recoverable drive read as unreachable, or worse, as nothing there.

What was built

Two functions changed in tools/gui/server.py, one style added, one preview knob, one test file.

bios_password_set(profile) — a new helper beside the existing bios_locked(). It reads the biosPassword check the capture already holds in profile.locks (written by lock-checks.sh) and returns:

  • True — a BIOS password is confirmed SET (the check's status is WARNING),
  • False — the check ran and found none (PASS),
  • None — it could not be established (UNKNOWN, or no lock report).

Read from the check's STATUS field, never the row text — the same discipline as bios_locked().

drive_health_lines() — the hidden-drive (RAID) row is elevated to a new verdict only when bios_password_set(p) is True:

Inaccessible — locked Behind a RAID/Intel RST controller, and a BIOS password blocks changing the storage mode in setup. The drive is present but cannot be read here.

When the password is clear, unknown, or there is no lock report, the row keeps the ordinary "set AHCI and Rescan" guidance unchanged.

A new indigo pill (.dhl .dhp.locked, #eef2ff / #4338ca) distinguishes it from the fault colours — green (good), amber (caution), red (bad), slate (not measurable). It is not a fault, and it must not look like one.

What was deliberately NOT built

No lock is ever defeated, read or changed. The password state is read from a report the capture already produced; nothing new touches the firmware.

An unconfirmed lock never produces the verdict. None — which is what every vendor without a firmware-attributes driver (Acer, ASUS, Surface, Toshiba) returns — keeps the ordinary guidance. The LOCKED claim is made only when the password is established, per the design's conservative rule. The cost is that on those vendors a locked RAID drive still reads as "set AHCI"; the alternative — guessing LOCKED from an unread state — would be a false absence with extra steps.

Admin-vs-System is not yet distinguished. The gate fires on any BIOS password being set. On most business fleets an admin/setup password is what is set, so this is right; a rare System-only password that still allows setup entry would produce a LOCKED verdict the operator could in fact clear. If bench testing shows that happening, tighten the gate to the Admin password specifically (the detail string carries it). Noted, not pre-optimised.

Camera, Wi-Fi and the other firmware-disableable parts are not in this slice. They are the next pieces and are harder — their bus-presence signal is vendor-dependent where the RAID controller's is reliable.

How it was proved

19 unit checks in tools/test-bios-locked-drive.py, importing the real server.py and calling the real functions with fixture profiles:

  • bios_password_set returns True / False / None for SET / clear / UNKNOWN / no-report / no-check / non-dict input.
  • RAID + password SET → cls: locked, title "Inaccessible — locked", detail naming the controller and the lock, drive text preserved, and not the set-AHCI action.
  • RAID + password clear / UNKNOWN / no-report → not locked, keeps set-AHCI.
  • A visible measured drive is untouched even when the BIOS is locked.
  • A failed hidden-drive scan stays its own row, never locked.

No regression in test-drive-health.py (146), test-kiosk-ui.py (110), test-wipe-record.py (121), test-prior-audit.py (12).

Rendered in the real kiosk page. A PREVIEW_HEALTH=locked scenario was added to preview-server.py (mirroring the real output), served, and the pill confirmed in the DOM at cls="dhp locked", background rgb(238,242,255), colour rgb(67,56,202) — distinct from every fault colour.

Ships by stick sync, not a layer rebuild — it is gui/ code.

Open questions

  1. The bench proof. A RAID-mode machine with a set BIOS password must show the verdict on real hardware, and a machine where the password is then cleared must fall back to the set-AHCI guidance. Only metal settles it.
  2. Admin-vs-System, above — resolve only if bench testing shows a false LOCKED from a System-only password.
  3. The next slices — camera and Wi-Fi via bus presence, then the vendors without a firmware-attributes driver, per the parent design record.

A published copy. Commit references and internal identifiers have been removed and the operator is not named; the engineering, the counts and the stated limits are unchanged.