#!/bin/sh
# DF-1064 run -- load the harness and observe whether the cpu-dimension
# OOB write fires.
#
# Must run as root (kldload).  This is expected: the bug is a boot-time,
# firmware-data path, not a userspace syscall -- there is no unprivileged
# trigger.  The harness is the dynamic proof-of-primitive.
#
# Expected on the UNPATCHED kernel (#0):
#   DF1064: aliasing check: &cpu_id_to_apic_id[256]==&lapic_mem ? YES
#   DF1064: direct-OOB test: cpu_id_to_apic_id[256] write clobbered lapic_mem (OOB CONFIRMED)
#   DF1064: direct-OOB test: cpu_id_to_acpi_id[256] write landed OOB (OOB CONFIRMED)
#   DF1064: lapic_set_cpuid(256,1) test: lapic_mem clobbered to 1 (OOB via lapic_set_cpuid CONFIRMED)
#   DF1064: SUMMARY: OOB WRITE CONFIRMED -- ...
#
# Expected on the PATCHED kernel (#1, fix.diff applied):
#   - lapic_set_cpuid(256,1) is rejected by the new bounds check; no OOB.
#   - Note: the direct array writes still succeed (we are writing past the
#     array in C by definition); but the *bug path* via lapic_set_cpuid is
#     closed and the adjacent CPUID_TO_ACPIID write is guarded by
#     "if (cpu >= MAXCPU) return 0" in the callback.  The fix is judged on
#     the lapic_set_cpuid(256,1) line, which should report NO clobber.
cd "$(dirname "$0")"
KO=$(ls /usr/obj$(pwd)/df1064.ko /usr/obj/*/$(pwd)/df1064.ko 2>/dev/null | head -1)
[ -z "$KO" ] && KO=$(find /usr/obj -name df1064.ko -newer df1064_harness.c 2>/dev/null | head -1)
cp "$KO" /root/df1064.ko
kldload /root/df1064.ko 2>&1
echo "--- dmesg (DF1064) ---"
dmesg | grep -E 'DF1064|lapic_set_cpuid: invalid' | tail -25
kldunload df1064 2>/dev/null || true