Skip to content

vms-f49: rung 4 — un-fakeable ODS-2 independent-reader proof (+ vms-1fc LLP64 width fix) - #1063

Open
baron-3dl wants to merge 11 commits into
mainfrom
work/vms-f49-alpha-ods2-proof
Open

vms-f49: rung 4 — un-fakeable ODS-2 independent-reader proof (+ vms-1fc LLP64 width fix)#1063
baron-3dl wants to merge 11 commits into
mainfrom
work/vms-f49-alpha-ods2-proof

Conversation

@baron-3dl

@baron-3dl baron-3dl commented Sep 7, 2026

Copy link
Copy Markdown
Contributor

Lands the MILESTONE of the vms-b4f ladder: proves the alpha-dec-vms GCC-port image's CRTL fopen genuinely writes to a real Files-11 ODS-2 volume over the executive ACP — not musl-ramfs. The anti-fabrication payoff (INV-6). Two coupled items in one PR, because the width fix is validated by the proof.

Part A — vms-1fc: LLP64 syscall width fix

On the alpha-dec-vms C model long/unsigned long are 32 bits while pointers are 64 (LLP64), so the libvmssys raw-syscall path truncated every pointer passed to the /dev/vms transport — ioctl(/dev/vms, …, &kif_request) landed on a garbage address and the RMS-over-ACP write reached nothing.

  • vms_syscall.h: widen __vms_syscall0..6 params+return to a guaranteed-64-bit vms_reg_t (== long long) and the vms_sys_* pointer casts with it; widen vms_sys_ioctl's arg param from unsigned long → vms_reg_t.
  • arch/alpha/syscall_vms.c: match the widened prototypes.
  • kif_transport_linux.c: cast the request-block pointer through vms_reg_t, not unsigned long — THIS is the /dev/vms pointer the proof exercises.
  • vms_bgsock.c: widen its ioctl pointer casts to match.

No-op on the LP64 targets (x86_64/aarch64/alpha-linux-gnu: long long == long, byte-identical codegen); the actual fix only on alpha-dec-vms. VAX untouched by construction — it takes the __NetBSD__ branch and compiles none of these declarations.

Part B — vms-f49: rung 4, the un-fakeable gate

New crtl-rms-veneer-gate mode boots the veneer-wired crtl_rms port image (JOINT_CRTL_RMS_VENEER=1) on the real /dev/vms + qemu-system-alpha; its decc$fopen → veneer → sys$create/$put → LIBVMSRMS$SHR → ioctl(/dev/vms) → ACP writes PORTTEST.DAT. Then an INDEPENDENT reader — DCL DIRECTORY/FULL, a different accessor than the writer's CRTL/RMS handle, running its own sys$search over the ACP directory — asserts PORTTEST.DAT;1 exists on the ODS-2 volume with a genuine ODS-2 File ID a ramfs write cannot produce.

  • SYSTARTUP_VMS_VENEER_PROOF.COM: RUN JOINT_E2E, then DIRECTORY/FULL PORTTEST.DAT.
  • build-alpha-bootimage.sh: stage LIBVMSRMS$SHR.EXE into SYS$SHARE + swap in the veneer-proof SYSTARTUP when a veneer build is present; verify on the mastered volume.
  • assert_veneer(): gates on the independent File-ID reader, not console/CRTL state; a can-fail selftest proves teeth incl. the NEGATIVE/REJECTION case — a same-CRTL success that ramfs satisfies (%DIRECT-W-NOFILES) must FAIL.
  • ci.yml: new PR job alpha-crtl-rms-veneer (alpha_activation scope, 150m). The non-veneer alpha-crtl-rms-n7 gate stays green as the control.

Local verification (buildable part)

  • Veneer graph links zero-deferred under the alpha-dec-vms cc1 with the width fix (decc$fopen→DECC$SHR, veneer sys$create/$put/$get→LIBVMSRMS$SHR), LIBVMSRMS$SHR.EXE emitted.
  • Part A recompiles clean on x86_64 with -Wall -Wextra; vms_reg_t is 64-bit.
  • assert_veneer selftest passes all six fixtures (good passes; ramfs / no-fid / zero-fid / wrong-sentinel / crash all red).

The qemu-alpha runtime proof runs in CI (alpha-crtl-rms-veneer) — that is what validates Part A end-to-end.

🤖 Generated with Claude Code

@baron-3dl baron-3dl mentioned this pull request Sep 7, 2026
Merged
baron-3dl and others added 9 commits September 7, 2026 22:00
@baron-3dl @claude
vms-f49: rung 4 — un-fakeable ODS-2 independent-reader proof + vms-1f…
8f9bb5f 
…c LLP64 width fix

Lands the MILESTONE of the vms-b4f ladder: prove the alpha-dec-vms GCC-port
image's CRTL fopen genuinely writes to a real Files-11 ODS-2 volume over the
executive ACP, not musl-ramfs — the anti-fabrication payoff (INV-6). Two
coupled items in one PR, because the width fix is VALIDATED by the proof.

PART A — vms-1fc (LLP64 syscall width fix). On the alpha-dec-vms C model
`long`/`unsigned long` are 32 bits while pointers are 64 (LLP64), so the
libvmssys raw-syscall path truncated every pointer argument to the /dev/vms
transport — the ioctl(/dev/vms, ...) RMS-over-ACP write landed on a garbage
address and reached nothing.
  - vms_syscall.h: widen __vms_syscall0..6 params + return to a guaranteed-
    64-bit `vms_reg_t` (== long long), and the vms_sys_* pointer casts with it;
    widen vms_sys_ioctl's `arg` param from `unsigned long` to vms_reg_t.
  - arch/alpha/syscall_vms.c: match the widened prototypes (long long).
  - kif_transport_linux.c: cast the request-block pointer through vms_reg_t,
    not `unsigned long` — THIS is the /dev/vms pointer the proof exercises.
  - vms_bgsock.c: widen its ioctl pointer casts to match.
  No-op on the LP64 targets (x86_64/aarch64/alpha-linux-gnu: long long == long,
  byte-identical codegen); the actual fix only on alpha-dec-vms. VAX is
  untouched by construction — it takes the __NetBSD__ branch
  (arch/vax/vms_syscall_netbsd.h) and compiles none of these declarations.

PART B — vms-f49 (rung 4, the un-fakeable gate). New `crtl-rms-veneer-gate`
mode of run-module-gp-activation-alpha.sh boots the veneer-wired crtl_rms port
image (JOINT_CRTL_RMS_VENEER=1) on the real /dev/vms + qemu-system-alpha; its
decc$fopen -> the crtl_rms_stdio veneer -> sys$create/$put -> LIBVMSRMS$SHR ->
ioctl(/dev/vms) -> ACP writes PORTTEST.DAT. Then an INDEPENDENT reader — DCL
DIRECTORY/FULL, a DIFFERENT accessor than the writer's CRTL/RMS handle, running
its own sys$search over the ACP directory — asserts PORTTEST.DAT;1 exists on the
ODS-2 volume with a genuine ODS-2 File ID that a ramfs write cannot produce.
  - SYSTARTUP_VMS_VENEER_PROOF.COM: RUN JOINT_E2E, then DIRECTORY/FULL PORTTEST.DAT.
  - build-alpha-bootimage.sh: stage LIBVMSRMS$SHR.EXE into SYS$SHARE and swap in
    the veneer-proof SYSTARTUP when a veneer build is present (keyed on the
    shareable), verify it on the mastered volume.
  - assert_veneer(): gates on the independent File-ID reader, NOT console/CRTL
    state; a can-fail selftest proves teeth incl. the NEGATIVE/REJECTION case —
    a same-CRTL success that ramfs satisfies (%DIRECT-W-NOFILES) must FAIL.
  - ci.yml: new PR job alpha-crtl-rms-veneer (alpha_activation scope, 150m). The
    non-veneer alpha-crtl-rms-n7 gate stays green as the control.

Local build+link verified: the veneer graph links zero-deferred under the
alpha-dec-vms cc1 with the width fix (decc$fopen->DECC$SHR, veneer
sys$create/$put/$get->LIBVMSRMS$SHR), LIBVMSRMS$SHR.EXE emitted; assert_veneer
selftest passes all six fixtures. The qemu-alpha runtime proof runs in CI.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FJZf62TMXxvy6fXzFQYfLQ
@baron-3dl @claude
vms-f49: fix apostrophe quote-break in build-alpha-bootimage.sh stagi…
3af4412 
…ng block

The vms-f49 staging comments landed inside the assemble `docker run ... bash -c
'...'` SINGLE-QUOTED block with apostrophes ("image's"), which closed the quote
mid-body and exposed `decc$fopen` to the outer shell -> `line 91: fopen: unbound
variable` under `set -u`. This broke the boot-image assembly for EVERY alpha
activation gate that calls assemble_boot_image (gate/crtl-rms-gate/mf-gate/
crtl-rms-veneer-gate), before any qemu boot -- NOT a Part A regression (all three
reds died at the identical line-91 quote-break after "step 1 staged", pre-boot;
Part A links clean, proven by the green alpha RMS-substrate STRICT-link + DECC$SHR
jobs). The script's own header warns "no apostrophes in this block". Reworded the
two added comments apostrophe-free; verified the docker -c body now has balanced
single-quotes with zero outer-shell `$` exposure.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FJZf62TMXxvy6fXzFQYfLQ
@baron-3dl @claude
vms-f49: stage the full RMS producer graph + fix its DECC producer na…
ac2d721 
…me (rung-4 activation)

The rung-4 veneer gate booted this time (N=7 control PASSED -> Part A width fix
does NOT regress alpha activation) but the veneer image RUN drew
%IMGACT-F-IMGNOTFND: LIBVMSRMS$SHR is not self-contained. It transitively imports
from the whole executive producer graph (LIBVMS/LIBVMSFS/LIBVMSLNM/LIBVMSPROCESS/
LIBVMSSYS$SHR) AND recorded its DECC producer as the phantom pass-1 bootstrap name
"DECC1$SHR.EXE" -- neither on SYS$SHARE, so IMGACT could not resolve them.

Two in-scope Part-B wiring fixes (no new executive facility):
 - build-joint-image.sh: build the pass-1 bootstrap DECC under $WORK/p1 with the
   BASENAME DECC$SHR.EXE (not DECC1$SHR.EXE). LINK records producers by basename,
   so the graph + LIBVMSRMS$SHR now record "DECC$SHR.EXE" and, at activation,
   IMGACT name-keyed binding resolves them against the SINGLE staged pass-2
   (veneer) DECC$SHR.EXE (GSMATCH LEQUAL). One DECC$SHR at runtime, no duplicate
   musl C-RTL. Also emit the whole producer graph to OUTDIR.
 - run-module-gp-activation-alpha.sh + build-alpha-bootimage.sh: stage the full
   graph (LIBVMSRMS/LIBVMS/LIBVMSFS/LIBVMSLNM/LIBVMSPROCESS/LIBVMSSYS$SHR) into
   SYS$SHARE and verify each on the mastered ODS-2 volume.

Also fixes a second single-quote apostrophe break ("IMGACT's", and 'DECC$SHR.EXE'
exposing $SHR) in the build-joint-image.sh docker bash -c block.

Local verify: veneer graph links zero-deferred; LIBVMSRMS$SHR + all 7 sibling
shareables now record DECC$SHR.EXE (grep DECC1 = 0 across the whole staged set);
full graph emitted to OUTDIR. Runtime activation runs in CI.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FJZf62TMXxvy6fXzFQYfLQ
@baron-3dl @claude
vms-f49: surface the guest-kernel faulting PC in the veneer-gate fail…
41f9e00 
…ure output

The veneer image now activates (producer graph staged) but SIGSEGVs
(%DCL-F-ABORT signal 11) in the first-ever runtime execution of the alpha RMS
substrate over the veneer. The Alpha guest kernel prints the faulting user
PC/RA/VA to the console at fault time, but the gate's fixed pattern-grep never
surfaced it. Dump the guest fault-signature line(s) + the last 60 console lines
in the veneer-gate FAIL path so the authoritative fault PC is captured in CI
(disk-safe -- no qemu -d flags; the guest kernel already emitted it). This
localizes the crash so it can be fixed. Not a gate weakening -- failure path only.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FJZf62TMXxvy6fXzFQYfLQ
@baron-3dl @claude
vms-f49: capture qemu CPU-exception log to pin the veneer SIGSEGV fau…
c99fdae 
…lting PC

The previous fault-capture confirmed the veneer image crashes at/near ACTIVATION
(no OVMX-CRTL-RMS sys$create trace precedes the %DCL-F-ABORT signal 11), and the
Alpha guest kernel prints no userspace fault line. So add qemu exception logging
(-d int,cpu_reset,guest_errors -D /work/qint.log), enabled ONLY for the
crtl-rms-veneer-gate via QEMU_DBG, and dump the last exceptions (faulting PC/VA)
in the veneer FAIL path. Disk-safe: the boot reaches Username: within ~30-60s so
qint.log stays small; other gates pass QEMU_DBG empty (unchanged). This is the
gdb-equivalent authoritative fault PC needed to decide RMS-substrate truncation
(hyp 1) vs IMGACT mutual-producer-cycle activation crash (hyp 2, the leading
hypothesis: the veneer DECC$SHR<->LIBVMSRMS$SHR cycle the non-veneer control lacks).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FJZf62TMXxvy6fXzFQYfLQ
@baron-3dl @claude
vms-f49: filter qemu exception log (clk-interrupt firehose hid the fa…
ba562f5 
…ult)

The -d int log is dominated by clk_interrupt; the veneer SIGSEGV's Dfault/MMFAULT
exception with the faulting user pc= is buried. Filter out clk/dev interrupts and
add an exception-type histogram so the fault exception + PC is surfaced.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FJZf62TMXxvy6fXzFQYfLQ
@baron-3dl @claude
vms-f49: IMGACT-MAP producer base logging to resolve the veneer fault PC
e55e5df 
The qemu -d int log localized the veneer SIGSEGV to a repeated mmfault loop at
user pc=0x12005eb00 (and 0x12005a7f4). IMGACT is only ~37KB so the fault is in a
mmap'd producer (likely DECC$SHR, which holds the veneer ovmx_crtl_fopen). Print
each producer's runtime base (IMGACT-MAP: <name> base=0x..) at load so the
faulting pc can be resolved to <image>+offset and then to a symbol. Diagnostic
only; other gates grep their own patterns so the extra lines are inert.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FJZf62TMXxvy6fXzFQYfLQ
@baron-3dl @claude
vms-f49: log MAIN-EXE + IMGACT-INTERP bases to place the 0x120000000 …
bd2d456 
…fault region

Producer bases are all 0x20000xxxxx, but the veneer fault PCs cluster in the
0x120000000 range (0x12005eb00 repeated 18x = the unrecoverable fault; other
single-hit pcs are benign TLB fills). Log the kernel-mapped main-exe bias and the
PT_INTERP (IMGACT) base so the faulting region can be attributed to the main
image, the interp, or an unmapped bad-jump target (mis-resolved cross-image
linkage = hyp 2).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FJZf62TMXxvy6fXzFQYfLQ
@baron-3dl @claude
vms-f49: gate IMGACT-MAP behind OVMX_IMGACT_MAP=1 (silent by default)
261e910 
Housekeeping: the IMGACT-MAP producer-base logging now emits only when the boot
cmdline carries OVMX_IMGACT_MAP=1 (kept for fault-localization, silent in
production). run_boot_a gains an optional QEMU_APPEND injection; the veneer gate
sets QEMU_APPEND=OVMX_IMGACT_MAP=1 so it still gets the map. The QEMU_DBG -d int
fault capture is retained (inert for other gates).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FJZf62TMXxvy6fXzFQYfLQ
@baron-3dl
baron-3dl force-pushed the work/vms-f49-alpha-ods2-proof branch from 7c001f9 to 2ba413f Compare September 7, 2026 22:00
@baron-3dl @claude
vms-f49: Option-1 probe — log wild (0x120000000-region) import bindin…
cfc668d 
…gs in IMGACT

The veneer SIGSEGV jumps to 0x120000000+offset (default/stack-top base) while all
images map at 0x200_xxxx_xxxx; the value is COMPUTED at runtime (not stored). Add
a gated (OVMX_IMGACT_MAP=1) probe in bind_imports that logs any binding whose
resolved PV or filled code entry *(PV+8) lands in the wild region -- with the
importing image, the symbol, the cell, the PV, and the entry. A wild PV isolates
an SV-value fault; a sane PV with a wild entry isolates a producer PDSC-entry
rebase fault. Surface IMGACT-WILD/IMGACT-MAP in the veneer-gate failure dump. If
nothing fires, the wild target is code/GP-computed (not a linkage fill) and the
next step is a register (RA) capture. Probe only; no behavior change.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FJZf62TMXxvy6fXzFQYfLQ
@baron-3dl
baron-3dl force-pushed the work/vms-f49-alpha-ods2-proof branch from 2ba413f to cfc668d Compare September 7, 2026 22:21
@baron-3dl @claude
vms-f49: correct the Option-1 probe wild-region range (0x1_xx, not th…
c177632 
…e 0x200xxx image region)

The probe flagged all valid 0x200_xxxx_xxxx bindings as wild because the upper
bound (0x200000000000) sat above the real image region. Narrow it to
[0x1_0000_0000, 0x100_0000_0000) -- the 0x120000000 default/stack-top region --
so only genuinely-wild values fire. Confirmed against the CI run: with the correct
range NO binding is wild (all PVs/entries resolve to 0x200xxx), proving the veneer
SIGSEGV is NOT a linkage fill but a wrong-base code jump.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FJZf62TMXxvy6fXzFQYfLQ
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@baron-3dl