[xen-4.14-testing bisection] complete test-xtf-amd64-amd64-1
branch xen-4.14-testing
xenbranch xen-4.14-testing
job test-xtf-amd64-amd64-1
testid xtf/test-pv64-xsa-221
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Tree: xtf git://xenbits.xen.org/xtf.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: b8c2efbe7b3e8fa5f0b0a3679afccd1204949070
Bug not present: f5469067ee0260673ca1e554ff512a55ccfc
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/154774/
commit b8c2efbe7b3e8fa5f0b0a3679afccd1204949070
Author: Jan Beulich
Date: Tue Sep 22 16:13:34 2020 +0200
evtchn/x86: enforce correct upper limit for 32-bit guests
The recording of d->max_evtchns in evtchn_2l_init(), in particular with
the limited set of callers of the function, is insufficient. Neither for
PV nor for HVM guests the bitness is known at domain_create() time, yet
the upper bound in 2-level mode depends upon guest bitness. Recording
too high a limit "allows" x86 32-bit domains to open not properly usable
event channels, management of which (inside Xen) would then result in
corruption of the shared info and vCPU info structures.
Keep the upper limit dynamic for the 2-level case, introducing a helper
function to retrieve the effective limit. This helper is now supposed to
be private to the event channel code. The used in do_poll() and
domain_dump_evtchn_info() weren't consistent with port uses elsewhere
and hence get switched to port_is_valid().
Furthermore FIFO mode's setup_ports() gets adjusted to loop only up to
the prior ABI limit, rather than all the way up to the new one.
Finally a word on the change to do_poll(): Accessing ->max_evtchns
without holding a suitable lock was never safe, as it as well as
->evtchn_port_ops may change behind do_poll()'s back. Using
port_is_valid() instead widens some the window for potential abuse,
until we've dealt with the race altogether (see XSA-343).
This is XSA-342.
Reported-by: Julien Grall
Fixes: 48974e6ce52e ("evtchn: use a per-domain variable for the max
number of event channels")
Signed-off-by: Jan Beulich
Reviewed-by: Stefano Stabellini
Reviewed-by: Julien Grall
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.14-testing/test-xtf-amd64-amd64-1.xtf--test-pv64-xsa-221.html
Revision IDs in each graph node refer, respectively, to the Trees above.
Running cs-bisection-step
--graph-out=/home/logs/results/bisect/xen-4.14-testing/test-xtf-amd64-amd64-1.xtf--test-pv64-xsa-221
--summary-out=tmp/154889.bisection-summary --basis-template=154350
--blessings=real,real-bisect --flight=154889 xen-4.14-testing
test-xtf-amd64-amd64-1 xtf/test-pv64-xsa-221
Searching for failure / basis pass:
154641 fail [host=chardonnay1] / 154350 [host=huxelrebe1] 154148
[host=albana0] 154116 [host=godello0] 152545 [host=elbling1] 152537
[host=chardonnay0] 152531 [host=godello0] 152153 [host=godello0] 152124
[host=fiano1] 152081 [host=albana0] 152061 [host=albana1] 152043
[host=huxelrebe1] 151922 [host=elbling1] 151899 ok.
Failure / basis pass flights: 154641 / 151899
(tree with no url: minios)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Tree: xtf git://xenbits.xen.org/xtf.git
Latest c3038e718a19fc596f7b1baba0f83d5146dc7784
c530a75c1e6a472b0eb9558310b518f0dfcd8860
fb97626fe04747ec89599dce0992def9a36e2f6b
3c659044118e34603161457db9934a34f816d78b
ea6d3cd1ed79d824e605a70c3626bc437c386260
155821a1990b6de78dde5f98fa5ab90e802021e0
f37a1cf023b277d0d49323bf322ce3ff0c92262d
17d372b763cb0b2e2e6b5a637c11f3997d2533fa
Basis pass c3038e718a19fc596f7b1baba0f83d5146dc7784
c530a75c1e6a472b0eb9558310b518f0dfcd8860
9c6f3545aee0808b78a0ad4480b6eb9d24989dc1
3c659044118e34603161457db9934a34f816d78b
ea6d3cd1ed79d824e605a70c3626bc437c386260
88ab0c15525ced2eefe39220742efe4769089ad8
ce3c4493e4e6c94495ddd8538e801a35980bff0d
f645a19115e666ce6401ca63b7d7388571463b55
Generating revisions with ./adhoc-revtuple-generator
git://xenbits.xen.org/linux-pvops.git#c3038e718a19fc596f7b1baba0f83d5146dc7784-c3038e718a19fc596f7b1baba0f83d5146dc7784
[xen-4.14-testing bisection] complete test-xtf-amd64-amd64-1
branch xen-4.14-testing
xenbranch xen-4.14-testing
job test-xtf-amd64-amd64-1
testid xtf/test-hvm64-xsa-221
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Tree: xtf git://xenbits.xen.org/xtf.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: b8c2efbe7b3e8fa5f0b0a3679afccd1204949070
Bug not present: f5469067ee0260673ca1e554ff512a55ccfc
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/154774/
commit b8c2efbe7b3e8fa5f0b0a3679afccd1204949070
Author: Jan Beulich
Date: Tue Sep 22 16:13:34 2020 +0200
evtchn/x86: enforce correct upper limit for 32-bit guests
The recording of d->max_evtchns in evtchn_2l_init(), in particular with
the limited set of callers of the function, is insufficient. Neither for
PV nor for HVM guests the bitness is known at domain_create() time, yet
the upper bound in 2-level mode depends upon guest bitness. Recording
too high a limit "allows" x86 32-bit domains to open not properly usable
event channels, management of which (inside Xen) would then result in
corruption of the shared info and vCPU info structures.
Keep the upper limit dynamic for the 2-level case, introducing a helper
function to retrieve the effective limit. This helper is now supposed to
be private to the event channel code. The used in do_poll() and
domain_dump_evtchn_info() weren't consistent with port uses elsewhere
and hence get switched to port_is_valid().
Furthermore FIFO mode's setup_ports() gets adjusted to loop only up to
the prior ABI limit, rather than all the way up to the new one.
Finally a word on the change to do_poll(): Accessing ->max_evtchns
without holding a suitable lock was never safe, as it as well as
->evtchn_port_ops may change behind do_poll()'s back. Using
port_is_valid() instead widens some the window for potential abuse,
until we've dealt with the race altogether (see XSA-343).
This is XSA-342.
Reported-by: Julien Grall
Fixes: 48974e6ce52e ("evtchn: use a per-domain variable for the max
number of event channels")
Signed-off-by: Jan Beulich
Reviewed-by: Stefano Stabellini
Reviewed-by: Julien Grall
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.14-testing/test-xtf-amd64-amd64-1.xtf--test-hvm64-xsa-221.html
Revision IDs in each graph node refer, respectively, to the Trees above.
Running cs-bisection-step
--graph-out=/home/logs/results/bisect/xen-4.14-testing/test-xtf-amd64-amd64-1.xtf--test-hvm64-xsa-221
--summary-out=tmp/154774.bisection-summary --basis-template=154350
--blessings=real,real-bisect xen-4.14-testing test-xtf-amd64-amd64-1
xtf/test-hvm64-xsa-221
Searching for failure / basis pass:
154641 fail [host=chardonnay1] / 154350 [host=huxelrebe1] 154148
[host=albana0] 154116 [host=godello0] 152545 [host=elbling1] 152537
[host=chardonnay0] 152531 [host=godello0] 152153 [host=godello0] 152124
[host=fiano1] 152081 [host=albana0] 152061 [host=albana1] 152043
[host=huxelrebe1] 151922 [host=elbling1] 151899 ok.
Failure / basis pass flights: 154641 / 151899
(tree with no url: minios)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Tree: xtf git://xenbits.xen.org/xtf.git
Latest c3038e718a19fc596f7b1baba0f83d5146dc7784
c530a75c1e6a472b0eb9558310b518f0dfcd8860
fb97626fe04747ec89599dce0992def9a36e2f6b
3c659044118e34603161457db9934a34f816d78b
ea6d3cd1ed79d824e605a70c3626bc437c386260
155821a1990b6de78dde5f98fa5ab90e802021e0
f37a1cf023b277d0d49323bf322ce3ff0c92262d
17d372b763cb0b2e2e6b5a637c11f3997d2533fa
Basis pass c3038e718a19fc596f7b1baba0f83d5146dc7784
c530a75c1e6a472b0eb9558310b518f0dfcd8860
9c6f3545aee0808b78a0ad4480b6eb9d24989dc1
3c659044118e34603161457db9934a34f816d78b
ea6d3cd1ed79d824e605a70c3626bc437c386260
88ab0c15525ced2eefe39220742efe4769089ad8
ce3c4493e4e6c94495ddd8538e801a35980bff0d
f645a19115e666ce6401ca63b7d7388571463b55
Generating revisions with ./adhoc-revtuple-generator
git://xenbits.xen.org/linux-pvops.git#c3038e718a19fc596f7b1baba0f83d5146dc7784-c3038e718a19fc596f7b1baba0f83d5146dc7784
