main/xen: upgrade to 4.6.1

This commit is contained in:
Natanael Copa 2016-02-29 10:54:26 +00:00
parent e717081f17
commit 8de87f6fcb
18 changed files with 19 additions and 1099 deletions

View File

@ -2,8 +2,8 @@
# Contributor: Roger Pau Monne <roger.pau@entel.upc.edu>
# Maintainer: William Pitcock <nenolod@dereferenced.org>
pkgname=xen
pkgver=4.6.0
pkgrel=5
pkgver=4.6.1
pkgrel=0
pkgdesc="Xen hypervisor"
url="http://www.xen.org/"
arch="x86_64"
@ -42,23 +42,10 @@ source="http://bits.xensource.com/oss-xen/release/$pkgver/$pkgname-$pkgver.tar.g
http://xenbits.xen.org/xen-extfiles/zlib-$_ZLIB_VERSION.tar.gz
http://xenbits.xen.org/xen-extfiles/ipxe-git-$_IPXE_GIT_TAG.tar.gz
xsa148.patch
xsa149.patch
xsa150.patch
xsa151.patch
xsa152.patch
xsa153-libxl.patch
xsa154.patch
xsa154-4.6.patch
xsa155-xen-0001-xen-Add-RING_COPY_REQUEST.patch
xsa155-xen-0002-blktap2-Use-RING_COPY_REQUEST.patch
xsa155-xen-0003-libvchan-Read-prod-cons-only-once.patch
xsa156.patch
xsa159.patch
xsa160.patch
xsa165.patch
xsa167.patch
xsa168.patch
xsa169.patch
xsa170.patch
qemu-coroutine-gthread.patch
@ -93,12 +80,13 @@ source="http://bits.xensource.com/oss-xen/release/$pkgver/$pkgname-$pkgver.tar.g
_builddir="$srcdir"/$pkgname-$pkgver
_seabios=/usr/share/seabios/bios-256k.bin
prepare() {
local i
local i _failed=
cd "$_builddir"
for i in $source; do
case $i in
*.patch) msg $i; patch -p1 -i "$srcdir"/$i || return 1
*.patch) msg $i; patch -s -N -p1 -i "$srcdir"/$i \
|| _failed="$_failed $i"
;;
*/ipxe-git-*)
ln -s "$srcdir"/${i##*/} \
@ -109,6 +97,13 @@ prepare() {
;;
esac
done
if [ -n "$_failed" ]; then
error "Patches failed:"
for i in $_failed; do
echo $i
done
return 1
fi
# install our stdint_local.h and elf_local.h
install "$srcdir"/stdint_local.h "$srcdir"/elf_local.h \
@ -238,7 +233,7 @@ hypervisor() {
mv "$pkgdir"/boot "$subpkgdir"/
}
md5sums="48e232f90927c08326a7b52bb06f49bc xen-4.6.0.tar.gz
md5sums="df2d854c3c90ffeefaf71e7f868fb326 xen-4.6.1.tar.gz
dd60683d7057917e34630b4a787932e8 gmp-4.3.2.tar.bz2
cd3f3eb54446be6003156158d51f4884 grub-0.97.tar.gz
36cc57650cffda9a0269493be2a169bb lwip-1.3.0.tar.gz
@ -248,23 +243,10 @@ cec05e7785497c5e19da2f114b934ffd pciutils-2.2.9.tar.bz2
e26becb8a6a2b6695f6b3e8097593db8 tpm_emulator-0.7.4.tar.gz
debc62758716a169df9f62e6ab2bc634 zlib-1.2.3.tar.gz
7496268cebf47d5c9ccb0696e3b26065 ipxe-git-9a93db3f0947484e30e753bbd61a10b17336e20e.tar.gz
6e302a683e89f320c07a4819aa7247f1 xsa148.patch
92b0a8119ddec698291498fc4d14c5aa xsa149.patch
ebd65969e47ea94480d031481521259f xsa150.patch
b9c287c042317017f201a45193fdcf17 xsa151.patch
161a985c52ca2db47c09ae3245f8bceb xsa152.patch
e5ddc6b5a2c7ef0437812ce39cb55034 xsa153-libxl.patch
2109cf26a61f99158615d0e8566aa7d9 xsa154.patch
2109cf26a61f99158615d0e8566aa7d9 xsa154-4.6.patch
8e87b1bcd1e5c057c8d7ad41010c27f1 xsa155-xen-0001-xen-Add-RING_COPY_REQUEST.patch
48be8e53712d8656549fcdf1a96ffdec xsa155-xen-0002-blktap2-Use-RING_COPY_REQUEST.patch
21448f920d1643580e261ac3650d1ef9 xsa155-xen-0003-libvchan-Read-prod-cons-only-once.patch
ea188fa0ada9e5217f166dc3f0b8102c xsa156.patch
9dad98f18893ab696e7a26e5d2a707b2 xsa159.patch
7c53a997967656b10a3b2494c3f5a96d xsa160.patch
7f5cc2a2e8e7fe705ae8764595065ff0 xsa165.patch
e3423c61854be1658ea7aa596594c2d1 xsa167.patch
b837726ce186fa61cfe7238b225b0335 xsa168.patch
0931b87a6b9ba846c5797dbbbacdf324 xsa169.patch
e0fd8934b37592a6a3e6ab107a2ab41a xsa170.patch
de1a3db370b87cfb0bddb51796b50315 qemu-coroutine-gthread.patch
08bfdf8caff5d631f53660bf3fd4edaf qemu-xen_paths.patch
@ -288,7 +270,7 @@ dcdd1de2c29e469e834a02ede4f47806 xendomains.confd
9df68ac65dc3f372f5d61183abdc83ff xen-consoles.logrotate
6a2f777c16678d84039acf670d86fff6 xenqemu.confd
e1c9e1c83a5cc49224608a48060bd677 xenqemu.initd"
sha256sums="6fa1c2431df55aa5950d248e6093b8c8c0f11c357a0adbd348a2186478e80909 xen-4.6.0.tar.gz
sha256sums="44cc2fccba1e147ef4c8da0584ce0f24189c8743de0e3e9a9226da88ddb5f589 xen-4.6.1.tar.gz
936162c0312886c21581002b79932829aa048cfaf9937c6265aeaa14f1cd1775 gmp-4.3.2.tar.bz2
4e1d15d12dbd3e9208111d6b806ad5a9857ca8850c47877d36575b904559260b grub-0.97.tar.gz
772e4d550e07826665ed0528c071dd5404ef7dbe1825a38c8adbc2a00bca948f lwip-1.3.0.tar.gz
@ -298,23 +280,10 @@ f60ae61cfbd5da1d849d0beaa21f593c38dac9359f0b3ddc612f447408265b24 pciutils-2.2.9
4e48ea0d83dd9441cc1af04ab18cd6c961b9fa54d5cbf2c2feee038988dea459 tpm_emulator-0.7.4.tar.gz
1795c7d067a43174113fdf03447532f373e1c6c57c08d61d9e4e9be5e244b05e zlib-1.2.3.tar.gz
632ce8c193ccacc3012bd354bdb733a4be126f7c098e111930aa41dad537405c ipxe-git-9a93db3f0947484e30e753bbd61a10b17336e20e.tar.gz
f320d105a4832124910f46c50acd4803fe289bd7c4702ec15f97fb611b70944d xsa148.patch
e01628400b81c4bb7bafba348f2ecb1fe80f16e3162cee5013e0be1d7311738b xsa149.patch
9054215f08cab48d2523efb456eb3c93ca6ac580d661f6e4f1feca115c67afa8 xsa150.patch
e247a9dbbe236ffa3c5aa5e2d41047fa67da80f2b0474eef3440b5b3da2d5617 xsa151.patch
596f51797aa591b5abd068ead03e21215cf70997c98a4a562392499afe47b81c xsa152.patch
f5cbc98cba758e10da0a01d9379012ec56b98a85a92bfeb0c6b8132d4b91ce77 xsa153-libxl.patch
eec88c2a57466f83a81844cb7025f70c2b671d07a75d85487d4ed73cdabbb020 xsa154.patch
eec88c2a57466f83a81844cb7025f70c2b671d07a75d85487d4ed73cdabbb020 xsa154-4.6.patch
e52467fcec73bcc86d3e96d06f8ca8085ae56a83d2c42a30c16bc3dc630d8f8a xsa155-xen-0001-xen-Add-RING_COPY_REQUEST.patch
eae34c8ccc096ad93a74190506b3d55020a88afb0cc504a3a514590e9fd746fd xsa155-xen-0002-blktap2-Use-RING_COPY_REQUEST.patch
42780265014085a4221ad32b026214693d751789eb5219e2e83862c0006c66f4 xsa155-xen-0003-libvchan-Read-prod-cons-only-once.patch
d92729ca9174f7d1d8c6fd31321d1a58696c0630e87420539c32f7718b9e8ee8 xsa156.patch
05c35871c1430e9cfdbee049411b23fca6c64c5bc9f112d7508afe5cbd289cef xsa159.patch
40362873b7fa2c1450596ef9ea23c73f80608b77ca50b89e62daf46c131fcee6 xsa160.patch
4bb18f2e44f49f140932c2d1e956e2e28017439cbb0e76eb16a8af617c4112ac xsa165.patch
2bd786cccfd13c6732d6db8afc9e18058465efcb1bc93f894c359e3a820d5403 xsa167.patch
c95198a66485d6e538d113ce2b84630d77c15f597113c38fadd6bf1e24e4c8ec xsa168.patch
b818922880313cdbc12ea68ae757da5eabed9b3c9e1f8acefe1653683545ccbe xsa169.patch
77b4b14b2c93da5f68e724cf74e1616f7df2e78305f66d164b3de2d980221a9a xsa170.patch
3941f99b49c7e8dafc9fae8aad2136a14c6d84533cd542cc5f1040a41ef7c6fe qemu-coroutine-gthread.patch
e4e5e838e259a3116978aabbcebc1865a895179a7fcbf4bad195c83e9b4c0f98 qemu-xen_paths.patch
@ -338,7 +307,7 @@ d13719093a2c3824525f36ac91ac3c9bd1154e5ba0974e5441e4a2ab5e883521 xenconsoled.in
0da87a4b9094f934e3de937e8ef8d3afc752e76793aa3d730182d0241e118b19 xen-consoles.logrotate
4cfcddcade5d055422ab4543e8caa6e5c5eee7625c41880a9000b7a87c7c424e xenqemu.confd
c92bbb1166edd61141fdf678116974209c4422daf373cdd5bc438aa4adb25b8d xenqemu.initd"
sha512sums="b4b02f306ffea360f539dd8c231b2f58c00c3638fdb665cb659c7291b475b40f1075bc59d49a6144767729e57b8bc40a1cfd9030d61de2b8fa4ac97d43655c2b xen-4.6.0.tar.gz
sha512sums="f01a0b7874abf8b3a81432428d7ba2d5aceb9d75ae20310f8ef49a3a0df927720a51d49090f74fda7f374c779e121ad26da6966a6f2623ed1a7743b4c080427c xen-4.6.1.tar.gz
2e0b0fd23e6f10742a5517981e5171c6e88b0a93c83da701b296f5c0861d72c19782daab589a7eac3f9032152a0fc7eff7f5362db8fccc4859564a9aa82329cf gmp-4.3.2.tar.bz2
c2bc9ffc8583aeae71cee9ddcc4418969768d4e3764d47307da54f93981c0109fb07d84b061b3a3628bd00ba4d14a54742bc04848110eb3ae8ca25dbfbaabadb grub-0.97.tar.gz
1465b58279af1647f909450e394fe002ca165f0ff4a0254bfa9fe0e64316f50facdde2729d79a4e632565b4500cf4d6c74192ac0dd3bc9fe09129bbd67ba089d lwip-1.3.0.tar.gz
@ -348,23 +317,10 @@ c2bc9ffc8583aeae71cee9ddcc4418969768d4e3764d47307da54f93981c0109fb07d84b061b3a36
4928b5b82f57645be9408362706ff2c4d9baa635b21b0d41b1c82930e8c60a759b1ea4fa74d7e6c7cae1b7692d006aa5cb72df0c3b88bf049779aa2b566f9d35 tpm_emulator-0.7.4.tar.gz
021b958fcd0d346c4ba761bcf0cc40f3522de6186cf5a0a6ea34a70504ce9622b1c2626fce40675bc8282cf5f5ade18473656abc38050f72f5d6480507a2106e zlib-1.2.3.tar.gz
c5cb1cdff40d2d71fd3e692a9d0efadf2aa17290daf5195391a1c81ddd9dfc913a8e44d5be2b12be85b2a5565ea31631c99c7053564f2fb2225c80ea0bb0e4a4 ipxe-git-9a93db3f0947484e30e753bbd61a10b17336e20e.tar.gz
f6d1753641741c6d921ec6ba4acd9ac9df511ef1a7ca7c21fb3498a2b7b8758827b9d8cb19543ffda0125b632c7ac8004366ba47036ecb7c66c5723143e125e5 xsa148.patch
86c19dbab57c9dee5443ba10fcea38d35e0bef821a502d916684f9010b530101af4386db88f2fa90a252812fa2722da9450964747eb7204ee23a94369e58ec72 xsa149.patch
8c4a588764c5829d4722766e9766fe769e93e21b5b027578ffdfac3e85c8cdf11281cf4b3a28de4fbbb64ab102f13ed55f029d11201a7fe8ecd1b5c94b6134ec xsa150.patch
d1d6f11ff4c108d57de408cd75a818eeb124b3788c480bee6eb46ffdb18ef53a5dd96588f961f3336881d38c07908fae7c4042d8ee7267704647b306180aaebf xsa151.patch
e442c062b6bcf54761784649d3b21df2b4e46b7e1d94ab7375e227e65d6741b5457a838e72569ab9e49fb0ca57063226652f9efd4331356b822d686829682faa xsa152.patch
a33a184fdb1588ee17ddaab53dd45f9e68b2523f99278de7e8a403b36ce2dd71efcccae1c94b4b196f5d83d6423766a23e48fbf0a6a2e1dd681313edb0d1c399 xsa153-libxl.patch
fde4c58acb857bd4eec807a78bee356a02358174e8c52a66555a6ad9cf5670b43391429ff973e74d27ee43a27c338b89bc3e63d2d821ee85682d8799d3bdd35c xsa154.patch
fde4c58acb857bd4eec807a78bee356a02358174e8c52a66555a6ad9cf5670b43391429ff973e74d27ee43a27c338b89bc3e63d2d821ee85682d8799d3bdd35c xsa154-4.6.patch
96574c07cc31b11cddbe90bbfd0ff92ec9a2aa52903f74258e1291c1dec91e85c65c18ce10ed85aa659e3c363a460375153f2f45f1bbc4cebcc904398518a8f4 xsa155-xen-0001-xen-Add-RING_COPY_REQUEST.patch
d64d7e0dd96e31fa45d9d9b0cad9c543484709d699d9ab2efe1992f9375e8e0d67b0164e9ea8d3e75998388964f2fbfd96b5520a4acf13804dcf8c3472e37791 xsa155-xen-0002-blktap2-Use-RING_COPY_REQUEST.patch
cad6b571ccca123e2a797cf82669ad0fe2e1ec99b7a68396beb3a2279e2cf87d8f0cf75e22dcd98238dd5031b2c7e9cb86d02ecaa82ae973fba6d26b2acfb514 xsa155-xen-0003-libvchan-Read-prod-cons-only-once.patch
a879a7c8f5a1a49d5c1dc9c80ca5a7086b68f5cfa1938819ec93f354f2ba916862e8a553822f0e8d004fe90cf389c37675fc2c523157ad8a2426f60dcc03715d xsa156.patch
82a8cd774078b201e3ca854b2419d5c2e69d8168066dcf0cf2c7373b649a9c0325b568cb7434b0f50e10dcc965a0557e845309dd1ddb9925950f386b12249d5d xsa159.patch
91819a014821ff1b468a0e116edf657ea4db64b095637da1886caa3b8b29ffda8d00915e808508d8ecd526be9ce325b7e9733c220fba2b2cfaaee0977b1d9454 xsa160.patch
ecd47873290937ce13b6d4f23751c62a7fe16a5f0c9a3d895b91b8c9065829883333181755240298a1bb4cfdb8414d431422d1a2a7fbd390707b373d5ca1a9a9 xsa165.patch
5e908dc801eb5d15c59156c6d3bbe24df21acb39ef3a337b43e0f5bc0bbeaee78c9dc8352880251379dddbe203acbd8762abee954ede25dfaf032c6959c8fe09 xsa167.patch
c55ee924b21edf54ce3c873d952a20f32f851661a13514528d42d2ef36767cfa9e31b1a42a4e0f40ff1011c692c406155fcc59be0c43fd44973cd0a5acee2ac7 xsa168.patch
5bc99d5b4e8e57852c88401c49cc97f82706763f88682ed8faad6344fb0e17782ed7ba063fd463c3da46e28994af11e575ce6e02aa957ff042e3c86269d15acc xsa169.patch
09a6defca0f32319dddf4325fb0105a468517a7150c8a8ea287677b4a55f09bf776f5aa673bae22a0708537cf075d5e2143a24aa1b08629ef911a7cdfd8376f0 xsa170.patch
c3c46f232f0bd9f767b232af7e8ce910a6166b126bd5427bb8dc325aeb2c634b956de3fc225cab5af72649070c8205cc8e1cab7689fc266c204f525086f1a562 qemu-coroutine-gthread.patch
1936ab39a1867957fa640eb81c4070214ca4856a2743ba7e49c0cd017917071a9680d015f002c57fa7b9600dbadd29dcea5887f50e6c133305df2669a7a933f3 qemu-xen_paths.patch

View File

@ -1,55 +0,0 @@
diff --git a/tools/firmware/etherboot/patches/gcc5.patch b/tools/firmware/etherboot/patches/gcc5.patch
new file mode 100644
index 0000000..e091f4b
--- /dev/null
+++ b/tools/firmware/etherboot/patches/gcc5.patch
@@ -0,0 +1,39 @@
+--- ipxe.orig/src/drivers/net/ath/ath9k/ath9k_ar9003_phy.c 2011-12-11 03:28:04.000000000 +0100
++++ ipxe/src/drivers/net/ath/ath9k/ath9k_ar9003_phy.c 2015-05-25 10:33:05.576229086 +0200
+@@ -859,7 +859,7 @@
+ REG_CLR_BIT(ah, AR_PHY_SFCORR_LOW,
+ AR_PHY_SFCORR_LOW_USE_SELF_CORR_LOW);
+
+- if (!on != aniState->ofdmWeakSigDetectOff) {
++ if ((!on) != aniState->ofdmWeakSigDetectOff) {
+ DBG2("ath9k: "
+ "** ch %d: ofdm weak signal: %s=>%s\n",
+ chan->channel,
+@@ -1013,7 +1013,7 @@
+ AR_PHY_MRC_CCK_ENABLE, is_on);
+ REG_RMW_FIELD(ah, AR_PHY_MRC_CCK_CTRL,
+ AR_PHY_MRC_CCK_MUX_REG, is_on);
+- if (!is_on != aniState->mrcCCKOff) {
++ if ((!is_on) != aniState->mrcCCKOff) {
+ DBG2("ath9k: "
+ "** ch %d: MRC CCK: %s=>%s\n",
+ chan->channel,--- ipxe.orig/src/drivers/net/ath/ath9k/ath9k_ar5008_phy.c 2011-12-11 03:28:04.000000000 +0100
++++ ipxe/src/drivers/net/ath/ath9k/ath9k_ar5008_phy.c 2015-05-25 11:14:30.732759966 +0200
+@@ -1141,7 +1141,7 @@
+ REG_CLR_BIT(ah, AR_PHY_SFCORR_LOW,
+ AR_PHY_SFCORR_LOW_USE_SELF_CORR_LOW);
+
+- if (!on != aniState->ofdmWeakSigDetectOff) {
++ if ((!on) != aniState->ofdmWeakSigDetectOff) {
+ if (on)
+ ah->stats.ast_ani_ofdmon++;
+ else
+@@ -1307,7 +1307,7 @@
+ REG_CLR_BIT(ah, AR_PHY_SFCORR_LOW,
+ AR_PHY_SFCORR_LOW_USE_SELF_CORR_LOW);
+
+- if (!on != aniState->ofdmWeakSigDetectOff) {
++ if ((!on) != aniState->ofdmWeakSigDetectOff) {
+ DBG2("ath9k: "
+ "** ch %d: ofdm weak signal: %s=>%s\n",
+ chan->channel,
\ No newline at end of file
diff --git a/tools/firmware/etherboot/patches/series b/tools/firmware/etherboot/patches/series
index 154e65b..73c9447 100644
--- a/tools/firmware/etherboot/patches/series
+++ b/tools/firmware/etherboot/patches/series
@@ -4,3 +4,4 @@ build_fix_2.patch
build_fix_3.patch
no-clobber-ebp.patch
no-clobber-ebp2.patch
+gcc5.patch

View File

@ -1,42 +0,0 @@
From 828ca41769f5070bec903db348647a47d2e0515e Mon Sep 17 00:00:00 2001
From: Natanael Copa <ncopa@alpinelinux.org>
Date: Tue, 29 Apr 2014 10:14:57 +0200
Subject: [PATCH] util/qemu-openpty: fix build with musl libc by include
termios.h as fallback
Include termios.h as POSIX fallback when not glibc, bsd or solaris.
POSIX says that termios.h should define struct termios and TCAFLUSH.
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/termios.h.html
This fixes the following compile errors with musl libc:
util/qemu-openpty.c: In function 'qemu_openpty_raw':
util/qemu-openpty.c:112:20: error: storage size of 'tty' isn't known
struct termios tty;
^
...
util/qemu-openpty.c:128:24: error: 'TCSAFLUSH' undeclared (first use in this function)
tcsetattr(*aslave, TCSAFLUSH, &tty);
^
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
---
util/qemu-openpty.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/util/qemu-openpty.c b/util/qemu-openpty.c
index 4febfe9..4c53211 100644
--- a/tools/qemu-xen/util/qemu-openpty.c
+++ b/tools/qemu-xen/util/qemu-openpty.c
@@ -47,6 +47,8 @@
#elif defined CONFIG_SOLARIS
# include <termios.h>
# include <stropts.h>
+#else
+# include <termios.h>
#endif
#ifdef __sun__
--
2.1.2

View File

@ -1,39 +0,0 @@
x86: guard against undue super page PTE creation
When optional super page support got added (commit bd1cd81d64 "x86: PV
support for hugepages"), two adjustments were missed: mod_l2_entry()
needs to consider the PSE and RW bits when deciding whether to use the
fast path, and the PSE bit must not be removed from L2_DISALLOW_MASK
unconditionally.
This is XSA-148.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -160,7 +160,10 @@ static void put_superpage(unsigned long
static uint32_t base_disallow_mask;
/* Global bit is allowed to be set on L1 PTEs. Intended for user mappings. */
#define L1_DISALLOW_MASK ((base_disallow_mask | _PAGE_GNTTAB) & ~_PAGE_GLOBAL)
-#define L2_DISALLOW_MASK (base_disallow_mask & ~_PAGE_PSE)
+
+#define L2_DISALLOW_MASK (unlikely(opt_allow_superpage) \
+ ? base_disallow_mask & ~_PAGE_PSE \
+ : base_disallow_mask)
#define l3_disallow_mask(d) (!is_pv_32bit_domain(d) ? \
base_disallow_mask : 0xFFFFF198U)
@@ -1841,7 +1844,10 @@ static int mod_l2_entry(l2_pgentry_t *pl
}
/* Fast path for identical mapping and presence. */
- if ( !l2e_has_changed(ol2e, nl2e, _PAGE_PRESENT) )
+ if ( !l2e_has_changed(ol2e, nl2e,
+ unlikely(opt_allow_superpage)
+ ? _PAGE_PSE | _PAGE_RW | _PAGE_PRESENT
+ : _PAGE_PRESENT) )
{
adjust_guest_l2e(nl2e, d);
if ( UPDATE_ENTRY(l2, pl2e, ol2e, nl2e, pfn, vcpu, preserve_ad) )

View File

@ -1,20 +0,0 @@
xen: free domain's vcpu array
This was overlooked in fb442e2171 ("x86_64: allow more vCPU-s per
guest").
This is XSA-149.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -841,6 +841,7 @@ static void complete_domain_destroy(stru
xsm_free_security_domain(d);
free_cpumask_var(d->domain_dirty_cpumask);
+ xfree(d->vcpu);
free_domain_struct(d);
send_global_virq(VIRQ_DOM_EXC);

View File

@ -1,201 +0,0 @@
x86/PoD: Eager sweep for zeroed pages
Based on the contents of a guests physical address space,
p2m_pod_emergency_sweep() could degrade into a linear memcmp() from 0 to
max_gfn, which runs non-preemptibly.
As p2m_pod_emergency_sweep() runs behind the scenes in a number of contexts,
making it preemptible is not feasible.
Instead, a different approach is taken. Recently-populated pages are eagerly
checked for reclaimation, which amortises the p2m_pod_emergency_sweep()
operation across each p2m_pod_demand_populate() operation.
Note that in the case that a 2M superpage can't be reclaimed as a superpage,
it is shattered if 4K pages of zeros can be reclaimed. This is unfortunate
but matches the previous behaviour, and is required to avoid regressions
(domain crash from PoD exhaustion) with VMs configured close to the limit.
This is CVE-2015-7970 / XSA-150.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -920,28 +920,6 @@ p2m_pod_zero_check(struct p2m_domain *p2
}
#define POD_SWEEP_LIMIT 1024
-
-/* When populating a new superpage, look at recently populated superpages
- * hoping that they've been zeroed. This will snap up zeroed pages as soon as
- * the guest OS is done with them. */
-static void
-p2m_pod_check_last_super(struct p2m_domain *p2m, unsigned long gfn_aligned)
-{
- unsigned long check_gfn;
-
- ASSERT(p2m->pod.last_populated_index < POD_HISTORY_MAX);
-
- check_gfn = p2m->pod.last_populated[p2m->pod.last_populated_index];
-
- p2m->pod.last_populated[p2m->pod.last_populated_index] = gfn_aligned;
-
- p2m->pod.last_populated_index =
- ( p2m->pod.last_populated_index + 1 ) % POD_HISTORY_MAX;
-
- p2m_pod_zero_check_superpage(p2m, check_gfn);
-}
-
-
#define POD_SWEEP_STRIDE 16
static void
p2m_pod_emergency_sweep(struct p2m_domain *p2m)
@@ -982,7 +960,7 @@ p2m_pod_emergency_sweep(struct p2m_domai
* NB that this is a zero-sum game; we're increasing our cache size
* by re-increasing our 'debt'. Since we hold the pod lock,
* (entry_count - count) must remain the same. */
- if ( p2m->pod.count > 0 && i < limit )
+ if ( i < limit && (p2m->pod.count > 0 || hypercall_preempt_check()) )
break;
}
@@ -994,6 +972,58 @@ p2m_pod_emergency_sweep(struct p2m_domai
}
+static void pod_eager_reclaim(struct p2m_domain *p2m)
+{
+ struct pod_mrp_list *mrp = &p2m->pod.mrp;
+ unsigned int i = 0;
+
+ /*
+ * Always check one page for reclaimation.
+ *
+ * If the PoD pool is empty, keep checking some space is found, or all
+ * entries have been exhaused.
+ */
+ do
+ {
+ unsigned int idx = (mrp->idx + i++) % ARRAY_SIZE(mrp->list);
+ unsigned long gfn = mrp->list[idx];
+
+ if ( gfn != INVALID_GFN )
+ {
+ if ( gfn & POD_LAST_SUPERPAGE )
+ {
+ gfn &= ~POD_LAST_SUPERPAGE;
+
+ if ( p2m_pod_zero_check_superpage(p2m, gfn) == 0 )
+ {
+ unsigned int x;
+
+ for ( x = 0; x < SUPERPAGE_PAGES; ++x, ++gfn )
+ p2m_pod_zero_check(p2m, &gfn, 1);
+ }
+ }
+ else
+ p2m_pod_zero_check(p2m, &gfn, 1);
+
+ mrp->list[idx] = INVALID_GFN;
+ }
+
+ } while ( (p2m->pod.count == 0) && (i < ARRAY_SIZE(mrp->list)) );
+}
+
+static void pod_eager_record(struct p2m_domain *p2m,
+ unsigned long gfn, unsigned int order)
+{
+ struct pod_mrp_list *mrp = &p2m->pod.mrp;
+
+ ASSERT(mrp->list[mrp->idx] == INVALID_GFN);
+ ASSERT(gfn != INVALID_GFN);
+
+ mrp->list[mrp->idx++] =
+ gfn | (order == PAGE_ORDER_2M ? POD_LAST_SUPERPAGE : 0);
+ mrp->idx %= ARRAY_SIZE(mrp->list);
+}
+
int
p2m_pod_demand_populate(struct p2m_domain *p2m, unsigned long gfn,
unsigned int order,
@@ -1034,6 +1064,8 @@ p2m_pod_demand_populate(struct p2m_domai
return 0;
}
+ pod_eager_reclaim(p2m);
+
/* Only sweep if we're actually out of memory. Doing anything else
* causes unnecessary time and fragmentation of superpages in the p2m. */
if ( p2m->pod.count == 0 )
@@ -1070,6 +1102,8 @@ p2m_pod_demand_populate(struct p2m_domai
p2m->pod.entry_count -= (1 << order);
BUG_ON(p2m->pod.entry_count < 0);
+ pod_eager_record(p2m, gfn_aligned, order);
+
if ( tb_init_done )
{
struct {
@@ -1085,12 +1119,6 @@ p2m_pod_demand_populate(struct p2m_domai
__trace_var(TRC_MEM_POD_POPULATE, 0, sizeof(t), &t);
}
- /* Check the last guest demand-populate */
- if ( p2m->pod.entry_count > p2m->pod.count
- && (order == PAGE_ORDER_2M)
- && (q & P2M_ALLOC) )
- p2m_pod_check_last_super(p2m, gfn_aligned);
-
pod_unlock(p2m);
return 0;
out_of_memory:
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -58,6 +58,7 @@ boolean_param("hap_2mb", opt_hap_2mb);
/* Init the datastructures for later use by the p2m code */
static int p2m_initialise(struct domain *d, struct p2m_domain *p2m)
{
+ unsigned int i;
int ret = 0;
mm_rwlock_init(&p2m->lock);
@@ -73,6 +74,9 @@ static int p2m_initialise(struct domain
p2m->np2m_base = P2M_BASE_EADDR;
+ for ( i = 0; i < ARRAY_SIZE(p2m->pod.mrp.list); ++i )
+ p2m->pod.mrp.list[i] = INVALID_GFN;
+
if ( hap_enabled(d) && cpu_has_vmx )
ret = ept_p2m_init(p2m);
else
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -292,10 +292,20 @@ struct p2m_domain {
entry_count; /* # of pages in p2m marked pod */
unsigned long reclaim_single; /* Last gpfn of a scan */
unsigned long max_guest; /* gpfn of max guest demand-populate */
-#define POD_HISTORY_MAX 128
- /* gpfn of last guest superpage demand-populated */
- unsigned long last_populated[POD_HISTORY_MAX];
- unsigned int last_populated_index;
+
+ /*
+ * Tracking of the most recently populated PoD pages, for eager
+ * reclamation.
+ */
+ struct pod_mrp_list {
+#define NR_POD_MRP_ENTRIES 32
+
+/* Encode ORDER_2M superpage in top bit of GFN */
+#define POD_LAST_SUPERPAGE (INVALID_GFN & ~(INVALID_GFN >> 1))
+
+ unsigned long list[NR_POD_MRP_ENTRIES];
+ unsigned int idx;
+ } mrp;
mm_lock_t lock; /* Locking of private pod structs, *
* not relying on the p2m lock. */
} pod;

View File

@ -1,28 +0,0 @@
xenoprof: free domain's vcpu array
This was overlooked in fb442e2171 ("x86_64: allow more vCPU-s per
guest").
This is XSA-151.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
--- a/xen/common/xenoprof.c
+++ b/xen/common/xenoprof.c
@@ -239,6 +239,7 @@ static int alloc_xenoprof_struct(
d->xenoprof->rawbuf = alloc_xenheap_pages(get_order_from_pages(npages), 0);
if ( d->xenoprof->rawbuf == NULL )
{
+ xfree(d->xenoprof->vcpu);
xfree(d->xenoprof);
d->xenoprof = NULL;
return -ENOMEM;
@@ -286,6 +287,7 @@ void free_xenoprof_pages(struct domain *
free_xenheap_pages(x->rawbuf, order);
}
+ xfree(x->vcpu);
xfree(x);
d->xenoprof = NULL;
}

View File

@ -1,66 +0,0 @@
x86: rate-limit logging in do_xen{oprof,pmu}_op()
Some of the sub-ops are acessible to all guests, and hence should be
rate-limited. In the xenoprof case, just like for XSA-146, include them
only in debug builds. Since the vPMU code is rather new, allow them to
be always present, but downgrade them to (rate limited) guest messages.
This is XSA-152.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -682,8 +682,8 @@ long do_xenpmu_op(unsigned int op, XEN_G
vpmu_mode = pmu_params.val;
else if ( vpmu_mode != pmu_params.val )
{
- printk(XENLOG_WARNING
- "VPMU: Cannot change mode while active VPMUs exist\n");
+ gprintk(XENLOG_WARNING,
+ "VPMU: Cannot change mode while active VPMUs exist\n");
ret = -EBUSY;
}
@@ -714,8 +714,8 @@ long do_xenpmu_op(unsigned int op, XEN_G
vpmu_features = pmu_params.val;
else
{
- printk(XENLOG_WARNING "VPMU: Cannot change features while"
- " active VPMUs exist\n");
+ gprintk(XENLOG_WARNING,
+ "VPMU: Cannot change features while active VPMUs exist\n");
ret = -EBUSY;
}
--- a/xen/common/xenoprof.c
+++ b/xen/common/xenoprof.c
@@ -676,15 +676,13 @@ ret_t do_xenoprof_op(int op, XEN_GUEST_H
if ( (op < 0) || (op > XENOPROF_last_op) )
{
- printk("xenoprof: invalid operation %d for domain %d\n",
- op, current->domain->domain_id);
+ gdprintk(XENLOG_DEBUG, "invalid operation %d\n", op);
return -EINVAL;
}
if ( !NONPRIV_OP(op) && (current->domain != xenoprof_primary_profiler) )
{
- printk("xenoprof: dom %d denied privileged operation %d\n",
- current->domain->domain_id, op);
+ gdprintk(XENLOG_DEBUG, "denied privileged operation %d\n", op);
return -EPERM;
}
@@ -907,8 +905,7 @@ ret_t do_xenoprof_op(int op, XEN_GUEST_H
spin_unlock(&xenoprof_lock);
if ( ret < 0 )
- printk("xenoprof: operation %d failed for dom %d (status : %d)\n",
- op, current->domain->domain_id, ret);
+ gdprintk(XENLOG_DEBUG, "operation %d failed: %d\n", op, ret);
return ret;
}

View File

@ -1,86 +0,0 @@
From 27593ec62bdad8621df910931349d964a6dbaa8c Mon Sep 17 00:00:00 2001
From: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 21 Oct 2015 16:18:30 +0100
Subject: [PATCH XSA-153 v3] libxl: adjust PoD target by memory fudge, too
PoD guests need to balloon at least as far as required by PoD, or risk
crashing. Currently they don't necessarily know what the right value
is, because our memory accounting is (at the very least) confusing.
Apply the memory limit fudge factor to the in-hypervisor PoD memory
target, too. This will increase the size of the guest's PoD cache by
the fudge factor LIBXL_MAXMEM_CONSTANT (currently 1Mby). This ensures
that even with a slightly-off balloon driver, the guest will be
stable even under memory pressure.
There are two call sites of xc_domain_set_pod_target that need fixing:
The one in libxl_set_memory_target is straightforward.
The one in xc_hvm_build_x86.c:setup_guest is more awkward. Simply
setting the PoD target differently does not work because the various
amounts of memory during domain construction no longer match up.
Instead, we adjust the guest memory target in xenstore (but only for
PoD guests).
This introduces a 1Mby discrepancy between the balloon target of a PoD
guest at boot, and the target set by an apparently-equivalent `xl
mem-set' (or similar) later. This approach is low-risk for a security
fix but we need to fix this up properly in xen.git#staging and
probably also in stable trees.
This is XSA-153.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
tools/libxl/libxl.c | 2 +-
tools/libxl/libxl_dom.c | 9 ++++++++-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index d38d0c7..1366177 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4815,7 +4815,7 @@ retry_transaction:
}
rc = xc_domain_set_pod_target(ctx->xch, domid,
- new_target_memkb / 4, NULL, NULL, NULL);
+ (new_target_memkb + LIBXL_MAXMEM_CONSTANT) / 4, NULL, NULL, NULL);
if (rc != 0) {
LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
"xc_domain_set_pod_target domid=%d, memkb=%d "
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index b514377..8019f4e 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -486,6 +486,7 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid,
xs_transaction_t t;
char **ents;
int i, rc;
+ int64_t mem_target_fudge;
if (info->num_vnuma_nodes && !info->num_vcpu_soft_affinity) {
rc = set_vnuma_affinity(gc, domid, info);
@@ -518,11 +519,17 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid,
}
}
+ mem_target_fudge =
+ (info->type == LIBXL_DOMAIN_TYPE_HVM &&
+ info->max_memkb > info->target_memkb)
+ ? LIBXL_MAXMEM_CONSTANT : 0;
+
ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
ents[0] = "memory/static-max";
ents[1] = GCSPRINTF("%"PRId64, info->max_memkb);
ents[2] = "memory/target";
- ents[3] = GCSPRINTF("%"PRId64, info->target_memkb - info->video_memkb);
+ ents[3] = GCSPRINTF("%"PRId64, info->target_memkb - info->video_memkb
+ - mem_target_fudge);
ents[4] = "memory/videoram";
ents[5] = GCSPRINTF("%"PRId64, info->video_memkb);
ents[6] = "domid";
--
1.7.10.4

View File

@ -1,127 +0,0 @@
x86/HVM: always intercept #AC and #DB
Both being benign exceptions, and both being possible to get triggered
by exception delivery, this is required to prevent a guest from locking
up a CPU (resulting from no other VM exits occurring once getting into
such a loop).
The specific scenarios:
1) #AC may be raised during exception delivery if the handler is set to
be a ring-3 one by a 32-bit guest, and the stack is misaligned.
2) #DB may be raised during exception delivery when a breakpoint got
placed on a data structure involved in delivering the exception. This
can result in an endless loop when a 64-bit guest uses a non-zero IST
for the vector 1 IDT entry, but even without use of IST the time it
takes until a contributory fault would get raised (results depending
on the handler) may be quite long.
This is XSA-156.
Reported-by: Benjamin Serebrin <serebrin@google.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1043,10 +1043,11 @@ static void noreturn svm_do_resume(struc
unlikely(v->arch.hvm_vcpu.debug_state_latch != debug_state) )
{
uint32_t intercepts = vmcb_get_exception_intercepts(vmcb);
- uint32_t mask = (1U << TRAP_debug) | (1U << TRAP_int3);
+
v->arch.hvm_vcpu.debug_state_latch = debug_state;
vmcb_set_exception_intercepts(
- vmcb, debug_state ? (intercepts | mask) : (intercepts & ~mask));
+ vmcb, debug_state ? (intercepts | (1U << TRAP_int3))
+ : (intercepts & ~(1U << TRAP_int3)));
}
if ( v->arch.hvm_svm.launch_core != smp_processor_id() )
@@ -2434,8 +2435,9 @@ void svm_vmexit_handler(struct cpu_user_
case VMEXIT_EXCEPTION_DB:
if ( !v->domain->debugger_attached )
- goto unexpected_exit_type;
- domain_pause_for_debugger();
+ hvm_inject_hw_exception(TRAP_debug, HVM_DELIVER_NO_ERROR_CODE);
+ else
+ domain_pause_for_debugger();
break;
case VMEXIT_EXCEPTION_BP:
@@ -2483,6 +2485,11 @@ void svm_vmexit_handler(struct cpu_user_
break;
}
+ case VMEXIT_EXCEPTION_AC:
+ HVMTRACE_1D(TRAP, TRAP_alignment_check);
+ hvm_inject_hw_exception(TRAP_alignment_check, vmcb->exitinfo1);
+ break;
+
case VMEXIT_EXCEPTION_UD:
svm_vmexit_ud_intercept(regs);
break;
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1224,16 +1224,10 @@ static void vmx_update_host_cr3(struct v
void vmx_update_debug_state(struct vcpu *v)
{
- unsigned long mask;
-
- mask = 1u << TRAP_int3;
- if ( !cpu_has_monitor_trap_flag )
- mask |= 1u << TRAP_debug;
-
if ( v->arch.hvm_vcpu.debug_state_latch )
- v->arch.hvm_vmx.exception_bitmap |= mask;
+ v->arch.hvm_vmx.exception_bitmap |= 1U << TRAP_int3;
else
- v->arch.hvm_vmx.exception_bitmap &= ~mask;
+ v->arch.hvm_vmx.exception_bitmap &= ~(1U << TRAP_int3);
vmx_vmcs_enter(v);
vmx_update_exception_bitmap(v);
@@ -3060,9 +3054,10 @@ void vmx_vmexit_handler(struct cpu_user_
__vmread(EXIT_QUALIFICATION, &exit_qualification);
HVMTRACE_1D(TRAP_DEBUG, exit_qualification);
write_debugreg(6, exit_qualification | DR_STATUS_RESERVED_ONE);
- if ( !v->domain->debugger_attached || cpu_has_monitor_trap_flag )
- goto exit_and_crash;
- domain_pause_for_debugger();
+ if ( !v->domain->debugger_attached )
+ hvm_inject_hw_exception(vector, HVM_DELIVER_NO_ERROR_CODE);
+ else
+ domain_pause_for_debugger();
break;
case TRAP_int3:
{
@@ -3127,6 +3122,11 @@ void vmx_vmexit_handler(struct cpu_user_
hvm_inject_page_fault(regs->error_code, exit_qualification);
break;
+ case TRAP_alignment_check:
+ HVMTRACE_1D(TRAP, vector);
+ __vmread(VM_EXIT_INTR_ERROR_CODE, &ecode);
+ hvm_inject_hw_exception(vector, ecode);
+ break;
case TRAP_nmi:
if ( MASK_EXTR(intr_info, INTR_INFO_INTR_TYPE_MASK) !=
X86_EVENTTYPE_NMI )
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -385,7 +385,10 @@ static inline int hvm_event_pending(stru
(X86_CR4_VMXE | X86_CR4_PAE | X86_CR4_MCE))
/* These exceptions must always be intercepted. */
-#define HVM_TRAP_MASK ((1U << TRAP_machine_check) | (1U << TRAP_invalid_op))
+#define HVM_TRAP_MASK ((1U << TRAP_debug) | \
+ (1U << TRAP_invalid_op) | \
+ (1U << TRAP_alignment_check) | \
+ (1U << TRAP_machine_check))
/*
* x86 event types. This enumeration is valid for:

View File

@ -1,47 +0,0 @@
memory: fix XENMEM_exchange error handling
assign_pages() can fail due to the domain getting killed in parallel,
which should not result in a hypervisor crash.
Also delete a redundant put_gfn() - all relevant paths leading to the
"fail" label already do this (and there are also paths where it was
plain wrong). All of the put_gfn()-s got introduced by 51032ca058
("Modify naming of queries into the p2m"), including the otherwise
unneeded initializer for k (with even a kind of misleading comment -
the compiler warning could actually have served as a hint that the use
is wrong).
This is XSA-159.
Reported-by: Julien Grall <julien.grall@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -334,7 +334,7 @@ static long memory_exchange(XEN_GUEST_HA
PAGE_LIST_HEAD(out_chunk_list);
unsigned long in_chunk_order, out_chunk_order;
xen_pfn_t gpfn, gmfn, mfn;
- unsigned long i, j, k = 0; /* gcc ... */
+ unsigned long i, j, k;
unsigned int memflags = 0;
long rc = 0;
struct domain *d;
@@ -572,11 +572,12 @@ static long memory_exchange(XEN_GUEST_HA
fail:
/* Reassign any input pages we managed to steal. */
while ( (page = page_list_remove_head(&in_chunk_list)) )
- {
- put_gfn(d, gmfn + k--);
if ( assign_pages(d, page, 0, MEMF_no_refcount) )
- BUG();
- }
+ {
+ BUG_ON(!d->is_dying);
+ if ( test_and_clear_bit(_PGC_allocated, &page->count_info) )
+ put_page(page);
+ }
dying:
rcu_unlock_domain(d);

View File

@ -1,69 +0,0 @@
From adcbd15b1aec8367f790774c998db199c9b577bf Mon Sep 17 00:00:00 2001
From: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 18 Nov 2015 15:34:54 +0000
Subject: [PATCH] libxl: Fix bootloader-related virtual memory leak on pv
build failure
The bootloader may call libxl__file_reference_map(), which mmap's the
pv_kernel and pv_ramdisk into process memory. This was only unmapped,
however, on the success path of libxl__build_pv(). If there were a
failure anywhere between libxl_bootloader.c:parse_bootloader_result()
and the end of libxl__build_pv(), the calls to
libxl__file_reference_unmap() would be skipped, leaking the mapped
virtual memory.
Ideally this would be fixed by adding the unmap calls to the
destruction path for libxl__domain_build_state. Unfortunately the
lifetime of the libxl__domain_build_state is opaque, and it doesn't
have a proper destruction path. But, the only thing in it that isn't
from the gc are these bootloader references, and they are only ever
set for one libxl__domain_build_state, the one which is
libxl__domain_create_state.build_state.
So we can clean up in the exit path from libxl__domain_create_*, which
always comes through domcreate_complete.
Remove the now-redundant unmaps in libxl__build_pv's success path.
This is XSA-160.
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Tested-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
tools/libxl/libxl_create.c | 3 +++
tools/libxl/libxl_dom.c | 3 ---
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index f5771da..278b9ed 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1484,6 +1484,9 @@ static void domcreate_complete(libxl__egc *egc,
libxl_domain_config *const d_config = dcs->guest_config;
libxl_domain_config *d_config_saved = &dcs->guest_config_saved;
+ libxl__file_reference_unmap(&dcs->build_state.pv_kernel);
+ libxl__file_reference_unmap(&dcs->build_state.pv_ramdisk);
+
if (!rc && d_config->b_info.exec_ssidref)
rc = xc_flask_relabel_domain(CTX->xch, dcs->guest_domid, d_config->b_info.exec_ssidref);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 8019f4e..2da3ac4 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -750,9 +750,6 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
state->store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
}
- libxl__file_reference_unmap(&state->pv_kernel);
- libxl__file_reference_unmap(&state->pv_ramdisk);
-
ret = 0;
out:
xc_dom_release(dom);
--
1.7.10.4

View File

@ -1,34 +0,0 @@
MSI-X: avoid array overrun upon MSI-X table writes
pt_msix_init() allocates msix->msix_entry[] to just cover
msix->total_entries entries. While pci_msix_readl() resorts to reading
physical memory for out of bounds reads, pci_msix_writel() so far
simply accessed/corrupted unrelated memory.
pt_iomem_map()'s call to cpu_register_physical_memory() registers a
page granular region, which is necessary as the Pending Bit Array may
share space with the MSI-X table (but nothing else is allowed to). This
also explains why pci_msix_readl() actually honors out of bounds reads,
but pci_msi_writel() doesn't need to.
This is XSA-164.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
--- a/hw/pt-msi.c
+++ b/hw/pt-msi.c
@@ -440,6 +440,13 @@ static void pci_msix_writel(void *opaque
return;
}
+ if ( addr - msix->mmio_base_addr >= msix->total_entries * 16 )
+ {
+ PT_LOG("Error: Out of bounds write to MSI-X table,"
+ " addr %016"PRIx64"\n", addr);
+ return;
+ }
+
entry_nr = (addr - msix->mmio_base_addr) / 16;
entry = &msix->msix_entry[entry_nr];
offset = ((addr - msix->mmio_base_addr) % 16) / 4;

View File

@ -1,85 +0,0 @@
x86: don't leak ST(n)/XMMn values to domains first using them
FNINIT doesn't alter these registers, and hence using it is
insufficient to initialize a guest's initial state.
This is XSA-165.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -851,6 +851,17 @@ int arch_set_info_guest(
if ( v->arch.xsave_area )
v->arch.xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE;
}
+ else if ( v->arch.xsave_area )
+ memset(&v->arch.xsave_area->xsave_hdr, 0,
+ sizeof(v->arch.xsave_area->xsave_hdr));
+ else
+ {
+ typeof(v->arch.xsave_area->fpu_sse) *fpu_sse = v->arch.fpu_ctxt;
+
+ memset(fpu_sse, 0, sizeof(*fpu_sse));
+ fpu_sse->fcw = FCW_DEFAULT;
+ fpu_sse->mxcsr = MXCSR_DEFAULT;
+ }
if ( !compat )
{
--- a/xen/arch/x86/i387.c
+++ b/xen/arch/x86/i387.c
@@ -17,19 +17,6 @@
#include <asm/xstate.h>
#include <asm/asm_defns.h>
-static void fpu_init(void)
-{
- unsigned long val;
-
- asm volatile ( "fninit" );
- if ( cpu_has_xmm )
- {
- /* load default value into MXCSR control/status register */
- val = MXCSR_DEFAULT;
- asm volatile ( "ldmxcsr %0" : : "m" (val) );
- }
-}
-
/*******************************/
/* FPU Restore Functions */
/*******************************/
@@ -248,15 +235,8 @@ void vcpu_restore_fpu_lazy(struct vcpu *
if ( cpu_has_xsave )
fpu_xrstor(v, XSTATE_LAZY);
- else if ( v->fpu_initialised )
- {
- if ( cpu_has_fxsr )
- fpu_fxrstor(v);
- else
- fpu_frstor(v);
- }
else
- fpu_init();
+ fpu_fxrstor(v);
v->fpu_initialised = 1;
v->fpu_dirtied = 1;
@@ -313,7 +293,14 @@ int vcpu_init_fpu(struct vcpu *v)
else
{
v->arch.fpu_ctxt = _xzalloc(sizeof(v->arch.xsave_area->fpu_sse), 16);
- if ( !v->arch.fpu_ctxt )
+ if ( v->arch.fpu_ctxt )
+ {
+ typeof(v->arch.xsave_area->fpu_sse) *fpu_sse = v->arch.fpu_ctxt;
+
+ fpu_sse->fcw = FCW_DEFAULT;
+ fpu_sse->mxcsr = MXCSR_DEFAULT;
+ }
+ else
rc = -ENOMEM;
}

View File

@ -1,77 +0,0 @@
x86/mm: PV superpage handling lacks sanity checks
MMUEXT_{,UN}MARK_SUPER fail to check the input MFN for validity before
dereferencing pointers into the superpage frame table.
get_superpage() has a similar issue.
This is XSA-167.
Reported-by: Qinghao Tang <luodalongde@gmail.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2624,6 +2624,9 @@ int get_superpage(unsigned long mfn, str
ASSERT(opt_allow_superpage);
+ if ( !mfn_valid(mfn | (L1_PAGETABLE_ENTRIES - 1)) )
+ return -EINVAL;
+
spage = mfn_to_spage(mfn);
y = spage->type_info;
do {
@@ -3401,42 +3404,26 @@ long do_mmuext_op(
}
case MMUEXT_MARK_SUPER:
+ case MMUEXT_UNMARK_SUPER:
{
unsigned long mfn = op.arg1.mfn;
- if ( unlikely(d != pg_owner) )
- rc = -EPERM;
- else if ( mfn & (L1_PAGETABLE_ENTRIES-1) )
- {
- MEM_LOG("Unaligned superpage reference mfn %lx", mfn);
- okay = 0;
- }
- else if ( !opt_allow_superpage )
+ if ( !opt_allow_superpage )
{
MEM_LOG("Superpages disallowed");
rc = -ENOSYS;
}
- else
- rc = mark_superpage(mfn_to_spage(mfn), d);
- break;
- }
-
- case MMUEXT_UNMARK_SUPER:
- {
- unsigned long mfn = op.arg1.mfn;
-
- if ( unlikely(d != pg_owner) )
+ else if ( unlikely(d != pg_owner) )
rc = -EPERM;
- else if ( mfn & (L1_PAGETABLE_ENTRIES-1) )
+ else if ( mfn & (L1_PAGETABLE_ENTRIES - 1) )
{
MEM_LOG("Unaligned superpage reference mfn %lx", mfn);
- okay = 0;
- }
- else if ( !opt_allow_superpage )
- {
- MEM_LOG("Superpages disallowed");
- rc = -ENOSYS;
+ rc = -EINVAL;
}
+ else if ( !mfn_valid(mfn | (L1_PAGETABLE_ENTRIES - 1)) )
+ rc = -EINVAL;
+ else if ( op.cmd == MMUEXT_MARK_SUPER )
+ rc = mark_superpage(mfn_to_spage(mfn), d);
else
rc = unmark_superpage(mfn_to_spage(mfn));
break;

View File

@ -1,27 +0,0 @@
x86/VMX: prevent INVVPID failure due to non-canonical guest address
While INVLPG (and on SVM INVLPGA) don't fault on non-canonical
addresses, INVVPID fails (in the "individual address" case) when passed
such an address.
Since such intercepted INVLPG are effectively no-ops anyway, don't fix
this in vmx_invlpg_intercept(), but instead have paging_invlpg() never
return true in such a case.
This is XSA-168.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
--- a/xen/include/asm-x86/paging.h
+++ b/xen/include/asm-x86/paging.h
@@ -245,7 +245,7 @@ paging_fault(unsigned long va, struct cp
* or 0 if it's safe not to do so. */
static inline int paging_invlpg(struct vcpu *v, unsigned long va)
{
- return paging_get_hostmode(v)->invlpg(v, va);
+ return is_canonical_address(va) && paging_get_hostmode(v)->invlpg(v, va);
}
/* Translate a guest virtual address to the frame number that the

View File

@ -1,33 +0,0 @@
x86: make debug output consistent in hvm_set_callback_via
The unconditional printks in the switch statement of the
hvm_set_callback_via function results in Xen log spam in non debug
versions of Xen. The printks are for debug output only so conditionally
compile the entire switch statement on debug versions of Xen only.
This is XSA-169.
Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -386,7 +386,8 @@ void hvm_set_callback_via(struct domain
spin_unlock(&d->arch.hvm_domain.irq_lock);
- dprintk(XENLOG_G_INFO, "Dom%u callback via changed to ", d->domain_id);
+#ifndef NDEBUG
+ printk(XENLOG_G_INFO "Dom%u callback via changed to ", d->domain_id);
switch ( via_type )
{
case HVMIRQ_callback_gsi:
@@ -402,6 +403,7 @@ void hvm_set_callback_via(struct domain
printk("None\n");
break;
}
+#endif
}
struct hvm_intack hvm_vcpu_has_pending_irq(struct vcpu *v)