DF-5123 — hypercall_md() inline asm violates the GCC asm contract: r8 lifetime unprotected between two asm statements, indirect-call asm missing clobbers

Severity: Info (latent miscompile hazard) · Confidence: likely (the contract violation is certain by inspection; an actual miscompile was not produced on the shipping compiler — see verdict)

What this is

sys/dev/virtual/hyperv/x86_64/hyperv_machdep.c:74-84:

    __asm__ __volatile__ ("mov %0, %%r8" : : "r" (out_paddr): "r8");
    __asm__ __volatile__ ("call *%3" : "=a" (status) :
        "c" (in_val), "d" (in_paddr), "m" (hc_addr));

Three contract violations in one function:

1. r8 lifetime. The first asm declares r8 clobbered while depending on r8 surviving until the second asm executes. The compiler is entitled to allocate r8 for anything between the two statements (including the input-register setup moves for the second asm). The Hyper-V hypercall ABI argument in r8 (output-page GFN) is therefore carried across a gap the compiler knows nothing about — silently dropping or corrupting out_paddr.
2. Missing call clobbers. call *%3 can clobber every caller-saved register (rax,rcx,rdx,rsi,rdi,r8-r11) and flags; the asm declares none of r9-r11/rsi/rdi/"cc".
3. No "memory" clobber. Hypercalls read their input page and write their output page in memory; without "memory" the compiler may reorder/cache memory traffic around the asm (relevant if the function is ever inlined — e.g. under LTO).

Inherited verbatim from FreeBSD's hyperv_machdep.c.

Reproduce (codegen evidence — done on the audit guest)

build.sh compiles an exact copy of the function (plus an always_inline variant exercising the inlined case) with the guest's gcc 8.3 at -O2 and disassembles. Observed (objdump_gcc83_O2.txt):

hypercall_md:
   0: mov    %rdi,-0x8(%rsp)
   5: mov    %rcx,%r8          <- asm #1
   8: mov    %rsi,%rcx         <- compiler-emitted, BETWEEN the two asms
   b: callq  *-0x8(%rsp)       <- asm #2

The mov %rsi,%rcx sitting between the two asm statements is the demonstration: the compiler does place instructions in exactly the gap where r8 must be preserved, and nothing in the asm constraints stops a different allocation decision from putting a conflicting use of r8 there. With gcc 8.3 at -O2 the standalone function happens to leave r8 intact — so the consequence (hypercall invoked with a garbage output-page GFN / stale hypercall pages) does not manifest today; the defect is real but latent, hence Info.

Recommended fix

Merge into a single asm and declare the full call effect (see fix.diff):

    __asm__ __volatile__ ("movq %3, %%r8\n\tcall *%4"
        : "=a" (status)
        : "c" (in_val), "d" (in_paddr), "r" (out_paddr), "m" (hc_addr)
        : "r8", "r9", "r10", "r11", "memory", "cc");

VERDICT — DF-5123

status: not_reproduced (no miscompile manifests on the shipping compiler) reproduced: false · impact: none (latent) · confidence: likely

Narrative

The claim has two parts: (a) the inline asm in hypercall_md() (hyperv_machdep.c:74-84) violates the GCC extended-asm contract — certain, by inspection; (b) the violation can miscompile into a hypercall with a corrupted r8 (output-page GFN) or reordered hypercall page traffic — latent: not observed with the shipping compiler.

What was run

hypercall_md.c (exact copy of the function + an always_inline variant) was compiled on the audit guest (DragonFly 6.5-DEVELOPMENT, gcc 8.3 "cc 8.3 [DragonFly] Release/2019-02-22") at -O2 and disassembled (build.sh, objdump_gcc83_O2.txt).

What the disassembly proves

• In the standalone function, gcc emits the operand-setup move mov %rsi,%rcx between mov %rcx,%r8 (asm #1) and callq *-0x8(%rsp) (asm #2). This is the structural precondition of the hazard: the gap between the two volatile asm statements is not a compiler-free zone, and the first asm telling the compiler "r8 is clobbered" means gcc considers r8 dead from that point — it may legally allocate r8 for the inter-asm moves of a different input set, silently destroying out_paddr before the call.
• In the always_inline variant (simulating what an LTO build could do to the real call site in hyperv.c:108), the same pattern appears inline in the caller; the missing "memory" clobber means any non-volatile loads/stores around the hypercall (i.e. the hypercall message-page writes done by hypercall_post_message()'s callers in vmbus.c) are freely reorderable across the asm — the demo's surrounding stores were volatile so no reorder was expected to show; that sub-claim remains inspection-based.

What was NOT observed

With gcc 8.3 at -O2, r8 survives the gap in both shapes; no hypercall can actually be issued on the guest anyway (it is a KVM guest — VMM/Hypervisor: Origin="KVMKVMKVM" in env.txt — so hyperv_identify() fails and the whole file is dormant, hyperv.c:207-208). Therefore the exploitable consequence does not reproduce on this system: status not_reproduced / impact none, while the underlying defect is certain.

Why it still matters

The function is the only hypercall gateway on Hyper-V systems; a future compiler upgrade, LTO, or an added statement between the asms turns the latent contract violation into: hypercalls invoked with an attacker- irrelevant but kernel-corrupting wrong output GFN, or message pages read stale — failure modes that would be nearly undebuggable in production. The one-statement fix (see fix.diff) removes the entire class.

Fix validation

Not applicable (Info-class hardening; no runtime behavior to compare — the code path is dormant on KVM and the miscompile does not manifest on gcc 8.3).

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.