6 Commits

Include renames

Author	SHA1	Message	Date
enricobuehlerandClaude Opus 5	560e663aef	fix(drivers): the pad channel asks the devnode who to trust, not the mailbox ... A LocalService principal could take over a virtual pad's shared input section and forge HID input into the interactive desktop. The host duplicates each pad's unnamed DATA section into the driver's WUDFHost, and through gamepad proto v2 it learned that process from `driver_pid` in the named bootstrap mailbox. That mailbox has to be LocalService-writable — that is what the driver's own WUDFHost runs as — and the delivery gate, verify_is_wudfhost, only checks that the target's IMAGE is %SystemRoot%\System32\WUDFHost.exe. That image is world-executable. So anything running as LocalService — notably the deliberately de-privileged plugin runner — could spawn its own WUDFHost (CREATE_SUSPENDED parks it indefinitely with the right image path), publish that pid, and be handed SECTION_MAP_READ|WRITE on a live section. For pf-mouse that section drives a real absolute pointer, so it was desktop control; for the pads it was forged gamepad input plus a read of the remote user's controller state. The module docs claimed mailbox tampering "yields at worst a gamepad DoS, never a read or an injection". That was wrong, and the reasoning behind it — that a LocalService token is DACL-denied OpenProcess on a UMDF WUDFHost — only covers the REAL host, not one the attacker spawned itself. The pid now comes from the device stack (ChannelProof, proto 2 -> 3). The host asks the devnode it SwDeviceCreate'd who is serving it, looked up by the instance id PnP handed back, so a planted look-alike devnode is not a candidate and the kernel — not anything the attacker supplies — does the routing. Only the driver PnP actually bound to that device can answer. `driver_pid` survives as a liveness hint; a tamperer can still deny a pad, which squatting the name always allowed, but can no longer choose the recipient. Two rules keep the state machine honest around it: a delivery stands until its target process EXITS (judged on a retained SYNCHRONIZE handle, so a recycled pid cannot fake it, and UMDF's restart-after-driver-crash still re-attaches), and a pad with no SwDeviceCreate devnode refuses to deliver rather than fall back — unless an operator sets PUNKTFUNK_PAD_CHANNEL_TRUST_MAILBOX, which says so loudly. Three transports, because Windows carries different things to different driver shapes, and the obvious two did not survive contact with hidclass. Measured on .173 (Win11 26200): HidD_GetIndexedString is NOT forwarded to a UMDF HID minidriver at all — it failed for every index including ones the driver demonstrably serves through the named wrappers; and a private device interface registers and enumerates but cannot be OPENED (ERROR_GEN_FAILURE), because hidclass owns IRP_MJ_CREATE on a devnode it is the FDO for. That is exactly why pf-xusb was never affected: it is not a HID minidriver, so nothing sits above it. What works: * pf-xusb — a private IOCTL on its own GUID_DEVINTERFACE_XUSB. * pf-mouse — the HID serial string. Verified: PFCP:3:0:7296, and 7296 was a genuine service-spawned WUDFHost.exe. Safe here alone: nothing reads the virtual mouse's serial, whereas a pad's is SDL/Steam dedup material. * pf-gamepad — a HID feature report, and it cost NO report-descriptor change. The captured descriptors already declare far more Feature ids than the driver ever served: 0x85 is declared on DualSense, DualShock 4 and Edge alike and used to fail with STATUS_INVALID_PARAMETER, so hidclass lets it through and nothing can have depended on the old failure. The Deck's one feature report is unnumbered and Steam drives it command->response, so its proof rides that existing contract via a private two-byte command. Verified: feature 0x85 returned magic "PFCP", proto 3, pad_index 0, wudf_pid 18456 — and 18456 was a WUDFHost — with the product string still 'DualSense Wireless Controller'. Also renamed pf-dualsense -> pf-gamepad. One driver has always served four identities, so the old name read as if the other three lived elsewhere. ONLY the package identity moved (crate, INF/CAT/DLL, UMDF service, build script, CI lines, log file, env var). The four HARDWARE IDS are deliberately unchanged — they bind every devnode the host creates and every installed system — as are the Global\pfds-boot-<i> mailbox and PAD_MAGIC, which are wire contract. `driver install --gamepad` now retires the pre-rename store package first, matched on pf_dualsense.dll because that string appears only in the OLD inf; matching on the hardware ids would delete what we are about to install. On .173 that separated 14 stale packages from the 1 new one with 0 ambiguous, and the renamed package binds the old hwid (devgen root\pf_dualsense -> oem143.inf = pf_gamepad.inf). The repo's own pre-commit/pre-push rustfmt hooks named the old crate, so they caught the rename before the commit did — they now check pf-gamepad, and pf-mouse alongside it, which they had been missing relative to the CI line. Host and drivers MUST ship together: v2<->v3 fails closed in both directions by design, with the existing "update host + drivers together" diagnostic. The rename moved files that also carry the security change, so splitting this into two commits would mean reconstructing an intermediate state that was never gated. It is one commit on purpose. Gated on the windows-amd64 runner with cargo clean first (the box's clock lags, so stale artifacts would read as a vacuous green): clippy -D warnings clean for pf-inject, pf-capture and pf-driver-proto, drivers workspace build + the CI clippy line clean, cargo check --release -p punktfunk-host clean, 19 + 58 tests green. Also fixes pf-mouse still writing its debug log to world-writable C:\Users\Public, which the 2026-07-17 review moved for the other three drivers and missed here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 16:54:40 +02:00
enricobuehlerandClaude Fable 5	9e6fc6e071	fix(host/inject,drivers): rumble root fixes A-C — lossless report ring + rumble-keyed idle watchdogs ... B: PadFeedback.game_drove -> rumble_drove, keyed on vibration-asserting reports — an LED/adaptive-trigger stream can no longer feed the abandoned-rumble force-off while a coalesced stop never re-asserts (the confirmed unbounded stuck-ON path). C: Linux parity — every UHID backend now arms the shared watchdog (Steam Input drives these pads over hidraw with Windows abandonment semantics) and the uinput mixer force-stops abandoned infinite-replay FF effects (FfState, unit-tested). Shared PUNKTFUNK_RUMBLE_IDLE_MS hatch (0 = off; non-zero floored above SDL's ~2 s rumble resend). A: PadShm v2.1 — a 1024 B tail extension carrying an 8-slot lossless output-report ring, feature-negotiated via zeroed reserved fields (out_ring_ver; deliberately NO GAMEPAD_PROTO_VERSION bump — mixed generations degrade to the legacy latest-report slot instead of failing closed). The pf-dualsense driver dual-writes both planes (publish_output); the host's shared OutputDrain drains oldest->newest with a torn-read recheck and an overflow->resync path (PadFeedback.resync force-stops + re-arms dedups). pf-umdf-util grows a min_data_size map fallback. Ds*Feedback.fresh removed (dead). design/rumble-root-fix.md par. A-C. Verified: pf-inject tests+clippy Linux+Windows (53/53 on winbox incl. the stop-coalesce repro); drivers ws check+clippy on the CI runner. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-17 14:07:32 +02:00
enricobuehlerandClaude Fable 5	796d381926	fix(windows): opt-in pad-driver file logs + size-capped service log rotation ... Two disk-write fixes: - pf-xusb/pf-dualsense no longer write C:\Users\Public\pf*-driver.log unconditionally — the file log is now opt-in (debug builds, or the PFXUSB_DEBUG_LOG / PFDS_DEBUG_LOG system env var), mirroring the audit-§4.4 fix pf-vdisplay already got: a release driver never writes the world-writable Public file (info-leak/DoS surface), and the per-report OUTPUT/SET_STATE hex dumps stop being a sustained per-rumble disk-write path during gameplay. OutputDebugStringA stays unconditional; the host's driver-silence WARN and the gamepad-driver-health failure-mode table now say the log is opt-in. - service.log/host.log get one-generation rotation: at each (re)open a file over 10 MB is renamed to .old, so a crash-restart loop or a RUST_LOG=debug left in host.env can't grow the append-forever logs without bound. Rotation runs only before an open (never under a live appender — host.log's handle lacks FILE_SHARE_DELETE, so a racing rename harmlessly fails). Windows CI compile/clippy pending (drivers workspace + host are not Linux-cross-checkable); rides along with the next pad-driver redeploy. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-03 14:03:32 +00:00
enricobuehlerandClaude Fable 5	8b47be668f	feat(host/windows): seal the host↔driver channels (frame + gamepad, proto v2) ... Frame ring (pf-vdisplay) and both gamepad SHM channels move off named Global\ objects (openable by any sibling LocalService) to UNNAMED sections/events whose handles the host DuplicateHandles into the driver's verified WUDFHost with least access — frame delivery over the SYSTEM+admins-only IOCTL_SET_FRAME_CHANNEL, pads over a 32-byte named bootstrap mailbox (pid + handle value only, DoS-bounded; HID minidrivers have no control device). Driver-validated pad_index kills cross-pad redirects; v1↔v2 mixes fail closed with diagnosis logs on both sides. Sibling-LocalService denial proven empirically (design/idd-push-security.md, design/gamepad-channel-sealing.md). Driver-side raw ops now live behind pf-umdf-util (checked shm accessors, the forbid(unsafe_code) ChannelClient state machine, WDF request tokens) — the pad drivers' logic is 100% safe Rust; whole drivers workspace clippy-gated in CI. driver install --gamepad now sweeps SWD\punktfunk phantom devnodes: a re-created SwDevice REVIVES the old devnode with its previously-bound driver (never re-ranks), so an upgrade otherwise leaves the old driver serving — or, across the v1→v2 fence, a dead pad (found live on the RTX box). On-glass validated on the RTX 4090 box: frame path 7007 frames p50 2.06 ms cross-machine; DualSense + XUSB "sealed pad channel mapped"/proto=2 attach via both the test harness and a real streaming session; phantom-sweep repro. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-03 12:08:56 +00:00
enricobuehlerandClaude Fable 5	6bbe7ae137	feat(host/windows,drivers): gamepad driver attach/heartbeat health surfaced in logs ... The gamepad drivers have no IOCTL plane (hidclass gates the stack), so until now the host had ZERO visibility into whether a driver ever bound: a pad could be "created" with no driver installed and nothing was logged. Two health fields are carved from reserved shm space (layout-compatible; pf-driver-proto pins the offsets): driver_proto — stamped by pf-xusb at device add + per serviced XInput IOCTL (movement = the game-visible path) and by pf-dualsense/DS4 from its ~125Hz timer — and driver_heartbeat. Host-side, every pad owns a DriverAttach watcher fed from the existing service() poll: INFO on attach (WARN on proto mismatch), and after 3s of silence ONE diagnosis WARN combining a cached pnputil /enum-drivers store check, the devnode's CM problem code (CM_Locate_DevNodeW/CM_Get_DevNode_Status on the instance id now captured from the create callback, with plain-language hints: 28 = not installed, 52 = signature/Memory Integrity, …) and the driver's debug log path. Also fixes a real bug both SwDeviceCreate wrappers shared: the 10s WaitForSingleObject result was ignored and the callback HRESULT zero-initialised, so a PnP timeout read as SUCCESS (now E_FAIL init + explicit timeout error). Failure-mode table: design/gamepad-driver-health.md. Linux workspace green; Windows host + drivers CI-compile only, on-box recipe at the bottom of the design doc. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-02 16:33:56 +00:00
enricobuehlerandClaude Opus 4.8	8d5e33da0f	fix(windows-installer): build the gamepad drivers from source in CI too ... Fold the pf-dualsense (DualSense / DualShock 4) and pf-xusb (Xbox 360 / XInput) UMDF drivers into the in-tree drivers workspace (their source had stale ../../crates/wdk-* path-deps from before the wdk vendoring reorg and could no longer build at all) and build them from source per release, exactly like pf-vdisplay - same anti-stale reasoning. One `cargo build --release` now builds all three drivers against the vendored wdk-sys (incl. the bindgen 0.72 pin), and build-gamepad-drivers.ps1 signs pf_dualsense + pf_xusb (clear FORCE_INTEGRITY -> sign dll -> stampinf -> Inf2Cat -> sign cat) with one shared cert + .cer, matching the layout install-gamepad-drivers.ps1 expects. pack-host-installer.ps1 builds + stages them instead of the retired checked-in binaries. Validated on the runner: the whole workspace (pf-vdisplay + pf-dualsense + pf-xusb) builds with CARGO_TARGET_DIR=C:\t set, and build-gamepad-drivers.ps1 produces signed pf_dualsense.{dll,inf,cat} + pf_xusb.{dll,inf,cat} + the .cer. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 15:08:40 +00:00