Could we have an initial SMBASE that is within TSEG.
toggle quoted messageShow quoted text
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
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.
From: Paolo Bonzini [mailto:pbonzini@...]
Sent: Wednesday, August 21, 2019 10:06 AM
To: Kinney, Michael D <michael.d.kinney@...>;
firstname.lastname@example.org; Yao, Jiewen <jiewen.yao@...>
Cc: Alex Williamson <alex.williamson@...>; Laszlo
Ersek <lersek@...>; email@example.com; qemu
devel list <qemu-devel@...>; Igor Mammedov
<imammedo@...>; Chen, Yingwen
<yingwen.chen@...>; Nakajima, Jun
<jun.nakajima@...>; Boris Ostrovsky
<boris.ostrovsky@...>; Joao Marcal Lemos Martins
<joao.m.martins@...>; Phillip Goerl
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 startupvector.
If a CPU is added after a cold reset, it is already in
state because one of the active CPUs needs to releaseit by
interacting with the hot plug controller.to match the
Can the SMRR for CPUs in that state be pre-programmed
SMRR in the rest of the active CPUs?SMRR value, so
For OVMF we expect all the active CPUs to use the same
a check can be made to verify that all the active CPUshave the same
SMRR value. If they do, then any CPU released throughthe hot plug
controller can have its SMRR pre-programmed and theinitial SMI will
start within TSEG.case where all the
We just need to decide what to do in the unexpected
active CPUs do not have the same SMRR value.The problem is not the SMRR but the SMBASE. If the
This should also reduce the total number of steps.
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
(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
However, I would like to understand what hardware
platforms plan to do, if anything.
MikeOn Behalf Of
From: firstname.lastname@example.org [mailto:email@example.com]
Sent: Sunday, August 18, 2019 4:01 PM
To: Paolo Bonzini <pbonzini@...>
Cc: Alex Williamson <alex.williamson@...>;
<lersek@...>; firstname.lastname@example.org; edk2- rfc-
<email@example.com>; qemu devel list <qemu-
Mammedov <imammedo@...>; Chen, Yingwen
<yingwen.chen@...>; Nakajima, Jun
Boris Ostrovsky <boris.ostrovsky@...>; Joao
using SMM with
Martins <joao.m.martins@...>; Phillip Goerl
Subject: Re: [edk2-rfc] [edk2-devel] CPU hotplug
in real world, we deprecate AB-seg usage because they
world, or there
to smm cache poison attack.
I assume cache poison is out of scope in the virtual
such as VTd. --
is a way to prevent ABseg cache poison.
在 2019年8月19日，上午3:50，Paolo Bonzini<pbonzini@...> 写道：
On 17/08/19 02:20, Yao, Jiewen wrote:
[Jiewen] That is OK. Then we MUST add the third
device to perform DMA attack in the virtual world.
-- Adversary: Simple hardware attacker, who can use
scope. That is be handled by IOMMU in the real world,
NOTE: The DMA attack in the real world is out of
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
region. It depends upon the silicon design.
#4: the normal OS accessible memory - including
NVS, and reserved memory not included by #3 - MUST
DMA capable region.
As such, IOMMU protection is NOT required for #1
required for #4.
protection MIGHT be required for #3 and MUST be
same way. Please
I assume the virtual environment is designed in the
correct me if I am wrong.Correct. The 0x30000...0x3ffff area is the only
Igor's idea (or a variant, for example optionallyremapping
0xa0000..0xaffff SMRAM to 0x30000) is becoming moreand more attractive.