On 08/30/19 16:48, Igor Mammedov wrote: > (01) On boot firmware maps and initializes SMI handler at default SMBASE > (30000) > (using dedicated SMRAM at 30000 would allow us to avoid save/restore > steps and make SMM handler pointer not vulnerable to DMA attacks) > > (02) QEMU hotplugs a new CPU in reset-ed state and sends SCI > > (03) on receiving SCI, host CPU calls GPE cpu hotplug handler > which writes to IO port 0xB2 (broadcast SMI) > > (04) firmware waits for all existing CPUs rendezvous in SMM mode, > new CPU(s) have SMI pending but does nothing yet > > (05) host CPU wakes up one new CPU (INIT-INIT-SIPI) > SIPI vector points to RO flash HLT loop. > (how host CPU will know which new CPUs to relocate? > possibly reuse QEMU CPU hotplug MMIO interface???) > > (06) new CPU does relocation. > (in case of attacker sends SIPI to several new CPUs, > open question how to detect collision of several CPUs at the same > default SMBASE) > > (07) once new CPU relocated host CPU completes initialization, returns > from IO port write and executes the rest of GPE handler, telling OS > to online new CPU.
In step (03), it is the OS that handles the SCI; it transfers control to ACPI. The AML can write to IO port 0xB2 only because the OS allows it. If the OS decides to omit that step, and sends an INIT-SIPI-SIPI directly to the new CPU, can it steal the CPU? Thanks! Laszlo
