Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

[Laszlo Ersek <lersek@redhat.com>]

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