[BUG] Query canary fixture assumes identical direct and scheduled entry stacks #16

New issue

Closed

opened 2026-09-17 13:34:18 +02:00 by erikinkinen · 0 comments

erikinkinen commented

2026-09-17 13:34:18 +02:00

Owner

Summary

The newly added query canary fixture in Kernel a2b13de0d51387e9175035f6e191d3f2961cd70e faults when its second process first runs. Its expected stack address assumes the direct entry route for every participant, but ordinary initial scheduler resume reserves an eight-byte synthetic return slot. This is a diagnostic fixture defect; the retained failure does not establish corruption by the capability query.

Reproduction

Build the isolated owned-invocation kernel with the matching diagnostic dependency graph. Use the corrected explicit-catalog manifest preparation described in Integration issue 59, then run scripts/run-native-kernel-vm.sh invocation. The first real QEMU attempt reaches OWNED_INVOCATION_BEGIN, then faults at the caller's first query stack comparison.

Expected and actual behavior

Expected: the diagnostic explicitly selects a valid private stack interval before installing canaries, and every subsequent query preserves its selected RSP and live stack words.

Actual: user UD2 at 0x51000228, with RSP 0x51033f78 instead of the assumed 0x51033f80. QEMU exits 37 instead of 33; OWNED_INVOCATION_OK is absent. The exact checks correctly fail. Source inspection identifies the initial resume function's synthetic eight-byte return slot; the directly entered first process does not use that resume path.

Environment and identity

Kernel: a2b13de0d51387e9175035f6e191d3f2961cd70e; Integration base: df8147dfa437194cd091747fd7147941bd2793c4 plus the explicit-catalog preparation repair under review.
x86-64, release, one TCG CPU, unchanged 60-second scenario deadline. Boot image SHA-256: 9b96d71906d2fcc449e850289237c90318efda1c42358205a0459942914cc85f. Kernel ELF SHA-256: 6cc07895aa9dbed03a1859090a27b49e2061a933e9e90c97d74f5ca45ed6a35d.
Rust 1.97.1; actual private CSpaces and VSpaces; no additional fixture capability grants.
The new query checks were absent from the preceding diagnostic. Both automatic kernel CI runs 576 and 577 pass their host/native build suites; they do not execute this isolated scenario.

Evidence and prior checks

The complete first serial log, boot image, kernel, EFI executable, variable store and original exit/cleanup status are retained. Kernel artifact checks and boot authentication succeed before the controlled user comparison faults. No unchanged VM retry is accepted as evidence.

Initialize RSP explicitly to the fixture-owned stack top before reserving its live canary interval. Keep the same exact RSP, GP, metadata and memory comparisons after every query, together with all preceding invocation assertions. This tests preservation across a syscall without guessing each participant's entry convention. Rebuild from a new signed kernel revision and run invocation plus lifetime regressions under their original budgets.

Caller-local query checkpoint — 17 September 2026: Corrected in signed Kernel e15a045d7701030e58d9e59517406f8c79694ff8. The complete strict matrix, original CI 578/579 and matching query/invocation plus lifetime VMs pass. Every post-query assertion and original 60-second deadline remains; the initial failing image and status are retained. This closes the fixture-entry defect only.

Tracking

Owning review: #3. Caller-local query design: #1. The independent packaging regression is erix/integration#59. Runtime acceptance remains incomplete until the corrected selected image passes.

## Summary The newly added query canary fixture in Kernel `a2b13de0d51387e9175035f6e191d3f2961cd70e` faults when its second process first runs. Its expected stack address assumes the direct entry route for every participant, but ordinary initial scheduler resume reserves an eight-byte synthetic return slot. This is a diagnostic fixture defect; the retained failure does not establish corruption by the capability query. ## Reproduction Build the isolated owned-invocation kernel with the matching diagnostic dependency graph. Use the corrected explicit-catalog manifest preparation described in Integration issue 59, then run `scripts/run-native-kernel-vm.sh invocation`. The first real QEMU attempt reaches `OWNED_INVOCATION_BEGIN`, then faults at the caller's first query stack comparison. ## Expected and actual behavior Expected: the diagnostic explicitly selects a valid private stack interval before installing canaries, and every subsequent query preserves its selected RSP and live stack words. Actual: user UD2 at `0x51000228`, with RSP `0x51033f78` instead of the assumed `0x51033f80`. QEMU exits 37 instead of 33; `OWNED_INVOCATION_OK` is absent. The exact checks correctly fail. Source inspection identifies the initial resume function's synthetic eight-byte return slot; the directly entered first process does not use that resume path. ## Environment and identity - Kernel: `a2b13de0d51387e9175035f6e191d3f2961cd70e`; Integration base: `df8147dfa437194cd091747fd7147941bd2793c4` plus the explicit-catalog preparation repair under review. - x86-64, release, one TCG CPU, unchanged 60-second scenario deadline. Boot image SHA-256: `9b96d71906d2fcc449e850289237c90318efda1c42358205a0459942914cc85f`. Kernel ELF SHA-256: `6cc07895aa9dbed03a1859090a27b49e2061a933e9e90c97d74f5ca45ed6a35d`. - Rust 1.97.1; actual private CSpaces and VSpaces; no additional fixture capability grants. - The new query checks were absent from the preceding diagnostic. Both automatic kernel CI runs 576 and 577 pass their host/native build suites; they do not execute this isolated scenario. ## Evidence and prior checks The complete first serial log, boot image, kernel, EFI executable, variable store and original exit/cleanup status are retained. Kernel artifact checks and boot authentication succeed before the controlled user comparison faults. No unchanged VM retry is accepted as evidence. Initialize RSP explicitly to the fixture-owned stack top before reserving its live canary interval. Keep the same exact RSP, GP, metadata and memory comparisons after every query, together with all preceding invocation assertions. This tests preservation across a syscall without guessing each participant's entry convention. Rebuild from a new signed kernel revision and run invocation plus lifetime regressions under their original budgets. Caller-local query checkpoint — 17 September 2026: Corrected in signed Kernel `e15a045d7701030e58d9e59517406f8c79694ff8`. The complete strict matrix, original CI 578/579 and matching query/invocation plus lifetime VMs pass. Every post-query assertion and original 60-second deadline remains; the initial failing image and status are retained. This closes the fixture-entry defect only. ## Tracking Owning review: https://git.erikinkinen.fi/erix/kernel/pulls/3. Caller-local query design: https://git.erikinkinen.fi/erix/kernel/issues/1. The independent packaging regression is https://git.erikinkinen.fi/erix/integration/issues/59. Runtime acceptance remains incomplete until the corrected selected image passes.

erikinkinen

2026-09-17 13:34:18 +02:00