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 (#46015): https://edk2.groups.io/g/devel/message/46015 Mute This Topic: https://groups.io/mt/32852911/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
