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

Michael D Kinney michael.d.kinney at intel.com
Fri Aug 23 15:25:00 UTC 2019


Hi Jiewen,

If a hot add CPU needs to run any code before the
first SMI, I would recommend is only executes code
from a write protected FLASH range without a stack
and then wait for the first SMI.

For this OVMF use case, is any CPU init required
before the first SMI?

>From Paolo's list of steps are steps (8a) and (8b) 
really required?  Can the SMI monarch use the Local
APIC to send a directed SMI to the hot added CPU?
The SMI monarch needs to know the APIC ID of the
hot added CPU.  Do we also need to handle the case
where multiple CPUs are added at once?  I think we
would need to serialize the use of 3000:8000 for the
SMM rebase operation on each hot added CPU.

It would be simpler if we can guarantee that only
one CPU can be added or removed at a time and the 
complete flow of adding a CPU to SMM and the OS
needs to be completed before another add/remove
event needs to be processed.

Mike

> -----Original Message-----
> From: Yao, Jiewen
> Sent: Thursday, August 22, 2019 10:00 PM
> To: Kinney, Michael D <michael.d.kinney at intel.com>;
> Paolo Bonzini <pbonzini at redhat.com>; Laszlo Ersek
> <lersek at redhat.com>; rfc at edk2.groups.io
> Cc: Alex Williamson <alex.williamson at redhat.com>;
> devel at edk2.groups.io; qemu devel list <qemu-
> devel at nongnu.org>; Igor Mammedov <imammedo at redhat.com>;
> Chen, Yingwen <yingwen.chen at intel.com>; Nakajima, Jun
> <jun.nakajima at intel.com>; Boris Ostrovsky
> <boris.ostrovsky at oracle.com>; Joao Marcal Lemos Martins
> <joao.m.martins at oracle.com>; Phillip Goerl
> <phillip.goerl at oracle.com>
> Subject: RE: [edk2-rfc] [edk2-devel] CPU hotplug using
> SMM with QEMU+OVMF
> 
> Thank you Mike!
> 
> That is good reference on the real hardware behavior.
> (Glad it is public.)
> 
> For threat model, the unique part in virtual environment
> is temp RAM.
> The temp RAM in real platform is per CPU cache, while
> the temp RAM in virtual platform is global memory.
> That brings one more potential attack surface in virtual
> environment, if hot-added CPU need run code with stack
> or heap before SMI rebase.
> 
> Other threats, such as SMRAM or DMA, are same.
> 
> Thank you
> Yao Jiewen
> 
> 
> > -----Original Message-----
> > From: Kinney, Michael D
> > Sent: Friday, August 23, 2019 9:03 AM
> > To: Paolo Bonzini <pbonzini at redhat.com>; Laszlo Ersek
> > <lersek at redhat.com>; rfc at edk2.groups.io; Yao, Jiewen
> > <jiewen.yao at intel.com>; Kinney, Michael D
> <michael.d.kinney at intel.com>
> > Cc: Alex Williamson <alex.williamson at redhat.com>;
> > devel at edk2.groups.io; qemu devel list <qemu-
> devel at nongnu.org>; Igor
> > Mammedov <imammedo at redhat.com>; Chen, Yingwen
> > <yingwen.chen at intel.com>; Nakajima, Jun
> <jun.nakajima at intel.com>;
> > Boris Ostrovsky <boris.ostrovsky at oracle.com>; Joao
> Marcal Lemos
> > Martins <joao.m.martins at oracle.com>; Phillip Goerl
> > <phillip.goerl at oracle.com>
> > Subject: RE: [edk2-rfc] [edk2-devel] CPU hotplug using
> SMM with
> > QEMU+OVMF
> >
> > Paolo,
> >
> > I find the following links related to the discussions
> here along with
> > one example feature called GENPROTRANGE.
> >
> > https://csrc.nist.gov/CSRC/media/Presentations/The-
> Whole-is-Greater/im
> > a ges-media/day1_trusted-computing_200-250.pdf
> > https://cansecwest.com/slides/2017/CSW2017_Cuauhtemoc-
> Rene_CPU_Ho
> > t-Add_flow.pdf
> > https://www.mouser.com/ds/2/612/5520-5500-chipset-ioh-
> datasheet-1131
> > 292.pdf
> >
> > Best regards,
> >
> > Mike
> >
> > > -----Original Message-----
> > > From: Paolo Bonzini [mailto:pbonzini at redhat.com]
> > > Sent: Thursday, August 22, 2019 4:12 PM
> > > To: Kinney, Michael D <michael.d.kinney at intel.com>;
> Laszlo Ersek
> > > <lersek at redhat.com>; rfc at edk2.groups.io; Yao, Jiewen
> > > <jiewen.yao at intel.com>
> > > Cc: Alex Williamson <alex.williamson at redhat.com>;
> > > devel at edk2.groups.io; qemu devel list <qemu-
> devel at nongnu.org>; Igor
> > > Mammedov <imammedo at redhat.com>; Chen, Yingwen
> > > <yingwen.chen at intel.com>; Nakajima, Jun
> <jun.nakajima at intel.com>;
> > > Boris Ostrovsky <boris.ostrovsky at oracle.com>; Joao
> Marcal Lemos
> > > Martins <joao.m.martins at oracle.com>; Phillip Goerl
> > > <phillip.goerl at oracle.com>
> > > Subject: Re: [edk2-rfc] [edk2-devel] CPU hotplug
> using SMM with
> > > QEMU+OVMF
> > >
> > > On 23/08/19 00:32, Kinney, Michael D wrote:
> > > > Paolo,
> > > >
> > > > It is my understanding that real HW hot plug uses
> the
> > > SDM defined
> > > > methods.  Meaning the initial SMI is to 3000:8000
> and
> > > they rebase to
> > > > TSEG in the first SMI.  They must have chipset
> specific
> > > methods to
> > > > protect 3000:8000 from DMA.
> > >
> > > It would be great if you could check.
> > >
> > > > Can we add a chipset feature to prevent DMA to
> 64KB
> > > range from
> > > > 0x30000-0x3FFFF and the UEFI Memory Map and ACPI
> > > content can be
> > > > updated so the Guest OS knows to not use that
> range for
> > > DMA?
> > >
> > > If real hardware does it at the chipset level, we
> will probably use
> > > Igor's suggestion of aliasing A-seg to 3000:0000.
> Before starting
> > > the new CPU, the SMI handler can prepare the SMBASE
> relocation
> > > trampoline at
> > > A000:8000 and the hot-plugged CPU will find it at
> > > 3000:8000 when it receives the initial SMI.  Because
> this is backed
> > > by RAM at 0xA0000-0xAFFFF, DMA cannot access it and
> would still go
> > > through to RAM at 0x30000.
> > >
> > > Paolo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#46308): https://edk2.groups.io/g/devel/message/46308
Mute This Topic: https://groups.io/mt/32979681/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-





More information about the edk2-devel-archive mailing list