DF-5479 — efi_enter()/efi_leave(): per-CPU CR4.SMEP disable with no CPU pinning or critical section — preempt+migrate inside the runtime-services window leaves the source CPU with SMEP permanently disabled and the migrated runtime call SMEP-fault-looping with efi_lock held forever.

FILE: sys/platform/pc64/x86_64/efirt.c (pass 2)

ROOT CAUSE (path:line): * efirt.c:342-359 efi_enter(): takes efi_lock, swaps lwp vmspace to the 1:1 efi_vmspace, npxpush(&efi_ctx), cpu_invltlb(), then smap_smep_disable() — and that is ALL. No critical section, no CPU pinning, interrupts left enabled by design (comment efirt.c:332-337). * The comment at efirt.c:327-330 claims the FreeBSD original's fpu_kern_enter() "enters critical section, giving us neccessary protection against context switch" — but the DragonFly port replaced it with npxpush() (npx.c:340-374), which only saves FPU state and enters NO critical section. The claimed protection does not exist. * smap_smep_disable() (pmap.c:1366-1390) mutates PER-CPU state: CR4.SMEP cleared (pmap.c:1389), plus per-thread STAC + pcb_onfault=1 (pmap.c:1383). smap_smep_enable() (pmap.c:1393-1399) restores on whatever CPU efi_leave() runs. CR4.SMAP/SMEP are never restored by the context-switch path — the only other CR4_SMEP touchpoint is boot-time enable (pmap.c:1355). * Therefore, if the calling thread is preempted inside the firmware window and migrates to another CPU (usched_dfly pulls runnable threads across CPUs), (a) the DESTINATION CPU still has SMEP set: firmware executes at 1:1 U/S=1 addresses (the efi map is a user map, efirt.c:214/224-231) → SMEP #PF at CPL0 → trap.c:894-928 (pcb_onfault=1 bypasses the fatal check) → vm_fault() against the efi map succeeds (page present, exec allowed) → reexecute → fault — an infinite fault loop at kernel priority with efi_lock held forever: every later EFI ioctl and the shutdown-time efi_reset_system() (efirt.c:374-386, 520-531) block permanently; and (b) the SOURCE CPU keeps CR4.SMEP cleared FOREVER (efi_leave runs elsewhere; no other code re-arms it) — a permanent per-CPU SMEP bypass for any other kernel-mode-executes-userpage attack. Even without migration, ANY thread preempting the EFI caller on the source CPU runs with SMEP disabled for the duration of the firmware call (transient hardening window).

THREAT: requires an EFI-booted machine (runtime services used by root via /dev/efi ioctls, debug.efi_time, shutdown reset) plus preemption/migration under load. Effect: permanent wedge of all EFI services + permanent per-CPU SMEP defeat. Not verified on the audit rig (legacy BIOS boot — efi_runtime == NULL; all runtime paths return ENXIO) — status inconclusive by rig limitation, established by code trace only.

PACK: analysis-only (README.md, VERDICT.md, verdict.json).

DF-5479 VERDICT — per-CPU SMEP window in efi_enter()/efi_leave() with no pinning

Status: inconclusive (rig limit: BIOS-boot guest, efi_runtime == NULL). Established by code trace; expected impact if triggered on EFI hardware: permanent wedge of all EFI runtime services (DoS) + permanent per-CPU SMEP defeat (hardening kill).

The trace, step by step

1. efi_enter() (efirt.c:342-359) acquires efi_lock and performs pmap_setlwpvm(td->td_lwp, efi_vmspace) → load_cr3 of the 1:1 map (pmap.c:6408-6450), npxpush(&efi_ctx) (FPU save only — npx.c:340-374, no crit_enter), cpu_invltlb(), smap_smep_disable().
2. smap_smep_disable() (pmap.c:1366-1390): * smap_open() = STAC → per-thread RFLAGS.AC (does NOT leak across context switches; AC is saved/restored with RFLAGS), * curthread->td_pcb->pcb_onfault = (void *)1 (pmap.c:1383) — bypasses the "Fatal user address access from kernel mode" software failsafe (trap.c:917-926) for this thread, * load_cr4(rcr4() & ~CR4_SMEP) (pmap.c:1389) — global per-CPU state, not per-thread.
3. The in-tree comment (efirt.c:327-330) asserts the FreeBSD original's fpu_kern_enter() "enters critical section, giving us neccessary protection against context switch". FreeBSD's fpu_kern_enter indeed does critical_enter(). The DragonFly port calls npxpush() instead, which has no such protection. The documented invariant is false.
4. Nothing prevents preemption inside the window: interrupts stay enabled (efirt.c:332-337, deliberate), efi_lock does not pin, and DFly's scheduler (usched_dfly) pulls runnable threads across CPUs.
5. Migration outcome on the destination CPU B (SMEP still armed there): * firmware instruction fetch at a 1:1 address: the efi map was created by vmspace_alloc(VM_MIN_USER_ADDRESS, VM_MAX_USER_ADDRESS) (efirt.c:214) and inserted RWX (efirt.c:224-231) → PTEs are U/S=1 user pages → SMEP violation at CPL0; * trap → trap_pfault (trap.c:629-631 → 860+): va < VM_MIN_KERNEL_ADDRESS, usermode == 0; pcb_onfault != NULL skips the fatal branch (trap.c:917-926); map = &efi_vmspace->vm_map (trap.c:928); * vm_fault(map, va, VM_PROT_EXECUTE, ...) (trap.c:961): the page is present and exec-permitted → KERN_SUCCESS → trap returns; * re-execute at the same RIP → SMEP faults again → infinite fault loop at kernel priority, efi_lock held forever. Consequences: every subsequent efi_enter() — i.e. every EFI ioctl (efidev.c), efi_get_time/efi_set_time, and the shutdown-final efi_reset_system() (efirt.c:374-386) — blocks forever; one CPU is spun in the trap path.
6. Migration outcome on the source CPU A: smap_smep_enable() runs on CPU B (wherever efi_leave executes); nothing on CPU A re-arms CR4.SMEP — the only other CR4_SMEP touchpoint in the kernel is the boot-time enable (pmap.c:1355; verified by grep). CPU A runs with SMEP permanently disabled — any subsequent kernel-mode-executes-userspace attack on that CPU is unimpeded (no gadget/ROP constraint from SMEP).
7. Even without migration, any thread that preempts the EFI caller on CPU A executes with CR4.SMEP disabled for the whole firmware call — a transient per-CPU hardening window open to unrelated attackers.

Why it could not be verified on this rig

The audit guest boots legacy BIOS: efi_systbl_phys == 0, efi_init() returns ENXIO (efirt.c:399-403), efi_runtime == NULL, and every runtime entry (efi_enter) fails at efirt.c:347-348. The window cannot be opened here. An EFI-booted VM (OVMF) plus an SMP preemption workload would be required; outside this rig's scope by construction.

Fix direction

Make the window non-migratable and the CR4 mutation paired per-CPU: enter a critical section or pin the thread to the current CPU for the duration (restoring before efi_leave), or track "SMEP disabled by EFI" per-CPU and re-arm it in the context-switch/IPI path (e.g. set the bit in mdcpu and have cpu_...switch restore CR4 when the EFI caller is descheduled). One-line hardening at minimum: crit_enter() around smap_smep_disable..smap_smep_enable does not fix migration (crit sections in DFly do prevent preemption while held — crit_enter DOES block preemption of this thread on this CPU; combined with the fact that an LWKT thread in a crit section cannot be pulled by another CPU, that is the correct minimal fix mirroring FreeBSD's fpu_kern_enter).

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.

(No fix.diff for this item: documented recommendation only - see Fix above.)