RE: [PATCH 3/3] hw/nvme: Add SPDM over DOE support
Comment on subjectAltName.
PCI-SIG realized that it may cause problem for certain device and decided to
remove such requirement in future ECN.
I don't think that is absolutely needed.
> -Original Message-
> From: Lukas Wunner
> Sent: Monday, October 2, 2023 4:48 PM
> To: Alistair Francis
> Cc: wilfred.mall...@wdc.com; jonathan.came...@huawei.com; Yao, Jiewen
> ; qemu-devel@nongnu.org; kbu...@kernel.org;
> i...@irrelevant.dk; m...@redhat.com; marcel.apfelb...@gmail.com;
> hch...@avery-design.com.tw; Browy, Chris ; qemu-
> bl...@nongnu.org; Alistair Francis
> Subject: Re: [PATCH 3/3] hw/nvme: Add SPDM over DOE support
>
> On Fri, Sep 15, 2023 at 09:27:23PM +1000, Alistair Francis wrote:
> > --- /dev/null
> > +++ b/docs/specs/spdm.rst
> > @@ -0,0 +1,56 @@
> > +==
> > +QEMU Security Protocols and Data Models (SPDM) Support
> > +==
> > +
> > +SPDM enables authentication, attestation and key exchange to assist in
> > +providing infrastructure security enablement. It's a standard published
> > +by the DMTF https://www.dmtf.org/standards/SPDM.
> > +
> > +Setting up a SPDM server
> [...]
> > +$ cd spdm-emu
> > +$ git submodule init; git submodule update --recursive
> > +$ mkdir build; cd build
> > +$ cmake -DARCH=x64 -DTOOLCHAIN=GCC -DTARGET=Debug -
> DCRYPTO=openssl ..
> > +$ make -j32
> > +$ make copy_sample_key # Build certificates, required for SPDM
> authentication.
>
> Might be worth pointing out that certificates need to have a
> Subject Alternative Name in compliance with PCIe r6.1 sec 6.31.3,
> what to add to openssl.cnf to get one, e.g. ...
>
> subjectAltName =
> otherName:2.23.147;UTF8:Vendor=1b36:Device=0010:CC=010802:REV=02:SSVI
> D=1af4:SSID=1100
> 2.23.147 = ASN1:OID:2.23.147
>
> ... and how to regenerate certificates after modifying openssl.cnf, e.g. ...
>
> $ openssl req -nodes -newkey ec:param.pem -keyout end_responder.key -out
> end_responder.req -sha384 -batch -subj "/CN=DMTF libspdm ECP384 responder
> cert"
> $ openssl x509 -req -in end_responder.req -out end_responder.cert -CA
> inter.cert -CAkey inter.key -sha384 -days 3650 -set_serial 3 -extensions
> v3_end -
> extfile ../openssl.cnf
> $ openssl asn1parse -in end_responder.cert -out end_responder.cert.der
> $ cat ca.cert.der inter.cert.der end_responder.cert.der >
> bundle_responder.certchain.der
>
> Or preferably modify upstream libspdm to automate this process,
> make it less cumbersome and error-prone.
>
>
> > +static bool pcie_doe_spdm_rsp(DOECap *doe_cap)
> > +{
> > +void *req = pcie_doe_get_write_mbox_ptr(doe_cap);
> > +uint32_t req_len = pcie_doe_get_obj_len(req) * 4;
> > +void *rsp = doe_cap->read_mbox;
> > +uint32_t rsp_len = SPDM_SOCKET_MAX_MESSAGE_BUFFER_SIZE;
> > +uint32_t recvd;
>
> Might be worth mentioning somewhere that this only implements the
> responder role.
>
> CPUs are coming to market which contain a Trusted Security Module.
> Some of those TSMs are capable of the SPDM requester role. Should
> qemu ever have the need to emulate a CPU containing a TSM, it may
> become necessary to add SPDM requester support.
>
> Thanks,
>
> Lukas
RE: [edk2-devel] [Qemu-devel] [PATCH 1/2] q35: implement 128K SMRAM at default SMBASE address
below > -Original Message- > From: de...@edk2.groups.io On Behalf Of Igor > Mammedov > Sent: Monday, September 30, 2019 8:37 PM > To: Laszlo Ersek > Cc: de...@edk2.groups.io; qemu-devel@nongnu.org; Chen, Yingwen > ; phillip.go...@oracle.com; > alex.william...@redhat.com; Yao, Jiewen ; Nakajima, > Jun ; Kinney, Michael D > ; pbonz...@redhat.com; > boris.ostrov...@oracle.com; r...@edk2.groups.io; joao.m.mart...@oracle.com; > Brijesh Singh > Subject: Re: [edk2-devel] [Qemu-devel] [PATCH 1/2] q35: implement 128K > SMRAM at default SMBASE address > > On Mon, 30 Sep 2019 13:51:46 +0200 > "Laszlo Ersek" wrote: > > > Hi Igor, > > > > On 09/24/19 13:19, Igor Mammedov wrote: > > > On Mon, 23 Sep 2019 20:35:02 +0200 > > > "Laszlo Ersek" wrote: > > > > >> I've got good results. For this (1/2) QEMU patch: > > >> > > >> Tested-by: Laszlo Ersek > > >> > > >> I tested the following scenarios. In every case, I verified the OVMF > > >> log, and also the "info mtree" monitor command's result (i.e. whether > > >> "smbase-blackhole" / "smbase-window" were disabled or enabled). > > >> Mostly, I diffed these text files between the test scenarios (looking > > >> for desired / undesired differences). In the Linux guests, I checked > > >> / compared the dmesg too (wrt. the UEFI memmap). > > >> > > >> - unpatched OVMF (regression test), Fedora guest, normal boot and S3 > > >> > > >> - patched OVMF, but feature disabled with "-global > > >> mch.smbase-smram=off" (another regression test), Fedora guest, > > >> normal boot and S3 > > >> > > >> - patched OVMF, feature enabled, Fedora and various Windows guests > > >> (win7, win8, win10 families, client/server), normal boot and S3 > > >> > > >> - a subset of the above guests, with S3 disabled (-global > > >> ICH9-LPC.disable_s3=1), and obviously S3 resume not tested > > >> > > >> SEV: used 5.2-ish Linux guest, with S3 disabled (no support under SEV > > >> for that now): > > >> > > >> - unpatched OVMF (regression test), normal boot > > >> > > >> - patched OVMF but feature disabled on the QEMU cmdline (another > > >> regression test), normal boot > > >> > > >> - patched OVMF, feature enabled, normal boot. > > >> > > >> I plan to post the OVMF patches tomorrow, for discussion. > > >> > > >> (It's likely too early to push these QEMU / edk2 patches right now -- > > >> we don't know yet if this path will take us to the destination. For > > >> now, it certainly looks great.) > > > > > > Laszlo, thanks for trying it out. > > > It's nice to hear that approach is somewhat usable. > > > Hopefully we won't have to invent 'paused' cpu mode. > > > > > > Pls CC me on your patches > > > (not that I qualify for reviewing, > > > but may be I could learn a thing or two from it) > > > > Considering the plan at [1], the two patch sets [2] [3] should cover > > step (01); at least as proof of concept. > > > > [1] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF > > http://mid.mail-archive.com/20190830164802.1b17ff26@redhat.com > > > > [2] The current thread: > > [Qemu-devel] [PATCH 0/2] q35: mch: allow to lock down 128K RAM at > default SMBASE address > > http://mid.mail-archive.com/20190917130708.10281-1- > imamm...@redhat.com > > > > [3] [edk2-devel] [PATCH wave 1 00/10] support QEMU's "SMRAM at default > SMBASE" feature > > http://mid.mail-archive.com/20190924113505.27272-1-lersek@redhat.com > > > > (I'll have to figure out what SMI handler to put in place there, but I'd > > like to experiment with that once we can cause a new CPU to start > > executing code there, in SMM.) > > > > So what's next? > > > > To me it looks like we need to figure out how QEMU can make the OS call > > into SMM (in the GPE cpu hotplug handler), passing in parameters and > > such. This would be step (03). > > > > Do you agree? > > > > If so, I'll ask Jiewen about such OS->SMM calls separately, because I > > seem to remember that there used to be an "SMM communcation table" of > > sorts, for flexible OS->SMM calls. However, it appears to be deprecated > > lately. > we can try to resurrect and put over
Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
I give my thought. Paolo may add more. > -Original Message- > From: Kinney, Michael D > Sent: Friday, August 23, 2019 11:25 PM > To: Yao, Jiewen ; Paolo Bonzini > ; Laszlo Ersek ; > r...@edk2.groups.io; Kinney, Michael D > Cc: Alex Williamson ; de...@edk2.groups.io; > qemu devel list ; Igor Mammedov > ; Chen, Yingwen ; > Nakajima, Jun ; Boris Ostrovsky > ; Joao Marcal Lemos Martins > ; Phillip Goerl > Subject: RE: [edk2-rfc] [edk2-devel] CPU hotplug using SMM with > QEMU+OVMF > > Hi Jiewen, > > If a hot add CPU needs to run any code before the > first SMI, I would recommend is only executes code > from a write protected FLASH range without a stack > and then wait for the first SMI. [Jiewen] Right. Another option from Paolo, the new CPU will not run until 0x7b. To mitigate DMA threat, someone need guarantee the low memory SIPI vector is DMA protected. NOTE: The LOW memory *could* be mapped to write protected FLASH AREA via PAM register. The Host CPU may setup that in SMM. If that is the case, we don’t need worry DMA. I copied the detail step here, because I found it is hard to dig them out again. (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.. > > For this OVMF use case, is any CPU init required > before the first SMI? [Jiewen] I am sure what is the detail action in 08b. And I am not sure what your "init" means here? Personally, I don’t think we need too much init work, such as Microcode or MTRR. But we need detail info. > From Paolo's list of steps are steps (8a) and (8b) > really required? Can the SMI monarch use the Local > APIC to send a directed SMI to the hot added CPU? > The SMI monarch needs to know the APIC ID of the > hot added CPU. [Jiewen] I think it depend upon virtual hardware design. Leave question to Paolo. Do we also need to handle the case > where multiple CPUs are added at once? I think we > would need to serialize the use of 3000:8000 for the > SMM rebase operation on each hot added CPU. > It would be simpler if we can guarantee that only > one CPU can be added or removed at a time and the > complete flow of adding a CPU to SMM and the OS > needs to be completed before another add/remove > event needs to be processed. [Jiewen] Right. I treat the multiple CPU hot-add at same time as a potential threat. We don’t want to trust end user. The solution could be: 1) Let trusted hardware guarantee hot-add one by one. 2) Let trusted software (SMM and init code) guarantee SMREBASE one by one (include any code runs before SMREBASE) 3) Let trusted software (SMM and init code) support SMREBASE simultaneously (include any code runs before SMREBASE). Solution #1 or #2 are simple solution. > Mike > > > -Original Message- > > From: Yao, Jiewen > > Sent: Thursday, August 22, 2019 10:00 PM > > To: Kinney, Michael D ; > > Paolo Bonzini ; Laszlo Ersek > > ; r...@edk2.groups.io > > Cc: Alex Williamson ; > > de...@edk2.groups.io; qemu devel list > de...@nongnu.org>; Igor Mammedov ; > > Chen, Yingwen ; Nakajima, Jun > > ; Boris Ostrovsky > > ; Joao Marcal Lemos Martins > > ; Phillip Goerl > > > > Subject: RE: [edk2-rfc] [edk2-devel] CPU hotplug using > > SMM with QEMU+OVMF > > > > Thank you Mike! > > > > That is good reference on the real hardware behavior. > > (Glad it is public.) > > > > For threat model, the unique part in virtual environment > > is temp RAM. > > The temp RAM in real platform is per CPU cache, while > > the temp RAM in virtual platform is global memory. > > That brings one more potential attack surfa
Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
Thank you Mike! That is good reference on the real hardware behavior. (Glad it is public.) For threat model, the unique part in virtual environment is temp RAM. The temp RAM in real platform is per CPU cache, while the temp RAM in virtual platform is global memory. That brings one more potential attack surface in virtual environment, if hot-added CPU need run code with stack or heap before SMI rebase. Other threats, such as SMRAM or DMA, are same. Thank you Yao Jiewen > -Original Message- > From: Kinney, Michael D > Sent: Friday, August 23, 2019 9:03 AM > To: Paolo Bonzini ; Laszlo Ersek > ; r...@edk2.groups.io; Yao, Jiewen > ; Kinney, Michael D > Cc: Alex Williamson ; de...@edk2.groups.io; > qemu devel list ; Igor Mammedov > ; Chen, Yingwen ; > Nakajima, Jun ; Boris Ostrovsky > ; Joao Marcal Lemos Martins > ; Phillip Goerl > Subject: RE: [edk2-rfc] [edk2-devel] CPU hotplug using SMM with > QEMU+OVMF > > Paolo, > > I find the following links related to the discussions here > along with one example feature called GENPROTRANGE. > > https://csrc.nist.gov/CSRC/media/Presentations/The-Whole-is-Greater/ima > ges-media/day1_trusted-computing_200-250.pdf > https://cansecwest.com/slides/2017/CSW2017_Cuauhtemoc-Rene_CPU_Ho > t-Add_flow.pdf > https://www.mouser.com/ds/2/612/5520-5500-chipset-ioh-datasheet-1131 > 292.pdf > > Best regards, > > Mike > > > -Original Message- > > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > > Sent: Thursday, August 22, 2019 4:12 PM > > To: Kinney, Michael D ; > > Laszlo Ersek ; r...@edk2.groups.io; > > Yao, Jiewen > > Cc: Alex Williamson ; > > de...@edk2.groups.io; qemu devel list > de...@nongnu.org>; Igor Mammedov ; > > Chen, Yingwen ; Nakajima, Jun > > ; Boris Ostrovsky > > ; Joao Marcal Lemos Martins > > ; Phillip Goerl > > > > Subject: Re: [edk2-rfc] [edk2-devel] CPU hotplug using > > SMM with QEMU+OVMF > > > > On 23/08/19 00:32, Kinney, Michael D wrote: > > > Paolo, > > > > > > It is my understanding that real HW hot plug uses the > > SDM defined > > > methods. Meaning the initial SMI is to 3000:8000 and > > they rebase to > > > TSEG in the first SMI. They must have chipset specific > > methods to > > > protect 3000:8000 from DMA. > > > > It would be great if you could check. > > > > > Can we add a chipset feature to prevent DMA to 64KB > > range from > > > 0x3-0x3 and the UEFI Memory Map and ACPI > > content can be > > > updated so the Guest OS knows to not use that range for > > DMA? > > > > If real hardware does it at the chipset level, we will > > probably use Igor's suggestion of aliasing A-seg to > > 3000:. Before starting the new CPU, the SMI handler > > can prepare the SMBASE relocation trampoline at > > A000:8000 and the hot-plugged CPU will find it at > > 3000:8000 when it receives the initial SMI. Because this > > is backed by RAM at 0xA-0xA, DMA cannot access it > > and would still go through to RAM at 0x3. > > > > 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
> -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
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
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] CPU hotplug using SMM with QEMU+OVMF
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 at first. Then we can continue the discussion. Thank you Yao Jiewen > -Original Message- > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: Wednesday, August 14, 2019 10:05 PM > To: Yao, Jiewen ; Laszlo Ersek > ; edk2-devel-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: CPU hotplug using SMM with QEMU+OVMF > > 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. > >> 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. > > > >> > >>>(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 OS involvement here. But, again, perhaps QEMU > can > >> force all existent CPUs into SMM immediately upon adding the new CPU. > > [Jiewen] OS here means the Host CPU running code in OS environment, not > in SMM environment. > > See above. > > >>> (06) Host CPU: (SMM) Save 38000, Update 38000 -- fill simple SMM > >>> rebase code. > >>> > >>> (07) Host CPU: (SMM) Send message to New CPU to Enable SMI. > >> > >> Aha, so this is the SMM-only register you mention in step (03). Is the > >> registe
Re: [Qemu-devel] CPU hotplug using SMM with QEMU+OVMF
My comments below. > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Wednesday, August 14, 2019 12:09 AM > To: edk2-devel-groups-io > Cc: edk2-rfc-groups-io ; qemu devel list > ; Igor Mammedov ; > Paolo Bonzini ; Yao, Jiewen > ; Chen, Yingwen ; > Nakajima, Jun ; Boris Ostrovsky > ; Joao Marcal Lemos Martins > ; Phillip Goerl > Subject: Re: CPU hotplug using SMM with QEMU+OVMF > > On 08/13/19 16:16, Laszlo Ersek wrote: > > > Yingwen and Jiewen suggested the following process. > > > > Legend: > > > > - "New CPU": CPU being hot-added > > - "Host CPU": existing CPU > > - (Flash):code running from flash > > - (SMM): code running from SMRAM > > > > Steps: > > > > (01) New CPU: (Flash) enter reset vector, Global SMI disabled by > > default. > > - What does "Global SMI disabled by default" mean? In particular, what > is "global" here? [Jiewen] OK. Let's don’t use the term "global". > Do you mean that the CPU being hot-plugged should mask (by default) > broadcast SMIs? What about directed SMIs? (An attacker could try that > too.) [Jiewen] I mean all SMIs are blocked for this specific hot-added CPU. > And what about other processors? (I'd assume step (01)) is not > relevant for other processors, but "global" is quite confusing here.) [Jiewen] No impact to other processors. > - 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. > - 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. > For example, in MpInitLib, we start a specific AP with INIT-SIPI-SIPI, > where "SIPI" stores the startup address in the "Interrupt Command > Register" (which is memory-mapped in xAPIC mode, and an MSR in x2APIC > mode, apparently). That doesn't apply here -- should QEMU auto-start > the new CPU? [Jiewen] You can send INIT-SIPI-SIPI to new CPU only after it can access memory. SIPI need give AP an below 1M memory address as waking vector. > - What memory is used as stack by the new CPU, when it runs code from > flash? [Jiewen] Same as other CPU in normal boot. You can use special reserved memory. > QEMU does not emulate CAR (Cache As RAM). The new CPU doesn't have > access to SMRAM. And we cannot use AcpiNVS or Reserved memory, > because > a malicious OS could use other CPUs -- or PCI device DMA -- to attack > the stack (unless QEMU forcibly paused other CPUs upon hotplug; I'm > not sure). [Jiewen] Excellent point! 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? > - If an attempt is made to hotplug multiple CPUs in quick succession, > does something serialize those attempts? [Jiewen] The BIOS need consider this as availability requirement. I don’t have strong opinion. You can design a system that required hotplug must be one-by-one, or fail the hot-add. Or you can design a system that did not have such restriction. Again, all we need to do is to maintain the integrity of SMM. The availability should be considered as separate requirement. > Again, stack usage could be a concern, even with Cache-As-RAM -- > HyperThreads (logical processors) on a single core don't have > dedicated cache. [Jiewen] Agree with you on the virtual environment. For real hardware, we do socket level hot-add only. So HT is not the concern. But if you want to do that in virtual environment, a processor specific memory should be considered. > 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? [Jiewen] Ditto. > > (02) New CPU: (Flash) configure memory control to let it access global > > host memory. > > In QEMU/KVM guests, we don't have to enable memory explicitly, it just > exists and works. > > In OVMF X64 SEC, we can't access RAM above 4GB, but that shouldn't be an > issue per se. [Jiewen] Agree. I do not see the issue. > > (03) New CPU: (Flash) send board message to tell host CPU (GPIO->SCI) > > -- I am waiting for hot-add message. > > Maybe we
Re: [Qemu-devel] [edk2] [PATCH v2 8/8] ovmf: add DxeTpm2MeasureBootLib
Good idea. The additional message looks great!!! thank you! Yao, Jiewen > 在 2018年3月9日，下午6:26，Laszlo Ersek <ler...@redhat.com> 写道： > > in
Re: [Qemu-devel] [PATCH v2 8/8] ovmf: add DxeTpm2MeasureBootLib
Besides the comment below, I should have used the example in OvmfPkg. Please refer to https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c The EfiBootManagerDispatchDeferredImages() API call is added just after gEfiDxeSmmReadyToLockProtocolGuid. So I don’t see any problem in OVMF pkg. Thank you Yao Jiewen > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao, > Jiewen > Sent: Friday, March 9, 2018 8:39 AM > To: Laszlo Ersek <ler...@redhat.com>; marcandre.lur...@redhat.com; > edk2-de...@lists.01.org > Cc: javi...@redhat.com; pjo...@redhat.com; qemu-devel@nongnu.org > Subject: Re: [edk2] [PATCH v2 8/8] ovmf: add DxeTpm2MeasureBootLib > > Very good question. > Comment below: > > > -Original Message- > > From: Laszlo Ersek [mailto:ler...@redhat.com] > > Sent: Friday, March 9, 2018 3:54 AM > > To: marcandre.lur...@redhat.com; edk2-de...@lists.01.org; Yao, Jiewen > > <jiewen@intel.com> > > Cc: pjo...@redhat.com; stef...@linux.vnet.ibm.com; > > qemu-devel@nongnu.org; javi...@redhat.com > > Subject: Re: [PATCH v2 8/8] ovmf: add DxeTpm2MeasureBootLib > > > > (Jiewen, below I have a question for you as well; please help with that.) > > > > On 03/07/18 16:57, marcandre.lur...@redhat.com wrote: > > > From: Marc-André Lureau <marcandre.lur...@redhat.com> > > > > > > The library registers a security management handler, to measure images > > > that are not measure in PEI phase. > > > > > > This seems to work for example with the qemu PXE rom: > > > > > > Loading driver at 0x0003E6C2000 EntryPoint=0x0003E6C9076 8086100e.efi > > > > > > And the following binary_bios_measurements log entry seems to be > > > added: > > > > > > PCR: 2type: EV_EFI_BOOT_SERVICES_DRIVER size: 0x4e digest: > > 70a22475e9f18806d2ed9193b48d80d26779d9a4 > > > > > > Cc: Laszlo Ersek <ler...@redhat.com> > > > Cc: Stefan Berger <stef...@linux.vnet.ibm.com> > > > Contributed-under: TianoCore Contribution Agreement 1.0 > > > Signed-off-by: Marc-André Lureau <marcandre.lur...@redhat.com> > > > --- > > > OvmfPkg/OvmfPkgX64.dsc | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc > > > index 7753852144fb..9db1712e3623 100644 > > > --- a/OvmfPkg/OvmfPkgX64.dsc > > > +++ b/OvmfPkg/OvmfPkgX64.dsc > > > @@ -662,6 +662,9 @@ [Components] > > > > > > !if $(SECURE_BOOT_ENABLE) == TRUE > > > > > > NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf > > > +!endif > > > +!if $(TPM2_ENABLE) == TRUE > > > + > > > NULL|SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.i > > nf > > > !endif > > >} > > > > > > > > > > (1) Marc-André, please change the subject line to: > > > > OvmfPkg: plug DxeTpm2MeasureBootLib into SecurityStubDxe > > > > > > (2) I have a question for Jiewen: > > > > DxeTpm2MeasureBootLib consumes the TCG2 protocol, but it does not depend > > on it with a DEPEX. Instead, DxeTpm2MeasureBootHandler() tries to locate > > the protocol on every invocation. > [Jiewen] Yes. > > > This means that SecurityStubDxe may produce the Security and Security2 > > Architectural Protocols before measurements into the TPM2 device are > > possible. > [Jiewen] Yes. > > > Therefore, UEFI_DRIVER modules (which depend on all of the > > Arch protocols) may be started before they can be measured into the TPM. > > > > Now, this is likely no problem for UEFI_DRIVER modules that are built > > into the firmware volume(s), because those are measured by Tcg2Pei > > anyway. > [Jiewen] That is TRUE. > > However, it would be a problem for UEFI_DRIVER modules / apps > > that come from external media (disk, network, PCI oprom, etc). > [Jiewen] By design, the 3rd part module should not be invoked before EndOfDxe. > All Arch Protocol Ready is not strong enough. :-) > Please refer to > https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/Sec > urityStubDxe/Defer3rdPartyImageLoad.c > > If a non-FV image is loaded before EndOfDxe, it will be queued into > mDeferred3rdPartyImage. > > We also added EfiBootManagerDispatchDeferredImages() API in > https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Librar > y/UefiBootManagerLib.h and impl
Re: [Qemu-devel] [PATCH v2 8/8] ovmf: add DxeTpm2MeasureBootLib
Very good question. Comment below: > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Friday, March 9, 2018 3:54 AM > To: marcandre.lur...@redhat.com; edk2-de...@lists.01.org; Yao, Jiewen > <jiewen@intel.com> > Cc: pjo...@redhat.com; stef...@linux.vnet.ibm.com; > qemu-devel@nongnu.org; javi...@redhat.com > Subject: Re: [PATCH v2 8/8] ovmf: add DxeTpm2MeasureBootLib > > (Jiewen, below I have a question for you as well; please help with that.) > > On 03/07/18 16:57, marcandre.lur...@redhat.com wrote: > > From: Marc-André Lureau <marcandre.lur...@redhat.com> > > > > The library registers a security management handler, to measure images > > that are not measure in PEI phase. > > > > This seems to work for example with the qemu PXE rom: > > > > Loading driver at 0x0003E6C2000 EntryPoint=0x0003E6C9076 8086100e.efi > > > > And the following binary_bios_measurements log entry seems to be > > added: > > > > PCR: 2 type: EV_EFI_BOOT_SERVICES_DRIVER size: 0x4e digest: > 70a22475e9f18806d2ed9193b48d80d26779d9a4 > > > > Cc: Laszlo Ersek <ler...@redhat.com> > > Cc: Stefan Berger <stef...@linux.vnet.ibm.com> > > Contributed-under: TianoCore Contribution Agreement 1.0 > > Signed-off-by: Marc-André Lureau <marcandre.lur...@redhat.com> > > --- > > OvmfPkg/OvmfPkgX64.dsc | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc > > index 7753852144fb..9db1712e3623 100644 > > --- a/OvmfPkg/OvmfPkgX64.dsc > > +++ b/OvmfPkg/OvmfPkgX64.dsc > > @@ -662,6 +662,9 @@ [Components] > > > > !if $(SECURE_BOOT_ENABLE) == TRUE > > > NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf > > +!endif > > +!if $(TPM2_ENABLE) == TRUE > > + > NULL|SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.i > nf > > !endif > >} > > > > > > (1) Marc-André, please change the subject line to: > > OvmfPkg: plug DxeTpm2MeasureBootLib into SecurityStubDxe > > > (2) I have a question for Jiewen: > > DxeTpm2MeasureBootLib consumes the TCG2 protocol, but it does not depend > on it with a DEPEX. Instead, DxeTpm2MeasureBootHandler() tries to locate > the protocol on every invocation. [Jiewen] Yes. > This means that SecurityStubDxe may produce the Security and Security2 > Architectural Protocols before measurements into the TPM2 device are > possible. [Jiewen] Yes. > Therefore, UEFI_DRIVER modules (which depend on all of the > Arch protocols) may be started before they can be measured into the TPM. > > Now, this is likely no problem for UEFI_DRIVER modules that are built > into the firmware volume(s), because those are measured by Tcg2Pei > anyway. [Jiewen] That is TRUE. However, it would be a problem for UEFI_DRIVER modules / apps > that come from external media (disk, network, PCI oprom, etc). [Jiewen] By design, the 3rd part module should not be invoked before EndOfDxe. All Arch Protocol Ready is not strong enough. :-) Please refer to https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/SecurityStubDxe/Defer3rdPartyImageLoad.c If a non-FV image is loaded before EndOfDxe, it will be queued into mDeferred3rdPartyImage. We also added EfiBootManagerDispatchDeferredImages() API in https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Library/UefiBootManagerLib.h and implemented in https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c A platform must call EfiBootManagerDispatchDeferredImages(), if the platform supports PCI OROM. You can find the sample code in https://github.com/tianocore/edk2-platforms/blob/devel-MinPlatform/Platform/Intel/MinPlatformPkg/Bds/Library/DxePlatformBootManagerLib/BdsPlatform.c > However, such are loaded only in the BDS phase, and BDS is only entered > after all of the DXE drivers are dispatched from the firmware volumes. > In other words, the ordering between Tcg2Dxe and external UEFI_DRIVER / > UEFI_APPLICATION modules is ensured that Tcg2Dxe will be dispatched in > the DXE phase, while the latter will only be loaded in BDS. > > Is this intentional? Is my understanding correct? [Jiewen] Right. The only assumption is: Tcg2Dxe is included in the firmware volume and it is dispatched before EndOfDxe. > > (3) If that's the case, then Marc-André, please add the following to the > commit message: > > > Hooking DxeTpm2MeasureBootLib into SecurityStubDxe ensures that the > Security and Security2 Arch protocols will entail, by the time of > entering the BDS phase, the measuring
Re: [Qemu-devel] [PATCH v2 2/8] SecurityPkg/Tcg2Pei: drop PeiReadOnlyVariable from Depex
Reviewed-by: jiewen@intel.com > -Original Message- > From: marcandre.lur...@redhat.com [mailto:marcandre.lur...@redhat.com] > Sent: Wednesday, March 7, 2018 11:58 PM > To: edk2-de...@lists.01.org > Cc: pjo...@redhat.com; Yao, Jiewen <jiewen@intel.com>; > stef...@linux.vnet.ibm.com; ler...@redhat.com; qemu-devel@nongnu.org; > javi...@redhat.com; Marc-André Lureau <marcandre.lur...@redhat.com> > Subject: [PATCH v2 2/8] SecurityPkg/Tcg2Pei: drop PeiReadOnlyVariable from > Depex > > From: Marc-André Lureau <marcandre.lur...@redhat.com> > > The module doesn't use read-only variable. > > Cc: Laszlo Ersek <ler...@redhat.com> > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Marc-André Lureau <marcandre.lur...@redhat.com> > --- > SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf > b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf > index bc910c3baf97..a4aae1488ff8 100644 > --- a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf > +++ b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf > @@ -91,7 +91,6 @@ [Pcd] > > [Depex] >gEfiPeiMasterBootModePpiGuid AND > - gEfiPeiReadOnlyVariable2PpiGuid AND >gEfiTpmDeviceSelectedGuid > > [UserExtensions.TianoCore."ExtraFiles"] > -- > 2.16.2.346.g9779355e34
Re: [Qemu-devel] [edk2] [PATCH 1/7] SecurityPkg/Tcg2Pei: drop Tcg2PhysicalPresenceLib dependency
Reviewed-by: jiewen@intel.com > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > marcandre.lur...@redhat.com > Sent: Friday, February 23, 2018 9:23 PM > To: edk2-de...@lists.01.org > Cc: qemu-devel@nongnu.org; javi...@redhat.com; pjo...@redhat.com; Yao, > Jiewen <jiewen@intel.com>; ler...@redhat.com > Subject: [edk2] [PATCH 1/7] SecurityPkg/Tcg2Pei: drop Tcg2PhysicalPresenceLib > dependency > > From: Marc-André Lureau <marcandre.lur...@redhat.com> > > Apparently, unnecessary. Avoids extra build dependency and churn. > > CC: Laszlo Ersek <ler...@redhat.com> > CC: Stefan Berger <stef...@linux.vnet.ibm.com> > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Marc-André Lureau <marcandre.lur...@redhat.com> > --- > SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c | 2 -- > SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf | 1 - > 2 files changed, 3 deletions(-) > > diff --git a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c > b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c > index a7ae3354b5..3758fc6a41 100644 > --- a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c > +++ b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c > @@ -18,7 +18,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY > KIND, EITHER EXPRESS OR IMPLIED. > #include > #include > #include > -#include > #include > #include > #include > @@ -44,7 +43,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY > KIND, EITHER EXPRESS OR IMPLIED. > #include > #include > #include > -#include > > #define PERF_ID_TCG2_PEI 0x3080 > > diff --git a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf > b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf > index f7b85444d9..bc910c3baf 100644 > --- a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf > +++ b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf > @@ -58,7 +58,6 @@ >PerformanceLib >MemoryAllocationLib >ReportStatusCodeLib > - Tcg2PhysicalPresenceLib >ResetSystemLib > > [Guids] > -- > 2.16.1.73.g5832b7e9f2 > > ___ > edk2-devel mailing list > edk2-de...@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel
Re: [Qemu-devel] investigating TPM for OVMF-on-QEMU
Hi Laszlo This is a good summary. One minor comment is: 1) Tcg2Pei/Dxe are arechitecture driver. We do not expect a platform modify them. 2) Tcg2ConfigPei/Dxe are platform sample driver. A platform may have its own version based upon platform requirement. For example, if a platform supports fTPM, it may use another Tcg2Config driver. Back to enabling, I think the first important question is how to access TPM device. If the TPM can expose FIFO interface or CRB interface defined in "Platform TPM Profile Specification definition for TPM2.0", most current TPM2 drivers can be reused. The second question is about PEI variable. I do not think PEI Variable is *required* component. Tcg2Pei has gEfiPeiReadOnlyVariable2PpiGuid dependency, and I think we can remove it. Tcg2ConfigPei has gEfiPeiReadOnlyVariable2PpiGuid dependency, but that is to support TPM selection. The Tcg2Config driver is an optional driver, and it can be customized by platform by design. Thank you Yao Jiewen > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Saturday, July 15, 2017 2:04 AM > To: Yao, Jiewen <jiewen@intel.com>; Stefan Berger > <stef...@linux.vnet.ibm.com>; Javier Martinez Canillas <javi...@redhat.com>; > Peter Jones <pjo...@redhat.com>; Marc-André Lureau > <marcandre.lur...@redhat.com>; Valluri, Amarnath > <amarnath.vall...@intel.com> > Cc: edk2-devel-01 <edk2-de...@lists.01.org>; qemu devel list > <qemu-devel@nongnu.org> > Subject: investigating TPM for OVMF-on-QEMU > > Hi, > > I spent most of today reading TPM related material (specs, guides and > source code), and below I'd like to describe what I think should be our > initial attack on enabling TPM on QEMU/OVMF. > > (1) Versions of UEFI abstractions regarding TPM (very roughly speaking): > > There have been three sets of specs for this, and accordingly, > edk2's SecurityPkg/Tcg/ directory supports each set. We can call > these TPM1, TrEE, and TPM2. > > - TPM1 was the initial TPM thing, supporting only SHA-1, and is now > obsolete. > > - TrEE was Microsoft's own update to the TPM1 software interfaces, > supporting TPM2 hardware with more hash algorithms, and is now > obsolete. Because, > > - TPM2 is basically the standardized version of TrEE, the most > recent set of specs, and what we should focus on. > > (2) Drivers (and features) in edk2/SecurityPkg/Tcg. > > There are 19 modules under SecurityPkg/Tcg/. Let me categorize them. > In each category, I'll try to list modules in loosely increasing > dependency (or PI/UEFI phase) order. > > (2a) Modules that are obsolete because they are tied to TPM1: > >TcgPei/TcgPei.inf >PhysicalPresencePei/PhysicalPresencePei.inf >TcgDxe/TcgDxe.inf >TcgConfigDxe/TcgConfigDxe.inf >TcgSmm/TcgSmm.inf > > The TPM enablement instructions at > > > https://github.com/tianocore/tianocore.github.io/wiki/How-to-Enable-Security# > Enabling_Trusted_Compute_Module_TPM > > are written up in terms of these modules, but that doesn't obsolete > the article too much. > > (2b) Modules that are obsolete due to being tied to TrEE: > >TrEEConfig/TrEEConfigPei.inf >TrEEPei/TrEEPei.inf >TrEEDxe/TrEEDxe.inf >TrEEConfig/TrEEConfigDxe.inf >TrEESmm/TrEESmm.inf > > There is a great Intel whitepaper called > >A Tour Beyond BIOS with the UEFI TPM2 Support in EDKII > > which is written in terms of TrEE and these modules, explaining how > they supersede TPM1 and the modules under (2a). > > This whitepaper seems to apply to the most recent TPM2 stack as > well (mostly just replace TrEE references with TPM2 references), so > it is very useful. > > (2c) Modules that call themselves obsolete or deprecated (without being > obviously tied to TPM1 or TrEE): > >MemoryOverwriteRequestControlLock/TcgMorLockSmm.inf > > (2d) Modules that we won't need due to no hardware support in QEMU: > >Opal/OpalPasswordDxe/OpalPasswordDxe.inf >Opal/OpalPasswordSmm/OpalPasswordSmm.inf > > TCG's "Opal" seems to be about self-encrypting drives, see > >https://en.wikipedia.org/wiki/Opal_Storage_Specification > > so these modules are not relevant for us. > > (2e) Modules that we should use. Again, in increasing order of > dependence. And here I'll comment as well on what these do: > >Tcg2Config/Tcg2ConfigPei.inf -- Informs the firmware globally >a
Re: [Qemu-devel] [edk2] implementing EFI_SMM_CONTROL2_PROTOCOL.Trigger() (was: [PATCH 6/6] [wip] tseg, part2, not (yet) tested)
Hi Laszlo Below is my thought. 2) You are right. According to IA32 manual - Maskable hardware interrupts, exceptions, NMI interrupts, SMI interrupts, A20M interrupts, single-step traps, breakpoint traps, and INIT operations are inhibited when the processor enters SMM. You can also find more detail in 34.6 EXCEPTIONS AND INTERRUPTS WITHIN SMM In below doc, the SMM Timer is initialized means the timer used by BSP to check if APs are all pulled into SMM for CPU Rendez-vous. A typical implementation is ACPI timer (PCH), or APIC timer (CPU). BSP just check timer count, but the timer does not generate any interrupt. 3) Yes. SmmCoreEntry is useful function as bridge between a real CPU_SMM driver and SMM_CORE. In real world, when SMI happen, CPU will jump to SM_BASE in real mode. Then it will jump to X64 mode immediately. The all CPUs will be in election phase. Only one will be elected as BSP. Just in case, some APIs are not in SMM yet, the BSP will send IPI to try pull those APs into SMM mode. (SMM timer is used at this moment). Above process is called CPU rendez-vous. Then BSP will do enter SMM_CORE entry point (registered by SmmCoreEntry), while APs are in loop state. After BSP returns from SMM_CORE, it will let APs leave loop state, and all CPUs run RSM instruction to return back. Hope that helps. BTW: I am not sure how QEMU emulate SMI. Does SMI can be trigger by 0xB2 port? And CPU will run to SMBASE in real mode? Thank you Yao Jiewen -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Wednesday, April 22, 2015 4:32 AM To: Paolo Bonzini; Gerd Hoffmann Cc: edk2-devel list; qemu-devel@nongnu.org; m...@redhat.com Subject: [edk2] implementing EFI_SMM_CONTROL2_PROTOCOL.Trigger() (was: [PATCH 6/6] [wip] tseg, part2, not (yet) tested) (b) This is actually the opposite argument. Since SMM is security sensitive, *and* UEFI is single-processor / single-threaded (well you can use multiple processors, you just can't run any UEFI code on anything but the BP), the timer interrupt should be blocked / masked *anyway* while in SMM, no? Otherwise edk2 could start running a plain timer event callback in the middle of an SMM handler. Which makes me think that this locking / interrupt masking must already be in place, and it's not the responsibility of the individual EFI_SMM_CONTROL2_PROTOCOL.Trigger() implementation. (PI 1.3 vol4 doesn't mention this responsibility in any case.) I've learned about the EDK II SMM Call Topology document from a piwg message: http://sourceforge.net/projects/edk2/files/General%20Documentation/EDK%20II%20SMM%20call%20topology.pdf/download It doesn't speak about masking the timer. Does SMI mask other interrupts architecturally perhaps? ... (3) Oh, this is sad. Well, I am sad. Turns out there's a third UEFI protocol that OVMF needs to implement: EFI_SMM_CONFIGURATION_PROTOCOL. Its only interesting member is RegisterSmmEntry(), and that function is supposed to bind the central entry point (which is already available in the edk2 tree) to the processor-level SMI handler. (I'm kind of confused, because last time I experimented with faking SMRAM / SMM in OVMF, my fake Trigger() function just returned success, and there was no EFI_SMM_CONFIGURATION_PROTOCOL at all, and things seemed to work. In retrospect I can't imagine how control was transferred at all, without actual SMM / SMI support in both QEMU and OVMF. Hm... looking at occurrences of SmmEntryPointRegistered, this may have been intentional in edk2.) EFI_SMM_CONFIGURATION_PROTOCOL discussed in the EDK II SMM Call Topology document, on the SmmDriverDispatcher and especially the SMBASE Relocation pages. It takes a separate CPU driver, and (obviously) assembly code. The SMBASE Relocation page references IA32FamilyCpuPkg, which is not open source. Nothing in edk2 produces gEfiSmmConfigurationProtocol, and no source file contains the RSM instruction. The Vlv2TbltDevicePkg package (ValleyView2 Tablet?) makes several references to IA32FamilyCpuPkg, but those are only references. I guess IA32FamilyCpuPkg is exactly the kind of chipset code that Intel has not opened up. Our SMM in OVMF effort just got set back by months. :( Laszlo -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ edk2-devel mailing list edk2-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [Qemu-devel] [edk2] implementing EFI_SMM_CONTROL2_PROTOCOL.Trigger()
Got it. Thanks! -Original Message- From: Paolo Bonzini [mailto:pbonz...@redhat.com] Sent: Friday, April 24, 2015 9:01 PM To: Yao, Jiewen; edk2-de...@lists.sourceforge.net; Gerd Hoffmann Cc: qemu-devel@nongnu.org; m...@redhat.com Subject: Re: [edk2] implementing EFI_SMM_CONTROL2_PROTOCOL.Trigger() On 24/04/2015 13:56, Yao, Jiewen wrote: BTW: I am not sure how QEMU emulate SMI. Does SMI can be trigger by 0xB2 port? And CPU will run to SMBASE in real mode? Yes, operation is the same. Paolo
Re: [Qemu-devel] [edk2] implementing EFI_SMM_CONTROL2_PROTOCOL.Trigger() (was: [PATCH 6/6] [wip] tseg, part2, not (yet) tested)
Hi Laszlo I think there is good resource for your reference - Intel Quark. https://downloadcenter.intel.com/download/23197 You may download Board_Support_Package_Sources_for_Intel_Quark_v1.1.0.7z, and find Quark_EDKII_v1.1.0 IA32FamilyCpuBasePkg\PiSmmCpuDxeSmm - it is CPUSMM driver. IA32FamilyCpuBasePkg\PiSmmCommunication - it is CommunicationPeim. PiSmmCpuDxeSmm works for Quark, but I think it should be easy to port to QEMU platform. PiSmmCommunication should be generic, it might be able to put to UefiCpuPkg later. Thank you Yao Jiewen -Original Message- From: Yao, Jiewen [mailto:jiewen@intel.com] Sent: Friday, April 24, 2015 7:56 PM To: edk2-de...@lists.sourceforge.net; Paolo Bonzini; Gerd Hoffmann Cc: qemu-devel@nongnu.org; m...@redhat.com Subject: Re: [edk2] implementing EFI_SMM_CONTROL2_PROTOCOL.Trigger() (was: [PATCH 6/6] [wip] tseg, part2, not (yet) tested) Hi Laszlo Below is my thought. 2) You are right. According to IA32 manual - Maskable hardware interrupts, exceptions, NMI interrupts, SMI interrupts, A20M interrupts, single-step traps, breakpoint traps, and INIT operations are inhibited when the processor enters SMM. You can also find more detail in 34.6 EXCEPTIONS AND INTERRUPTS WITHIN SMM In below doc, the SMM Timer is initialized means the timer used by BSP to check if APs are all pulled into SMM for CPU Rendez-vous. A typical implementation is ACPI timer (PCH), or APIC timer (CPU). BSP just check timer count, but the timer does not generate any interrupt. 3) Yes. SmmCoreEntry is useful function as bridge between a real CPU_SMM driver and SMM_CORE. In real world, when SMI happen, CPU will jump to SM_BASE in real mode. Then it will jump to X64 mode immediately. The all CPUs will be in election phase. Only one will be elected as BSP. Just in case, some APIs are not in SMM yet, the BSP will send IPI to try pull those APs into SMM mode. (SMM timer is used at this moment). Above process is called CPU rendez-vous. Then BSP will do enter SMM_CORE entry point (registered by SmmCoreEntry), while APs are in loop state. After BSP returns from SMM_CORE, it will let APs leave loop state, and all CPUs run RSM instruction to return back. Hope that helps. BTW: I am not sure how QEMU emulate SMI. Does SMI can be trigger by 0xB2 port? And CPU will run to SMBASE in real mode? Thank you Yao Jiewen -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Wednesday, April 22, 2015 4:32 AM To: Paolo Bonzini; Gerd Hoffmann Cc: edk2-devel list; qemu-devel@nongnu.org; m...@redhat.com Subject: [edk2] implementing EFI_SMM_CONTROL2_PROTOCOL.Trigger() (was: [PATCH 6/6] [wip] tseg, part2, not (yet) tested) (b) This is actually the opposite argument. Since SMM is security sensitive, *and* UEFI is single-processor / single-threaded (well you can use multiple processors, you just can't run any UEFI code on anything but the BP), the timer interrupt should be blocked / masked *anyway* while in SMM, no? Otherwise edk2 could start running a plain timer event callback in the middle of an SMM handler. Which makes me think that this locking / interrupt masking must already be in place, and it's not the responsibility of the individual EFI_SMM_CONTROL2_PROTOCOL.Trigger() implementation. (PI 1.3 vol4 doesn't mention this responsibility in any case.) I've learned about the EDK II SMM Call Topology document from a piwg message: http://sourceforge.net/projects/edk2/files/General%20Documentation/EDK%20II%20SMM%20call%20topology.pdf/download It doesn't speak about masking the timer. Does SMI mask other interrupts architecturally perhaps? ... (3) Oh, this is sad. Well, I am sad. Turns out there's a third UEFI protocol that OVMF needs to implement: EFI_SMM_CONFIGURATION_PROTOCOL. Its only interesting member is RegisterSmmEntry(), and that function is supposed to bind the central entry point (which is already available in the edk2 tree) to the processor-level SMI handler. (I'm kind of confused, because last time I experimented with faking SMRAM / SMM in OVMF, my fake Trigger() function just returned success, and there was no EFI_SMM_CONFIGURATION_PROTOCOL at all, and things seemed to work. In retrospect I can't imagine how control was transferred at all, without actual SMM / SMI support in both QEMU and OVMF. Hm... looking at occurrences of SmmEntryPointRegistered, this may have been intentional in edk2.) EFI_SMM_CONFIGURATION_PROTOCOL discussed in the EDK II SMM Call Topology document, on the SmmDriverDispatcher and especially the SMBASE Relocation pages. It takes a separate CPU driver, and (obviously) assembly code. The SMBASE Relocation page references IA32FamilyCpuPkg, which is not open source. Nothing in edk2 produces gEfiSmmConfigurationProtocol, and no source file contains the RSM instruction. The Vlv2TbltDevicePkg package (ValleyView2 Tablet?) makes several references to IA32FamilyCpuPkg, but those are only references. I guess
