* [Xen-devel] [ovmf test] 141080: regressions - FAIL
@ 2019-09-06 13:18 osstest service owner
0 siblings, 0 replies; only message in thread
From: osstest service owner @ 2019-09-06 13:18 UTC (permalink / raw)
To: xen-devel, osstest-admin
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@linaro.org>
Laszlo Ersek <lersek@redhat.com>
Leif Lindholm <leif.lindholm@linaro.org>
Zhichao Gao <zhichao.gao@intel.com>
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@redhat.com>
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@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1981
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
commit ae9f12058d71d9c5971c3cf36191cd813ecc9554
Author: Laszlo Ersek <lersek@redhat.com>
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@linaro.org>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Fixes: 23d04b58e27b382bbd3f9b16ba9adb1cb203dad5
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
commit 23908d0f5cc6bc04a0d19f694cd8c2a392077da0
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
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@linaro.org>
Acked-by: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
commit 04d9d89b7dd489c22558fc9691fc8152704c827f
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
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@linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2019-09-06 13:18 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-06 13:18 [Xen-devel] [ovmf test] 141080: regressions - FAIL osstest service owner
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.