|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [ovmf test] 153622: regressions - FAIL
flight 153622 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/153622/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm 6 xen-build fail REGR. vs. 152863 build-amd64-xsm 6 xen-build fail REGR. vs. 152863 build-amd64 6 xen-build fail REGR. vs. 152863 build-i386 6 xen-build fail REGR. vs. 152863 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf e8453aa373e96ed76b72a6968d8a48dfb002a1a6 baseline version: ovmf 63d92674d240ab4ecab94f98e1e198842bb7de00 Last test of basis 152863 2020-08-26 16:09:47 Z 7 days Failing since 152915 2020-08-27 18:09:42 Z 6 days 125 attempts Testing same since 153553 2020-09-02 12:40:39 Z 0 days 14 attempts ------------------------------------------------------------ People who touched revisions under test: Bob Feng <bob.c.feng@xxxxxxxxx> Laszlo Ersek <lersek@xxxxxxxxxx> Paul <paul.grimes@xxxxxxx> Paul G <paul.grimes@xxxxxxx> Qi Zhang <qi1.zhang@xxxxxxxxx> Wenyi Xie <xiewenyi2@xxxxxxxxxx> Zhiguang Liu <zhiguang.liu@xxxxxxxxx> jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit e8453aa373e96ed76b72a6968d8a48dfb002a1a6 Author: Qi Zhang <qi1.zhang@xxxxxxxxx> Date: Tue Sep 1 15:26:22 2020 +0800 MdeModulePkg/Library: add PEIM and SEC module type to TpmMeasurementLibNull REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2940 Signed-off-by: Qi Zhang <qi1.zhang@xxxxxxxxx> Cc: Jian J Wang <jian.j.wang@xxxxxxxxx> Cc: Hao A Wu <hao.a.wu@xxxxxxxxx> Cc: Jiewen Yao <jiewen.yao@xxxxxxxxx> Reviewed-by: Laszlo Ersek <lersek@xxxxxxxxxx> Message-Id: <20200901072622.9391-1-qi1.zhang@xxxxxxxxx> Reviewed-by: Jian J Wang <jian.j.wang@xxxxxxxxx> commit 0b143fa43e92be15d11e22f80773bcb1b2b0608f Author: Laszlo Ersek <lersek@xxxxxxxxxx> Date: Tue Sep 1 11:12:21 2020 +0200 SecurityPkg/DxeImageVerificationLib: catch alignment overflow (CVE-2019-14562) The DxeImageVerificationHandler() function currently checks whether "SecDataDir" has enough room for "WinCertificate->dwLength". However, for advancing "OffSet", "WinCertificate->dwLength" is aligned to the next multiple of 8. If "WinCertificate->dwLength" is large enough, the alignment will return 0, and "OffSet" will be stuck at the same value. Check whether "SecDataDir" has room left for both "WinCertificate->dwLength" and the alignment. Cc: Jian J Wang <jian.j.wang@xxxxxxxxx> Cc: Jiewen Yao <jiewen.yao@xxxxxxxxx> Cc: Min Xu <min.m.xu@xxxxxxxxx> Cc: Wenyi Xie <xiewenyi2@xxxxxxxxxx> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2215 Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx> Message-Id: <20200901091221.20948-4-lersek@xxxxxxxxxx> Reviewed-by: Philippe Mathieu-Daudé <philmd@xxxxxxxxxx> Tested-by: Wenyi Xie <xiewenyi2@xxxxxxxxxx> Reviewed-by: Min M Xu <min.m.xu@xxxxxxxxx> Reviewed-by: Jiewen Yao <jiewen.yao@xxxxxxxxx> commit a7632e913c1c106f436aefd5e76c394249c383a8 Author: Laszlo Ersek <lersek@xxxxxxxxxx> Date: Tue Sep 1 11:12:20 2020 +0200 SecurityPkg/DxeImageVerificationLib: assign WinCertificate after size check Currently the (SecDataDirLeft <= sizeof (WIN_CERTIFICATE)) check only guards the de-referencing of the "WinCertificate" pointer. It does not guard the calculation of the pointer itself: WinCertificate = (WIN_CERTIFICATE *) (mImageBase + OffSet); This is wrong; if we don't know for sure that we have enough room for a WIN_CERTIFICATE, then even creating such a pointer, not just de-referencing it, may invoke undefined behavior. Move the pointer calculation after the size check. Cc: Jian J Wang <jian.j.wang@xxxxxxxxx> Cc: Jiewen Yao <jiewen.yao@xxxxxxxxx> Cc: Min Xu <min.m.xu@xxxxxxxxx> Cc: Wenyi Xie <xiewenyi2@xxxxxxxxxx> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2215 Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx> Message-Id: <20200901091221.20948-3-lersek@xxxxxxxxxx> Reviewed-by: Philippe Mathieu-Daudé <philmd@xxxxxxxxxx> Tested-by: Wenyi Xie <xiewenyi2@xxxxxxxxxx> Reviewed-by: Min M Xu <min.m.xu@xxxxxxxxx> Reviewed-by: Jiewen Yao <jiewen.yao@xxxxxxxxx> commit 503248ccdf45c14d4040ce44163facdc212e4991 Author: Laszlo Ersek <lersek@xxxxxxxxxx> Date: Tue Sep 1 11:12:19 2020 +0200 SecurityPkg/DxeImageVerificationLib: extract SecDataDirEnd, SecDataDirLeft The following two quantities: SecDataDir->VirtualAddress + SecDataDir->Size SecDataDir->VirtualAddress + SecDataDir->Size - OffSet are used multiple times in DxeImageVerificationHandler(). Introduce helper variables for them: "SecDataDirEnd" and "SecDataDirLeft", respectively. This saves us multiple calculations and significantly simplifies the code. Note that all three summands above have type UINT32, therefore the new variables are also of type UINT32. This patch does not change behavior. (Note that the code already handles the case when the SecDataDir->VirtualAddress + SecDataDir->Size UINT32 addition overflows -- namely, in that case, the certificate loop is never entered, and the corruption check right after the loop fires.) Cc: Jian J Wang <jian.j.wang@xxxxxxxxx> Cc: Jiewen Yao <jiewen.yao@xxxxxxxxx> Cc: Min Xu <min.m.xu@xxxxxxxxx> Cc: Wenyi Xie <xiewenyi2@xxxxxxxxxx> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2215 Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx> Message-Id: <20200901091221.20948-2-lersek@xxxxxxxxxx> Reviewed-by: Philippe Mathieu-Daudé <philmd@xxxxxxxxxx> Tested-by: Wenyi Xie <xiewenyi2@xxxxxxxxxx> Reviewed-by: Min M Xu <min.m.xu@xxxxxxxxx> Reviewed-by: Jiewen Yao <jiewen.yao@xxxxxxxxx> commit 7513559926355dcd20516d01b0b44f2cddc2ff08 Author: Bob Feng <bob.c.feng@xxxxxxxxx> Date: Tue Sep 1 18:23:15 2020 +0800 BaseTools/Ecc: Fix an issue of path separator compatibility REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2904 The path separator is different in Windows and Linux, the original code does not handle this difference. This patch is to fix this issue. Signed-off-by: Bob Feng <bob.c.feng@xxxxxxxxx> Cc: Liming Gao <gaoliming@xxxxxxxxxxxxxx> Cc: Yuwei Chen <yuwei.chen@xxxxxxxxx> Cc: Shenglei Zhang <shenglei.zhang@xxxxxxxxx> Message-Id: <20200901102315.38840-1-bob.c.feng@xxxxxxxxx> Reviewed-by: Liming Gao <gaoliming@xxxxxxxxxxxxxx> commit 46db105b7b77bc478452887e25836cd0745e9b65 Author: Zhiguang Liu <zhiguang.liu@xxxxxxxxx> Date: Tue Sep 1 08:55:05 2020 +0800 SecurityPkg: Initailize variable Status before it is consumed. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2945 V2: Move "Status = EFI_SUCCESS;" before the EDKII_TCG_PRE_HASH check. Cc: Jiewen Yao <jiewen.yao@xxxxxxxxx> Cc: Jian J Wang <jian.j.wang@xxxxxxxxx> Cc: Qi Zhang <qi1.zhang@xxxxxxxxx> Cc: Rahul Kumar <rahul1.kumar@xxxxxxxxx> Cc: Laszlo Ersek <lersek@xxxxxxxxxx> Reviewed-by: Jiewen Yao <jiewen.yao@xxxxxxxxx> Signed-off-by: Zhiguang Liu <zhiguang.liu@xxxxxxxxx> Message-Id: <20200901005505.1722-1-zhiguang.liu@xxxxxxxxx> Reviewed-by: Laszlo Ersek <lersek@xxxxxxxxxx> commit 0c5c45a1337f82569aa9e60323e1a05a0cbbad74 Author: Qi Zhang <qi1.zhang@xxxxxxxxx> Date: Mon Aug 31 10:07:21 2020 +0800 IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dec: add FspMeasurementLib.h REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2944 Cc: Chasel Chiu <chasel.chiu@xxxxxxxxx> Cc: Nate DeSimone <nathaniel.l.desimone@xxxxxxxxx> Cc: Liming Gao <gaoliming@xxxxxxxxxxxxxx> Cc: Eric Dong <eric.dong@xxxxxxxxx> Signed-off-by: Qi Zhang <qi1.zhang@xxxxxxxxx> Message-Id: <20200831020721.8967-1-qi1.zhang@xxxxxxxxx> Reviewed-by: Chasel Chiu <chasel.chiu@xxxxxxxxx> commit 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0 Author: Paul <paul.grimes@xxxxxxx> Date: Fri Aug 28 04:40:51 2020 +0800 MdePkg: Correcting EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT definition In Acpi10.h, EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT is defined as 0x10, but should be 0x02 per the ACPI Specification. REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2937 Cc: Michael D Kinney <michael.d.kinney@xxxxxxxxx> Cc: Liming Gao <gaoliming@xxxxxxxxxxxxxx> Cc: Zhiguang Liu <zhiguang.liu@xxxxxxxxx> Signed-off-by: Paul G <paul.grimes@xxxxxxx> Reviewed-by: Liming Gao <gaoliming@xxxxxxxxxxxxxx> commit cbccf995920a28071f5403b847f29ebf8b732fa9 Author: Laszlo Ersek <lersek@xxxxxxxxxx> Date: Thu Aug 27 00:21:29 2020 +0200 OvmfPkg/CpuHotplugSmm: fix CPU hotplug race just after SMI broadcast The "virsh setvcpus" (plural) command may hot-plug several VCPUs in quick succession -- it means a series of "device_add" QEMU monitor commands, back-to-back. If a "device_add" occurs *just after* ACPI raises the broadcast SMI, then: - the CPU_FOREACH() loop in QEMU's ich9_apm_ctrl_changed() cannot make the SMI pending for the new CPU -- at that time, the new CPU doesn't even exist yet, - OVMF will find the new CPU however (in the CPU hotplug register block), in QemuCpuhpCollectApicIds(). As a result, when the firmware sends an INIT-SIPI-SIPI to the new CPU in SmbaseRelocate(), expecting it to boot into SMM (due to the pending SMI), the new CPU instead boots straight into the post-RSM (normal mode) "pen", skipping its initial SMI handler. The CPU halts nicely in the pen, but its SMBASE is never relocated, and the SMRAM message exchange with the BSP falls apart -- the BSP gets stuck in the following loop: // // Wait until the hot-added CPU is just about to execute RSM. // while (Context->AboutToLeaveSmm == 0) { CpuPause (); } because the new CPU's initial SMI handler never sets the flag to nonzero. Fix this by sending a directed SMI to the new CPU just before sending it the INIT-SIPI-SIPI. The various scenarios are documented in the code -- the cases affected by the patch are documented under point (2). Note that this is not considered a security patch, as for a malicious guest OS, the issue is not exploitable -- the symptom is a hang on the BSP, in the above-noted loop in SmbaseRelocate(). Instead, the patch fixes behavior for a benign guest OS. Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxx> Cc: Igor Mammedov <imammedo@xxxxxxxxxx> Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx> Cc: Philippe Mathieu-Daudé <philmd@xxxxxxxxxx> Fixes: 51a6fb41181529e4b50ea13377425bda6bb69ba6 Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2929 Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx> Message-Id: <20200826222129.25798-3-lersek@xxxxxxxxxx> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxx> commit 020bb4b46d6f6708bb3358e1c738109b7908f0de Author: Laszlo Ersek <lersek@xxxxxxxxxx> Date: Thu Aug 27 00:21:28 2020 +0200 OvmfPkg/CpuHotplugSmm: fix CPU hotplug race just before SMI broadcast The "virsh setvcpus" (plural) command may hot-plug several VCPUs in quick succession -- it means a series of "device_add" QEMU monitor commands, back-to-back. If a "device_add" occurs *just before* ACPI raises the broadcast SMI, then: - OVMF processes the hot-added CPU well. - However, QEMU's post-SMI ACPI loop -- which clears the pending events for the hot-added CPUs that were collected before raising the SMI -- is unaware of the stray CPU. Thus, the pending event is not cleared for it. As a result of the stuck event, at the next hot-plug, OVMF tries to re-add (relocate for the 2nd time) the already-known CPU. At that time, the AP is already in the normal edk2 SMM busy-wait however, so it doesn't respond to the exchange that the BSP intends to do in SmbaseRelocate(). Thus the VM gets stuck in SMM. (Because of the above symptom, this is not considered a security patch; it doesn't seem exploitable by a malicious guest OS.) In CpuHotplugMmi(), skip the supposedly hot-added CPU if it's already known. The post-SMI ACPI loop will clear the pending event for it this time. Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxx> Cc: Igor Mammedov <imammedo@xxxxxxxxxx> Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx> Cc: Philippe Mathieu-Daudé <philmd@xxxxxxxxxx> Fixes: bc498ac4ca7590479cfd91ad1bb8a36286b0dc21 Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2929 Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx> Message-Id: <20200826222129.25798-2-lersek@xxxxxxxxxx> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxx>
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |