Re: [Qemu-devel] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
On 08/19/19 16:10, Paolo Bonzini wrote: > On 19/08/19 01:00, Yao, Jiewen wrote: >> 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. > > Indeed the SMRR would not cover the A-seg on real hardware. However, if > the chipset allowed aliasing A-seg SMRAM to 0x3, it would only be > used for SMBASE relocation of hotplugged CPU. The firmware would still > keep low SMRAM disabled, *except around SMBASE relocation of hotplugged > CPUs*. To avoid cache poisoning attacks, you only have to issue a > WBINVD before enabling low SMRAM and before disabling it. Hotplug SMI > is not a performance-sensitive path, so it's not a big deal. > > So I guess you agree that PCI DMA attacks are a potential vector also on > real hardware. As Alex pointed out, VT-d is not a solution because > there could be legitimate DMA happening during CPU hotplug. 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 reading here. Thanks!) > For OVMF > we'll probably go with Igor's idea, it would be nice if Intel chipsets > supported it too. :) So what is Igor's idea? Please do spoon-feed it to me. I've seen the POC patch but the memory region manipulation isn't obvious to me. Regarding TSEG, QEMU doesn't implement it differently from normal RAM. Instead, if memory serves, there is an extra "black hole" region that is overlaid, which hides the RAM contents when TSEG is supposed to be closed (and the guest is not running in SMM). But this time we're doing something else, right? Is the idea to overlay the RAM range at 0x3 with a window (alias) into the "compatible" SMRAM at 0xA-0xB? I don't know how the "compatible" SMRAM is implemented in QEMU. Does the compatible SMRAM behave in sync with TSEG? OVMF doesn't configure or touch compatible SMRAM at all, at the moment. Thanks Laszlo
Re: [Qemu-devel] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
On 19/08/19 01:00, Yao, Jiewen wrote: > 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. Indeed the SMRR would not cover the A-seg on real hardware. However, if the chipset allowed aliasing A-seg SMRAM to 0x3, it would only be used for SMBASE relocation of hotplugged CPU. The firmware would still keep low SMRAM disabled, *except around SMBASE relocation of hotplugged CPUs*. To avoid cache poisoning attacks, you only have to issue a WBINVD before enabling low SMRAM and before disabling it. Hotplug SMI is not a performance-sensitive path, so it's not a big deal. So I guess you agree that PCI DMA attacks are a potential vector also on real hardware. As Alex pointed out, VT-d is not a solution because there could be legitimate DMA happening during CPU hotplug. For OVMF we'll probably go with Igor's idea, it would be nice if Intel chipsets supported it too. :) Paolo
Re: [Qemu-devel] [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 写道： > >> 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 0x3...0x3 area is the only problematic one; > Igor's idea (or a variant, for example optionally remapping > 0xa..0xa SMRAM to 0x3) is becoming more and more attractive. > > Paolo
Re: [Qemu-devel] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
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 0x3...0x3 area is the only problematic one; Igor's idea (or a variant, for example optionally remapping 0xa..0xa SMRAM to 0x3) is becoming more and more attractive. Paolo
Re: [Qemu-devel] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
> -Original Message- > From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Saturday, August 17, 2019 6:20 AM > To: Laszlo Ersek > Cc: Yao, Jiewen ; Paolo Bonzini > ; de...@edk2.groups.io; edk2-rfc-groups-io > ; qemu devel list ; Igor > Mammedov ; Chen, Yingwen > ; Nakajima, Jun ; Boris > Ostrovsky ; Joao Marcal Lemos Martins > ; Phillip Goerl > Subject: Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF > > On Fri, 16 Aug 2019 22:15:15 +0200 > Laszlo Ersek wrote: > > > +Alex (direct question at the bottom) > > > > On 08/16/19 09:49, Yao, Jiewen wrote: > > > below > > > > > >> -Original Message- > > >> From: Paolo Bonzini [mailto:pbonz...@redhat.com] > > >> Sent: Friday, August 16, 2019 3:20 PM > > >> To: Yao, Jiewen ; Laszlo Ersek > > >> ; de...@edk2.groups.io > > >> Cc: edk2-rfc-groups-io ; qemu devel list > > >> ; Igor Mammedov > ; > > >> Chen, Yingwen ; Nakajima, Jun > > >> ; Boris Ostrovsky > ; > > >> Joao Marcal Lemos Martins ; Phillip > Goerl > > >> > > >> Subject: Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF > > >> > > >> On 16/08/19 04:46, Yao, Jiewen wrote: > > >>> Comment below: > > >>> > > >>> > > >>>> -Original Message- > > >>>> From: Paolo Bonzini [mailto:pbonz...@redhat.com] > > >>>> Sent: Friday, August 16, 2019 12:21 AM > > >>>> To: Laszlo Ersek ; de...@edk2.groups.io; Yao, > > >> Jiewen > > >>>> > > >>>> Cc: edk2-rfc-groups-io ; qemu devel list > > >>>> ; Igor Mammedov > > >> ; > > >>>> Chen, Yingwen ; Nakajima, Jun > > >>>> ; Boris Ostrovsky > > >> ; > > >>>> Joao Marcal Lemos Martins ; Phillip > Goerl > > >>>> > > >>>> Subject: Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF > > >>>> > > >>>> On 15/08/19 17:00, Laszlo Ersek wrote: > > >>>>> On 08/14/19 16:04, Paolo Bonzini wrote: > > >>>>>> On 14/08/19 15:20, Yao, Jiewen wrote: > > >>>>>>>> - Does this part require a new branch somewhere in the OVMF > SEC > > >>>> code? > > >>>>>>>> How do we determine whether the CPU executing SEC is BSP > or > > >>>>>>>> hot-plugged AP? > > >>>>>>> [Jiewen] I think this is blocked from hardware perspective, since > the > > >> first > > >>>> instruction. > > >>>>>>> There are some hardware specific registers can be used to > determine > > >> if > > >>>> the CPU is new added. > > >>>>>>> I don’t think this must be same as the real hardware. > > >>>>>>> You are free to invent some registers in device model to be used > in > > >>>> OVMF hot plug driver. > > >>>>>> > > >>>>>> 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. > > >>>>>> > > >>>>>>>> - How do we tell the hot-plugged AP where to start execution? > (I.e. > > >>>> that > > >>>>>>>> it should execute code at a particular pflash location.) > > >>>>>>> [Jiewen] Same real mode reset vector at :FFF0. > > >>>>>> > > >>>>>> You do not need a reset vector or INIT/SIPI/SIPI sequence at all in > > >>>>>> QEMU. The AP does not start execution at all when it is > unplugged, > > >> so > > >>>>>> no cache-as-RAM etc. > > >>>>>> > > >>>>>> We only need to modify QEMU so that hot-plugged APIs do not > reply > > >> to > > >>>>>> INIT/SIPI/SMI. > > >>>>>> > > >>>>>>> I don’t think there is problem for real hardware, who always has > CAR. > > >>>>>>> Can QEMU provide some CPU specific space, such as MMIO > region? > > >>&g
Re: [Qemu-devel] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
On Fri, 16 Aug 2019 22:15:15 +0200 Laszlo Ersek wrote: > +Alex (direct question at the bottom) > > On 08/16/19 09:49, Yao, Jiewen wrote: > > below > > > >> -Original Message- > >> From: Paolo Bonzini [mailto:pbonz...@redhat.com] > >> Sent: Friday, August 16, 2019 3:20 PM > >> To: Yao, Jiewen ; Laszlo Ersek > >> ; de...@edk2.groups.io > >> Cc: edk2-rfc-groups-io ; qemu devel list > >> ; Igor Mammedov ; > >> Chen, Yingwen ; Nakajima, Jun > >> ; Boris Ostrovsky ; > >> Joao Marcal Lemos Martins ; Phillip Goerl > >> > >> Subject: Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF > >> > >> On 16/08/19 04:46, Yao, Jiewen wrote: > >>> Comment below: > >>> > >>> > >>>> -Original Message- > >>>> From: Paolo Bonzini [mailto:pbonz...@redhat.com] > >>>> Sent: Friday, August 16, 2019 12:21 AM > >>>> To: Laszlo Ersek ; de...@edk2.groups.io; Yao, > >> Jiewen > >>>> > >>>> Cc: edk2-rfc-groups-io ; qemu devel list > >>>> ; Igor Mammedov > >> ; > >>>> Chen, Yingwen ; Nakajima, Jun > >>>> ; Boris Ostrovsky > >> ; > >>>> Joao Marcal Lemos Martins ; Phillip Goerl > >>>> > >>>> Subject: Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF > >>>> > >>>> On 15/08/19 17:00, Laszlo Ersek wrote: > >>>>> On 08/14/19 16:04, Paolo Bonzini wrote: > >>>>>> On 14/08/19 15:20, Yao, Jiewen wrote: > >>>>>>>> - Does this part require a new branch somewhere in the OVMF SEC > >>>> code? > >>>>>>>> How do we determine whether the CPU executing SEC is BSP or > >>>>>>>> hot-plugged AP? > >>>>>>> [Jiewen] I think this is blocked from hardware perspective, since the > >>>>>>> > >> first > >>>> instruction. > >>>>>>> There are some hardware specific registers can be used to determine > >> if > >>>> the CPU is new added. > >>>>>>> I don’t think this must be same as the real hardware. > >>>>>>> You are free to invent some registers in device model to be used in > >>>> OVMF hot plug driver. > >>>>>> > >>>>>> 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. > >>>>>> > >>>>>>>> - How do we tell the hot-plugged AP where to start execution? (I.e. > >>>> that > >>>>>>>> it should execute code at a particular pflash location.) > >>>>>>> [Jiewen] Same real mode reset vector at :FFF0. > >>>>>> > >>>>>> You do not need a reset vector or INIT/SIPI/SIPI sequence at all in > >>>>>> QEMU. The AP does not start execution at all when it is unplugged, > >> so > >>>>>> no cache-as-RAM etc. > >>>>>> > >>>>>> We only need to modify QEMU so that hot-plugged APIs do not reply > >> to > >>>>>> INIT/SIPI/SMI. > >>>>>> > >>>>>>> I don’t think there is problem for real hardware, who always has CAR. > >>>>>>> Can QEMU provide some CPU specific space, such as MMIO region? > >>>>>> > >>>>>> Why is a CPU-specific region needed if every other processor is in SMM > >>>>>> and thus trusted. > >>>>> > >>>>> 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 > >> board > >>>>> message to tell host CPU (GPIO->SCI) -- I am waiting for hot-add > >>>>> message." For that action, the new CPU may need a stack (minimally if > >> we > >>>>> want to use C function calls). > >>>>> > >>>>> Until step (03),
Re: [Qemu-devel] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
+Alex (direct question at the bottom) On 08/16/19 09:49, Yao, Jiewen wrote: > below > >> -Original Message- >> From: Paolo Bonzini [mailto:pbonz...@redhat.com] >> Sent: Friday, August 16, 2019 3:20 PM >> To: Yao, Jiewen ; Laszlo Ersek >> ; de...@edk2.groups.io >> Cc: edk2-rfc-groups-io ; qemu devel list >> ; Igor Mammedov ; >> Chen, Yingwen ; Nakajima, Jun >> ; Boris Ostrovsky ; >> Joao Marcal Lemos Martins ; Phillip Goerl >> >> Subject: Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF >> >> On 16/08/19 04:46, Yao, Jiewen wrote: >>> Comment below: >>> >>> >>>> -Original Message- >>>> From: Paolo Bonzini [mailto:pbonz...@redhat.com] >>>> Sent: Friday, August 16, 2019 12:21 AM >>>> To: Laszlo Ersek ; de...@edk2.groups.io; Yao, >> Jiewen >>>> >>>> Cc: edk2-rfc-groups-io ; qemu devel list >>>> ; Igor Mammedov >> ; >>>> Chen, Yingwen ; Nakajima, Jun >>>> ; Boris Ostrovsky >> ; >>>> Joao Marcal Lemos Martins ; Phillip Goerl >>>> >>>> Subject: Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF >>>> >>>> On 15/08/19 17:00, Laszlo Ersek wrote: >>>>> On 08/14/19 16:04, Paolo Bonzini wrote: >>>>>> On 14/08/19 15:20, Yao, Jiewen wrote: >>>>>>>> - Does this part require a new branch somewhere in the OVMF SEC >>>> code? >>>>>>>> How do we determine whether the CPU executing SEC is BSP or >>>>>>>> hot-plugged AP? >>>>>>> [Jiewen] I think this is blocked from hardware perspective, since the >> first >>>> instruction. >>>>>>> There are some hardware specific registers can be used to determine >> if >>>> the CPU is new added. >>>>>>> I don’t think this must be same as the real hardware. >>>>>>> You are free to invent some registers in device model to be used in >>>> OVMF hot plug driver. >>>>>> >>>>>> 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. >>>>>> >>>>>>>> - How do we tell the hot-plugged AP where to start execution? (I.e. >>>> that >>>>>>>> it should execute code at a particular pflash location.) >>>>>>> [Jiewen] Same real mode reset vector at :FFF0. >>>>>> >>>>>> You do not need a reset vector or INIT/SIPI/SIPI sequence at all in >>>>>> QEMU. The AP does not start execution at all when it is unplugged, >> so >>>>>> no cache-as-RAM etc. >>>>>> >>>>>> We only need to modify QEMU so that hot-plugged APIs do not reply >> to >>>>>> INIT/SIPI/SMI. >>>>>> >>>>>>> I don’t think there is problem for real hardware, who always has CAR. >>>>>>> Can QEMU provide some CPU specific space, such as MMIO region? >>>>>> >>>>>> Why is a CPU-specific region needed if every other processor is in SMM >>>>>> and thus trusted. >>>>> >>>>> 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 >> board >>>>> message to tell host CPU (GPIO->SCI) -- I am waiting for hot-add >>>>> message." For that action, the new CPU may need a stack (minimally if >> we >>>>> want to use C function calls). >>>>> >>>>> Until step (03), there had been no word about any other (= pre-plugged) >>>>> CPUs (more precisely, Jiewen even confirmed "No impact to other >>>>> processors"), so I didn't assume that other CPUs had entered SMM. >>>>> >>>>> Paolo, I've attempted to read Jiewen's response, and yours, as carefully >>>>> as I can. I'm still very confused. If you have a better understanding, >>>>> could you please write up the 15-step process from the thread starter >>>>> again, with all QEMU customizations applied? Such as, unnecessary >> steps >
Re: [Qemu-devel] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
On 08/15/19 18:21, Paolo Bonzini wrote: > On 15/08/19 17:00, Laszlo Ersek wrote: >> On 08/14/19 16:04, Paolo Bonzini wrote: >>> On 14/08/19 15:20, Yao, Jiewen wrote: > - Does this part require a new branch somewhere in the OVMF SEC code? > How do we determine whether the CPU executing SEC is BSP or > hot-plugged AP? [Jiewen] I think this is blocked from hardware perspective, since the first instruction. There are some hardware specific registers can be used to determine if the CPU is new added. I don’t think this must be same as the real hardware. You are free to invent some registers in device model to be used in OVMF hot plug driver. >>> >>> 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. >>> > - How do we tell the hot-plugged AP where to start execution? (I.e. that > it should execute code at a particular pflash location.) [Jiewen] Same real mode reset vector at :FFF0. >>> >>> You do not need a reset vector or INIT/SIPI/SIPI sequence at all in >>> QEMU. The AP does not start execution at all when it is unplugged, so >>> no cache-as-RAM etc. >>> >>> We only need to modify QEMU so that hot-plugged APIs do not reply to >>> INIT/SIPI/SMI. >>> I don’t think there is problem for real hardware, who always has CAR. Can QEMU provide some CPU specific space, such as MMIO region? >>> >>> Why is a CPU-specific region needed if every other processor is in SMM >>> and thus trusted. >> >> 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 board >> message to tell host CPU (GPIO->SCI) -- I am waiting for hot-add >> message." For that action, the new CPU may need a stack (minimally if we >> want to use C function calls). >> >> Until step (03), there had been no word about any other (= pre-plugged) >> CPUs (more precisely, Jiewen even confirmed "No impact to other >> processors"), so I didn't assume that other CPUs had entered SMM. >> >> Paolo, I've attempted to read Jiewen's response, and yours, as carefully >> as I can. I'm still very confused. If you have a better understanding, >> could you please write up the 15-step process from the thread starter >> again, with all QEMU customizations applied? Such as, unnecessary steps >> removed, and platform specifics filled in. > > Sure. > > (01a) QEMU: create new CPU. The CPU already exists, but it does not > start running code until unparked by the CPU hotplug controller. > > (01b) QEMU: trigger SCI > > (02-03) no equivalent > > (04) Host CPU: (OS) execute GPE handler from DSDT > > (05) Host CPU: (OS) Port 0xB2 write, all CPUs enter SMM (NOTE: New CPU > will not enter CPU because SMI is disabled) > > (06) Host CPU: (SMM) Save 38000, Update 38000 -- fill simple SMM > rebase code. (Could Intel open source code for this?) > (07a) Host CPU: (SMM) Write to CPU hotplug controller to enable > new CPU > > (07b) Host CPU: (SMM) Send INIT/SIPI/SIPI to new CPU. > > (08a) New CPU: (Low RAM) Enter protected mode. PCI DMA attack might be relevant (but yes, I see you've mentioned that too, down-thread) > > (08b) New CPU: (Flash) Signals host CPU to proceed and enter cli;hlt loop. > > (09) Host CPU: (SMM) Send SMI to the new CPU only. > > (10) New CPU: (SMM) Run SMM code at 38000, and rebase SMBASE to > TSEG. I wish we could simply wake the new CPU -- after step 07a -- with an SMI. IOW, if we could excise steps 07b, 08a, 08b. Our CPU hotplug controller, and the initial parked state in 01a for the new CPU, are going to be home-brewed anyway. On the other hand... > (11) Host CPU: (SMM) Restore 38000. > > (12) Host CPU: (SMM) Update located data structure to add the new CPU > information. (This step will involve CPU_SERVICE protocol) > > (13) New CPU: (Flash) do whatever other initialization is needed > > (14) New CPU: (Flash) Deadloop, and wait for INIT-SIPI-SIPI. basically step 08b is the environment to which the new CPU returns in 13/14, after the RSM. Do we absolutely need low RAM for 08a (for entering protected mode)? we could execute from pflash, no? OTOH we'd still need RAM for the stack, and that could be attacked with PCI DMA similarly. I believe. > (15) Host CPU: (OS) Send INIT-SIPI-SIPI to pull new CPU in.. > > > In other words, the cache-as-RAM phase of 02-03 is replaced by the > INIT-SIPI-SIPI sequence of 07b-08a-08b. > > >>> The QEMU DSDT could be modified (when secure boot is in effect) to OUT >>> to 0xB2 when hotplug happens. It could write a well-known value to >>> 0xB2, to be read by an SMI handler in edk2. >> >> I dislike involving QEMU's generated DSDT in anything SMM (even >> injecting the SMI), because the AML interpreter runs in the
Re: [Qemu-devel] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
below > -Original Message- > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: Friday, August 16, 2019 3:20 PM > To: Yao, Jiewen ; Laszlo Ersek > ; de...@edk2.groups.io > Cc: edk2-rfc-groups-io ; qemu devel list > ; Igor Mammedov ; > Chen, Yingwen ; Nakajima, Jun > ; Boris Ostrovsky ; > Joao Marcal Lemos Martins ; Phillip Goerl > > Subject: Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF > > On 16/08/19 04:46, Yao, Jiewen wrote: > > Comment below: > > > > > >> -Original Message- > >> From: Paolo Bonzini [mailto:pbonz...@redhat.com] > >> Sent: Friday, August 16, 2019 12:21 AM > >> To: Laszlo Ersek ; de...@edk2.groups.io; Yao, > Jiewen > >> > >> Cc: edk2-rfc-groups-io ; qemu devel list > >> ; Igor Mammedov > ; > >> Chen, Yingwen ; Nakajima, Jun > >> ; Boris Ostrovsky > ; > >> Joao Marcal Lemos Martins ; Phillip Goerl > >> > >> Subject: Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF > >> > >> On 15/08/19 17:00, Laszlo Ersek wrote: > >>> On 08/14/19 16:04, Paolo Bonzini wrote: > >>>> On 14/08/19 15:20, Yao, Jiewen wrote: > >>>>>> - Does this part require a new branch somewhere in the OVMF SEC > >> code? > >>>>>> How do we determine whether the CPU executing SEC is BSP or > >>>>>> hot-plugged AP? > >>>>> [Jiewen] I think this is blocked from hardware perspective, since the > first > >> instruction. > >>>>> There are some hardware specific registers can be used to determine > if > >> the CPU is new added. > >>>>> I don’t think this must be same as the real hardware. > >>>>> You are free to invent some registers in device model to be used in > >> OVMF hot plug driver. > >>>> > >>>> 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. > >>>> > >>>>>> - How do we tell the hot-plugged AP where to start execution? (I.e. > >> that > >>>>>> it should execute code at a particular pflash location.) > >>>>> [Jiewen] Same real mode reset vector at :FFF0. > >>>> > >>>> You do not need a reset vector or INIT/SIPI/SIPI sequence at all in > >>>> QEMU. The AP does not start execution at all when it is unplugged, > so > >>>> no cache-as-RAM etc. > >>>> > >>>> We only need to modify QEMU so that hot-plugged APIs do not reply > to > >>>> INIT/SIPI/SMI. > >>>> > >>>>> I don’t think there is problem for real hardware, who always has CAR. > >>>>> Can QEMU provide some CPU specific space, such as MMIO region? > >>>> > >>>> Why is a CPU-specific region needed if every other processor is in SMM > >>>> and thus trusted. > >>> > >>> 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 > board > >>> message to tell host CPU (GPIO->SCI) -- I am waiting for hot-add > >>> message." For that action, the new CPU may need a stack (minimally if > we > >>> want to use C function calls). > >>> > >>> Until step (03), there had been no word about any other (= pre-plugged) > >>> CPUs (more precisely, Jiewen even confirmed "No impact to other > >>> processors"), so I didn't assume that other CPUs had entered SMM. > >>> > >>> Paolo, I've attempted to read Jiewen's response, and yours, as carefully > >>> as I can. I'm still very confused. If you have a better understanding, > >>> could you please write up the 15-step process from the thread starter > >>> again, with all QEMU customizations applied? Such as, unnecessary > steps > >>> removed, and platform specifics filled in. > >> > >> Sure. > >> > >> (01a) QEMU: create new CPU. The CPU already exists, but it does not > >> start running code until unparked by the CPU hotplug controller. > >> > >> (01b) QEMU: trigger SCI > >> > >> (02-03) no equivalent > >> > >&g
Re: [Qemu-devel] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
On 16/08/19 04:46, Yao, Jiewen wrote: > Comment below: > > >> -Original Message- >> From: Paolo Bonzini [mailto:pbonz...@redhat.com] >> Sent: Friday, August 16, 2019 12:21 AM >> To: Laszlo Ersek ; de...@edk2.groups.io; Yao, Jiewen >> >> Cc: edk2-rfc-groups-io ; qemu devel list >> ; Igor Mammedov ; >> Chen, Yingwen ; Nakajima, Jun >> ; Boris Ostrovsky ; >> Joao Marcal Lemos Martins ; Phillip Goerl >> >> Subject: Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF >> >> On 15/08/19 17:00, Laszlo Ersek wrote: >>> On 08/14/19 16:04, Paolo Bonzini wrote: >>>> On 14/08/19 15:20, Yao, Jiewen wrote: >>>>>> - Does this part require a new branch somewhere in the OVMF SEC >> code? >>>>>> How do we determine whether the CPU executing SEC is BSP or >>>>>> hot-plugged AP? >>>>> [Jiewen] I think this is blocked from hardware perspective, since the >>>>> first >> instruction. >>>>> There are some hardware specific registers can be used to determine if >> the CPU is new added. >>>>> I don’t think this must be same as the real hardware. >>>>> You are free to invent some registers in device model to be used in >> OVMF hot plug driver. >>>> >>>> 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. >>>> >>>>>> - How do we tell the hot-plugged AP where to start execution? (I.e. >> that >>>>>> it should execute code at a particular pflash location.) >>>>> [Jiewen] Same real mode reset vector at :FFF0. >>>> >>>> You do not need a reset vector or INIT/SIPI/SIPI sequence at all in >>>> QEMU. The AP does not start execution at all when it is unplugged, so >>>> no cache-as-RAM etc. >>>> >>>> We only need to modify QEMU so that hot-plugged APIs do not reply to >>>> INIT/SIPI/SMI. >>>> >>>>> I don’t think there is problem for real hardware, who always has CAR. >>>>> Can QEMU provide some CPU specific space, such as MMIO region? >>>> >>>> Why is a CPU-specific region needed if every other processor is in SMM >>>> and thus trusted. >>> >>> 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 board >>> message to tell host CPU (GPIO->SCI) -- I am waiting for hot-add >>> message." For that action, the new CPU may need a stack (minimally if we >>> want to use C function calls). >>> >>> Until step (03), there had been no word about any other (= pre-plugged) >>> CPUs (more precisely, Jiewen even confirmed "No impact to other >>> processors"), so I didn't assume that other CPUs had entered SMM. >>> >>> Paolo, I've attempted to read Jiewen's response, and yours, as carefully >>> as I can. I'm still very confused. If you have a better understanding, >>> could you please write up the 15-step process from the thread starter >>> again, with all QEMU customizations applied? Such as, unnecessary steps >>> removed, and platform specifics filled in. >> >> Sure. >> >> (01a) QEMU: create new CPU. The CPU already exists, but it does not >> start running code until unparked by the CPU hotplug controller. >> >> (01b) QEMU: trigger SCI >> >> (02-03) no equivalent >> >> (04) Host CPU: (OS) execute GPE handler from DSDT >> >> (05) Host CPU: (OS) Port 0xB2 write, all CPUs enter SMM (NOTE: New CPU >> will not enter CPU because SMI is disabled) >> >> (06) Host CPU: (SMM) Save 38000, Update 38000 -- fill simple SMM >> rebase code. >> >> (07a) Host CPU: (SMM) Write to CPU hotplug controller to enable >> new CPU >> >> (07b) Host CPU: (SMM) Send INIT/SIPI/SIPI to new CPU. > [Jiewen] NOTE: INIT/SIPI/SIPI can be sent by a malicious CPU. There is no > restriction that INIT/SIPI/SIPI can only be sent in SMM. All of the CPUs are now in SMM, and INIT/SIPI/SIPI will be discarded before 07a, so this is okay. However I do see a problem, because a PCI device's DMA could overwrite 0x38000 between (06) and (10) and hijack the code that is executed in SMM. How is this avoided on re
Re: [Qemu-devel] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
Comment below: > -Original Message- > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: Friday, August 16, 2019 12:21 AM > To: Laszlo Ersek ; de...@edk2.groups.io; Yao, Jiewen > > Cc: edk2-rfc-groups-io ; qemu devel list > ; Igor Mammedov ; > Chen, Yingwen ; Nakajima, Jun > ; Boris Ostrovsky ; > Joao Marcal Lemos Martins ; Phillip Goerl > > Subject: Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF > > On 15/08/19 17:00, Laszlo Ersek wrote: > > On 08/14/19 16:04, Paolo Bonzini wrote: > >> On 14/08/19 15:20, Yao, Jiewen wrote: > >>>> - Does this part require a new branch somewhere in the OVMF SEC > code? > >>>> How do we determine whether the CPU executing SEC is BSP or > >>>> hot-plugged AP? > >>> [Jiewen] I think this is blocked from hardware perspective, since the > >>> first > instruction. > >>> There are some hardware specific registers can be used to determine if > the CPU is new added. > >>> I don’t think this must be same as the real hardware. > >>> You are free to invent some registers in device model to be used in > OVMF hot plug driver. > >> > >> 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. > >> > >>>> - How do we tell the hot-plugged AP where to start execution? (I.e. > that > >>>> it should execute code at a particular pflash location.) > >>> [Jiewen] Same real mode reset vector at :FFF0. > >> > >> You do not need a reset vector or INIT/SIPI/SIPI sequence at all in > >> QEMU. The AP does not start execution at all when it is unplugged, so > >> no cache-as-RAM etc. > >> > >> We only need to modify QEMU so that hot-plugged APIs do not reply to > >> INIT/SIPI/SMI. > >> > >>> I don’t think there is problem for real hardware, who always has CAR. > >>> Can QEMU provide some CPU specific space, such as MMIO region? > >> > >> Why is a CPU-specific region needed if every other processor is in SMM > >> and thus trusted. > > > > 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 board > > message to tell host CPU (GPIO->SCI) -- I am waiting for hot-add > > message." For that action, the new CPU may need a stack (minimally if we > > want to use C function calls). > > > > Until step (03), there had been no word about any other (= pre-plugged) > > CPUs (more precisely, Jiewen even confirmed "No impact to other > > processors"), so I didn't assume that other CPUs had entered SMM. > > > > Paolo, I've attempted to read Jiewen's response, and yours, as carefully > > as I can. I'm still very confused. If you have a better understanding, > > could you please write up the 15-step process from the thread starter > > again, with all QEMU customizations applied? Such as, unnecessary steps > > removed, and platform specifics filled in. > > Sure. > > (01a) QEMU: create new CPU. The CPU already exists, but it does not > start running code until unparked by the CPU hotplug controller. > > (01b) QEMU: trigger SCI > > (02-03) no equivalent > > (04) Host CPU: (OS) execute GPE handler from DSDT > > (05) Host CPU: (OS) Port 0xB2 write, all CPUs enter SMM (NOTE: New CPU > will not enter CPU because SMI is disabled) > > (06) Host CPU: (SMM) Save 38000, Update 38000 -- fill simple SMM > rebase code. > > (07a) Host CPU: (SMM) Write to CPU hotplug controller to enable > new CPU > > (07b) Host CPU: (SMM) Send INIT/SIPI/SIPI to new CPU. [Jiewen] NOTE: INIT/SIPI/SIPI can be sent by a malicious CPU. There is no restriction that INIT/SIPI/SIPI can only be sent in SMM. > (08a) New CPU: (Low RAM) Enter protected mode. [Jiewen] NOTE: The new CPU still cannot use any physical memory, because the INIT/SIPI/SIPI may be sent by malicious CPU in non-SMM environment. > (08b) New CPU: (Flash) Signals host CPU to proceed and enter cli;hlt loop. > > (09) Host CPU: (SMM) Send SMI to the new CPU only. > > (10) New CPU: (SMM) Run SMM code at 38000, and rebase SMBASE to > TSEG. > > (11) Host CPU: (SMM) Restore 38000. > > (12) Host CPU: (SMM) Update located data structure to add the new CPU > information. (This step will involve CPU_SERVICE
Re: [Qemu-devel] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
On 15/08/19 17:00, Laszlo Ersek wrote: > On 08/14/19 16:04, Paolo Bonzini wrote: >> On 14/08/19 15:20, Yao, Jiewen wrote: - Does this part require a new branch somewhere in the OVMF SEC code? How do we determine whether the CPU executing SEC is BSP or hot-plugged AP? >>> [Jiewen] I think this is blocked from hardware perspective, since the first >>> instruction. >>> There are some hardware specific registers can be used to determine if the >>> CPU is new added. >>> I don’t think this must be same as the real hardware. >>> You are free to invent some registers in device model to be used in OVMF >>> hot plug driver. >> >> 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. >> - How do we tell the hot-plugged AP where to start execution? (I.e. that it should execute code at a particular pflash location.) >>> [Jiewen] Same real mode reset vector at :FFF0. >> >> You do not need a reset vector or INIT/SIPI/SIPI sequence at all in >> QEMU. The AP does not start execution at all when it is unplugged, so >> no cache-as-RAM etc. >> >> We only need to modify QEMU so that hot-plugged APIs do not reply to >> INIT/SIPI/SMI. >> >>> I don’t think there is problem for real hardware, who always has CAR. >>> Can QEMU provide some CPU specific space, such as MMIO region? >> >> Why is a CPU-specific region needed if every other processor is in SMM >> and thus trusted. > > 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 board > message to tell host CPU (GPIO->SCI) -- I am waiting for hot-add > message." For that action, the new CPU may need a stack (minimally if we > want to use C function calls). > > Until step (03), there had been no word about any other (= pre-plugged) > CPUs (more precisely, Jiewen even confirmed "No impact to other > processors"), so I didn't assume that other CPUs had entered SMM. > > Paolo, I've attempted to read Jiewen's response, and yours, as carefully > as I can. I'm still very confused. If you have a better understanding, > could you please write up the 15-step process from the thread starter > again, with all QEMU customizations applied? Such as, unnecessary steps > removed, and platform specifics filled in. Sure. (01a) QEMU: create new CPU. The CPU already exists, but it does not start running code until unparked by the CPU hotplug controller. (01b) QEMU: trigger SCI (02-03) no equivalent (04) Host CPU: (OS) execute GPE handler from DSDT (05) Host CPU: (OS) Port 0xB2 write, all CPUs enter SMM (NOTE: New CPU will not enter CPU because SMI is disabled) (06) Host CPU: (SMM) Save 38000, Update 38000 -- fill simple SMM rebase code. (07a) Host CPU: (SMM) Write to CPU hotplug controller to enable new CPU (07b) Host CPU: (SMM) Send INIT/SIPI/SIPI to new CPU. (08a) New CPU: (Low RAM) Enter protected mode. (08b) New CPU: (Flash) Signals host CPU to proceed and enter cli;hlt loop. (09) Host CPU: (SMM) Send SMI to the new CPU only. (10) New CPU: (SMM) Run SMM code at 38000, and rebase SMBASE to TSEG. (11) Host CPU: (SMM) Restore 38000. (12) Host CPU: (SMM) Update located data structure to add the new CPU information. (This step will involve CPU_SERVICE protocol) (13) New CPU: (Flash) do whatever other initialization is needed (14) New CPU: (Flash) Deadloop, and wait for INIT-SIPI-SIPI. (15) Host CPU: (OS) Send INIT-SIPI-SIPI to pull new CPU in.. In other words, the cache-as-RAM phase of 02-03 is replaced by the INIT-SIPI-SIPI sequence of 07b-08a-08b. >> The QEMU DSDT could be modified (when secure boot is in effect) to OUT >> to 0xB2 when hotplug happens. It could write a well-known value to >> 0xB2, to be read by an SMI handler in edk2. > > I dislike involving QEMU's generated DSDT in anything SMM (even > injecting the SMI), because the AML interpreter runs in the OS. > > If a malicious OS kernel is a bit too enlightened about the DSDT, it > could willfully diverge from the process that we design. If QEMU > broadcast the SMI internally, the guest OS could not interfere with that. > > If the purpose of the SMI is specifically to force all CPUs into SMM > (and thereby force them into trusted state), then the OS would be > explicitly counter-interested in carrying out the AML operations from > QEMU's DSDT. But since the hotplug controller would only be accessible from SMM, there would be no other way to invoke it than to follow the DSDT's instruction and write to 0xB2. FWIW, real hardware also has plenty of 0xB2 writes in the DSDT or in APEI tables (e.g. for persistent store access). Paolo
Re: [Qemu-devel] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
On Thu, 15 Aug 2019 17:00:16 +0200 Laszlo Ersek wrote: > On 08/14/19 16:04, Paolo Bonzini wrote: > > On 14/08/19 15:20, Yao, Jiewen wrote: > >>> - Does this part require a new branch somewhere in the OVMF SEC code? > >>> How do we determine whether the CPU executing SEC is BSP or > >>> hot-plugged AP? > >> [Jiewen] I think this is blocked from hardware perspective, since the > >> first instruction. > >> There are some hardware specific registers can be used to determine if the > >> CPU is new added. > >> I don’t think this must be same as the real hardware. > >> You are free to invent some registers in device model to be used in OVMF > >> hot plug driver. > > > > 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. > > > >>> - How do we tell the hot-plugged AP where to start execution? (I.e. that > >>> it should execute code at a particular pflash location.) > >> [Jiewen] Same real mode reset vector at :FFF0. > > > > You do not need a reset vector or INIT/SIPI/SIPI sequence at all in > > QEMU. The AP does not start execution at all when it is unplugged, so > > no cache-as-RAM etc. > > > > We only need to modify QEMU so that hot-plugged APIs do not reply to > > INIT/SIPI/SMI. > > > >> I don’t think there is problem for real hardware, who always has CAR. > >> Can QEMU provide some CPU specific space, such as MMIO region? > > > > Why is a CPU-specific region needed if every other processor is in SMM > > and thus trusted. > > 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 board > message to tell host CPU (GPIO->SCI) -- I am waiting for hot-add > message." For that action, the new CPU may need a stack (minimally if we > want to use C function calls). > > Until step (03), there had been no word about any other (= pre-plugged) > CPUs (more precisely, Jiewen even confirmed "No impact to other > processors"), so I didn't assume that other CPUs had entered SMM. > > Paolo, I've attempted to read Jiewen's response, and yours, as carefully > as I can. I'm still very confused. If you have a better understanding, > could you please write up the 15-step process from the thread starter > again, with all QEMU customizations applied? Such as, unnecessary steps > removed, and platform specifics filled in. > > One more comment below: > > > > >>> Does CPU hotplug apply only at the socket level? If the CPU is > >>> multi-core, what is responsible for hot-plugging all cores present in > >>> the socket? > > > > I can answer this: the SMM handler would interact with the hotplug > > controller in the same way that ACPI DSDT does normally. This supports > > multiple hotplugs already. > > > > Writes to the hotplug controller from outside SMM would be ignored. > > > (03) New CPU: (Flash) send board message to tell host CPU (GPIO->SCI) > -- I am waiting for hot-add message. > >>> > >>> Maybe we can simplify this in QEMU by broadcasting an SMI to existent > >>> processors immediately upon plugging the new CPU. > > > > The QEMU DSDT could be modified (when secure boot is in effect) to OUT > > to 0xB2 when hotplug happens. It could write a well-known value to > > 0xB2, to be read by an SMI handler in edk2. > > (My comment below is general, and may not apply to this particular > situation. I'm too confused to figure that out myself, sorry!) > > I dislike involving QEMU's generated DSDT in anything SMM (even > injecting the SMI), because the AML interpreter runs in the OS. > > If a malicious OS kernel is a bit too enlightened about the DSDT, it > could willfully diverge from the process that we design. If QEMU > broadcast the SMI internally, the guest OS could not interfere with that. > > If the purpose of the SMI is specifically to force all CPUs into SMM > (and thereby force them into trusted state), then the OS would be > explicitly counter-interested in carrying out the AML operations from > QEMU's DSDT. 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) CPU. The worst that could happen is that new cpu will stay parked. > I'd be OK with an SMM / SMI involvement in QEMU's DSDT if, by diverging > from that DSDT, the OS kernel could only mess with its own state, and > not with the firmware's. > > Thanks > Laszlo > > > > > > >>> > (NOTE: Host CPU can only > >>> send > instruction in SMM mode. -- The register is SMM only) > >>> > >>> Sorry, I don't follow -- what register are we talking about here, and > >>> why is the BSP needed to send anything at all? What "instruction" do you > >>> have in
Re: [Qemu-devel] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
On 08/14/19 16:04, Paolo Bonzini wrote: > On 14/08/19 15:20, Yao, Jiewen wrote: >>> - Does this part require a new branch somewhere in the OVMF SEC code? >>> How do we determine whether the CPU executing SEC is BSP or >>> hot-plugged AP? >> [Jiewen] I think this is blocked from hardware perspective, since the first >> instruction. >> There are some hardware specific registers can be used to determine if the >> CPU is new added. >> I don’t think this must be same as the real hardware. >> You are free to invent some registers in device model to be used in OVMF hot >> plug driver. > > 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. > >>> - How do we tell the hot-plugged AP where to start execution? (I.e. that >>> it should execute code at a particular pflash location.) >> [Jiewen] Same real mode reset vector at :FFF0. > > You do not need a reset vector or INIT/SIPI/SIPI sequence at all in > QEMU. The AP does not start execution at all when it is unplugged, so > no cache-as-RAM etc. > > We only need to modify QEMU so that hot-plugged APIs do not reply to > INIT/SIPI/SMI. > >> I don’t think there is problem for real hardware, who always has CAR. >> Can QEMU provide some CPU specific space, such as MMIO region? > > Why is a CPU-specific region needed if every other processor is in SMM > and thus trusted. 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 board message to tell host CPU (GPIO->SCI) -- I am waiting for hot-add message." For that action, the new CPU may need a stack (minimally if we want to use C function calls). Until step (03), there had been no word about any other (= pre-plugged) CPUs (more precisely, Jiewen even confirmed "No impact to other processors"), so I didn't assume that other CPUs had entered SMM. Paolo, I've attempted to read Jiewen's response, and yours, as carefully as I can. I'm still very confused. If you have a better understanding, could you please write up the 15-step process from the thread starter again, with all QEMU customizations applied? Such as, unnecessary steps removed, and platform specifics filled in. One more comment below: > >>> Does CPU hotplug apply only at the socket level? If the CPU is >>> multi-core, what is responsible for hot-plugging all cores present in >>> the socket? > > I can answer this: the SMM handler would interact with the hotplug > controller in the same way that ACPI DSDT does normally. This supports > multiple hotplugs already. > > Writes to the hotplug controller from outside SMM would be ignored. > (03) New CPU: (Flash) send board message to tell host CPU (GPIO->SCI) -- I am waiting for hot-add message. >>> >>> Maybe we can simplify this in QEMU by broadcasting an SMI to existent >>> processors immediately upon plugging the new CPU. > > The QEMU DSDT could be modified (when secure boot is in effect) to OUT > to 0xB2 when hotplug happens. It could write a well-known value to > 0xB2, to be read by an SMI handler in edk2. (My comment below is general, and may not apply to this particular situation. I'm too confused to figure that out myself, sorry!) I dislike involving QEMU's generated DSDT in anything SMM (even injecting the SMI), because the AML interpreter runs in the OS. If a malicious OS kernel is a bit too enlightened about the DSDT, it could willfully diverge from the process that we design. If QEMU broadcast the SMI internally, the guest OS could not interfere with that. If the purpose of the SMI is specifically to force all CPUs into SMM (and thereby force them into trusted state), then the OS would be explicitly counter-interested in carrying out the AML operations from QEMU's DSDT. I'd be OK with an SMM / SMI involvement in QEMU's DSDT if, by diverging from that DSDT, the OS kernel could only mess with its own state, and not with the firmware's. Thanks Laszlo > > >>> (NOTE: Host CPU can only >>> send instruction in SMM mode. -- The register is SMM only) >>> >>> Sorry, I don't follow -- what register are we talking about here, and >>> why is the BSP needed to send anything at all? What "instruction" do you >>> have in mind? >> [Jiewen] The new CPU does not enable SMI at reset. >> At some point of time later, the CPU need enable SMI, right? >> The "instruction" here means, the host CPUs need tell to CPU to enable SMI. > > Right, this would be a write to the CPU hotplug controller > (04) Host CPU: (OS) get message from board that a new CPU is added. (GPIO -> SCI) (05) Host CPU: (OS) All CPUs enter SMM (SCI->SWSMI) (NOTE: New CPU will not enter CPU because SMI is disabled) >>> >>> I don't understand the
