|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen-4.7-testing test] 102518: regressions - FAIL
flight 102518 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/102518/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-winxpsp3-vcpus1 6 xen-boot fail REGR. vs. 101949 test-amd64-amd64-libvirt 11 guest-start fail REGR. vs. 101949 test-armhf-armhf-xl-xsm 5 xen-install fail REGR. vs. 101949 test-armhf-armhf-xl-arndale 6 xen-boot fail REGR. vs. 101949 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 101949 test-armhf-armhf-libvirt-xsm 6 xen-boot fail REGR. vs. 101949 test-amd64-i386-qemut-rhel6hvm-amd 9 redhat-install fail REGR. vs. 101949 test-armhf-armhf-libvirt 15 guest-start/debian.repeat fail REGR. vs. 101949 test-armhf-armhf-xl 15 guest-start/debian.repeat fail REGR. vs. 101949 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail REGR. vs. 101949 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail like 101949 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail like 101949 test-armhf-armhf-libvirt 13 saverestore-support-check fail like 101949 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101949 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101949 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 101949 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt 12 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-check fail never pass test-armhf-armhf-xl 12 migrate-support-check fail never pass test-armhf-armhf-xl 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 11 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-check fail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-rtds 12 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-check fail never pass version targeted for testing: xen 206fc7084dfaf05c55fd9de650f93a7ef9fe0722 baseline version: xen 86f912c86501b9a3c1abf908731e7d86778a594e Last test of basis 101949 2016-11-05 06:01:53 Z 17 days Testing same since 102518 2016-11-22 13:41:48 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Roger Pau Monné <roger.pau@xxxxxxxxxx> jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-armhf-pvops pass build-i386-pvops pass build-amd64-rumprun pass build-i386-rumprun pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-armhf-armhf-xl fail test-amd64-i386-xl pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm fail test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-armhf-armhf-xl-xsm fail test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-qemut-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-rumprun-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-armhf-armhf-xl-arndale fail test-amd64-amd64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-i386-freebsd10-i386 pass test-amd64-i386-rumprun-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvh-intel fail test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt fail test-armhf-armhf-libvirt fail test-amd64-i386-libvirt pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass test-amd64-amd64-xl-qemut-winxpsp3 pass test-amd64-i386-xl-qemut-winxpsp3 pass test-amd64-amd64-xl-qemuu-winxpsp3 pass test-amd64-i386-xl-qemuu-winxpsp3 pass ------------------------------------------------------------ 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 206fc7084dfaf05c55fd9de650f93a7ef9fe0722 Author: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> Date: Tue Nov 22 14:16:13 2016 +0100 pygrub: Properly quote results, when returning them to the caller: * When the caller wants sexpr output, use `repr()' This is what Xend expects. The returned S-expressions are now escaped and quoted by Python, generally using '...'. Previously kernel and ramdisk were unquoted and args was quoted with "..." but without proper escaping. This change may break toolstacks which do not properly dequote the returned S-expressions. * When the caller wants "simple" output, crash if the delimiter is contained in the returned value. With --output-format=simple it does not seem like this could ever happen, because the bootloader config parsers all take line-based input from the various bootloader config files. With --output-format=simple0, this can happen if the bootloader config file contains nul bytes. This is CVE-2016-9379 and CVE-2016-9380 / XSA-198. Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> Tested-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 27e14d346ed6ff1c3a3cfc479507e62d133e92a9 master date: 2016-11-22 13:52:09 +0100 commit a6b0650d858402bdb35a177db299c8f749affa3a Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Tue Nov 22 14:15:48 2016 +0100 x86/svm: fix injection of software interrupts The non-NextRip logic in c/s 36ebf14eb "x86/emulate: support for emulating software event injection" was based on an older version of the AMD software manual. The manual was later corrected, following findings from that series. I took the original wording of "not supported without NextRIP" to mean that X86_EVENTTYPE_SW_INTERRUPT was not eligible for use. It turns out that this is not the case, and the new wording is clearer on the matter. Despite testing the original patch series on non-NRip hardware, the swint-emulation XTF test case focuses on the debug vectors; it never ended up executing an `int $n` instruction for a vector which wasn't also an exception. During a vmentry, the use of X86_EVENTTYPE_HW_EXCEPTION comes with a vector check to ensure that it is only used with exception vectors. Xen's use of X86_EVENTTYPE_HW_EXCEPTION for `int $n` injection has always been buggy on AMD hardware. Fix this by always using X86_EVENTTYPE_SW_INTERRUPT. Print and decode the eventinj information in svm_vmcb_dump(), as it has several invalid combinations which cause vmentry failures. This is CVE-2016-9378 / part of XSA-196. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: 920edccd41db6cb0145545afa1850edf5e7d098e master date: 2016-11-22 13:51:16 +0100 commit 98eaf9ce737dbc72df0c8e15fa5962c428ed637a Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Tue Nov 22 14:15:17 2016 +0100 x86/emul: correct the IDT entry calculation in inject_swint() The logic, as introduced in c/s 36ebf14ebe "x86/emulate: support for emulating software event injection" is buggy. The size of an IDT entry depends on long mode being active, not the width of the code segment currently in use. In particular, this means that a compatibility code segment which hits emulation for software event injection will end up using an incorrect offset in the IDT for DPL/Presence checking. In practice, this only occurs on old AMD hardware lacking NRip support; all newer AMD hardware, and all Intel hardware bypass this path in the emulator. While here, fix a minor issue with reading the IDT entry. The return value from ops->read() wasn't checked, but in reality the only failure case is if a pagefault occurs. This is not a realistic problem as the kernel will almost certainly crash with a double fault if this setup actually occured. This is CVE-2016-9377 / part of XSA-196. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: 255e8fe95f22ded5186fd75244ffcfb9d5dbc855 master date: 2016-11-22 13:50:49 +0100 commit 1b65a347f3ce294524e242a49733e36de52f0ee7 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Nov 22 14:14:27 2016 +0100 x86emul: fix huge bit offset handling We must never chop off the high 32 bits. This is CVE-2016-9383 / XSA-195. Reported-by: George Dunlap <george.dunlap@xxxxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 1c6c2d60d205f71ede0fbbd9047e459112f576db master date: 2016-11-22 13:49:06 +0100 commit 8ce2238f197fde118e291932d869a8a6c10ac539 Author: Roger Pau Monné <roger.pau@xxxxxxxxxx> Date: Tue Nov 22 14:13:55 2016 +0100 libelf: fix stack memory leak when loading 32 bit symbol tables The 32 bit Elf structs are smaller than the 64 bit ones, which means that when loading them there's some padding left uninitialized at the end of each struct (because the size indicated in e_ehsize and e_shentsize is smaller than the size of elf_ehdr and elf_shdr). Fix this by introducing a new helper that is used to set [caller_]xdest_{base/size} and that takes care of performing the appropriate memset of the region. This newly introduced helper is then used to set and unset xdest_{base/size} in elf_load_bsdsyms. Now that the full struct is zeroed, there's no need to specifically zero the undefined section. This is CVE-2016-9384 / XSA-164. Suggested-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Also remove the open coded (and redundant with the earlier elf_memset_unchecked()) use of caller_xdest_* from elf_init(). Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> master commit: fb08f7d009a64b96efa4462c9d19ed6881936859 master date: 2016-11-22 13:48:30 +0100 commit 2cd9fa043e176c777a0e7430a4b82283d85746fc Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Nov 22 14:13:25 2016 +0100 x86/PV: writes of %fs and %gs base MSRs require canonical addresses Commit c42494acb2 ("x86: fix FS/GS base handling when using the fsgsbase feature") replaced the use of wrmsr_safe() on these paths without recognizing that wr{f,g}sbase() use just wrmsrl() and that the WR{F,G}SBASE instructions also raise #GP for non-canonical input. Similarly arch_set_info_guest() needs to prevent non-canonical addresses from getting stored into state later to be loaded by context switch code. For consistency also check stack pointers and LDT base. DR0..3, otoh, already get properly checked in set_debugreg() (albeit we discard the error there). The SHADOW_GS_BASE check isn't strictly necessary, but I think we better avoid trying the WRMSR if we know it's going to fail. This is CVE-2016-9385 / XSA-193. Reported-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: f3fa3abf3e61fb1f25ce721e14ac324dda67311f master date: 2016-11-22 13:46:28 +0100 commit 42bc34b5a414384152c73c9805da90d882baa882 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Nov 22 14:12:53 2016 +0100 x86/HVM: don't load LDTR with VM86 mode attrs during task switch Just like TR, LDTR is purely a protected mode facility and hence needs to be loaded accordingly. Also move its loading to where it architecurally belongs. This is CVE-2016-9382 / XSA-192. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Tested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 93aa42b85ae0084ba7b749d0e990c94fbf0c17e3 master date: 2016-11-22 13:45:44 +0100 commit e98e17e3a5915d9f75fc8ca9624919e02ddc9d4f Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Tue Nov 22 14:12:18 2016 +0100 x86/hvm: Fix the handling of non-present segments In 32bit, the data segments may be NULL to indicate that the segment is ineligible for use. In both 32bit and 64bit, the LDT selector may be NULL to indicate that the entire LDT is ineligible for use. However, nothing in Xen actually checks for this condition when performing other segmentation checks. (Note however that limit and writeability checks are correctly performed). Neither Intel nor AMD specify the exact behaviour of loading a NULL segment. Experimentally, AMD zeroes all attributes but leaves the base and limit unmodified. Intel zeroes the base, sets the limit to 0xfffffff and resets the attributes to just .G and .D/B. The use of the segment information in the VMCB/VMCS is equivalent to a native pipeline interacting with the segment cache. The present bit can therefore have a subtly different meaning, and it is now cooked to uniformly indicate whether the segment is usable or not. GDTR and IDTR don't have access rights like the other segments, but for consistency, they are treated as being present so no special casing is needed elsewhere in the segmentation logic. AMD hardware does not consider the present bit for %cs and %tr, and will function as if they were present. They are therefore unconditionally set to present when reading information from the VMCB, to maintain the new meaning of usability. Intel hardware has a separate unusable bit in the VMCS segment attributes. This bit is inverted and stored in the present field, so the hvm code can work with architecturally-common state. This is CVE-2016-9386 / XSA-191. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: 04beafa8e6c66f5cd814c00e2d2b51cfbc41cb8a master date: 2016-11-22 13:44:50 +0100 commit 0561a33838a026311a0fe61ac88628c398d52185 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Nov 22 14:10:29 2016 +0100 update Xen version to 4.7.2-pre (qemu changes not included) _______________________________________________ osstest-output mailing list osstest-output@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/cgi-bin/mailman/listinfo/osstest-output
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |