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:[email protected]] > Sent: Wednesday, August 21, 2019 10:06 AM > To: Kinney, Michael D <[email protected]>; > [email protected]; Yao, Jiewen <[email protected]> > Cc: Alex Williamson <[email protected]>; Laszlo > Ersek <[email protected]>; [email protected]; qemu > devel list <[email protected]>; Igor Mammedov > <[email protected]>; Chen, Yingwen > <[email protected]>; Nakajima, Jun > <[email protected]>; Boris Ostrovsky > <[email protected]>; Joao Marcal Lemos Martins > <[email protected]>; Phillip Goerl > <[email protected]> > 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: [email protected] [mailto:[email protected]] > On Behalf Of > >> Yao, Jiewen > >> Sent: Sunday, August 18, 2019 4:01 PM > >> To: Paolo Bonzini <[email protected]> > >> Cc: Alex Williamson <[email protected]>; > Laszlo Ersek > >> <[email protected]>; [email protected]; edk2- rfc- > groups-io > >> <[email protected]>; qemu devel list <qemu- > [email protected]>; Igor > >> Mammedov <[email protected]>; Chen, Yingwen > >> <[email protected]>; Nakajima, Jun > <[email protected]>; > >> Boris Ostrovsky <[email protected]>; Joao > Marcal Lemos > >> Martins <[email protected]>; Phillip Goerl > >> <[email protected]> > >> 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 > >> <[email protected]> 写道： > >>> > >>>> 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: [email protected] Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
