On Thu, 7 May 2026 at 15:14, Matthew Jackson <[email protected]> wrote:
>
> With APPLESMC_GET_KEY_BY_INDEX_CMD now functional (previous
> patch), the modern macOS AppleSMC kext walks the device's key
> table at boot to discover what's available. The current key
> set (REV/OSK0/OSK1/NATJ/MSSP/MSSD) is sparse enough that
> several macOS subsystems retry-poll keys they expect to find,
> contributing to the same kSMCSpuriousData traffic the previous
> patch addresses.
> + /*
> + * #KEY - Apple SMC convention for "total key count". macOS reads it
> + * at boot and iterates 0..count-1 via APPLESMC_GET_KEY_BY_INDEX_CMD.
> + * Without this key, macOS iterates unbounded and every out-of-range
> + * request floods the kernel log with kSMCSpuriousData errors
> + * (measured ~1800/sec on macOS 15). Count is computed by walking the
> + * list. The buffer is function-static so the pointer stays valid
> + * for the device's lifetime.
> + */
The applesmc_add_key() API's "pointer passed in must remain
valid forever" is a bit awkward, but I suppose for a single
key that's not "fixed data" it's fine.
Does the guest query this stuff often enough that the "loop
through all keys" in applesmc_find_key() is at all noticeable
in a profile? I'm guessing not, but if we did find we wanted
to replace that with a glib hashtable then we could take the
opportunity to make the memory lifetime requirement here a bit
less bug-prone.
> + {
> + int count = 1; /* include #KEY itself */
> + struct AppleSMCData *def;
> + QLIST_FOREACH(def, &s->data_def, node) count++;
Loops always need {}, even single line bodies.
> + static char numkey_buf[4];
> + numkey_buf[0] = (count >> 24) & 0xff;
> + numkey_buf[1] = (count >> 16) & 0xff;
> + numkey_buf[2] = (count >> 8) & 0xff;
> + numkey_buf[3] = count & 0xff;
This is
stl_be_p(numkey_buf, count);
> + applesmc_add_key(s, "#KEY", 4, numkey_buf);
> + }
> }
thanks
-- PMM
