docs(prod): BIOS password answer + CORRECT the 0x4 'auth failure' reading

Operator asked for the default BIOS password. ANSWER: there is none, and no factory default
exists to look up. HP business desktops ship with no Setup and no Power-On password; the
is_enabled=0 we measured IS the factory state. Recovery for a forgotten password is the PSWD
jumper — and 'stringent security' must NOT be enabled, since HP documents that it removes the
physical bypass and turns a 5-minute fix into a signed per-serial HP service case.

CORRECTION, and the kernel driver misled me: I recorded that the firmware refused our write for
lack of BIOS-admin authentication. Wrong. hp-bioscfg passes the return of HP's WMI SetBIOSSetting
through hp_wmi_error_and_message(), which is THE ERROR TABLE FOR A DIFFERENT INTERFACE (the
"SECU" commands under HP_WMI_BIOS_GUID). Per HP's Client Management Interface white paper,
SetBIOSSetting 4 = 'Failed' (generic) and 6 = 'Access Denied'. We got 4, not 6 — and the driver
has a separate BIOS_ADMIN_NOT_SET = 0x38 -> -EPERM for the no-password case, which we also did
not get. 'Invalid command type' is the driver looking 4 up in the wrong table: a genuine upstream
bug worth reporting to platform-driver-x86.

Most likely real cause (inferred, testable): with an empty password the driver emits an UNTAGGED
empty UTF-16 string, while every HP-documented caller passes Password="<utf-16/>" even when
blank — the driver only prepends that prefix for a non-empty string. Setting a password may fix
writes, but by flipping onto the tagged code path, NOT because 0x4 meant unauthorised.

Also verified from source: hp-bioscfg CANNOT set a password. current_password and new_password
both funnel into store_password_instance(), which only strscpy's into driver RAM; new_password is
write-only into a buffer nothing ever reads.

Count corrected: 241 attributes exposed, 239 with a current_value, 215 non-empty. I had quoted
215 as the total; it was the non-empty subset.

Recommendation recorded: land read-only drift detection now (zero risk, no new credential, and it
already caught real drift); treat a Setup password as a deliberate experiment on node 3 only;
hp-repsetup as fallback but it needs Secure Boot off or a self-signed module; skip Sure Admin/BCU
at this scale.

Serves: R-ENV-03, R-SEC-01. Task: T-7.1.

infra/PROD-PROVISIONING.md

@@ -142,8 +142,9 @@ To investigate, cheapest first:
 ## 1. Firmware / BIOS (per node, before OS install)
 
 > **These are MACHINE-CHECKABLE — but NOT machine-enforceable.** The `hp-bioscfg` driver exposes
-> 215 BIOS attributes at `/sys/class/firmware-attributes/hp-bioscfg/attributes/`, and **reads work
-> fine**: node 1 and node 2 were diffed programmatically, which is how the drift in §0b was found
+> **241** BIOS attributes at `/sys/class/firmware-attributes/hp-bioscfg/attributes/` (239 have a
+> `current_value`; 215 returned a non-empty value — an earlier note here said "215 attributes",
+> which was the non-empty subset, not the total). **Reads work fine**: node 1 and node 2 were diffed programmatically, which is how the drift in §0b was found
 > at all. Nobody could have spotted `After Power Loss=Power Off` on node 2 by eye.
 >
 > **Writes are refused by the firmware** — verified 2026-09-01, `hp_bioscfg: Returned error 0x4,
@@ -169,6 +170,80 @@ To investigate, cheapest first:
       nodes match.
 - [ ] **Firmware version recorded** in §0 and consistent across all three nodes.
 
+### 1b. BIOS passwords and programmatic configuration — researched 2026-09-01
+
+**There is no default BIOS password, and no factory default exists to look up.** HP business
+desktops ship with **no** Setup password and **no** Power-On password set; the `is_enabled=0` we
+observe on both is the factory state, not drift. HP's own Maintenance & Service Guide for the 800 G5
+describes both purely as things the owner configures in Computer Setup.
+
+**Owner recovery path, for the runbook:** if a Setup password is ever set and forgotten, HP documents
+clearing it with the **PSWD jumper** on the system board (power off, open, remove jumper, boot once).
+**Do NOT enable "stringent security"** — HP documents that it removes the physical bypass entirely,
+turning a five-minute jumper fix into an HP service case requiring a signed, per-serial unlock. The
+permissive default is the right setting for a homelab.
+
+#### CORRECTION — error `0x4` is NOT an authorisation failure
+
+I recorded that the firmware refused our write because BIOS-admin authentication was missing. **That
+was wrong, and the kernel driver misled me.** `hp-bioscfg` passes the return value of HP's WMI
+`SetBIOSSetting` method through `hp_wmi_error_and_message()` — which is **the error table for a
+different interface** (the `"SECU"` commands under `HP_WMI_BIOS_GUID`). The two methods have
+unrelated return-code spaces. Per HP's *Client Management Interface* white paper, `SetBIOSSetting`
+returns:
+
+| Code | Meaning |
+|---|---|
+| 0 | Success |
+| 1 | Not Supported |
+| **4** | **Failed** (generic) |
+| 6 | Access Denied |
+
+So the firmware said a generic **"Failed"**. An authorisation problem would have returned **6**, and
+the driver has a *separate* `BIOS_ADMIN_NOT_SET = 0x38` → `-EPERM` for the no-password case — neither
+of which we saw. The string "Invalid command type" printed in our logs is the driver looking `4` up
+in the wrong table. This is a genuine upstream bug worth reporting to `platform-driver-x86`.
+
+**Most likely actual cause (inferred, testable):** with an empty password the driver emits an
+*untagged* empty UTF-16 string, whereas every HP-documented caller passes the encoding tag even when
+blank (`Password = "<utf-16/>"`). The driver only prepends that prefix for a *non-empty* string. So
+setting a Setup password may well fix writes — **but not because 0x4 means "unauthorised"**; it would
+work by flipping the driver onto the tagged code path HP's own tools use. Corroborating smell: this
+firmware already makes the driver log `Prerequisites size value exceeded the maximum number of
+elements supported or data may be malformed` at boot.
+
+**`hp-bioscfg` cannot set a password** — verified from source. Both `current_password` and
+`new_password` funnel into `store_password_instance()`, which only `strscpy`s into driver RAM;
+nothing ever transmits `new_password` to firmware. It is write-only into a buffer that is never read.
+
+#### Recommendation
+
+1. **Land the read-only drift check now** — encode this §1 checklist as expected values, diff
+   `current_value` on every node in `roles/node_health`, fail on mismatch. That is the whole R-ENV
+   win, at zero risk and with no new credential, and it is available today. Remediate by hand at F10.
+2. **Do not provision a Setup password "to fix the auth error"** — there is no auth error. Provision
+   one only as a deliberate experiment on **node 3** (not yet built): set it at F10, write it to
+   `current_password`, retry one benign attribute. Return `0` confirms the `<utf-16/>` theory; `6`
+   would mean a password mismatch; another `4` means the driver is incompatible with R21 and the
+   fallback is `hp-repsetup`.
+3. **Fallback if that fails:** HP's own Linux tool `hp-repsetup` (HP Flash and Replicated Setup
+   Utilities, v3.26) can both dump/apply settings *and* set the Setup password from Linux — but it
+   needs the out-of-tree `hpuefi.ko`, which requires **Secure Boot disabled or the module self-signed**.
+   Secure Boot is currently enabled on these nodes, so this costs either a signing setup or a
+   security downgrade.
+4. **Skip HP Sure Admin / SPM and BCU.** Sure Admin's key-based model is genuinely better in
+   principle — the private key never leaves the workstation, each change is individually signed, with
+   anti-replay — but provisioning and every signature require Windows-only tooling. For three
+   machines whose firmware settings change roughly never, the operational cost far exceeds the risk
+   reduction. BCU is Windows/WinPE-only.
+5. **Security trade-off if you do provision a password:** it is a *shared* credential granting full
+   pre-OS control of all three nodes (disable Secure Boot, re-order boot, re-enable ports) —
+   functionally equivalent to unsupervised physical access. Exposure is bounded in that using it via
+   `hp-bioscfg` needs root on the node already (sysfs is `--w-------`), so the marginal loss is
+   persistence and pre-boot control rather than initial compromise. Note `hp-repsetup -p` takes the
+   password in cleartext on the command line — it would land in process listings and shell history
+   unless wrapped. Store it in the Ansible vault **and** offline.
+
 ## 2. Disk layout — **OPEN DECISION, blocks the build**
 
 `docs/02` requires the OS-vs-Longhorn device split to be **documented before prod build**. Dev went