From 5ea9c93f58651f188dc1d8fd0a3bade75e496187 Mon Sep 17 00:00:00 2001 From: Keith Jackson Date: Tue, 1 Sep 2026 22:10:07 -0500 Subject: [PATCH] docs(prod): BIOS password answer + CORRECT the 0x4 'auth failure' reading MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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="" 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 | 79 +++++++++++++++++++++++++++++++++++++- 1 file changed, 77 insertions(+), 2 deletions(-) diff --git a/infra/PROD-PROVISIONING.md b/infra/PROD-PROVISIONING.md index 53c3b58..f79ae2f 100644 --- a/infra/PROD-PROVISIONING.md +++ b/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 = ""`). 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 `` 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