Auditing a machine when USB boot is blocked: a network-boot fallback and the line it must not cross

Status

Design exploration — nothing built, 2 October 2026. This is the one kind of record that breaks rule 2 ("no record before the work is done") on purpose: it exists to fix the architecture, and the boundary, in writing before any code, so the boundary is decided when nobody is mid-build and under pressure to ship. Everything under "What was built" is proposed, not present. Raised by the operator after a BIOS-locked machine could not boot the stick.

Amended the same day, twice: (1) the existing image-server PC takes the netboot role rather than a new box, with the active-vs-passive wiring rule it forces; (2) the boot-policy "detect and recommend a route" step is dropped — the operator chooses USB or LAN at the firmware boot menu, and the station does not try to recommend.

The problem

The station audits a machine by booting its own Linux off a USB stick. When a machine's firmware refuses to boot USB — a common setting on an ex-corporate fleet — the stick never runs, and the machine cannot be audited by the normal route. The operator asked whether the network/LAN could be a legitimate second route in, the way it already is for the IT departments these machines came from.

The question carries a trap, and the operator named it: the goal is not to defeat BIOS security. So the first job of this record is to draw the line that the design must not cross, and only then to describe what is on the right side of it.

The one distinction everything hinges on

Two different things both get called "getting around a USB block":

1. Using a boot path the firmware is configured to allow. If network boot is switched on, booting the audit environment over the network is using a feature that is already enabled. No control is defeated.
2. Making a forbidden path look like a permitted one. Getting a device the firmware refuses to boot to run anyway by disguising what it is.

Xorkbench may only ever do (1). It must never do (2). This is the same rule the station already lives by — it reports BIOS locks, it does not pick them (lock-checks.sh:373, check_bios_password; lock-checks.sh:1953, lock_bios_locked) — carried over from "what disk do we boot" to "what medium do we boot from".

Why it matters

A refurbisher is paid to certify stock. A machine that cannot be audited is either returned (lost margin) or, worse, sold uncertified. A legitimate network route turns "USB off, can't audit" into "audited over the LAN" for a large slice of ex-corporate fleets — the very machines most likely to have USB boot locked and network boot left on, because their former owners imaged them over PXE.

Equally, the business depends on the audit being trustworthy. The moment the tool can be pointed at a machine to defeat its boot policy, its certificates are worth nothing and the operator is exposed. So the value and the boundary are the same decision.

The boot-policy matrix

"USB boot disabled" is one switch; "network boot disabled" is a separate switch. They are set independently, and that independence is the whole opportunity.

The fallback is real, but it lives on one row. It is available only when the firmware already permits network boot. It is not a route around the third row, where no legitimate path exists and the station's existing job — detect and report the lock — is the whole of the correct answer.

What was built (proposed)

The operator chooses the route — there is no "which route" detector

The two delivery routes, USB and LAN, are both always available, and the operator picks one at the firmware boot menu (F12 → the stick, or F12 → onboard NIC). The station does not try to detect the machine's boot policy and recommend a route. This is a deliberate owner decision (2 Oct), and it is the right one for two reasons:

• It is the human's call. The technician at the bench knows what they are holding and which route they want; a recommendation is friction, not help.
• The detector would have been weak anyway. Reading the firmware's boot settings (Dell dell-wmi-sysman, Lenovo think-lmi, HP hp-bioscfg under /sys/class/firmware-attributes/*/attributes/) only works on a machine the station has already booted — never on the one that just refused the stick, which is exactly the machine a recommendation would be for. So it could never answer the question it would appear to answer.

Nothing in the audit itself changes with the route: a machine that netboots brings up the same kiosk, hardware-audit.sh and server.py as one that booted the stick. The choice is physical — which boot device you select at power-on — not a setting inside Xorkbench.

Xorkbench Netboot — the LAN route itself

Network boot has moved past slow TFTP. The chain to build:

1. The firmware's own network stack (UEFI network driver / NIC option ROM) does DHCP and is pointed at a small Network Boot Program.
2. That NBP is iPXE (behind shim → grub where Secure Boot is on). iPXE is the pivot: once running, it pulls everything else over HTTP(S), far faster and more flexible than TFTP.
3. iPXE HTTP-loads the same casper kernel + initrd + minimal.standard.live.station.squashfs the USB uses. One audit environment, two delivery routes. The kiosk, hardware-audit.sh and server.py come up identically; the only thing that changed is where root arrived from.

Where the boot server lives: the existing image-server PC, not a new box. A bench that loads OS images already runs an image server — a PC exposing a read-only file share that the station mounts for install-os.sh. In the code today this is the IMAGE_SERVER setting in audit.conf, mounted read-only by mount_image_server (gui/server.py:4840) as SMB (//host/share, cifs ro) or NFS (host:/path, ro,soft). That same PC should take the netboot role: it already holds the image repository, it is already the LAN box the bench trusts, and putting both jobs on it means one machine, one repository, one thing to maintain — no second box. It would then:

• store the OS images (as now),
• serve them to install-os.sh (as now),
• also hold the one audit squashfs the sticks use, and
• also answer a network-booting machine and hand it that squashfs.

The services it gains: dnsmasq in proxy-DHCP mode (it answers boot requests without taking over the site's DHCP) + TFTP for the tiny NBP + a static HTTP server for the kernel/initrd/squashfs + the iPXE and signed-boot binaries.

The one behaviour that genuinely changes, and the rule it forces. Today the image server is passive: it offers a read-only share and the station reaches out to it; it never initiates anything. Proxy-DHCP is active: it listens for and answers boot broadcasts on its segment. That is safe and correct on an isolated bench network (this PC + the machine under audit, nothing else), and a liability on a live corporate LAN (rogue-DHCP, booting the wrong machine). So the design rule, stated so it cannot be argued around: the image-server PC runs the netboot services only while on the isolated bench network; it is never an active boot responder on a customer's production LAN. The file-share role alone is passive and could live anywhere; the moment the netboot role is on, the wiring rule applies.

Reused unchanged: the squashfs layer, the kiosk, the engine, the offline queue, the Secure Boot signing posture (the reason the station is built on Ubuntu), and the image-server PC and its image repository. New: the iPXE config, the proxy-DHCP + TFTP + HTTP services added to that PC, and signing the netboot chain. A technician's laptop can stand in as the server where no image-server PC is present, but the image-server PC is the intended home.

Single point, but not a single point of failure for auditing. With both jobs on one PC, if it is off the bench loses the network-audit route and image loading at once. Acceptable, because USB auditing is wholly independent of this PC — a failure here drops you back to the stick, never to no audit at all.

A USB network adapter, for machines with no Ethernet port

A real USB-to-Ethernet adapter carrying a UEFI network driver, or a USB gadget that enumerates as a NIC (CDC-NCM / RNDIS) and is itself the boot server ("netboot server in your pocket"), gives a network-boot path to a thin laptop with no Ethernet. Legitimate, because the device genuinely is a network adapter and network boot is a feature the firmware permits — gated on exactly that condition.

What was deliberately NOT built

• Making a USB mass-storage device impersonate a permitted device class to boot when USB/storage boot is switched off. This is disguising a forbidden device as an allowed one to evade the restriction on its real class. It is circumvention, it is refused, and it is the precise thing the "report locks, never defeat them" rule exists to stop. The design principle, stated so it cannot be argued around later: a Xorkbench device enumerates only as what it actually is, uses only boot paths the firmware is configured to allow, and when every permitted path is closed, says so.
• Any route for the all-locked machine (row three). There is none, by design. The machine is reported locked and returned to its owner for the password. No amount of architecture changes this, and the tool's integrity depends on it staying unchanged.
• Touching the customer's production network. The boot server — the image-server PC, once it carries the netboot role — is bench-local and isolated while that role is on. An audit tool that PXE-answers on a live corporate LAN is a liability (rogue-DHCP incidents, imaging the wrong machine); proxy-DHCP on an isolated switch is the only acceptable shape. The passive file-share role the PC already has is exempt; the active netboot role is not.
• A "which route" detector / recommendation. Dropped by the operator: both routes are always available and the technician chooses at the boot menu. It would also have been unable to read the boot policy of the machine that just refused the stick (it can only read a machine already booted), so it could never answer the question it appeared to.
• Wi-Fi netboot. Firmware almost never PXEs over Wi-Fi; not pursued.

How it was proved

Nothing is proved — nothing is built. What is established, from firmware behaviour and the existing codebase, and what is still only reasoned:

• Established: USB-boot and network-boot are independent firmware switches; iPXE can HTTP-load a kernel/initrd/squashfs; the station's squashfs is already a casper live layer that boots this way from USB, so the same artefact can be served over HTTP without change; the firmware-attributes interface exposes readable boot settings on the three major business vendors (the station already reads its sibling authentication tree).
• Reasoned, unverified: that any specific locked machine on the bench has network boot left on (only an audit of it can say); the Secure Boot signing chain for the netboot NBP (same requirement as the USB, but not yet assembled); real-world proxy-DHCP behaviour on the bench switch alongside whatever DHCP the site runs; that the image-server PC can carry proxy-DHCP + TFTP + HTTP alongside its existing read-only share without the two roles interfering (the share is reached by the station; the netboot services answer to it, so they should not contend, but this is reasoned, not run).
• Why no route-recommendation: boot-policy attributes can only be read on a machine the station already booted, never on the one that just refused the stick — so a recommendation could not serve the case it was for. With the operator choosing the route at the boot menu, the question does not arise.

Open questions

• Priority and appetite. The netboot server is a real piece of infrastructure — worth building only if locked-but-network-on machines are a meaningful share of the bench's intake. The operator has the volume data.
• Where the boot server lives: decided — the existing image-server PC, which already holds the image repository and is the bench's LAN box, rather than a new appliance or the technician's laptop. The remaining choice is how that PC is kept on the isolated bench network when the netboot role is active (second NIC, a dedicated bench switch, or a VLAN) without disturbing its file-share duty.
• Signing: whether to sign the netboot chain under the same key posture as the USB, or run that bench segment Secure-Boot-off on an isolated switch. The USB keeps Secure Boot on deliberately; the netboot path should match unless there is a reason not to.
• Scope creep guard: this record exists partly so that, if network boot is ever built, the "NOT built" section is read first.