DF-5569 — vkernel64 DRIVERSLEEP(0) divides by zero (latent; no in-platform caller today)

What

sys/platform/vkernel64/platform/systimer.c:358-367:

void
DRIVERSLEEP(int usec)
{
        if (mycpu->gd_intr_nesting_level)
        DELAY(usec);
    else if (1000000 / usec >= hz)          /* <-- usec == 0 => SIGFPE */
        tsleep(DRIVERSLEEP, 0, "DELAY", 1000000 / usec / hz + 1);
    else
        DELAY(usec);
}

DRIVERSLEEP(0) (or negative) evaluates 1000000 / usec → integer division by zero. In the vkernel this is a host SIGFPE delivered to the vkernel process — i.e., a kernel-mode divide fault routed through exc_segfault/kern_trap (exception.c:223-229,262-272) → vkernel panic. In a bare-metal platform the same math would be a kernel panic.

Reachability today: NONE in this platform (why this is Info)

Callers found in the whole tree (rg DRIVERSLEEP sys/): - sys/dev/powermng/aps/aps.c:200 — DRIVERSLEEP(1) - sys/dev/powermng/aps/aps.c:224 — DRIVERSLEEP(500) - sys/dev/misc/psm/psm.c:865 — DRIVERSLEEP(10000) - definition twin sys/platform/pc64/isa/clock.c:485 (pc64's version has NO division by usec at all — it just picks between two DODELAY modes).

None of these drivers (aps(4), psm(4)) attach in a VKERNEL64 kernel, and all current calls pass nonzero constants. The defect is latent: any future vkernel64 driver (or kld) calling DRIVERSLEEP() with a driver-computed delay of 0 turns it into a vkernel panic. Notably the pc64 twin is immune, so the vkernel64 copy diverges from its sibling for no reason.

The interesting semantic quirk: even for usec > 0 the condition 1000000 / usec >= hz inverts the intent — for SMALL usec (busy-wait territory) 1000000/usec is large so it tsleeps for 1000000/usec/hz + 1 ticks, and for LARGE usec (where sleeping makes sense) it DELAYs (busy-waits); e.g. DRIVERSLEEP(10000) with hz=20 gives 100 >= 20 true → sleeps ~1 tick, while DRIVERSLEEP(100000) gives 10 >= 20 false → busy-waits 100 ms in a critical section. This looks inverted relative to the obvious intent (sleep for LONG waits, spin for SHORT ones). Kept as a secondary note; only the div-by-zero is asserted as a defect.

Fix

--- a/sys/platform/vkernel64/platform/systimer.c
+++ b/sys/platform/vkernel64/platform/systimer.c
@@ -356,6 +356,8 @@ DELAY(int usec)
 void
 DRIVERSLEEP(int usec)
 {
+   if (usec <= 0)
+       return;
    if (mycpu->gd_intr_nesting_level)
        DELAY(usec);
    else if (1000000 / usec >= hz)

(and optionally fix the inverted comparison while there, matching pc64's division-free structure).

Verification

Not executed: no code path in a VKERNEL64 kernel calls DRIVERSLEEP() at all, so no in-guest trigger exists; the division-by-zero for usec==0 is plain C semantics (fix.diff guards it). Status: untested — hardening finding with no demonstrated impact.