[ovmf test] 141080: regressions - FAIL

[osstest service owner <osstest-admin@xxxxxxxxxxxxxx>]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   6 xen-build                fail REGR. vs. 141054

Tests which did not succeed, but are not blocking:
 build-amd64-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                 59b754c9f697d9627b0ccccd327d5132f0e1abb0
baseline version:
 ovmf                 8a1305a11f3bda2d6c1ab758e4aea79ee021dd1c

Last test of basis   141054  2019-09-05 13:58:24 Z    0 days
Testing same since   141080  2019-09-06 03:49:55 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
  Laszlo Ersek <lersek@xxxxxxxxxx>
  Leif Lindholm <leif.lindholm@xxxxxxxxxx>
  Zhichao Gao <zhichao.gao@xxxxxxxxx>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-libvirt                                          blocked 
 build-i386-libvirt                                           pass    
 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 59b754c9f697d9627b0ccccd327d5132f0e1abb0
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Tue Jul 2 02:03:15 2019 +0200

    OvmfPkg/EnrollDefaultKeys: clean up Base64Decode() retval handling
    
    Since commit 35e242b698cd ("MdePkg/BaseLib: rewrite Base64Decode()",
    2019-07-16), Base64Decode() guarantees that DestinationSize is larger on
    output than it was on input if RETURN_BUFFER_TOO_SMALL is returned. Clean
    up the retval handling for the first Base64Decode() call in
    EnrollDefaultKeys, which used to work around the ambiguity in the previous
    Base64Decode() interface contract.
    
    Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Cc: Philippe Mathieu-Daudé <philmd@xxxxxxxxxx>
    Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1981
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Philippe Mathieu-Daude <philmd@xxxxxxxxxx>
    Acked-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>

commit ae9f12058d71d9c5971c3cf36191cd813ecc9554
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Tue Sep 3 17:08:45 2019 +0200

    ArmVirtPkg/PlatformBootManagerLib: unload image on EFI_SECURITY_VIOLATION
    
    The LoadImage() boot service is a bit unusual in that it allocates
    resources in a particular failure case; namely, it produces a valid
    "ImageHandle" when it returns EFI_SECURITY_VIOLATION. This is supposed to
    happen e.g. when Secure Boot verification fails for the image, but the
    platform policy for the particular image origin (such as "fixed media" or
    "removable media") is DEFER_EXECUTE_ON_SECURITY_VIOLATION. The return code
    allows platform logic to selectively override the verification failure,
    and launch the image nonetheless.
    
    ArmVirtPkg/PlatformBootManagerLib does not override EFI_SECURITY_VIOLATION
    for the kernel image loaded from fw_cfg -- any LoadImage() error is
    considered fatal. When we simply treat EFI_SECURITY_VIOLATION like any
    other LoadImage() error, we leak the resources associated with
    "KernelImageHandle". From a resource usage perspective,
    EFI_SECURITY_VIOLATION must be considered "success", and rolled back.
    
    Implement this rollback, without breaking the proper "nesting" of error
    handling jumps and labels.
    
    Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Cc: Dandan Bi <dandan.bi@xxxxxxxxx>
    Cc: Leif Lindholm <leif.lindholm@xxxxxxxxxx>
    Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
    Fixes: 23d04b58e27b382bbd3f9b16ba9adb1cb203dad5
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Acked-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Dandan Bi <dandan.bi@xxxxxxxxx>
    Reviewed-by: Philippe Mathieu-Daude <philmd@xxxxxxxxxx>

commit 23908d0f5cc6bc04a0d19f694cd8c2a392077da0
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Wed Sep 4 09:30:47 2019 -0700

    ShellPkg/ShellPkg.dsc AARCH64: enable stack protector
    
    Incorporate the stack protector library into the AARCH64 build of
    the Shell binaries as a NULL library resolution, to avoid build
    errors when the compiler injects stack integrity checks.
    
    Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx>
    Acked-by: Zhichao Gao <zhichao.gao@xxxxxxxxx>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>

commit 04d9d89b7dd489c22558fc9691fc8152704c827f
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Wed Sep 4 15:49:28 2019 -0700

    ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: revert to PIE linking
    
    In some cases, the CLANG38 toolchain profile in LTO mode emits GOT
    based relocations in spite of our attempts to avoid this, by using
    hidden visibility, -Bsymbolic etc.
    
    On AARCH64, we managed to work around this by processing the GOT
    based relocations in GenFw. As it turns out, the same issue exists
    on 32-bit ARM, but unfortunately, we cannot use a similar trick to
    get rid of the GOT entry, and the relocation metadata is insufficient
    to locate the GOT entry in the binary.
    
    Note that in this particular case, we are interested in PIE linking
    only (i.e., producing a .rela section containing dynamic relocations
    that the startup code can process directly), and not in position
    independent code generation, and by passing the -pie option to the
    linker directly using -Wl,-pie (and dropping -shared), we can coerce
    the GOLD linker into doing only the former rather than both when it
    performs its LTO code generation.
    
    Acked-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>

_______________________________________________
osstest-output mailing list
osstest-output@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/osstest-output