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

From: Igor Mammedov <imammedo@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: "Chen, Yingwen" <yingwen.chen@intel.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>,
	Phillip Goerl <phillip.goerl@oracle.com>,
	qemu devel list <qemu-devel@nongnu.org>,
	Alex Williamson <alex.williamson@redhat.com>,
	"Yao, Jiewen" <jiewen.yao@intel.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>,
	"Kinney, Michael D" <michael.d.kinney@intel.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"rfc@edk2.groups.io" <rfc@edk2.groups.io>,
	Joao Marcal Lemos Martins <joao.m.martins@oracle.com>
Subject: Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
Date: Mon, 2 Sep 2019 10:45:34 +0200	[thread overview]
Message-ID: <20190902104534.46e58c95@redhat.com> (raw)
In-Reply-To: <a43d47e0-6e99-ad42-77d4-638421e8768c@redhat.com>

On Fri, 30 Aug 2019 20:46:14 +0200
Laszlo Ersek <lersek@redhat.com> wrote:

> 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?
It sure can but this way it won't get access to privileged SMRAM
so OS can't subvert firmware.
The next time SMI broadcast is sent the CPU will use SMI handler at
default 30000 SMBASE. It's up to us to define behavior here (for example
relocation handler can put such CPU in shutdown state).

It's in the best interest of OS to cooperate and execute AML
provided by firmware, if it does not follow proper cpu hotplug flow
we can't guarantee that stolen CPU will work.

> Thanks!
> Laszlo