-----Original Message-----
From: Paolo Bonzini [mailto:pbonzini@...]
Sent: Wednesday, August 21, 2019 10:06 AM
To: Kinney, Michael D <michael.d.kinney@...>;
rfc@edk2.groups.io; Yao, Jiewen <jiewen.yao@...>
Cc: Alex Williamson <alex.williamson@...>; Laszlo
Ersek <lersek@...>; devel@edk2.groups.io; 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
<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 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@...>
Cc: Alex Williamson <alex.williamson@...>;

Laszlo Ersek

<lersek@...>; devel@edk2.groups.io; edk2- rfc-

groups-io

<rfc@edk2.groups.io>; 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
<phillip.goerl@...>
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@...> 写道：

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