xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: osstest service owner <osstest-admin@xenproject.org>
To: xen-devel@lists.xensource.com, osstest-admin@xenproject.org
Subject: [qemu-upstream-4.3-testing test] 95831: regressions - trouble: blocked/broken/fail/pass
Date: Fri, 17 Jun 2016 08:58:18 +0000	[thread overview]
Message-ID: <osstest-95831-mainreport@xen.org> (raw)

flight 95831 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95831/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt           5 libvirt-build             fail REGR. vs. 80927
 build-i386-libvirt            5 libvirt-build             fail REGR. vs. 80927

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-raw        3 host-install(3)  broken in 95788 pass in 95831
 test-amd64-i386-freebsd10-i386 3 host-install(3) broken in 95788 pass in 95831
 test-amd64-i386-xl            3 host-install(3)           broken pass in 95788
 test-amd64-amd64-pygrub       3 host-install(3)           broken pass in 95788
 test-amd64-amd64-amd64-pvgrub  3 host-install(3)          broken pass in 95788

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop              fail like 80927
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop             fail like 80927

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install     fail never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install      fail never pass

version targeted for testing:
 qemuu                12e8fccf5b5460be7aecddc71d27eceaba6e1f15
baseline version:
 qemuu                10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis    80927  2016-02-06 13:30:02 Z  131 days
Failing since         93977  2016-05-10 11:09:16 Z   37 days  126 attempts
Testing same since    95534  2016-06-11 00:59:46 Z    6 days    6 attempts

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Stefano Stabellini <sstabellini@kernel.org>
  Wei Liu <wei.liu2@citrix.com>

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          fail    
 build-i386-libvirt                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           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                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-credit2                                  pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-amd64-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-amd64-pvgrub                                broken  
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-pygrub                                      broken  
 test-amd64-amd64-xl-qcow2                                    pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     pass    
 test-amd64-amd64-libvirt-vhd                                 blocked 
 test-amd64-amd64-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

broken-step test-amd64-i386-xl host-install(3)
broken-step test-amd64-amd64-pygrub host-install(3)
broken-step test-amd64-amd64-amd64-pvgrub host-install(3)

Not pushing.

------------------------------------------------------------
commit 12e8fccf5b5460be7aecddc71d27eceaba6e1f15
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu May 26 16:21:56 2016 +0100

    main loop: Big hammer to fix logfile disk DoS in Xen setups
    
    Each time round the main loop, we now fstat stderr.  If it is too big,
    we dup2 /dev/null onto it.  This is not a very pretty patch but it is
    very simple, easy to see that it's correct, and has a low risk of
    collateral damage.
    
    There is no limit by default but can be adjusted by setting a new
    environment variable.
    
    This fixes CVE-2014-3672.
    
    Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    Tested-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    Set the default to 0 so that it won't affect non-xen installation. The
    limit will be set by Xen toolstack.
    
    Signed-off-by: Wei Liu <wei.liu2@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Anthony PERARD <anthony.perard@citrix.com>
    (cherry picked from commit 44a072f0de0d57c95c2212bbce02888832b7b74f)

commit 0aabf85123a437e60e6cfb15f13bc559b75a21d5
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Tue May 17 10:54:54 2016 +0200

    vga: add sr_vbe register set
    
    Commit "fd3c136 vga: make sure vga register setup for vbe stays intact
    (CVE-2016-3712)." causes a regression.  The win7 installer is unhappy
    because it can't freely modify vga registers any more while in vbe mode.
    
    This patch introduces a new sr_vbe register set.  The vbe_update_vgaregs
    will fill sr_vbe[] instead of sr[].  Normal vga register reads and
    writes go to sr[].  Any sr register read access happens through a new
    sr() helper function which will read from sr_vbe[] with vbe active and
    from sr[] otherwise.
    
    This way we can allow guests update sr[] registers as they want, without
    allowing them disrupt vbe video modes that way.
    
    upstream-commit-id: 94ef4f337fb614f18b765a8e0e878a4c23cdedcd
    
    Cc: qemu-stable@nongnu.org
    Reported-by: Thomas Lamprecht <thomas@lamprecht.org>
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Message-id: 1463475294-14119-1-git-send-email-kraxel@redhat.com

commit c97c20f71240a538a19cb6b0e598bc1bbd5168f1
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Wed May 4 17:43:36 2016 +0100

    vga: make sure vga register setup for vbe stays intact (CVE-2016-3712).
    
    Call vbe_update_vgaregs() when the guest touches GFX, SEQ or CRT
    registers, to make sure the vga registers will always have the
    values needed by vbe mode.  This makes sure the sanity checks
    applied by vbe_fixup_regs() are effective.
    
    Without this guests can muck with shift_control, can turn on planar
    vga modes or text mode emulation while VBE is active, making qemu
    take code paths meant for CGA compatibility, but with the very
    large display widths and heigts settable using VBE registers.
    
    Which is good for one or another buffer overflow.  Not that
    critical as they typically read overflows happening somewhere
    in the display code.  So guests can DoS by crashing qemu with a
    segfault, but it is probably not possible to break out of the VM.
    
    upstream-commit-id: fd3c136b3e1482cd0ec7285d6bc2a3e6a62c38d7
    
    Fixes: CVE-2016-3712
    Reported-by: Zuozhi Fzz <zuozhi.fzz@alibaba-inc.com>
    Reported-by: P J P <ppandit@redhat.com>
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>

commit 5ee8a0795e9656b370e9f67b6acea2f2690a1aca
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Wed May 4 17:42:59 2016 +0100

    vga: update vga register setup on vbe changes
    
    Call the new vbe_update_vgaregs() function on vbe configuration
    changes, to make sure vga registers are up-to-date.
    
    upstream-commit-id: 2068192dcccd8a80dddfcc8df6164cf9c26e0fc4
    
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>

commit 7073ff0127babd7d8b35326cf50753b337b23bb0
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Wed May 4 17:42:24 2016 +0100

    vga: factor out vga register setup
    
    When enabling vbe mode qemu will setup a bunch of vga registers to make
    sure the vga emulation operates in correct mode for a linear
    framebuffer.  Move that code to a separate function so we can call it
    from other places too.
    
    upstream-commit-id: 7fa5c2c5dc9f9bf878c1e8669eb9644d70a71e71
    
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>

commit 856e1ebb1fcc44856ef682e31295310a29e66ffd
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Wed May 4 17:41:39 2016 +0100

    vga: add vbe_enabled() helper
    
    Makes code a bit easier to read.
    
    upstream-commit-id: bfa0f151a564a83b5a26f3e917da98674bf3cf62
    
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>

commit cae20a4a923c292158080bf538d7583fc2e1b455
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Wed May 4 17:40:58 2016 +0100

    vga: fix banked access bounds checking (CVE-2016-3710)
    
    vga allows banked access to video memory using the window at 0xa00000
    and it supports a different access modes with different address
    calculations.
    
    The VBE bochs extentions support banked access too, using the
    VBE_DISPI_INDEX_BANK register.  The code tries to take the different
    address calculations into account and applies different limits to
    VBE_DISPI_INDEX_BANK depending on the current access mode.
    
    Which is probably effective in stopping misprogramming by accident.
    But from a security point of view completely useless as an attacker
    can easily change access modes after setting the bank register.
    
    Drop the bogus check, add range checks to vga_mem_{readb,writeb}
    instead.
    
    upstream-commit-id: 3bf1817079bb0d80c0d8a86a7c7dd0bfe90eb82e
    
    Fixes: CVE-2016-3710
    Reported-by: Qinghao Tang <luodalongde@gmail.com>
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

                 reply	other threads:[~2016-06-17  8:58 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=osstest-95831-mainreport@xen.org \
    --to=osstest-admin@xenproject.org \
    --cc=xen-devel@lists.xensource.com \
    --subject='Re: [qemu-upstream-4.3-testing test] 95831: regressions - trouble: blocked/broken/fail/pass' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).