[Pedro Henrique Penna (ppenna)]

Makes a microVM snapshot's canonical memory-expansion ranges compute without overflowing near the top of the guest-physical address space, for microsoft/nvx#1364. A manifest that declares a base RAM of at least 2^64 - 4 GiB below a larger RAM capacity overflowed an addition when OpenVMM built or checked its machine contract, so opening such a crafted snapshot panicked a debug build with "attempt to add with overflow" before the size check of memory.bin could refuse it. No VM has such RAM, but a manifest can declare it.

One commit on b4028c1aa, the head of feature/microvm/dev. microsoft/nvx#1423 pins this head. It is a draft, at the bottom of a stack of three; see Stack.

Compute memory-expansion ranges without overflow (ac3dc27a7)

• Cause. canonical_memory_expansion_ranges computes the parts of the capacity's RAM layout beyond the base RAM, which memory.bin lacks, when OpenVMM builds a contract and when it checks a contract's shape, as opening a snapshot does. It placed each range at gpa_start + logical_start - file_offset, so for the capacity's high-RAM range, at GPA 4 GiB and memory.bin offset 3 GiB, the addition overflowed whenever the base RAM was at least 2^64 - 4 GiB and below the capacity, although the result, below the range's end, fits. A debug build panicked, and a release build wrapped back to the right address.
• Change. Subtract first: gpa_start + (logical_start - file_offset). The subtraction cannot underflow, since logical_start is at least file_offset, and the sum is below the range's end, which canonical_microvm_memory_ranges has checked fits in a u64. Every range that the old expression computed without overflowing is unchanged.
• Tests. memory_expansion_near_gpa_limit_does_not_overflow requires a base RAM of 2^64 - 4 GiB with a capacity of 2^64 - 2 GiB to expand by one 2 GiB range at GPA 2^64 - 3 GiB, the values that NVX's memory-layout design (doc/design/2.3-memory-layout.md) gives, the shape check to accept the manifest whose contract records it, and a restore to the capacity to select it. Without the fix, it panics with "attempt to add with overflow" at microvm.rs:913:24, on Windows and Linux. A contract-builder test would need a full command line and reaches the same helper, so there is none.

Validation

At this head, ac3dc27a7, with Rust 1.97.1. It is the commit that NVX's phase-1 validation tested, 78085e3c6 on 154548a0e, rebased onto b4028c1aa; git range-diff shows the patch identical.

• Windows: cargo nextest run --profile agent -p openvmm_helpers, 127 passed; cargo clippy --all-targets -p openvmm_helpers and cargo doc --no-deps -p openvmm_helpers, without warnings.
• Linux (NVX's KVM test VM, Azure Linux 3.0, glibc): the same three commands, 133 passed, without warnings.
• cargo xtask fmt at the head of the stack, which holds this commit's file as it is here, clean.

At 78085e3c6:

• The new test panicked without the fix on Windows and Linux, and passed with it on Windows and on NVX's KVM, MSHV, and WHP test VMs; openvmm_helpers passed, 118 tests on Windows and 124 on Linux; cargo clippy, cargo doc, and cargo xtask fmt were clean.
• A scratch test, not committed, that opens a snapshot whose manifest declares 2^64 - 4 GiB of RAM and a 2^64 - 2 GiB capacity panicked in OpenedSnapshot::open on Windows without the fix, and with it failed with "memory.bin size (1024 bytes) doesn't match manifest (18446744069414584320 bytes)".
• NVX's restore-memory scenario passed on its KVM, MSHV, and WHP test VMs with OpenVMM built from it, and NVX's runtime-adapter suite passed, 158 of 158, on KVM.

Stack

Three drafts, one for each of three microsoft/nvx issues, each based on the branch of the one before it:

1. This pull request, for openvmm: memory-expansion range math overflows near the top of the GPA space nvx#1364, on feature/microvm/dev.
2. [DO NOT REVIEW] openvmm_helpers: refuse a FIFO artifact without waiting for a writer #5004, for openvmm: a writerless FIFO snapshot artifact hangs restore before validation nvx#1154, on this branch.
3. [DO NOT REVIEW] vmotherboard: gate a device's input without closing it to the vCPUs #5005, for openvmm: snapshot input gating closes device mutexes while other vCPUs still access them nvx#1138, on [DO NOT REVIEW] openvmm_helpers: refuse a FIFO artifact without waiting for a writer #5004's branch.

NVX pins each one's head in its own draft, stacked the same way: microsoft/nvx#1423, microsoft/nvx#1424, and microsoft/nvx#1425, in this order, with microsoft/nvx#1427, part 2 of microsoft/nvx#544, which moves no pin, on top.

This one lands first, by fast-forwarding feature/microvm/dev to this head, ac3dc27a738808d38e1148d3caefc5e89111ee32, since this repository's merge button squashes and would leave NVX's pin off the branch. The next one then has its base retargeted to feature/microvm/dev and lands the same way, at its exact head.