From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 928ABC433E7 for ; Wed, 2 Sep 2020 22:43:38 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 50A9120758 for ; Wed, 2 Sep 2020 22:43:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=xenproject.org header.i=@xenproject.org header.b="mRjlAn+U" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 50A9120758 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xenproject.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kDbSx-000679-Pc; Wed, 02 Sep 2020 22:42:55 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kDbSw-000674-8Q for xen-devel@lists.xenproject.org; Wed, 02 Sep 2020 22:42:54 +0000 X-Inumbo-ID: 47d9f0f1-9431-4fce-91a9-f17e958e9ec1 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 47d9f0f1-9431-4fce-91a9-f17e958e9ec1; Wed, 02 Sep 2020 22:42:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=G2b17DzAbCQW+49OrbBV86oZhOhxXnkAlIKsIMvxE1E=; b=mRjlAn+U0UBl/udnSUs+XKpPE5 vMVUmvtKB5lwXcfrtlK1MMYiocvHVbOG/HzlxLilBAHnfvaWrbLYpv17i7phxEUiGWr1GTIqEuOhK /ciLJTAW55YWORdn8Kr/Lc/ytuw7b4LB/4Y3LPJYMtvvFFE3aeH9OKAqs6UlKFvC2GCw=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kDbSs-000124-Tc; Wed, 02 Sep 2020 22:42:50 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kDbSs-00033V-Lu; Wed, 02 Sep 2020 22:42:50 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1kDbSs-0006f6-LP; Wed, 02 Sep 2020 22:42:50 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 153595: regressions - FAIL X-Osstest-Failures: ovmf:build-i386-xsm:xen-build:fail:regression ovmf:build-amd64-xsm:xen-build:fail:regression ovmf:build-amd64:xen-build:fail:regression ovmf:build-i386:xen-build:fail:regression ovmf:build-amd64-libvirt:build-check(1):blocked:nonblocking ovmf:build-i386-libvirt:build-check(1):blocked:nonblocking ovmf:test-amd64-amd64-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking ovmf:test-amd64-i386-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking X-Osstest-Versions-This: ovmf=e8453aa373e96ed76b72a6968d8a48dfb002a1a6 X-Osstest-Versions-That: ovmf=63d92674d240ab4ecab94f98e1e198842bb7de00 From: osstest service owner Date: Wed, 02 Sep 2020 22:42:50 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 153595 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/153595/ 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 117 attempts Testing same since 153553 2020-09-02 12:40:39 Z 0 days 6 attempts ------------------------------------------------------------ People who touched revisions under test: Bob Feng Laszlo Ersek Paul Paul G Qi Zhang Wenyi Xie Zhiguang Liu 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 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 Cc: Jian J Wang Cc: Hao A Wu Cc: Jiewen Yao Reviewed-by: Laszlo Ersek Message-Id: <20200901072622.9391-1-qi1.zhang@intel.com> Reviewed-by: Jian J Wang commit 0b143fa43e92be15d11e22f80773bcb1b2b0608f Author: Laszlo Ersek 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 Cc: Jiewen Yao Cc: Min Xu Cc: Wenyi Xie Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2215 Signed-off-by: Laszlo Ersek Message-Id: <20200901091221.20948-4-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé Tested-by: Wenyi Xie Reviewed-by: Min M Xu Reviewed-by: Jiewen Yao commit a7632e913c1c106f436aefd5e76c394249c383a8 Author: Laszlo Ersek 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 Cc: Jiewen Yao Cc: Min Xu Cc: Wenyi Xie Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2215 Signed-off-by: Laszlo Ersek Message-Id: <20200901091221.20948-3-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé Tested-by: Wenyi Xie Reviewed-by: Min M Xu Reviewed-by: Jiewen Yao commit 503248ccdf45c14d4040ce44163facdc212e4991 Author: Laszlo Ersek 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 Cc: Jiewen Yao Cc: Min Xu Cc: Wenyi Xie Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2215 Signed-off-by: Laszlo Ersek Message-Id: <20200901091221.20948-2-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé Tested-by: Wenyi Xie Reviewed-by: Min M Xu Reviewed-by: Jiewen Yao commit 7513559926355dcd20516d01b0b44f2cddc2ff08 Author: Bob Feng 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 Cc: Liming Gao Cc: Yuwei Chen Cc: Shenglei Zhang Message-Id: <20200901102315.38840-1-bob.c.feng@intel.com> Reviewed-by: Liming Gao commit 46db105b7b77bc478452887e25836cd0745e9b65 Author: Zhiguang Liu 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 Cc: Jian J Wang Cc: Qi Zhang Cc: Rahul Kumar Cc: Laszlo Ersek Reviewed-by: Jiewen Yao Signed-off-by: Zhiguang Liu Message-Id: <20200901005505.1722-1-zhiguang.liu@intel.com> Reviewed-by: Laszlo Ersek commit 0c5c45a1337f82569aa9e60323e1a05a0cbbad74 Author: Qi Zhang 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 Cc: Nate DeSimone Cc: Liming Gao Cc: Eric Dong Signed-off-by: Qi Zhang Message-Id: <20200831020721.8967-1-qi1.zhang@intel.com> Reviewed-by: Chasel Chiu commit 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0 Author: Paul 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 Cc: Liming Gao Cc: Zhiguang Liu Signed-off-by: Paul G Reviewed-by: Liming Gao commit cbccf995920a28071f5403b847f29ebf8b732fa9 Author: Laszlo Ersek 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 Cc: Igor Mammedov Cc: Jordan Justen Cc: Philippe Mathieu-Daudé Fixes: 51a6fb41181529e4b50ea13377425bda6bb69ba6 Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2929 Signed-off-by: Laszlo Ersek Message-Id: <20200826222129.25798-3-lersek@redhat.com> Reviewed-by: Ard Biesheuvel commit 020bb4b46d6f6708bb3358e1c738109b7908f0de Author: Laszlo Ersek 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 Cc: Igor Mammedov Cc: Jordan Justen Cc: Philippe Mathieu-Daudé Fixes: bc498ac4ca7590479cfd91ad1bb8a36286b0dc21 Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2929 Signed-off-by: Laszlo Ersek Message-Id: <20200826222129.25798-2-lersek@redhat.com> Reviewed-by: Ard Biesheuvel