tl;dr: luu's considerations are plausible. ad 5: Microcode updates can be installed on top of another, and there's a Linux driver for Intel at least (so they e

tl;dr: luu's considerations are plausible. ad 5: Microcode updates can be installed on top of another, and there's a Linux driver for Intel at least (so they expect to still be able to install updates). They're not persistent though - after a reboot, they're gone. In general: Intel has the Management Engine, a separate processor running its own multi-MB firmware and is required (otherwise you're system won't run for very long) and Intel-signed (so you can't replace it). It also has access to memory, USB, NIC and certain control over the CPU. When it comes to your mechanisms, my guess is #4, but probably entering System Management Mode or Trusted Execution Mode (on TXT systems) - there are some things you can't access from ring 0. As for hiding within the instruction set, x86 has prefixes and I doubt anyone tried redundant ones on all kinds of opcodes: something like "LOCK LOCK REPNE DATA32 DATA32 LOCK ADDR32 MOV $entrypoint, dr0;" might just do the trick. Or simply a long chain of non-sensical prefixes after which the CPU just expects a magic value and the entry point... x86 is known to accept 14 bytes of prefixes, so there's some space to hide special behaviour.