1. The "covert channel on audio" approach to bypassing air gaps is a research topic. It's possible that it's already exploited independently. 2. Differentiatin

1. The "covert channel on audio" approach to bypassing air gaps is a research topic. It's possible that it's already exploited independently. 2. Differentiating BIOS or EFI at that level is a semantics game. It's firmware, and on x86 it's traditionally called BIOS. There's the API difference, but they serve approximately the same purpose. Most "BIOS"es since 2009 are actually UEFI underneath, while some early UEFI implementations were 80% BIOS with just enough UEFI surface tacked on to boot Windows Server in UEFI mode. 3. It's somewhat unlikely that Apple built some custom circuitry to run before the CPU gets its chance to run x86 instructions. Without Anchor Cove, the state of the art on x86 is that the firmware verifies itself by measuring into the TPM. Considerations of the usefulness of such an operation are left as exercise to the reader. The "SOS" mentioned in the paper beep seems to be recoverable with a rescue CD (https://discussions.apple.com/thread/2164874 https://discussions.apple.com/thread/2164874), so that sounds like a self-test of the firmware (with even enough support to load files from media, for which almost all hardware must be initialized). The only way to make this remotely safe would be to lock down parts of the flash in hardware (like Chromebooks do), but I'm not sure Apple even considered that as a threat. The SOS thing is probably just a user-friendly way to cope with flash updates that went wrong. That Black Hat paper stopped with SOS, and it seems like they didn't even look how to circumvent that test. 4. (U)EFI runs whatever PE/TE binaries it gets presented. UEFI Secure Boot (not relevant for Macs) locks that down a bit, but in-flash binaries are typically exempt from signature tests (EDK2 allows to configure security levels for 4 source categories: IIRC Flash, Option ROMs, readonly media, readwrite media) 5. The Black Hat paper claims that UEFI Secure Boot and TPM somehow interact. They don't. Secure Boot is specifically designed to work without a TPM. Reading across the entire account (there's more than just this post), it indeed sounds like science fiction and there are some wild suspicions, but it's still just so plausible.