DF-5481 — EFIIOC_GET_TABLE hands a kernel DMAP virtual address straight
back to userspace: kernel-VA disclosure (root-only) and a useless ioctl
ABI (userspace cannot dereference a DMAP address).

FILE: sys/platform/pc64/x86_64/efirt.c (+ the efidev ioctl ABI)

ROOT CAUSE (path:line):
  * efirt.c:481: `*ptr = (void *)PHYS_TO_DMAP(ct->ct_data);` — the table
    location is returned as a KERNEL direct-map VA (e.g. 0xffffc5...,
    DMAP base 0xffffb80000000000 on this build — demonstrated empirically
    by the DF-5477 harness, run.log).
  * sys/dev/misc/efirt/efidev.c:77-84: EFIIOC_GET_TABLE copies the
    efi_get_table_ioc struct (uuid in, ptr out) back to the caller —
    the kernel VA goes to userspace verbatim.
  * Two defects in one: (1) kernel-address disclosure to the (root-only,
    0700 root:wheel — efidev.c:205-206) caller, a KASLR-adjacent leak of
    the fixed DMAP base relationship; (2) the returned pointer is
    unusable in userspace (DMAP is kernel-only VA), so the ioctl can
    never have worked as an API on this port — upstream FreeBSD later
    reworked the ABI to copy table contents instead.

SEVERITY: Info — root-gated, fixed-offset DMAP (little entropy value on
this platform), no privilege boundary crossed. Filed for completeness of
the /dev/efi surface review.

PACK: analysis-only; the disclosure mechanic itself was demonstrated
kernel-side by the DF-5477 harness (see findings/poc/DF-5477/run.log:
"returned kernel DMAP pointer 0xffffc5eadbeef000"); end-to-end ioctl
delivery is not testable on this BIOS-boot rig (efi_get_table returns
ENXIO). status inconclusive by rig limit.