diff options
| author | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-20 19:57:34 -0400 |
|---|---|---|
| committer | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-20 19:57:34 -0400 |
| commit | db0c982b954e4782dff4d22d1673f04edac54770 (patch) | |
| tree | 300695631c64c32b4250f8231783c0b263d063dd /kernel/gsp_sema_service.h | |
| parent | f99e6860e963b841baf486348e14c735ea12c010 (diff) | |
| download | open-iov-db0c982b954e4782dff4d22d1673f04edac54770.tar.gz open-iov-db0c982b954e4782dff4d22d1673f04edac54770.zip | |
sema: r384 fill-destination guards - pin-demand hold for large unproven fills + page-table-shape refusal for zero fills (the boot-corruption lottery root-caused to zero writes landing on guest page-table pages)
Forensics from the r383 boot (guest panic at t=216 during victory_strided):
the guest kernel's direct map had TWO 2 MiB holes (phys 0x105000000 and
0x131800000) because their PTE pages at gpa 0x12d3c2000/0x3000 - two
adjacent 4 KiB page-table pages - were found all-zero. Kernel objects
(the kprobe nodes UVM registers at module load) lived in those regions;
the first access after the zeroing faulted (Oops #1 get_kprobe from
uvm_init_entry), cascading to the t=230 panic. The zeroing is an 8 KiB
all-zero write, the exact shape of the guest's window page-table clear
(LINE_LENGTH=8192, value=0), and the emulation's virtual fill resolver
is demonstrably non-deterministic: four executions of that same 8 KiB
fill resolved to four different guest pages (0x126af8000, 0x12d8e4000,
0x12f20c000, 0x1187fb000 - every one refused by the below-floor guard).
The below-floor guard covers window VAs only; a >= 1 TiB VA fill that
resolves through the walk/scan had no guard at all.
Two nets in svc_fill, both default-on (sema_fill_guard=1) and both
fail-open/histed:
- net 1: a >= 64 KiB virtual fill whose only authority is the walk/scan
(no pin, no landing-table entry) is held through a bounded 800 ms
window (sema_fill_guard_ms) while its VA is demanded through the pin
channel (the userspace pin stream injects the guest-pagemap truth), so
the retried decode resolves through a real pin. Mirrors the m169/r378
copy guards; releases with the historical behaviour after the bound.
- net 2: a ZERO fill about to land in guest RAM on a page whose first 64
qwords are all present+NX+in-range PTEs is REFUSED loudly
(FILL-PT-REFUSED) - a page table page is never a legitimate zero-fill
destination. Pin-backed resolutions are exempt (guest pagemap truth).
New witnesses: FILL-HOLD (held fills) and FILL-PT-REFUSED (refused
page-table targets), both bounded.
Diffstat (limited to 'kernel/gsp_sema_service.h')
| -rw-r--r-- | kernel/gsp_sema_service.h | 10 |
1 files changed, 10 insertions, 0 deletions
diff --git a/kernel/gsp_sema_service.h b/kernel/gsp_sema_service.h index 0f47244..063ed5c 100644 --- a/kernel/gsp_sema_service.h +++ b/kernel/gsp_sema_service.h @@ -312,6 +312,16 @@ extern bool gsp_sema_copy_dst_pin_guard; extern bool gsp_sema_wait_gate; /* + * r384 (guest boot-corruption lottery): fill-destination guards (default + * on). Large virtual fills whose only authority is the walk/scan resolver + * are held through a short bounded window while their VA is demanded + * through the pin channel (fail-open after gsp_sema_fill_guard_ms); zero + * fills targeting a page-table-shaped guest page are refused loudly. + */ +extern bool gsp_sema_fill_guard; +extern unsigned gsp_sema_fill_guard_ms; + +/* * r231 READ-ORDER guard (default 0: witness only). Defer a device-src copy * whose source VA has a pending device-dst write hold (READ-ORDER-WIT) so * the read re-decodes after the write resolves. Opt-in pending an A/B. |
