[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ovmf test] 153552: regressions - FAIL



flight 153552 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153552/

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                 0b143fa43e92be15d11e22f80773bcb1b2b0608f
baseline version:
 ovmf                 63d92674d240ab4ecab94f98e1e198842bb7de00

Last test of basis   152863  2020-08-26 16:09:47 Z    6 days
Failing since        152915  2020-08-27 18:09:42 Z    5 days  111 attempts
Testing same since   153549  2020-09-02 10:41:52 Z    0 days    2 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 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>



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.