mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 18:21:39 +01:00
Wei Liu
aa67b97ed3
XSA-273 involves one hyperthread being able to use Spectre-like
techniques to "spy" on another thread. The details are somewhat
complicated, but the upshot is that after all Xen-based mitigations
have been applied:
* PV guests cannot spy on sibling threads
* HVM guests can spy on sibling threads
(NB that for purposes of this vulnerability, PVH and HVM guests are
identical. Whenever this comment refers to 'HVM', this includes PVH.)
There are many possible mitigations to this, including disabling
hyperthreading entirely. But another solution would be:
* Specify some cores as PV-only, others as PV or HVM
* Allow HVM guests to only run on thread 0 of the "HVM-or-PV" cores
* Allow PV guests to run on the above cores, as well as any thread of the PV-only cores.
For example, suppose you had 16 threads across 8 cores (0-7). You
could specify 0-3 as PV-only, and 4-7 as HVM-or-PV. Then you'd set
the affinity of the HVM guests as follows (binary representation):
0000000010101010
And the affinity of the PV guests as follows:
1111111110101010
In order to make this easy, this patches introduces three "global affinity
masks", placed in xl.conf:
vm.cpumask
vm.hvm.cpumask
vm.pv.cpumask
These are parsed just like the 'cpus' and 'cpus_soft' options in the
per-domain xl configuration files. The resulting mask is AND-ed with
whatever mask results at the end of the xl configuration file.
`vm.cpumask` would be applied to all guest types, `vm.hvm.cpumask`
would be applied to HVM and PVH guest types, and `vm.pv.cpumask`
would be applied to PV guest types.
The idea would be that to implement the above mask across all your
VMs, you'd simply add the following two lines to the configuration
file:
vm.hvm.cpumask=8,10,12,14
vm.pv.cpumask=0-8,10,12,14
See xl.conf manpage for details.
This is part of XSA-273 / CVE-2018-3646.
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
45 lines
1.4 KiB
Plaintext
45 lines
1.4 KiB
Plaintext
## Global XL config file ##
|
|
|
|
# Control whether dom0 is ballooned down when xen doesn't have enough
|
|
# free memory to create a domain. "auto" means only balloon if dom0
|
|
# starts with all the host's memory.
|
|
#autoballoon="auto"
|
|
|
|
# full path of the lockfile used by xl during domain creation
|
|
#lockfile="/var/lock/xl"
|
|
|
|
# default output format used by "xl list -l"
|
|
#output_format="json"
|
|
|
|
# first block device to be used for temporary VM disk mounts
|
|
#blkdev_start="xvda"
|
|
|
|
# default option to run hotplug scripts from xl
|
|
# if disabled the old behaviour will be used, and hotplug scripts will be
|
|
# launched by udev.
|
|
#run_hotplug_scripts=1
|
|
|
|
# default backend domain to connect guest vifs to. This can be any
|
|
# valid domain identifier.
|
|
#vif.default.backend="0"
|
|
|
|
# default gateway device to use with vif-route hotplug script
|
|
#vif.default.gatewaydev="eth0"
|
|
|
|
# default vif script to use if none is specified in the guest config
|
|
#vif.default.script="vif-bridge"
|
|
|
|
# default bridge device to use with vif-bridge hotplug scripts
|
|
#vif.default.bridge="xenbr0"
|
|
|
|
# Reserve a claim of memory when launching a guest. This guarantees immediate
|
|
# feedback whether the guest can be launched due to memory exhaustion
|
|
# (which can take a long time to find out if launching huge guests).
|
|
# see xl.conf(5) for details.
|
|
#claim_mode=1
|
|
|
|
# Specify global vcpu hard affinity masks. See xl.conf(5) for details.
|
|
#vm.cpumask="0-7"
|
|
#vm.pv.cpumask="0-3"
|
|
#vm.hvm.cpumask="3-7"
|