DF-0595: Michael MIC memcmp timing-channel demonstration
  kernel MIC length: 8 bytes (IEEE80211_WEP_MICLEN)
  iterations/case:   5000000

The DragonFlyBSD kernel verifies the 8-byte Michael MIC tag with libc
`memcmp` (tkip.c:361, ccmp.c:642). `memcmp` short-circuits on the first
differing byte. We measure two adversarial cases of equal-length buffers:
  first-byte-diff  -> early memcmp exit
  last-byte-diff   -> full memcmp scan

A non-constant-time memcmp should show last/first > 1; a constant-time
comparison (the libkern timingsafe_bcmp idiom) should show ~1.0.

=== Test 1: principle (longer 256-byte buffers, SIMD-defeating) ===
Timing (CLOCK_THREAD_CPUTIME_ID, ns/call):
  memcmp           first-byte-diff:    5.40 ns/call   last-byte-diff:   16.21 ns/call   ratio(last/first) = 3.003
  timingsafe_bcmp  first-byte-diff:  174.60 ns/call   last-byte-diff:  183.59 ns/call   ratio(last/first) = 1.052

=== Test 2: the actual kernel case (8-byte MIC tag) ===
At 8 bytes the signal is small and easily swamped by jitter — this is
precisely why DF-0595 is Info (defense-in-depth), not Critical: the channel
is real in principle but dominated by WiFi RTT / softirq jitter in practice.
Timing (CLOCK_THREAD_CPUTIME_ID, ns/call):
  memcmp           first-byte-diff:    5.40 ns/call   last-byte-diff:    3.60 ns/call   ratio(last/first) = 0.666
  timingsafe_bcmp  first-byte-diff:    5.41 ns/call   last-byte-diff:    9.00 ns/call   ratio(last/first) = 1.663

Interpretation:
  - Test 1 (>1 ratio for memcmp, ~1.0 for ct_bcmp): proves this libc's
    memcmp IS short-circuit / non-constant-time.
  - Test 2 (noisy): at the real MIC length the signal is small and
    jitter-dominated — empirically confirming the Info severity.
Either way, the kernel fix (memcmp -> libkern timingsafe_bcmp) removes
the channel entirely. See findings/poc/DF-0595/fix.diff.