Laszlo Ersek <lersek@...> wrote: it shouldn't matter where from management SMI comes if OS won't be able to actually trigger SMI with un-trusted content at SMBASE on hotplugged (parked)

The BSP starts running from 0xFFFFFFF0. APs do not start running at all and just sit waiting for an INIT-SIPI-SIPI sequence. Please see my proposal in the reply to Laszlo. Paolo

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

Laszlo Ersek <lersek@...> wrote: It depends. For starters, the vfio mapping API does not allow unmapping arbitrary sub-ranges of previous mappings. So the hole you want to punch would need

for purpose of demo SMRAM (at 0x30000) is aliased at a0000 in system address space for easy initialization of SMI entry point. Here is resulting debug output showing that RAM at 0x30000 is not

It's just a quick hack together with Seabios to show that normal RAM at 0x30000 is not affected by SMM relocation and dedicated SMRAM could be used for relocation without need to care about untrusted

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

Alex, thank you for the help! Please let us know if we should remove you from the CC list, in order not to clutter your inbox. (I've kept your address for now, for saying thanks. Feel free to stop

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

+Alex (direct question at the bottom) The magic is 07a itself, IIUC. The CPU hotplug controller would be accessible only in SMM. And until 07a happens, the new CPU ignores INIT/SIPI/SIPI even if

(Could Intel open source code for this?) PCI DMA attack might be relevant (but yes, I see you've mentioned that too, down-thread) I wish we could simply wake the new CPU -- after step 07a -- with

Hi, all Now, we enter into Soft Feature Freeze phase. In this phase, the feature under review will not be allowed to be pushed. The patch review can continue without break in edk2 community. If

below

Comment below:

I was going through the steps Jiewen and Yingwen recommended. In step (02), the new CPU is expected to set up RAM access. In step (03), the new CPU, executing code from flash, is expected to "send

Hi Paolo I am not sure what do you mean - "You do not need a reset vector ...". If so, where is the first instruction of the new CPU in the virtualization environment? Please help me understand that

Hi Leif,

Yes, this would be a new operation mode for QEMU, that only applies to hot-plugged CPUs. In this mode the AP doesn't reply to INIT or SMI, in fact it doesn't reply to anything at all. You do not

My comments below.