Walkthrough

Broaden the WDDM/WSL2 placeholder denylist to JMJWOA-Generic-*, add a Linux /proc/driver/nvidia kernel-interface check, and make detectGpu() early-reject probes with denylisted names or missing kernel driver when firmware doesn't vouch; update tests and docs to cover these gates and unified-memory fallback paths.

Changes

NVIDIA placeholder hardening

Sequence Diagram(s)

sequenceDiagram
  participant Client as detectGpu()
  participant SMI as nvidia-smi
  participant FW as firmware detection
  participant Kernel as nvidiaHostLooksGenuine()
  Client->>SMI: run nvidia-smi probe (parse rows)
  SMI-->>Client: CSV rows / names
  Client->>FW: is platform vouched? (spark/station/jetson)
  FW-->>Client: vouched | unvouched
  alt unvouched
    Client->>Kernel: check /proc/driver/nvidia on linux/arm64
    Kernel-->>Client: present | absent
    Client->>Client: if any row matches denylist -> return null
  else vouched
    Client->>Client: bypass denylist/kernel gate, apply plausibility filter
  end

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

• NVIDIA/NemoClaw#4062: Similar changes expanding JMJWOA-Generic-* denylist and adding kernel-interface early-reject logic; overlaps in detection logic and tests.

Suggested labels

Platform: Windows/WSL, v0.0.53

Suggested reviewers

• ericksoa

Poem

🐰 I sniff the names beneath system logs so wide,
I hop through kernels to see if drivers hide.
Placeholders tremble when my regex is near,
Real cards step forward, the fakes disappear.
I nibble tests and docs until the logic’s clear.

❌ Failed checks (1 warning)

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

E2E Recommendation Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required E2E

• gpu-e2e (high): Validates the highest-risk runtime path changed by this PR: a real NVIDIA GPU host is still trusted, onboard enables GPU/local Ollama flow, sandbox creation succeeds, and inference works through the sandbox.
• cloud-onboard-e2e (medium): Validates standard Ubuntu cloud onboarding on a non-GPU runner after the preflight/GPU-detection changes, including sandbox health and security checks with GPU passthrough left disabled unless a trusted GPU is found.

Optional E2E

• gpu-double-onboard-e2e (high): Additional confidence that repeated GPU-provider onboarding still handles GPU detection, gateway/sandbox reuse, and local Ollama proxy state consistently after the trust-gate refactor.
• issue-3600-gpu-proof-optional-e2e (low): Adjacent GPU preflight guard that checks optional direct sandbox GPU proof handling; useful because this PR changes sandbox GPU preflight behavior, but it does not exercise the new nvidia-smi trust decision end-to-end.
• wsl-repo-cloud-openclaw (high): Adjacent WSL onboarding scenario because the motivating spoof source is WSL-related. Current runner is Windows/x64 and is unlikely to reproduce Windows-on-ARM nvidia-smi spoofing, so this is confidence-only rather than merge-blocking.

New E2E recommendations

• gpu-detection-trust-security-boundary (high): No existing E2E appears to exercise an ARM64 Linux or Windows-on-ARM WSL environment where nvidia-smi emits JMJWOA-Generic-* while /proc/driver/nvidia is absent. Unit tests cover this, but the user-visible safety boundary is onboarding preflight and sandbox GPU passthrough suppression.
  • Suggested test: Add a hermetic E2E negative preflight spoof test that injects a fake nvidia-smi returning JMJWOA-Generic-* on simulated ARM64 Linux with generic firmware and no /proc/driver/nvidia, then asserts nemoclaw onboard reports no trusted NVIDIA GPU and does not pass gateway/sandbox GPU flags.
• jetson-tegra-gpu-fallback (medium): The trust gate intentionally bypasses Jetson/Tegra firmware and device-node fallback paths, but there is no clear E2E coverage proving hosts without nvidia-smi still onboard with NVIDIA unified-memory GPU detection.
  • Suggested test: Add an E2E or scenario fixture for Jetson/Tegra-style preflight that stubs devicetree/device-node detection without nvidia-smi and verifies sandbox GPU config remains in the intended auto/Jetson mode.

Dispatch hint

• Workflow: .github/workflows/nightly-e2e.yaml
• jobs input: gpu-e2e,cloud-onboard-e2e

E2E Scenario Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required scenario E2E

• gpu-repo-local-ollama-openclaw: Changes affect NVIDIA GPU trust/detection and NIM GPU handling; this is the only routed scenario with a real NVIDIA GPU/CDI runner and local Ollama GPU inference coverage.
  • Dispatch: gh workflow run e2e-scenarios.yaml --ref <pr-head-ref> --field scenarios=gpu-repo-local-ollama-openclaw
• ubuntu-repo-cloud-openclaw: Exercises the standard repo onboarding/preflight path on Ubuntu and helps catch regressions in default cloud onboarding after the GPU detection/preflight changes.
  • Dispatch: gh workflow run e2e-scenarios.yaml --ref <pr-head-ref> --field scenarios=ubuntu-repo-cloud-openclaw

Optional scenario E2E

• wsl-repo-cloud-openclaw: Adjacent coverage for WSL onboarding, relevant because the change targets Windows-on-ARM/WSL-style nvidia-smi shim false positives, though the routed WSL runner is a special platform scenario and not the primary GPU path.
  • Dispatch: gh workflow run e2e-scenarios.yaml --ref <pr-head-ref> --field scenarios=wsl-repo-cloud-openclaw

Relevant changed files

• src/lib/inference/gpu-trust.ts
• src/lib/inference/nim.ts

🛠️ Needs attention

• N1X acceptance is still not proven at the user-facing preflight boundary (src/lib/onboard/machine/handlers/preflight.test.ts:82): The linked issue is about `nemoclaw onboard` preflight printing `✓ NVIDIA GPU detected` for Snapdragon/N1X hardware and then proceeding down GPU/CDI paths as though NVIDIA hardware exists. This PR now has strong `detectGpu()` unit coverage and a handler-level test showing that a mocked null GPU disables sandbox GPU, but it still does not assert the real `onboard.ts` preflight output and sandbox GPU decision for the N1X spoof fixture.
  • Recommendation: Add a targeted preflight-level regression that feeds the N1X `nvidia-smi`/generic-firmware/no-`/proc/driver/nvidia` fixture through the actual preflight output path and asserts that `✓ NVIDIA GPU detected` is absent, the no-GPU or GPU-disabled line is present, CDI/GPU passthrough is opted out, and sandbox GPU remains disabled unless explicitly requested.
  • Evidence: Issue [WSL2][Onboard] preflight false-positive: Snapdragon iGPU reported as "NVIDIA GPU detected" on Windows ARM #3988 says reporting `✓ NVIDIA GPU detected` for `JMJWOA-Generic-GPU` is wrong and misleading. The diff adds `nimModule.detectGpu()` rejection tests and a `handlePreflightState` test with `runPreflight: vi.fn(async () => null)`, while `src/lib/onboard.ts` still owns `formatNvidiaGpuPreflightLines()`, `Local NIM unavailable — no GPU detected`, and `Sandbox GPU` output.

🔎 Worth checking

• Generic x86_64 Linux still trusts plausible nvidia-smi names without a driver signal (src/lib/inference/gpu-trust.ts:45): The new trust gate intentionally keeps historical behavior for non-ARM64 Linux by returning true before checking `/proc/driver/nvidia`. That addresses the observed WoA/ARM64 shim, but on generic x86_64 Linux or WSL a spoofed or shimmed `nvidia-smi` that returns a plausible NVIDIA product name can still enable gateway/sandbox GPU passthrough without an independent kernel-driver signal.
  • Recommendation: Either require an additional real-driver signal for generic Linux/WSL before enabling GPU passthrough, or explicitly accept this as a security tradeoff and add a negative regression for any x86_64 spoof shape that should be rejected. Keep the current denylist as a universal reject.
  • Evidence: `nvidiaHostLooksGenuine()` returns true when `process.arch !== "arm64"`, and the test `trusts x86_64 generic firmware even when /proc/driver/nvidia/ is absent` locks in the permissive behavior.
• Inference test monolith grows substantially (src/lib/inference/nim.test.ts:1): The already-large NIM inference test file gains another broad GPU spoofing and compatibility matrix, including process platform/architecture monkeypatching and fs monkeypatching. Keeping primary trust checks, unified-memory fallback checks, Spark regression guards, and unrelated NIM tests together makes future security-sensitive regressions harder to review.
  • Recommendation: Move the GPU spoofing, generic-firmware, ARM64 kernel-interface, and unified-memory fallback cases into a focused GPU detection test file, or extract shared fixtures/helpers and offset the growth so `nim.test.ts` does not keep expanding.
  • Evidence: Deterministic monolith analysis reports `src/lib/inference/nim.test.ts` baseLines 1361, headLines 1698, delta +337. Although `gpu-trust.test.ts` was added, most new detection matrix coverage remains in `nim.test.ts`.

🌱 Nice ideas

• None.

Current findings:

• N1X acceptance is still not proven at the user-facing preflight boundary (src/lib/onboard/machine/handlers/preflight.test.ts:82): The linked issue is about `nemoclaw onboard` preflight printing `✓ NVIDIA GPU detected` for Snapdragon/N1X hardware and then proceeding down GPU/CDI paths as though NVIDIA hardware exists. This PR now has strong `detectGpu()` unit coverage and a handler-level test showing that a mocked null GPU disables sandbox GPU, but it still does not assert the real `onboard.ts` preflight output and sandbox GPU decision for the N1X spoof fixture.
  • Recommendation: Add a targeted preflight-level regression that feeds the N1X `nvidia-smi`/generic-firmware/no-`/proc/driver/nvidia` fixture through the actual preflight output path and asserts that `✓ NVIDIA GPU detected` is absent, the no-GPU or GPU-disabled line is present, CDI/GPU passthrough is opted out, and sandbox GPU remains disabled unless explicitly requested.
  • Evidence: Issue [WSL2][Onboard] preflight false-positive: Snapdragon iGPU reported as "NVIDIA GPU detected" on Windows ARM #3988 says reporting `✓ NVIDIA GPU detected` for `JMJWOA-Generic-GPU` is wrong and misleading. The diff adds `nimModule.detectGpu()` rejection tests and a `handlePreflightState` test with `runPreflight: vi.fn(async () => null)`, while `src/lib/onboard.ts` still owns `formatNvidiaGpuPreflightLines()`, `Local NIM unavailable — no GPU detected`, and `Sandbox GPU` output.
• Generic x86_64 Linux still trusts plausible nvidia-smi names without a driver signal (src/lib/inference/gpu-trust.ts:45): The new trust gate intentionally keeps historical behavior for non-ARM64 Linux by returning true before checking `/proc/driver/nvidia`. That addresses the observed WoA/ARM64 shim, but on generic x86_64 Linux or WSL a spoofed or shimmed `nvidia-smi` that returns a plausible NVIDIA product name can still enable gateway/sandbox GPU passthrough without an independent kernel-driver signal.
  • Recommendation: Either require an additional real-driver signal for generic Linux/WSL before enabling GPU passthrough, or explicitly accept this as a security tradeoff and add a negative regression for any x86_64 spoof shape that should be rejected. Keep the current denylist as a universal reject.
  • Evidence: `nvidiaHostLooksGenuine()` returns true when `process.arch !== "arm64"`, and the test `trusts x86_64 generic firmware even when /proc/driver/nvidia/ is absent` locks in the permissive behavior.
• Inference test monolith grows substantially (src/lib/inference/nim.test.ts:1): The already-large NIM inference test file gains another broad GPU spoofing and compatibility matrix, including process platform/architecture monkeypatching and fs monkeypatching. Keeping primary trust checks, unified-memory fallback checks, Spark regression guards, and unrelated NIM tests together makes future security-sensitive regressions harder to review.
  • Recommendation: Move the GPU spoofing, generic-firmware, ARM64 kernel-interface, and unified-memory fallback cases into a focused GPU detection test file, or extract shared fixtures/helpers and offset the growth so `nim.test.ts` does not keep expanding.
  • Evidence: Deterministic monolith analysis reports `src/lib/inference/nim.test.ts` baseLines 1361, headLines 1698, delta +337. Although `gpu-trust.test.ts` was added, most new detection matrix coverage remains in `nim.test.ts`.