* [xen-unstable test] 15452: regressions - FAIL
@ 2013-02-09 7:00 xen.org
2013-02-11 11:12 ` Ian Campbell
0 siblings, 1 reply; 3+ messages in thread
From: xen.org @ 2013-02-09 7:00 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson
flight 15452 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15452/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-credit2 14 guest-localmigrate/x10 fail REGR. vs. 15442
test-amd64-i386-xl-multivcpu 14 guest-localmigrate/x10 fail REGR. vs. 15442
test-amd64-amd64-pv 14 guest-localmigrate/x10 fail REGR. vs. 15442
test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check fail REGR. vs. 15442
test-amd64-i386-win 11 guest-localmigrate.2 fail REGR. vs. 15442
test-amd64-i386-xend-qemut-winxpsp3 11 guest-localmigrate.2 fail REGR. vs. 15442
test-amd64-i386-xl-qemut-win-vcpus1 7 windows-install fail REGR. vs. 15442
test-amd64-i386-qemut-win 11 guest-localmigrate.2 fail REGR. vs. 15442
test-amd64-amd64-qemut-win 7 windows-install fail REGR. vs. 15442
test-amd64-i386-win-vcpus1 7 windows-install fail REGR. vs. 15442
test-amd64-amd64-win 7 windows-install fail REGR. vs. 15442
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-sedf 5 xen-boot fail like 15442
test-amd64-amd64-xl-sedf-pin 5 xen-boot fail like 15442
test-amd64-amd64-xl-qemut-win 7 windows-install fail like 15442
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop fail never pass
test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass
test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop fail never pass
test-amd64-i386-qemut-win-vcpus1 16 leak-check/check fail never pass
test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass
test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass
test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass
test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop fail never pass
test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass
test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass
test-amd64-amd64-xl-win 13 guest-stop fail never pass
version targeted for testing:
xen fd997a96d448
baseline version:
xen 6c1b12c884b4
------------------------------------------------------------
People who touched revisions under test:
David Scott <dave.scott@eu.citrix.com>
Ian Campbell <ian.campbell@citrix.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Keir Fraser <keir@xen.org>
Matthew Daley <mattjd@gmail.com>
------------------------------------------------------------
jobs:
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-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-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-win7-amd64 fail
test-amd64-i386-xl-win7-amd64 fail
test-amd64-i386-xl-credit2 fail
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 fail
test-amd64-i386-xl-multivcpu fail
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-xl-sedf-pin fail
test-amd64-amd64-pv fail
test-amd64-i386-pv pass
test-amd64-amd64-xl-sedf fail
test-amd64-i386-win-vcpus1 fail
test-amd64-i386-qemut-win-vcpus1 fail
test-amd64-i386-xl-qemut-win-vcpus1 fail
test-amd64-i386-xl-win-vcpus1 fail
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail
test-amd64-i386-xl-winxpsp3-vcpus1 fail
test-amd64-amd64-win fail
test-amd64-i386-win fail
test-amd64-amd64-qemut-win fail
test-amd64-i386-qemut-win fail
test-amd64-amd64-xl-qemut-win fail
test-amd64-amd64-xl-win 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 woking.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.
------------------------------------------------------------
changeset: 26523:fd997a96d448
tag: tip
user: Jan Beulich <jbeulich@suse.com>
date: Fri Feb 08 11:06:04 2013 +0100
x86: debugging code for testing 16Tb support on smaller memory systems
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
changeset: 26522:ffd30e7388ad
user: Ian Jackson <Ian.Jackson@eu.citrix.com>
date: Thu Feb 07 14:21:47 2013 +0000
oxenstored: Enforce a maximum message size of 4096 bytes
The maximum size of a message is part of the protocol spec in
xen/include/public/io/xs_wire.h
Before this patch a client which sends an overly large message can
cause a buffer read overrun.
Note if a badly-behaved client sends a very large message
then it will be difficult for them to make their connection
work again-- they will probably need to reboot.
Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
changeset: 26521:2c0fd406f02c
user: Ian Jackson <ian.jackson@eu.citrix.com>
date: Thu Feb 07 14:21:44 2013 +0000
tools/ocaml: oxenstored: Be more paranoid about ring reading
oxenstored makes use of the OCaml Xenbus bindings, in which the
function xs_ring_read in tools/ocaml/libs/xb/xs_ring_stubs.c is used
to read from the shared memory Xenstore ring.
This function does not correctly handle all possible (prod, cons)
states when MASK_XENSTORE_IDX(prod) > MASK_XENSTORE_IDX(cons).
The root cause is the use of the unmasked values of prod and cons to
calculate to_read. If prod is set to an out-of-range value, the ring
peer can cause to_read to be too large or even negative. This allows
the ring peer to force oxenstored to read and write out of range for
the buffers leading to a crash or possibly to privilege escalation.
Correct this by masking the values of cons and prod at the start, so
we only deal with masked values. This makes the logic simpler, as
semantically inappropriate values of the upper bits of the ring
pointers are simply ignored.
The same vulnerability does not exist in the ring writer because the
only use made of the unmasked value is the check which prevents the
prod pointer overtaking the cons pointer. A ring peer which defeats
this check will suffer only lost data.
However, additionally, precautions need to be taken to ensure that
req_cons and req_prod are only read once in each function. Without
the use of volatile or some asm construct, the compiler can "prove"
that req_cons and req_prod do not change unexpectedly and is permitted
to "amplify" the read of (say) req_cons into two reads at different
times, giving two different values for use as cons, and then use the
two sources of cons interchangeably. (The use of xen_mb() does not
forbid this.)
Therefore do the reads of req_cons and req_prod through a volatile
pointer in both xs_ring_read and xs_ring_write.
This is currently believed to be a theoretical vulnerability as we are
not aware of any compilers which amplify reads in this way.
This is a security issue, part of XSA-38 / CVE-2013-0215.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Tested-by: Matthew Daley <mattjd@gmail.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
changeset: 26520:6c1b12c884b4
user: Ian Campbell <Ian.Campbell@citrix.com>
date: Tue Feb 05 15:47:41 2013 +0000
xen: enable stubdom on a per arch basis
... and disable on ARM (for now).
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
========================================
commit 2a1354d655d816feaad7dbdb8364f40a208439c1
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu Jan 17 15:52:16 2013 +0000
e1000: fix compile warning introduced by security fix, and debugging
e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
hw/e1000.c:641: warning: 'return' with a value, in function returning void
In upstream qemu (where this change came from), e1000_receive returns
a value used by queueing machinery to decide whether to try
resubmitting the packet later. Returning "size" means that the packet
has been dealt with and should not be retried.
In this old branch (aka qemu-xen-traditional), this machinery is
absent and e1000_receive returns void. Fix the return statement.
Also add a debugging statement along the lines of the others in this
function.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [xen-unstable test] 15452: regressions - FAIL
2013-02-09 7:00 [xen-unstable test] 15452: regressions - FAIL xen.org
@ 2013-02-11 11:12 ` Ian Campbell
2013-02-11 11:30 ` [PATCH] tools/ocaml: oxenstored: correctly handle a full ring. (Was: Re: [xen-unstable test] 15452: regressions - FAIL) Ian Campbell
0 siblings, 1 reply; 3+ messages in thread
From: Ian Campbell @ 2013-02-11 11:12 UTC (permalink / raw)
To: xen.org; +Cc: xen-devel, Dave Scott
On Sat, 2013-02-09 at 07:00 +0000, xen.org wrote:
> flight 15452 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/15452/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-xl-credit2 14 guest-localmigrate/x10 fail REGR. vs. 15442
> test-amd64-i386-xl-multivcpu 14 guest-localmigrate/x10 fail REGR. vs. 15442
> test-amd64-amd64-pv 14 guest-localmigrate/x10 fail REGR. vs. 15442
> test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check fail REGR. vs. 15442
> test-amd64-i386-win 11 guest-localmigrate.2 fail REGR. vs. 15442
> test-amd64-i386-xend-qemut-winxpsp3 11 guest-localmigrate.2 fail REGR. vs. 15442
> test-amd64-i386-xl-qemut-win-vcpus1 7 windows-install fail REGR. vs. 15442
> test-amd64-i386-qemut-win 11 guest-localmigrate.2 fail REGR. vs. 15442
> test-amd64-amd64-qemut-win 7 windows-install fail REGR. vs. 15442
> test-amd64-i386-win-vcpus1 7 windows-install fail REGR. vs. 15442
> test-amd64-amd64-win 7 windows-install fail REGR. vs. 15442
Of the windows install failures the xl one failed with:
libxl: error: libxl.c:2101:device_disk_add: failed to get blktap devpath for 0x82ba7b0
libxl: error: libxl_create.c:901:domcreate_launch_dm: unable to add disk devices
libxl: error: libxl_dm.c:1229:libxl__destroy_device_model: could not find device-model's pid for dom 2
libxl: error: libxl.c:1414:libxl__destroy_domid: libxl__destroy_device_model failed for 2
Parsing config from /etc/xen/win.guest.osstest.cfg
The xend ones failed in every case with:
[2013-02-09 00:11:38 2336] DEBUG (XendDomainInfo:2499)
XendDomainInfo.constructDomain
[2013-02-09 00:11:38 2336] ERROR (XendDomainInfo:488) VM start failed
Traceback (most recent call last):
File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendDomainInfo.py", line 473, in start
XendTask.log_progress(0, 30, self._constructDomain)
File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendTask.py", line 209, in log_progress
retval = func(*args, **kwds)
File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendDomainInfo.py", line 2576, in _constructDomain
self._recreateDom()
File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendDomainInfo.py", line 1730, in _recreateDom
complete(self.dompath, lambda t: self._recreateDomFunc(t))
File "/usr/local/lib/python2.6/dist-packages/xen/xend/xenstore/xstransact.py", line 364, in complete
if t.commit():
File "/usr/local/lib/python2.6/dist-packages/xen/xend/xenstore/xstransact.py", line 41, in commit
rc = xshandle().transaction_end(self.transaction, False)
Error: (2, 'No such file or directory')
oxenstored was in use in every case, which does tend to focus the
attention on:
26521:2c0fd406f02c tools/ocaml: oxenstored: Be more paranoid about ring reading
26522:ffd30e7388ad oxenstored: Enforce a maximum message size of 4096 bytes
The other two changes in the range under test are
x86: debugging code for testing 16Tb support on smaller memory systems
xen: enable stubdom on a per arch basis
which seem far less plausible.
The bisector doesn't appear to be having a go at this issue though.
At least one of the xend migration failures also ends with a similar
xshandle().transaction_end stack trace. I don't see anything similar in
any of the xl variants, but that may be down to poor logging plus the
fact that xl cases are the minority and one of them has no logs. This
mostly affects Windows VMs but not exclusively.
Ian.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [PATCH] tools/ocaml: oxenstored: correctly handle a full ring. (Was: Re: [xen-unstable test] 15452: regressions - FAIL)
2013-02-11 11:12 ` Ian Campbell
@ 2013-02-11 11:30 ` Ian Campbell
0 siblings, 0 replies; 3+ messages in thread
From: Ian Campbell @ 2013-02-11 11:30 UTC (permalink / raw)
To: Ian Jackson; +Cc: xen-devel, Dave Scott
On Mon, 2013-02-11 at 11:12 +0000, Ian Campbell wrote:
>
> 26521:2c0fd406f02c tools/ocaml: oxenstored: Be more paranoid about
> ring reading
I think this change has broken the case where the ring is full.
Specifically we've gone from
cons = intf->req_cons;
prod = intf->req_prod;
...
if (prod == cons)
return 0;
to:
cons = intf->req_cons;
prod = intf->req_prod;
cons = MASK_XENSTORE_IDX(cons);
prod = MASK_XENSTORE_IDX(prod);
...
if (prod == cons)
return 0;
IOW if prod == cons + PAGE_SIZE we now make proc == cons before checking
if they are the same...
8<---------------------------------
>From dd72c63ee56e700b00c0ceffa5d8c150e50fa36f Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 11 Feb 2013 11:27:47 +0000
Subject: [PATCH] tools/ocaml: oxenstored: correctly handle a full ring.
Change 26521:2c0fd406f02c (part of XSA-38 / CVE-2013-0215) incorrectly
caused us to ignore rather than process a completely full ring. Check if
producer and consumer are equal before masking to avoid this, since prod ==
cons + PAGE_SIZE after masking becomes prod == cons.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
tools/ocaml/libs/xb/xs_ring_stubs.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/ocaml/libs/xb/xs_ring_stubs.c b/tools/ocaml/libs/xb/xs_ring_stubs.c
index 4888ac5..fdd9983 100644
--- a/tools/ocaml/libs/xb/xs_ring_stubs.c
+++ b/tools/ocaml/libs/xb/xs_ring_stubs.c
@@ -45,10 +45,10 @@ static int xs_ring_read(struct mmap_interface *interface,
cons = *(volatile uint32*)&intf->req_cons;
prod = *(volatile uint32*)&intf->req_prod;
xen_mb();
- cons = MASK_XENSTORE_IDX(cons);
- prod = MASK_XENSTORE_IDX(prod);
if (prod == cons)
return 0;
+ cons = MASK_XENSTORE_IDX(cons);
+ prod = MASK_XENSTORE_IDX(prod);
if (prod > cons)
to_read = prod - cons;
else
--
1.7.2.5
^ permalink raw reply related [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-02-11 11:30 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-09 7:00 [xen-unstable test] 15452: regressions - FAIL xen.org
2013-02-11 11:12 ` Ian Campbell
2013-02-11 11:30 ` [PATCH] tools/ocaml: oxenstored: correctly handle a full ring. (Was: Re: [xen-unstable test] 15452: regressions - FAIL) Ian Campbell
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.