[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[xen-unstable-smoke test] 122662: regressions - FAIL



flight 122662 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122662/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt    18 guest-start/debian.repeat fail REGR. vs. 122642

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  92938e5d149669033aecdfb3d1396948d49d1887
baseline version:
 xen                  f78c8322850dbe3dbe9cd828ee00767190529100

Last test of basis   122642  2018-05-07 16:00:38 Z    1 days
Failing since        122654  2018-05-08 17:00:50 Z    0 days    2 attempts
Testing same since   122662  2018-05-08 19:00:37 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Roger Pau Monné <roger.pau@xxxxxxxxxx>
  Xen Project Security Team <security@xxxxxxxxxxxxxx>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386                     pass    
 test-amd64-amd64-libvirt                                     fail    


------------------------------------------------------------
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 92938e5d149669033aecdfb3d1396948d49d1887
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue May 8 18:12:56 2018 +0100

    x86/HVM: guard against emulator driving ioreq state in weird ways
    
    In the case where hvm_wait_for_io() calls wait_on_xen_event_channel(),
    p->state ends up being read twice in succession: once to determine that
    state != p->state, and then again at the top of the loop.  This gives a
    compromised emulator a chance to change the state back between the two
    reads, potentially keeping Xen in a loop indefinitely.
    
    Instead:
    * Read p->state once in each of the wait_on_xen_event_channel() tests,
    * re-use that value the next time around,
    * and insist that the states continue to transition "forward" (with the
      exception of the transition to STATE_IOREQ_NONE).
    
    This is XSA-262.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx>

commit 14c3f68a57361f20be33ec3848f83d8636a0d34e
Author: Xen Project Security Team <security@xxxxxxxxxxxxxx>
Date:   Tue May 8 18:12:10 2018 +0100

    x86/vpt: add support for IO-APIC routed interrupts
    
    And modify the HPET code to make use of it. Currently HPET interrupts
    are always treated as ISA and thus injected through the vPIC. This is
    wrong because HPET interrupts when not in legacy mode should be
    injected from the IO-APIC.
    
    To make things worse, the supported interrupt routing values are set
    to [20..23], which clearly falls outside of the ISA range, thus
    leading to an ASSERT in debug builds or memory corruption in non-debug
    builds because the interrupt injection code will write out of the
    bounds of the arch.hvm_domain.vpic array.
    
    Since the HPET interrupt source can change between ISA and IO-APIC
    always destroy the timer before changing the mode, or else Xen risks
    changing it while the timer is active.
    
    Note that vpt interrupt injection is racy in the sense that the
    vIO-APIC RTE entry can be written by the guest in between the call to
    pt_irq_masked and hvm_ioapic_assert, or the call to pt_update_irq and
    pt_intr_post. Those are not deemed to be security issues, but rather
    quirks of the current implementation. In the worse case the guest
    might lose interrupts or get multiple interrupt vectors injected for
    the same timer source.
    
    This is part of XSA-261.
    
    Address actual and potential compiler warnings. Fix formatting.
    
    Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit 75d6828bc2146d0eea16adc92376951a310d94a7
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Fri Mar 23 17:03:42 2018 +0000

    x86/traps: Fix handling of #DB exceptions in hypervisor context
    
    The WARN_ON() can be triggered by guest activities, and emits a full stack
    trace without rate limiting.  Swap it out for a ratelimited printk with just
    enough information to work out what is going on.
    
    Not all #DB exceptions are traps, so blindly continuing is not a safe action
    to take.  We don't let PV guests select these settings in the real %dr7 to
    begin with, but for added safety against unexpected situations, detect the
    fault cases and crash in an obvious manner.
    
    This is part of XSA-260 / CVE-2018-8897
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 5d37af364dc158aa387f7c8b2a05c90325c63dce
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Thu Mar 22 11:27:03 2018 +0000

    x86/traps: Use an Interrupt Stack Table for #DB
    
    PV guests can use architectural corner cases to cause #DB to be raised after
    transitioning into supervisor mode.
    
    Use an interrupt stack table for #DB to prevent the exception being taken 
with
    a guest controlled stack pointer.
    
    This is part of XSA-260 / CVE-2018-8897
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 0c6c2b1428658687b8f603bf248dec5bdcd882a9
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Thu Mar 22 11:27:03 2018 +0000

    x86/pv: Move exception injection into {,compat_}test_all_events()
    
    This allows paths to jump straight to {,compat_}test_all_events() and have
    injection of pending exceptions happen automatically, rather than requiring
    all calling paths to handle exceptions themselves.
    
    The normal exception path is simplified as a result, and
    compat_post_handle_exception() is removed entirely.
    
    This is part of XSA-260 / CVE-2018-8897
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit f7d457524c7d4fbf8fba635452e12c057fe71e60
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Mon Mar 26 09:02:34 2018 +0100

    x86/traps: Fix %dr6 handing in #DB handler
    
    Most bits in %dr6 accumulate, rather than being set directly based on the
    current source of #DB.  Have the handler follow the manuals guidance, which
    avoids leaking hypervisor debugging activities into guest context.
    
    This is part of XSA-260 / CVE-2018-8897
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit b190f0c0c1dff13ce92c5f056a87d6c81d3ee8f9
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Tue May 8 13:45:45 2018 +0100

    x86/domain: Drop the only-written smap_check_policy infrastructure
    
    c/s 4c5d78a10d "x86/pagewalk: Re-implement the pagetable walker" dropped the
    consumer of smap_policy.  Looking at c/s 31ae587e6f which introduced the
    smap_check logic, it exists only to work around a bug in guest_walk_tables()
    was resolved by the aformentioned commit.
    
    Remove the unused variables and associated infrastructure.
    
    Reported-by: Jason Andryuk <jandryuk@xxxxxxxxx>
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx>
    Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Release-acked-by: Juergen Gross <jgross@xxxxxxxx>
(qemu changes not included)

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.