Ian Jackson [Tue, 3 May 2016 14:58:32 +0000 (15:58 +0100)]
libxl: Do not trust frontend for vtpm list
libxl_device_vtpm_list needs to enumerate and identify devices without
trusting frontend-controlled data. So
* Use the /libxl path to enumerate vtpms.
* Use the /libxl path to find the corresponding backends.
* Parse the backend path to find the backend domid.
This is part of XSA-175.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Ian Jackson [Fri, 29 Apr 2016 18:21:51 +0000 (19:21 +0100)]
libxl: Do not trust frontend for disk in getinfo
* Rename the frontend variable to `fe_path' to check we caught them all
* Read the backend path from /libxl, rather than from the frontend
* Parse the backend domid from the backend path, rather than reading it
from the frontend (and add the appropriate error path and initialisation)
This is part of XSA-175.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Ian Jackson [Wed, 27 Apr 2016 15:08:49 +0000 (16:08 +0100)]
libxl: Do not trust frontend for disk eject event
Use the /libxl path for interpreting disk eject watch events: do not
read the backend path out of the frontend. Instead, use the version
in /libxl. That avoids us relying on the guest-modifiable
$frontend/backend pointer.
To implement this we store the path
/libxl/$guest/device/vbd/$devid/backend
in the evgen structure.
This is part of XSA-175.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Ian Jackson [Tue, 3 May 2016 17:39:36 +0000 (18:39 +0100)]
libxl: Do not trust frontend in libxl__devices_destroy
We need to enumerate the devices we have provided to a domain, without
trusting the guest-writeable (or, at least, guest-deletable) frontend
paths.
Instead, enumerate via, and read the backend path from, /libxl.
The console /libxl path is regular, so the special case for console 0
is not relevant any more: /libxl/GUEST/device/console/0 will be found,
and then libxl__device_destroy will DTRT to the right frontend path.
This is part of XSA-175.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Ian Jackson [Wed, 27 Apr 2016 15:34:19 +0000 (16:34 +0100)]
libxl: Provide libxl__backendpath_parse_domid
Multiple places in libxl need to figure out the backend domid of a
device. This can be discovered easily by looking at the backend path,
which always starts /local/domain/$backend_domid/.
There are no call sites yet.
This is part of XSA-175.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Ian Jackson [Wed, 27 Apr 2016 14:50:01 +0000 (15:50 +0100)]
libxl: Record backend/frontend paths in /libxl/$DOMID
This gives us a record of all the backends we have set up for a
domain, which is separate from the frontends in
/local/domain/$DOMID/device.
In particular:
1. A guest has write permission for the frontend path:
/local/domain/$DOMID/device/$KIND/$DEVID
which means that the guest can completely delete the frontend.
(They can't recreate it because they don't have write permission
on the containing directory.)
2. A guest has write permission for the backend path recorded in the
frontend, ie, it can write to
/local/domain/$DOMID/device/$KIND/$DEVID/backend
which means that the guest can break the association between
frontend and backend.
So we can't rely on iterating over the frontends to find all the
backends, or examining a frontend to discover how a device is
configured.
So, have libxl__device_generic_add record the frontend and backend
paths in /libxl/$DOMID/device, and have libxl__device_destroy remove
them again.
Create the containing directory /libxl/GUEST/device in
libxl__domain_make. The already existing xs_rm in devices_destroy_cb
will take care of removing it.
This is part of XSA-175.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
---
v2: Correct actual path computation (!)
v3: Correct actual path computation - really this time (!)
AMD IOMMU: remove currently non-functioning guest iommu feature
The guest IOMMU feature is currently not functioning. However,
the current guest_iommu_init() is causing issue when it tries to
register mmio handler because the it is currently called by the
following code path:
libxl: keep PoD target adjustment by memory fudge after reload_domain_config()
Commit 56fb5fd623 ("libxl: adjust PoD target by memory fudge, too")
introduced target_memkb adjustment for HVM PoD domains on create,
wherein the value it wrote to target is always 1MiB lower than the
actual target_memkb. Unfortunately, on reboot, it is this value which
is read *unmodified* to feed into the next domain creation; from which
1MiB is subtracted *again*. This means that any guest which reboots
with memory < maxmem will have its memory target decreased by 1MiB on
every boot.
This patch makes it so that when reading target on reboot, we adjust the
value we read *up* by 1MiB, so that the domain will be build with the
appropriate amount of memory and the target will remain the same after
reboot.
This is still not quite a complete fix, as the 1MiB offset is only
subtracted when creating or rebooting; it is not subtracted when 'xl
set-memory' is called. But it will prevent any situations where memory
is continually increased or decreased. A better fix will have to wait
until after the release.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
In AArch32, MPIDR bit 31 is defined as multiprocessing extensions bit.
But in AArch64, this bit is always RES1. So the value check for this
bit is no longer necessary in AArch64.
Wei Chen [Tue, 31 May 2016 02:54:13 +0000 (10:54 +0800)]
xen:arm: arm64: Add correct MPIDR_HWID_MASK value for ARM64
Currently, MPIDR_HWID_MASK is using the bit definition of AArch32
MPIDR register. But from D7.2.67 of ARM ARM (DDI 0487A.i) we can see
there are 4 levels of affinity on AArch64 whilst AArch32 has only 3.
So, this value is not correct when Xen is running on AArch64.
Now, we use the value 0xff00ffffff for this macro on AArch64. But
neither of this value and its bitwise invert value can be used in mov
instruction with the encoding of {imm16:shift} or {imms:immr}. So we
have to use ldr to load the bitwise invert value to register.
The details of mov immediate encoding are listed in C4.2.5 of ARM ARM
(DDI 0487A.i).
Wei Chen [Tue, 31 May 2016 02:54:12 +0000 (10:54 +0800)]
xen/arm: Make AFFINITY_MASK generate correct mask for level3
The original affinity shift bits algorithm in AFFINITY_MASK is buggy,
it could not generate correct affinity shift bits of level3.
The macro MPIDR_LEVEL_SHIFT can calculate level3 affinity shift bits
correctly. We use this macro in AFFINITY_MASK to generate correct
mask for level3.
Wei Chen [Tue, 31 May 2016 02:54:11 +0000 (10:54 +0800)]
xen/arm: Change the variable type of cpu_logical_map to register_t
The cpu_logical_map is used to store CPU hardware ID from MPIDR_EL1 or
from CPU node of DT. Currently, the cpu_logical_map is using the u32 as
its variable type. It can work properly while Xen is running on ARM32,
because the hardware ID is 32-bits. While Xen is running on ARM64, the
hardware ID expands to 64-bits and then the cpu_logical_map will overflow.
Change the variable type of cpu_logical_map to register_t will make
cpu_logical_map to store hardware IDs correctly on ARM32 and ARM64.
The commit is causing a dead loop inside the spinlock function.
spinlocks in Xen are not recursive. Re-acquiring a spinlock that was
already taken by the calling cpu leads to deadlock. This happens
whenever dom0 writes to GICD regs ISENABLER/ICENABLER.
DOM0 writes GICD_ISENABLER/GICD_ICENABLER
vgic_v3_distr_common_mmio_write()
vgic_lock_rank() --> acquiring first time
vgic_enable_irqs()
route_irq_to_guest()
gic_route_irq_to_guest()
vgic_get_target_vcpu()
vgic_lock_rank() --> attemping acquired lock
Chris Patterson [Tue, 31 May 2016 15:13:52 +0000 (11:13 -0400)]
xen/Makefile: quote HOSTCC and HOSTCXX args
In some cross-compilation environments, the CC/CXX variables may
expand out to more than one argument (to include things
like --sysroot=...). Quote these to safely pass along.
Signed-off-by: Chris Patterson <pattersonc@ainfosec.com> Acked-by: Jan Beulich <jbeulich@suse.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Jan Beulich [Tue, 31 May 2016 16:14:22 +0000 (18:14 +0200)]
build: fix assembler instruction tests again
Commit 7fb252bd41 ("build/xen: fix assembler instruction tests") added
$(AFLAGS) here, which results in all of those tests now failing.
Certain items need to be removed for things to work again.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Julien Grall [Fri, 27 May 2016 16:06:20 +0000 (17:06 +0100)]
xen: XENMEM_add_to_physmap_batch: Mark 'foreign_id' as reserved for dev_mmio
The field 'foreign_id' is not used when the space is dev_mmio. As the
space is not yet part of the stable ABI, the field is marked as reserved
for future use.
The value should always be 0, other values will return -EOPNOTSUPP.
The get_maintainer.pl script showed Jan as the maintainer so I pushed
this patch. But in fact according to MAINTAINERS file, he's not. Revert
this patch and wait until a maintainer acks it.
Haozhong Zhang [Fri, 27 May 2016 13:30:33 +0000 (21:30 +0800)]
x86/mce: handle reserved domain ID in XEN_MC_msrinject
Commit 26646f3 "x86/mce: translate passed-in GPA to host machine
address" and commit 4ddf474 "tools/xen-mceinj: Pass in GPA when
injecting through MSR_MCI_ADDR" forgot to consider reserved domain
ID and mistakenly add MC_MSRINJ_F_GPADDR flag for them, which in turn
causes bug reported by
http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg02640.html.
This patch removes MC_MSRINK_F_GPADDR flag and checks this when injecting
to reserved domain IDs except DOMID_SELF, and treats the passed-in
address as host machine address.
Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Jan Beulich [Thu, 26 May 2016 16:26:24 +0000 (17:26 +0100)]
x86/compat: correct SMEP/SMAP NOPs patching
Correct the number of single byte NOPs we want to be replaced in case
neither SMEP nor SMAP are available.
Also simplify the expression adding these NOPs - at that location .
equals .Lcr4_orig, and removing that part of the expression fixes a
bogus ".space or fill with negative value, ignored" warning by very old
gas (which actually is what made me look at those constructs again).
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Chao Peng [Thu, 26 May 2016 02:03:13 +0000 (10:03 +0800)]
x86/psr: make opt_psr persistent
opt_psr is now not only used at booting time but also at runtime.
More specifically, it is used to check CDP switch in psr_cpu_init()
which can potentially be called in CPU hotplug case.
Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Julien Grall [Wed, 25 May 2016 13:14:06 +0000 (14:14 +0100)]
xen/arm: Don't call setup_virtual_regions multiple time
The commit 2aa925be84293b44ad587ed117184ace61b41dd6 "arm/x86: Use struct
virtual_region to do bug, symbol, and (x86) exception tables lookup."
has introduced virtual_region. The call to initialize those regions is
made in init_traps which is called during each CPU bring up.
This will result to register multiple time the same region and Xen crash
when an address is looked up.
This can be fixed by moving the call to setup_virtual_region directly in
start_xen.
Signed-off-by: Julien Grall <julien.grall@arm.com> Reported-by: Chenxia Zhao <chenxiao.zhao@gmail.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Wei Liu [Wed, 18 May 2016 13:35:40 +0000 (14:35 +0100)]
tools: bump library version numbers
The following libraries are checked:
1. libxc, version number bumped
2. libxl, version number bumped
3. libxlu, no development in 4.7 cycle, but depends on libxl, version
number bumped
4. libs/*, new in 4.7 cycle, version numbers not bumped
5. libxenstore, no development in 4.7 cycle, version number not bumped
6. libxenstat, no development in 4.7 cycle, version number not bumped
7. libvchan, depends on xengnttab library, API changed, version number
bumped
Signed-off-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Anthony PERARD [Tue, 24 May 2016 14:45:36 +0000 (15:45 +0100)]
libxl: Avoid advertising about device_model_user config option
Running QEMU as non-root user is not ready yet, so replace the warning
with a debug message and remove the option from the man page.
Also improve the doc to include more potential issue with running QEMU
as non-root.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Wei Liu [Fri, 20 May 2016 17:16:05 +0000 (18:16 +0100)]
libxl: nic type defaults to vif in hotplug for hvm guest
We don't support plugging in emulated nic to a HVM guest.
The "update_json" flag is only set when doing hotplug, so use that as an
indicator in libxl__device_nic_add. The new hotplug flag to _setdefault
function should be false in all other locations.
This then requires saving nic type in JSON file, because we don't want
the receiving end to recalculate the nic type.
Signed-off-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Dario Faggioli [Mon, 23 May 2016 12:39:51 +0000 (14:39 +0200)]
sched: avoid races on time values read from NOW()
or (even in cases where there is no race, e.g., outside
of Credit2) avoid using a time sample which may be rather
old, and hence stale.
In fact, we should only sample NOW() from _inside_
the critical region within which the value we read is
used. If we don't, in case we have to spin for a while
before entering the region, when actually using it:
1) we will use something that, at the veryy least, is
not really "now", because of the spinning,
2) if someone else sampled NOW() during a critical
region protected by the lock we are spinning on,
and if we compare the two samples when we get
inside our region, our one will be 'earlier',
even if we actually arrived later, which is a
race.
In Credit2, we see an instance of 2), in runq_tickle(),
when it is called by csched2_context_saved() as it samples
NOW() before acquiring the runq lock. This makes things
look like the time went backwards, and it confuses the
algorithm (there's even a d2printk() about it, which would
trigger all the time, if enabled).
In RTDS, something similar happens in repl_timer_handler(),
and there's another instance in schedule() (in generic code),
so fix these cases too.
While there, improve csched2_vcpu_wake() and and rt_vcpu_wake()
a little as well (removing a pointless initialization, and
moving the sampling a bit closer to its use). These two hunks
entail no further functional changes.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com> Reviewed-by: George Dunlap <george.dunlap@citrix.com> Reviewed-by: Meng Xu <mengxu@cis.upenn.edu> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Surround the string in backticks to make it verbatim text.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Andrew Cooper [Mon, 25 Apr 2016 12:55:12 +0000 (12:55 +0000)]
docs/build: Avoid using multi-target pattern rules
Multi-target non-pattern rules and Multi-target pattern rules behave rather
differently. From `Pattern Intro':
Pattern rules may have more than one target. Unlike normal rules, this does
not act as many different rules with the same prerequisites and commands.
If a pattern rule has multiple targets, `make' knows that the rule's
commands are responsible for making all of the targets. The commands are
executed only once to make all the targets.
The intended use of the multi-target pattern rules was to avoid repeating the
identical recipe multiple times. The issue can be demonstrated with the
generation of documentation from pandoc source.
./xen.git$ touch docs/features/template.pandoc
./xen.git$ make -C docs/
# Regenerates html/features/template.html
./xen.git$ make -C docs/
# Regenerates txt/features/template.txt
./xen.git$ make -C docs/
# Regenerates pdf/features/template.pdf
To work around this, there need to be three distinct rules, so the execution
of one recipe doesn't short ciruit the others. To avoid copy&paste
duplication, introduce a metarule, and evalute it for each document target.
As $(PANDOC) is used to generate documentation from different source types,
the metarule can be extended to also encompas the rule to create pdfs from
markdown.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Julien Grall [Fri, 20 May 2016 13:37:42 +0000 (14:37 +0100)]
xen/arm: p2m: Release the p2m lock before undoing the mappings
Since commit 4b25423a "arch/arm: unmap partially-mapped memory regions",
Xen has been undoing the P2M mappings when an error occurred during
insertion or memory allocation.
This is done by calling recursively apply_p2m_changes, however the
second call is done with the p2m lock taken which will result in a
deadlock for the current processor.
The p2m lock is here to protect 2 threads modifying concurrently the
page tables. However, it does not guarantee the ordering of the
changes. I.e if 2 threads request change on regions that overlaps,
then the result is undefined.
Therefore it is fine to move the recursive call to undo the changes
after the lock is released.
Julien Grall [Fri, 20 May 2016 13:37:41 +0000 (14:37 +0100)]
xen/arm: p2m: apply_p2m_changes: Do not undo more than necessary
Since commit 4b25423a "arch/arm: unmap partially-mapped memory regions",
Xen has been undoing the P2M mappings when an error occurred during
insertion or memory allocation.
The function apply_p2m_changes can work with region not-aligned to a
block size (2MB, 1G) or page size (4K). The mapping will be done by
splitting the region in a set of regions aligned to the size supported
by the page table.
The mapping of a region could fail when it is not possible to allocate
memory for an intermediate table (i.e a new or when shattering a block).
When the mapping is undone, the end of the region is computed using the
base address of the current region and the size of the failing level.
However the failing level may not be the leaf one, therefore unrelated
entries will be removed.
Fix it by removing the mapping from the start address up to the last
region that has been successfully mapped.
Andrew Cooper [Tue, 12 Apr 2016 18:57:35 +0000 (19:57 +0100)]
xen/nested_p2m: Don't walk EPT tables with a regular PT walker
hostmode->p2m_ga_to_gfn() is a plain PT walker, and is not appropriate for a
general L1 p2m walk. It is fine for AMD as NPT share the same format as
normal pagetables. For Intel EPT however, it is wrong.
The translation ends up correct (as the formats are sufficiently similar), but
the control bits in lower 12 bits differ in meaning. A plain PT walker sets
A/D bits (bits 5 and 6) as it walks, but in EPT tables, these are the IPAT and
top bit of EMT (caching type). This in turn causes problem when the EPT
tables are subsequently used.
Replace hostmode->p2m_ga_to_gfn() with nestedhap_walk_L1_p2m() in
paging_gva_to_gfn(), which is the correct function for the task. This
involves making nestedhap_walk_L1_p2m() non-static, and adding
vmx_vmcs_enter/exit() pairs to nvmx_hap_walk_L1_p2m() as it is now reachable
from contexts other than v == current.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Acked-by: George Dunlap <george.dunlap@citrix.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
xen/device-tree: Do not remap IRQs for secondary IRQ controllers
Do not remap IRQs connected to secondary interrupt controllers.
These IRQs have no meaning to us until they connect to the
primary controller.
Secondary IRQ controllers will at some point connect to the
primary controller (possibly via other IRQ controllers). We
map the IRQs at that last connection point.
Reviewed-by: Julien Grall <julien.grall@linaro.org> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Andrew Cooper [Fri, 13 May 2016 18:38:41 +0000 (19:38 +0100)]
x86/cpuid: Avoid unconditionally clobbering ITSC for guests
In general, Invariant TSC is not a feature which can be advertised to guests,
because it cannot be guaranteed across migrate. domain_cpuid() goes so far as
to deliberately clobber the feature flag under a number of circumstances.
Because ITSC is absent from the static {pv,hvm}_featureset masks, c/s b648feff
"xen/x86: Improvements to in-hypervisor cpuid sanity checks" caused ITSC to be
unconditionally masked out.
As an interim solution, include the hosts idea of ITSC along with the static
{pv,hvm}_featureset when restricting the guests view of features. This causes
the hardware domain, and VMs explicitly configured with ITSC and no-migrate to
be offered ITSC (subject to hardware availability).
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <JBeulich@suse.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Jan Beulich [Tue, 17 May 2016 14:42:15 +0000 (16:42 +0200)]
x86: make SMEP/SMAP suppression tolerate NMI/MCE at the "wrong" time
There is one instruction boundary where any kind of interruption would
break the assumptions cr4_pv32_restore's debug mode checking makes on
the correlation between the CR4 register value and its in-memory cache.
Correct this (see the code comment) even in non-debug mode, or else
a subsequent cr4_pv32_restore would also be misguided into thinking the
features are enabled when they really aren't.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Jan Beulich [Tue, 17 May 2016 14:41:35 +0000 (16:41 +0200)]
x86: refine debugging of SMEP/SMAP fix
Instead of just latching cr4_pv32_mask into %rdx, correct the found
wrong value in %cr4 (to avoid triggering another BUG). The value left
in %rdx should be sufficient for deducing cr4_pv32_mask from the
register dump.
Also there is one more place for XEN_CR4_PV32_BITS to be used.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Jan Beulich [Tue, 17 May 2016 12:41:14 +0000 (14:41 +0200)]
x86/mm: fully honor PS bits in guest page table walks
In L4 entries it is currently unconditionally reserved (and hence
should, when set, always result in a reserved bit page fault), and is
reserved on hardware not supporting 1Gb pages (and hence should, when
set, similarly cause a reserved bit page fault on such hardware).
This is CVE-2016-4480 / XSA-176.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Peng Fan [Thu, 12 May 2016 13:03:08 +0000 (21:03 +0800)]
xen/arm: mm: fix nr_second calculation in setup_frametable_mappings
On ARM64, "frametable_size >> SECOND_SHIFT" computes the number
of second level entries, not the number of second level pages.
"ROUNDUP(frametable_size, FIRST_SIZE) >> FIRST_SHIFT" which computes
the number of the first level entries (the number of second level pages),
is the correct one that should be used.
Signed-off-by: Peng Fan <van.freenix@gmail.com> Reviewed-by: Julien Grall <julien.grall@arm.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Andrew Cooper [Mon, 16 May 2016 10:48:52 +0000 (11:48 +0100)]
x86/compat: Cleanup and further debugging of SMAP/SMEP fixup
* Abstract (X86_CR4_SMEP | X86_CR4_SMAP) behind XEN_CR4_PV32_BITS to avoid
opencoding the invidial bits which are fixed up behind a 32bit PV guests
back.
* In the debug case, perform the the AND and CMP on 64bit values rather than
32bit values, to match the logic in then non-debug case.
* Show cr4_pv32_mask in the BUG register dump
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Jim Fehlig [Thu, 28 Apr 2016 21:20:46 +0000 (15:20 -0600)]
libxl: don't add cache mode for qdisk cdrom drives
qemu commit 91a097e7 forbids specifying cache mode for empty
drives. Attempting to create a domain with an empty qdisk cdrom
drive results in
qemu-system-x86_64: -drive if=ide,index=1,readonly=on,media=cdrom,
cache=writeback,id=ide-832: Must specify either driver or file
libxl only allows an empty 'target=' for cdroms. By default, cdroms
are readonly (see the 'access' parameter in xl-disk-configuration.txt)
and forced to readonly by any tools (e.g. xl) using libxlutil's
xlu_disk_parse() function. With cdroms always marked readonly,
explicitly specifying the cache mode for cdrom drives can be dropped.
The drive's 'readonly=on' option can also be set unconditionally.
Signed-off-by: Jim Fehlig <jfehlig@suse.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Jan Beulich [Fri, 13 May 2016 17:15:34 +0000 (18:15 +0100)]
x86: reduce code size of struct cpu_info member accesses
Instead of addressing these fields via the base of the stack (which
uniformly requires 4-byte displacements), address them from the end
(which for everything other than guest_cpu_user_regs requires just
1-byte ones). This yields a code size reduction somewhere between 8k
and 12k in my builds.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Jan Beulich [Fri, 13 May 2016 17:12:22 +0000 (18:12 +0100)]
x86: suppress SMEP and SMAP while running 32-bit PV guest code
Since such guests' kernel code runs in ring 1, their memory accesses,
at the paging layer, are supervisor mode ones, and hence subject to
SMAP/SMEP checks. Such guests cannot be expected to be aware of those
two features though (and so far we also don't expose the respective
feature flags), and hence may suffer page faults they cannot deal with.
While the placement of the re-enabling slightly weakens the intended
protection, it was selected such that 64-bit paths would remain
unaffected where possible. At the expense of a further performance hit
the re-enabling could be put right next to the CLACs.
Note that this introduces a number of extra TLB flushes - CR4.SMEP
transitioning from 0 to 1 always causes a flush, and it transitioning
from 1 to 0 may also do.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Jan Beulich [Thu, 12 May 2016 16:02:21 +0000 (18:02 +0200)]
x86/PoD: skip eager reclaim when possible
Reclaiming pages is pointless when the cache can already satisfy all
outstanding PoD entries, and doing reclaims in that case can be very
harmful to performance when that memory gets used by the guest, but
only to store zeroes there.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Jan Beulich [Thu, 12 May 2016 12:24:39 +0000 (14:24 +0200)]
Revert "blktap2: Use RING_COPY_REQUEST"
This reverts commit 19f6c522a6a9599317ee1d8c4a155d1400d04c89. It
did wrongly get associated with XSA-155, and was (rightfully) never
backported to any of the stable trees. See also
http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg00571.html.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
xsplice: Unmask (aka reinstall NMI handler) if we need to abort.
If we have to abort in xsplice_spin() we end following
the goto abort. But unfortunataly we neglected to unmask.
This patch fixes that.
Reported-by: Martin Pohlack <mpohlack@amazon.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
George Dunlap [Wed, 11 May 2016 11:14:45 +0000 (12:14 +0100)]
tools/xendomains: Create lockfile on start unconditionally
At the moment, the xendomains init script will only create a lockfile
if when started, it actually does something -- either tries to restore
a previously saved domain as a result of XENDOMAINS_RESTORE, or tries
to create a domain as a result of XENDOMAINS_AUTO.
RedHat-based SYSV init systems try to only call "${SERVICE} shutdown"
on systems which actually have an actively running component; and they
use the existence of /var/lock/subsys/${SERVICE} to determine which
systems are running.
This means that at the moment, on RedHat-based SYSV systems (such as
CentOS 6), if you enable xendomains, and have XENDOMAINS_RESTORE set
to "true", but don't happen to start a VM, then your running VMs will
not be suspended on shutdown.
Since the lockfile doesn't really have any other effect than to
prevent duplicate starting, just create it unconditionally every time
we start the xendomains script.
The other option would have been to touch the lockfile if
XENDOMAINS_RESTORE was true regardless of whether there were any
domains to be restored. But this would mean that if you started with
the xendomains script active but XENDOMAINS_RESTORE set to "false",
and then changed it to "true", then xendomains would still not run the
next time you shut down. This seems to me to violate the principle of
least surprise.
Signed-off-by: George Dunlap <george.dunlap@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Olaf Hering <olaf@aepfle.de> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
George Dunlap [Wed, 11 May 2016 11:14:44 +0000 (12:14 +0100)]
hotplug: Fix xendomains lock path for RHEL-based systems
Commit c996572 changed the LOCKFILE path from a check between two
hardcoded paths (/var/lock/subsys/ or /var/lock) to using the
XEN_LOCK_DIR variable designated at configure time. Since
XEN_LOCK_DIR doesn't (and shouldn't) have the 'subsys' postfix, this
effectively moves all the lock files by default to /var/lock instead.
Unfortunately, this breaks xendomains on RedHat-based SYSV init
systems. RedHat-based SYSV init systems try to only call "${SERVICE}
shutdown" on systems which actually have an actively running
component; and they use the existence of /var/lock/subsys/${SERVICE}
to determine which systems are running.
Changing XEN_LOCK_DIR to /var/lock/subsys is not suitable, as only
system services like xendomains should create lockfiles there; other
locks (such as the console locks) should be created in /var/lock
instead.
Instead, re-instate the check for the subsys/ subdirectory of the lock
directory in the xendomains script.
Signed-off-by: George Dunlap <george.dunlap@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Olaf Hering <olaf@aepfle.de> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Paul Durrant [Mon, 9 May 2016 16:43:14 +0000 (17:43 +0100)]
tools: configure correct trace backend for QEMU
Newer versions of the QEMU source have replaced the 'stderr' trace
backend with 'log'. This patch adjusts the tools Makefile to test for
the 'log' backend and specify it if it is available.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Jan Beulich [Wed, 11 May 2016 07:46:02 +0000 (09:46 +0200)]
XSA-77: widen scope again
As discussed on the hackathon, avoid us having to issue security
advisories for issues affecting only heavily disaggregated tool stack
setups, which no-one appears to use (or else they should step up to get
things into shape).
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Ross Lagerwall [Tue, 10 May 2016 09:10:02 +0000 (10:10 +0100)]
xsplice: Prevent new symbols duplicating core symbols
When loading patches, the code prevents loading a patch containing a new
symbol that duplicates a symbol from another loaded patch. However, the
check should also prevent loading a new symbol that duplicates a symbol
from the core hypervisor.
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Andrew Cooper [Mon, 9 May 2016 13:13:57 +0000 (13:13 +0000)]
x86/hvm: Fix invalidation for emulated invlpg instructions
hap_invlpg() is reachable from the instruction emulator, which means
introspection and tests using hvm_fep can end up here. As such, crashing the
domain is not an appropriate action to take.
Fixing this involves rearranging the callgraph.
paging_invlpg() is now the central entry point. It first checks for the
non-canonical NOP case, and calls ino the paging subsystem. If a real flush
is needed, it will call the appropriate handler for the vcpu. This allows the
PV callsites of paging_invlpg() to be simplified.
The sole user of hvm_funcs.invlpg_intercept() is altered to use
paging_invlpg() instead, allowing the .invlpg_intercept() hook to be removed.
For both VMX and SVM, the existing $VENDOR_invlpg_intercept() is split in
half. $VENDOR_invlpg_intercept() stays as the intercept handler only (which
just calls paging_invlpg()), and new $VENDOR_invlpg() functions do the
ASID/VPID management. These later functions are made available in hvm_funcs
for paging_invlpg() to use.
As a result, correct ASID/VPID management occurs for the hvmemul path, even if
it did not originate from an real hardware intercept.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Tim Deegan <tim@xen.org> Acked-by: George Dunlap <george.dunlap@citrix.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Andrew Cooper [Mon, 9 May 2016 17:09:38 +0000 (18:09 +0100)]
x86/svm: Don't unconditionally use a new ASID in svm_invlpg_intercept()
paging_invlpg() already returns a boolean indicating whether an invalidation
is necessary or not. A return value of 0 indicates that the specified virtual
address wasn't shadowed (or has already been flushed), cannot currently be
cached in the TLB.
This is a performance optimisation.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Tim Deegan <tim@xen.org> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Andrew Cooper [Fri, 22 Apr 2016 08:44:53 +0000 (09:44 +0100)]
x86/hvm: Correct the emulated interaction of invlpg with segments
The `invlpg` instruction is documented to take a memory address, and is not
documented to suffer faults from segmentation violations. It is also
explicitly documented to be a NOP when issued on a non-canonical address.
Experimentally, and subsequently confirmed by both Intel and AMD, the
instruction does take into account segment bases, but will happily invalidate
a TLB entry for a mapping beyond the segment limit.
The emulation logic will currently raise #GP/#SS faults for segment limit
violations, or non-canonical addresses, which doesn't match hardware's
behaviour. Instead, squash exceptions generated by
hvmemul_virtual_to_linear() and proceed with invalidation.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Andrew Cooper [Sat, 7 May 2016 12:41:05 +0000 (13:41 +0100)]
x86/hvm: Raise #SS faults for %ss-based segmentation violations
Raising #GP under such circumstances is architecturally wrong.
Refer to the Intel or AMD manuals describing faults, and the conditions
under which #SS is raised.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Tim Deegan <tim@xen.org> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Andrew Cooper [Tue, 10 May 2016 13:37:00 +0000 (14:37 +0100)]
sched/rt: Fix memory leak in rt_init()
c/s 2656bc7b0 "xen: adopt .deinit_pdata and improve timer handling"
introduced a error path into rt_init() which leaked prv if the
allocation of prv->repl_timer failed.
Introduce an error cleanup path.
Spotted by Coverity.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Meng Xu <mengxu@cis.upenn.edu> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
--- CC: George Dunlap <george.dunlap@eu.citrix.com> CC: Dario Faggioli <dario.faggioli@citrix.com>
Dario Faggioli [Mon, 9 May 2016 14:41:00 +0000 (15:41 +0100)]
xen: adopt .deinit_pdata and improve timer handling
The scheduling hooks API is now used properly, and no
initialization or de-initialization happen in
alloc/free_pdata any longer.
In fact, just like it is for Credit2, there is no real
need for implementing alloc_pdata and free_pdata.
This also made it possible to improve the replenishment
timer handling logic, such that now the timer is always
kept on one of the pCPU of the scheduler it's servicing.
Before this commit, in fact, even if the pCPU where the
timer happened to be initialized at creation time was
moved to another cpupool, the timer stayed there,
potentially inferfering with the new scheduler of the
pCPU itself.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com> Reviewed-and-Tested-by: Meng Xu <mengxu@cis.upenn.edu> Acked-by: George Dunlap <george.dunlap@citrix.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
xen: sched: avoid spuriously re-enabling IRQs in csched2_switch_sched()
interrupts are already disabled when calling the hook
(from schedule_cpu_switch()), so we must use spin_lock()
and spin_unlock().
Add an ASSERT(), so we will notice if this code and its
caller get out of sync with respect to disabling interrupts
(and add one at the same exact occurrence of this pattern
in Credit1 too)
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com> Reviewed-by: George Dunlap <george.dunlap@citrix.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Jan Beulich [Mon, 9 May 2016 11:21:06 +0000 (13:21 +0200)]
IOMMU: don't BUG() on exotic hardware
On x86, iommu_get_ops() BUG()s when running on non-Intel, non-AMD
hardware. While, with our current code, that's a correct prerequisite
assumption for IOMMU presence, this is wrong on systems without IOMMU.
Hence iommu_enabled (and alike) checks should be done prior to calling
that function, not after.
Also move iommu_suspend() next to iommu_resume() - it escapes me why
iommu_do_domctl() had got put between the two.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Roger Pau Monne [Tue, 3 May 2016 10:55:09 +0000 (12:55 +0200)]
xen/xsplice: add ELFOSABI_FREEBSD as a supported OSABI for payloads
The calling convention used by the FreeBSD ELF OSABI is exactly the same as
the the one defined by System V, so payloads with a FreeBSD OSABI should be
accepted by the xsplice machinery.
Specifically "the FreeBSD ELF OSABI only has a meaning for userspace
applications, it's used by FreeBSD in order to detect if an application
is native or if it needs to be run in the linuxator (the Linux emulator,
or any other emulator that is available and matches the ELF OSABI specified
in the binary FWIW).
The only difference from SYSV to FreeBSD OSABI is the sysentvec that's
selected inside of the FreeBSD kernel (the ABI between the kernel and the
user-space application), but of course this doesn't apply to kernel code,
which is what Xen and the xsplice payloads are. Sadly this is not written
anywhere. " And since the ELF tools on FreeBSD by default build with
this - they would stick this OSABI entry.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Wei Liu [Fri, 29 Apr 2016 15:11:17 +0000 (16:11 +0100)]
blktap2: initialise buf in qcow2raw.c:main
Gcc complains:
qcow2raw.c: In function ‘main’:
qcow2raw.c:387:17: error: ‘buf’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
treq.buf = buf;
^
But buf is a valid buffer allocated by posix_memalign at that point.
Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Doug Goldstein <cardoe@cardoe.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Wei Liu [Fri, 29 Apr 2016 15:11:16 +0000 (16:11 +0100)]
blktap2: initialise buf to NULL in img2qcow.c:main
Gcc complains:
qcow2raw.c: In function ‘main’:
qcow2raw.c:387:17: error: ‘buf’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
treq.buf = buf;
^
But at the point of that assignment, buf is a valid buffer allocated by
posix_memalign and filled in by read.
Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Doug Goldstein <cardoe@cardoe.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Wei Liu [Fri, 29 Apr 2016 15:11:15 +0000 (16:11 +0100)]
blktap2: initialise buf in vhd_util_check_footer
Gcc complains:
vhd-util-check.c: In function ‘vhd_util_check_footer’:
vhd-util-check.c:413:2: error: ‘buf’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
memcpy(&backup, buf, sizeof(backup));
In fact buf is initialised a few lines above.
Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Doug Goldstein <cardoe@cardoe.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Wei Liu [Fri, 29 Apr 2016 15:11:14 +0000 (16:11 +0100)]
rombios/tcgbios: initialise logdataptr in HashLogEvent32
Gcc complains:
tcgbios.c: In function ‘HashLogEvent32’:
tcgbios.c:1131:10: error: ‘logdataptr’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
entry = tcpa_extend_acpi_log(logdataptr);
It fails to figure out when logdataptr is used it is always initialised
in a if block a few line above.
Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Doug Goldstein <cardoe@cardoe.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Wei Liu [Fri, 29 Apr 2016 15:11:12 +0000 (16:11 +0100)]
rombios/tcgbios: initialise size in tcpa_extend_acpi_log
Gcc complains:
tcgbios.c:362:3: error: ‘size’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
memcpy((char *)lasa_last, (char *)entry_ptr, size);
It fails to figure out if size is used in memcpy it is always initialised.
Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Doug Goldstein <cardoe@cardoe.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Doug Goldstein [Thu, 5 May 2016 20:18:09 +0000 (15:18 -0500)]
init: shebang should be the first line
The shebang was not on the first line in the init script and it should
be.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Doug Goldstein [Thu, 5 May 2016 20:18:08 +0000 (15:18 -0500)]
init: drop GNU-isms for sleep command
Most implementations of the sleep command only take integers. GNU
coreutils has a GNU extension to allow any floating point number to be
passed but we shouldn't depend on that.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> Signed-off-by: Doug Goldstein <cardoe@cardoe.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Release-acked-by: Wei Liu <wei.liu2@citrix.com>
projects / xen.git / log