in real world, we deprecate AB-seg usage because they are vulnerable to smm cache poison attack.
toggle quoted messageShow quoted text
I assume cache poison is out of scope in the virtual world, or there is a way to prevent ABseg cache poison.
在 2019年8月19日，上午3:50，Paolo Bonzini <firstname.lastname@example.org> 写道：
On 17/08/19 02:20, Yao, Jiewen wrote:Correct. The 0x30000...0x3ffff area is the only problematic one;
[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.
Igor's idea (or a variant, for example optionally remapping
0xa0000..0xaffff SMRAM to 0x30000) is becoming more and more attractive.