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

["Michael D Kinney" <michael.d.kinney@intel.com>]

Could we have an initial SMBASE that is within TSEG.

If we bring in hot plug CPUs one at a time, then initial
SMBASE in TSEG can reprogram the SMBASE to the correct 
value for that CPU.

Can we add a register to the hot plug controller that
allows the BSP to set the initial SMBASE value for 
a hot added CPU?  The default can be 3000:8000 for
compatibility.

Another idea is when the SMI handler runs for a hot add
CPU event, the SMM monarch programs the hot plug controller
register with the SMBASE to use for the CPU that is being
added.  As each CPU is added, a different SMBASE value can
be programmed by the SMM Monarch.

Mike

> -----Original Message-----
> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> Sent: Wednesday, August 21, 2019 10:06 AM
> To: Kinney, Michael D <michael.d.kinney@intel.com>;
> rfc@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>
> Cc: Alex Williamson <alex.williamson@redhat.com>; Laszlo
> Ersek <lersek@redhat.com>; devel@edk2.groups.io; qemu
> devel list <qemu-devel@nongnu.org>; Igor Mammedov
> <imammedo@redhat.com>; Chen, Yingwen
> <yingwen.chen@intel.com>; Nakajima, Jun
> <jun.nakajima@intel.com>; Boris Ostrovsky
> <boris.ostrovsky@oracle.com>; Joao Marcal Lemos Martins
> <joao.m.martins@oracle.com>; Phillip Goerl
> <phillip.goerl@oracle.com>
> Subject: Re: [edk2-rfc] [edk2-devel] CPU hotplug using
> SMM with QEMU+OVMF
> 
> On 21/08/19 17:48, Kinney, Michael D wrote:
> > Perhaps there is a way to avoid the 3000:8000 startup
> vector.
> >
> > If a CPU is added after a cold reset, it is already in
> a different
> > state because one of the active CPUs needs to release
> it by
> > interacting with the hot plug controller.
> >
> > Can the SMRR for CPUs in that state be pre-programmed
> to match the
> > SMRR in the rest of the active CPUs?
> >
> > For OVMF we expect all the active CPUs to use the same
> SMRR value, so
> > a check can be made to verify that all the active CPUs
> have the same
> > SMRR value.  If they do, then any CPU released through
> the hot plug
> > controller can have its SMRR pre-programmed and the
> initial SMI will
> > start within TSEG.
> >
> > We just need to decide what to do in the unexpected
> case where all the
> > active CPUs do not have the same SMRR value.
> >
> > This should also reduce the total number of steps.
> 
> The problem is not the SMRR but the SMBASE.  If the
> SMBASE area is outside TSEG, it is vulnerable to DMA
> attacks independent of the SMRR.
> SMBASE is also different for all CPUs, so it cannot be
> preprogrammed.
> 
> (As an aside, virt platforms are also immune to cache
> poisoning so they don't have SMRR yet - we could use
> them for SMM_CODE_CHK_EN and block execution outside
> SMRR but we never got round to it).
> 
> An even simpler alternative would be to make A0000h the
> initial SMBASE.
>  However, I would like to understand what hardware
> platforms plan to do, if anything.
> 
> Paolo
> 
> > Mike
> >
> >> -----Original Message-----
> >> From: rfc@edk2.groups.io [mailto:rfc@edk2.groups.io]
> On Behalf Of
> >> Yao, Jiewen
> >> Sent: Sunday, August 18, 2019 4:01 PM
> >> To: Paolo Bonzini <pbonzini@redhat.com>
> >> Cc: Alex Williamson <alex.williamson@redhat.com>;
> Laszlo Ersek
> >> <lersek@redhat.com>; devel@edk2.groups.io; edk2- rfc-
> groups-io
> >> <rfc@edk2.groups.io>; qemu devel list <qemu-
> devel@nongnu.org>; Igor
> >> Mammedov <imammedo@redhat.com>; Chen, Yingwen
> >> <yingwen.chen@intel.com>; Nakajima, Jun
> <jun.nakajima@intel.com>;
> >> Boris Ostrovsky <boris.ostrovsky@oracle.com>; Joao
> Marcal Lemos
> >> Martins <joao.m.martins@oracle.com>; Phillip Goerl
> >> <phillip.goerl@oracle.com>
> >> Subject: Re: [edk2-rfc] [edk2-devel] CPU hotplug
> using SMM with
> >> QEMU+OVMF
> >>
> >> in real world, we deprecate AB-seg usage because they
> are vulnerable
> >> to smm cache poison attack.
> >> I assume cache poison is out of scope in the virtual
> world, or there
> >> is a way to prevent ABseg cache poison.
> >>
> >> thank you!
> >> Yao, Jiewen
> >>
> >>
> >>> 在 2019年8月19日，上午3:50，Paolo Bonzini
> >> <pbonzini@redhat.com> 写道：
> >>>
> >>>> On 17/08/19 02:20, Yao, Jiewen wrote:
> >>>> [Jiewen] That is OK. Then we MUST add the third
> >> adversary.
> >>>> -- Adversary: Simple hardware attacker, who can use
> >> device to perform DMA attack in the virtual world.
> >>>> NOTE: The DMA attack in the real world is out of
> >> scope. That is be handled by IOMMU in the real world,
> such as VTd. --
> >> Please do clarify if this is TRUE.
> >>>>
> >>>> In the real world:
> >>>> #1: the SMM MUST be non-DMA capable region.
> >>>> #2: the MMIO MUST be non-DMA capable region.
> >>>> #3: the stolen memory MIGHT be DMA capable region
> or
> >> non-DMA capable
> >>>> region. It depends upon the silicon design.
> >>>> #4: the normal OS accessible memory - including
> ACPI
> >> reclaim, ACPI
> >>>> NVS, and reserved memory not included by #3 - MUST
> be
> >> DMA capable region.
> >>>> As such, IOMMU protection is NOT required for #1
> and
> >> #2. IOMMU
> >>>> protection MIGHT be required for #3 and MUST be
> >> required for #4.
> >>>> I assume the virtual environment is designed in the
> >> same way. Please
> >>>> correct me if I am wrong.
> >>>>
> >>>
> >>> Correct.  The 0x30000...0x3ffff area is the only
> >> problematic one;
> >>> Igor's idea (or a variant, for example optionally
> >> remapping
> >>> 0xa0000..0xaffff SMRAM to 0x30000) is becoming more
> >> and more attractive.
> >>>
> >>> Paolo
> >>
> >> 
> >