summaryrefslogtreecommitdiffstats
path: root/kernel/main.c
diff options
context:
space:
mode:
authorArthur Hanson Rasmusson <arthur@vgpu.io>2026-10-20 19:57:34 -0400
committerArthur Hanson Rasmusson <arthur@vgpu.io>2026-10-20 19:57:34 -0400
commitdb0c982b954e4782dff4d22d1673f04edac54770 (patch)
tree300695631c64c32b4250f8231783c0b263d063dd /kernel/main.c
parentf99e6860e963b841baf486348e14c735ea12c010 (diff)
downloadopen-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/main.c')
-rw-r--r--kernel/main.c12
1 files changed, 12 insertions, 0 deletions
diff --git a/kernel/main.c b/kernel/main.c
index be5ff5e..92754d1 100644
--- a/kernel/main.c
+++ b/kernel/main.c
@@ -2832,6 +2832,18 @@ module_param_named(sema_wait_gate, gsp_sema_wait_gate, bool, 0644);
MODULE_PARM_DESC(sema_copy_dst_pin_guard, "hold device-dst copies without a pin-resolved translation (default 1)");
/*
+ * r384 (guest boot-corruption lottery): fill-destination guards. A large
+ * virtual fill whose only authority is the walk/scan resolver is held for
+ * gsp_sema_fill_guard_ms while its VA is demanded through the pin channel
+ * (fail-open, mirrors sema_copy_dst_pin_guard); a zero fill targeting a
+ * page-table-shaped guest page is refused loudly (FILL-PT-REFUSED).
+ */
+module_param_named(sema_fill_guard, gsp_sema_fill_guard, bool, 0644);
+MODULE_PARM_DESC(sema_fill_guard, "guard virtual fill destinations (pin-demand hold + page-table-shape refusal, default 1)");
+module_param_named(sema_fill_guard_ms, gsp_sema_fill_guard_ms, uint, 0644);
+MODULE_PARM_DESC(sema_fill_guard_ms, "fill pin-demand hold window in ms (default 800)");
+
+/*
* r231 READ-ORDER guard: defer a device-src copy whose source VA has a
* pending device-dst write hold so the read re-decodes after the write
* resolves (fixes the ctaid_probe RAWA upload/readback inversion).