|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.4-testing test] 26094: regressions - FAIL
flight 26094 xen-4.4-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/26094/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 25794 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 9 guest-start fail never pass test-armhf-armhf-libvirt 9 guest-start fail never pass test-amd64-amd64-libvirt 9 guest-start fail never pass test-armhf-armhf-xl 10 migrate-support-check fail never pass test-amd64-i386-xend-winxpsp3 17 leak-check/check fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass version targeted for testing: xen c9732f814a22337c6427a24be6ead993e656290a baseline version: xen 03eb5134056d61167e6781eecf7e570b491bda73 ------------------------------------------------------------ People who touched revisions under test: Ian Campbell <ian.campbell@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Julien Grall <julien.grall@xxxxxxxxxx> Tim Deegan <tim@xxxxxxx> ------------------------------------------------------------ jobs: build-amd64-xend pass build-i386-xend pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd 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-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-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass 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 fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-i386-xend-qemut-winxpsp3 fail test-amd64-amd64-xl-qemut-winxpsp3 fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on osstest.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit c9732f814a22337c6427a24be6ead993e656290a Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Apr 29 15:27:22 2014 +0200 x86/HVM: restrict HVMOP_set_mem_type Permitting arbitrary type changes here has the potential of creating present P2M (and hence EPT/NPT/IOMMU) entries pointing to an invalid MFN (INVALID_MFN truncated to the respective hardware structure field's width). This would become a problem the latest when something real sat at the end of the physical address space; I'm suspecting though that other things might break with such bogus entries. Along with that drop a bogus (and otherwise becoming stale) log message. Afaict the similar operation in p2m_set_mem_access() is safe. This is XSA-92. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Tim Deegan <tim@xxxxxxx> master commit: 83bb5eb4d340acebf27b34108fb1dae062146a68 master date: 2014-04-29 15:11:31 +0200 commit 9462b4a7af447b052a1d924a804520f748cd94b4 Author: Julien Grall <julien.grall@xxxxxxxxxx> Date: Thu Apr 10 12:43:57 2014 +0100 xen/arm64: Correctly align VFP regs On arm64, VFP instructions requires vfpregs to be 128-byte aligned. By chance, the field is already correctly aligned. In the case if someone decides to add a new field before, Xen will receive a data abort as soon as it saves/restores VFP. We are safe on arm32 as the only constraint is to be 32-byte aligned. Reported-by: Chen Baozi <baozich@xxxxxxxxx> Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> (cherry picked from commit 9b4e96724eeb916f2cd311d9133f00c216caa321) commit 64268fb6be4a417971a14cb95959bc68789ef37b Author: Ian Campbell <ian.campbell@xxxxxxxxxx> Date: Wed Mar 5 01:02:29 2014 +0000 xen: arm: prevent building with CONFIG_EARLY_PRINTK if not a debug build early printk on ARM is tied to debug being enabled, so error out instead of silently and unexpectedly building without early printk when asked. Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Acked-by: Julien Grall <julien.grall@xxxxxxxxxx> (cherry picked from commit 5940d3d095661f541a843e5d4c5f9363c18cd63c) commit 0105b1ae028f4a26916999884d6d18a92b6f84de Author: Julien Grall <julien.grall@xxxxxxxxxx> Date: Thu Mar 20 13:51:26 2014 +0000 xen/arm: domain_vgic_init: Check xzalloc_* return The allocations for shared_irqs and pending_irqs are not checked and use later. This may lead to a Xen segfault if the hypervisor run out of memory. Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> (cherry picked from commit a34f6affe799cf493640b58a794132d213288ba3) commit 139a62e98161051e7687d6c356d9a9b92a8801a3 Author: Ian Campbell <ian.campbell@xxxxxxxxxx> Date: Wed Apr 23 16:32:45 2014 +0100 xen/arm: vgic: Check rank in GICD_ICFGR* emulation before locking The function vgic_irq_rank may return NULL is the IRQ is not in range handled by the guest. This will result to derefence a NULL pointer which will crash Xen. I've checked the rest of the emulation and this is only place where the lock is taken before the rank is checked. This is CVE-2014-2986 / XSA-94. Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx> Reported-by: Thomas Leonard <talex5@xxxxxxxxx> Reviewed-by: Jan Beulich <JBeulich@xxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> commit fc070bcb683e6251a4c18b144ca7d869fc2f6467 Author: Ian Campbell <ian.campbell@xxxxxxxxxx> Date: Wed Apr 23 16:25:21 2014 +0200 xen: x86 & generic: change to __builtin_prefetch() Quoting Andi Kleen in Linux b483570a13be from 2007: gcc 3.2+ supports __builtin_prefetch, so it's possible to use it on all architectures. Change the generic fallback in linux/prefetch.h to use it instead of noping it out. gcc should do the right thing when the architecture doesn't support prefetching Undefine the x86-64 inline assembler version and use the fallback. ARM wants to use the builtins. Fix a pair of spelling errors, one of which was from Lucas De Marchi in the Linux tree. Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Cc: Keir Fraser <keir@xxxxxxx> Acked-by: Tim Deegan <tim@xxxxxxx> master commit: 630017f420f111e0c0332dbd99df30ebb8fed207 master date: 2014-04-03 17:15:41 +0100 commit cbd5a0c3fd72983fb7b4b5c689280209f8da218b Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Wed Apr 23 16:24:02 2014 +0200 x86/mm: fix checks against max_mapped_pfn This value is an inclusive one, i.e. this fixes an off-by-one in memory sharing and an off-by-two in shadow code. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Tim Deegan <tim@xxxxxxx> master commit: 088ee1d47b65d6bb92de61b404805f4ca92e3240 master date: 2014-04-03 12:08:43 +0100 commit da8e1586278dffd8510876e6fed8d47c9eba713c Author: Julien Grall <julien.grall@xxxxxxxxxx> Date: Tue Apr 15 14:06:42 2014 +0100 xen/arm: Don't let guess access to Debug and Performance Monitor registers Debug and performance registers are not properly switched by Xen. Trap them and inject an undefined instruction, except for those registers which might be unconditionally accessed which we implement as RAZ/WI. This is CVE-2014-2915 / XSA-93. Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx> Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> commit 8f416fc2669769a72783e13072547f8b2d071065 Author: Julien Grall <julien.grall@xxxxxxxxxx> Date: Tue Apr 15 12:45:28 2014 +0100 xen/arm: Don't expose implementation defined registers (Cp15 c15) to the guest On Cortex-A15, CP15 c15 contains registers to retrieve data from L1/L2 RAM. Exposing this registers to guest may result to leak data from Xen and/or another guest. By default trap every registers and inject an undefined instruction. This is CVE-2014-2915 / XSA-93. Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> commit 4642a2146e3d309266f537e7bbf55f5d85249229 Author: Julien Grall <julien.grall@xxxxxxxxxx> Date: Mon Apr 14 20:00:14 2014 +0100 xen/arm: Trap cache and TCM lockdown registers Some cp15 c9/c10/c11 encodings are used for: - cache control - TCM control - branch predictor control All of them are implementation defined. For now inject an undefined exception if the guest wants try to access it. This is CVE-2014-2915 / XSA-93. Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> commit 16ef39e797b0ef82449321ff5af7590e17b1b670 Author: Julien Grall <julien.grall@xxxxxxxxxx> Date: Mon Apr 14 20:46:43 2014 +0100 xen/arm: Upgrade DCISW into DCCISW A guest is allowed to use invalidate cache by set/way instruction (i.e DCISW) without any restriction. As the cache is shared with Xen, the guest invalidate an address being in used by Xen. This may lead a Xen crash because the memory state is invalid. Set the bit HCR.SWIO to upgrade invalidate cache by set/way instruction to an invalidate and clean. This is CVE-2014-2915 / XSA-93. Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx> Reported-by: Thomas Leonard <tal36@xxxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> commit 9800bfa275b654b20522c1c8e78eba12d4b21e2f Author: Julien Grall <julien.grall@xxxxxxxxxx> Date: Mon Apr 14 20:37:16 2014 +0100 xen/arm: Don't let the guest access the coprocessors registers In Xen we only handle save/restore for coprocessor 10 and 11 (NEON). Other coprocessors (0-9, 12-13) are currently exposed to the guest and may lead to data shared between guest. Disable access to all coprocessor except 10 and 11 by setting correctly HCTPR. This is CVE-2014-2915 / XSA-93. Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> commit ed13367f161c8e0716f75773c7915df1d0388263 Author: Julien Grall <julien.grall@xxxxxxxxxx> Date: Mon Apr 14 19:01:20 2014 +0100 xen/arm: Inject an undefined instruction when the coproc/sysreg is not handled Currently Xen panics if it's unable to handle a coprocessor/sysreg instruction. Replace this behavior by inject an undefined instruction to the faulty guest and log if Xen is in debug mode. This is CVE-2014-2915 / XSA-93. Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |