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:pbonz...@redhat.com] > Sent: Wednesday, August 21, 2019 10:06 AM > To: Kinney, Michael D <michael.d.kin...@intel.com>; > r...@edk2.groups.io; Yao, Jiewen <jiewen....@intel.com> > Cc: Alex Williamson <alex.william...@redhat.com>; Laszlo > Ersek <ler...@redhat.com>; devel@edk2.groups.io; qemu > devel list <qemu-de...@nongnu.org>; Igor Mammedov > <imamm...@redhat.com>; Chen, Yingwen > <yingwen.c...@intel.com>; Nakajima, Jun > <jun.nakaj...@intel.com>; Boris Ostrovsky > <boris.ostrov...@oracle.com>; Joao Marcal Lemos Martins > <joao.m.mart...@oracle.com>; Phillip Goerl > <phillip.go...@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: r...@edk2.groups.io [mailto:r...@edk2.groups.io] > On Behalf Of > >> Yao, Jiewen > >> Sent: Sunday, August 18, 2019 4:01 PM > >> To: Paolo Bonzini <pbonz...@redhat.com> > >> Cc: Alex Williamson <alex.william...@redhat.com>; > Laszlo Ersek > >> <ler...@redhat.com>; devel@edk2.groups.io; edk2- rfc- > groups-io > >> <r...@edk2.groups.io>; qemu devel list <qemu- > de...@nongnu.org>; Igor > >> Mammedov <imamm...@redhat.com>; Chen, Yingwen > >> <yingwen.c...@intel.com>; Nakajima, Jun > <jun.nakaj...@intel.com>; > >> Boris Ostrovsky <boris.ostrov...@oracle.com>; Joao > Marcal Lemos > >> Martins <joao.m.mart...@oracle.com>; Phillip Goerl > >> <phillip.go...@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 > >> <pbonz...@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 > >> > >> > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#46169): https://edk2.groups.io/g/devel/message/46169 Mute This Topic: https://groups.io/mt/32979681/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
