x86: limit checks in hypercall_xlat_continuation() to actual arguments

HVM/PVH guests can otherwise trigger the final BUG_ON() in that
function by entering 64-bit mode, setting the high halves of affected
registers to non-zero values, leaving 64-bit mode, and issuing a
hypercall that might get preempted and hence become subject to
continuation argument translation (HYPERVISOR_memory_op being the only
one possible for HVM, PVH also having the option of using
HYPERVISOR_mmuext_op). This issue got introduced when HVM code was
switched to use compat_memory_op() - neither that nor
hypercall_xlat_continuation() were originally intended to be used by
other than PV guests (which can't enter 64-bit mode and hence have no
way to alter the high halves of 64-bit registers).

This is CVE-2014-8866 / XSA-111.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
x86/HVM: confine internally handled MMIO to solitary regions

While it is generally wrong to cross region boundaries when dealing
with MMIO accesses of repeated string instructions (currently only
MOVS) as that would do things a guest doesn't expect (leaving aside
that none of these regions would normally be accessed with repeated
string instructions in the first place), this is even more of a problem
for all virtual MSI-X page accesses (both msixtbl_{read,write}() can be
made dereference NULL "entry" pointers this way) as well as undersized
(1- or 2-byte) LAPIC writes (causing vlapic_read_aligned() to access
space beyond the one memory page set up for holding LAPIC register
values).

Since those functions validly assume to be called only with addresses
their respective checking functions indicated to be okay, it is generic
code that needs to be fixed to clip the repetition count.

To be on the safe side (and consistent), also do the same for buffered
I/O intercepts, even if their only client (stdvga) doesn't put the
hypervisor at risk (i.e. "only" guest misbehavior would result).

This is CVE-2014-8867 / XSA-112.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
x86: disable VPMU for PVH guests

Currently when VPMU is enabled on a system both HVM and PVH VPCUs will
initialize their VPMUs, including setting up vpmu_ops. As result even
though VPMU will not work for PVH guests (APIC is not supported there),
the guest may decide to perform a write to a PMU MSR. This will cause a
call to is_vlapic_lvtpc_enabled() which will crash the hypervisor, e.g.:

 (XEN) Xen call trace:
 (XEN)    [<ffff82d0801ca06f>] is_vlapic_lvtpc_enabled+0x13/0x22
 (XEN)    [<ffff82d0801e2a15>] core2_vpmu_do_wrmsr+0x415/0x589
 (XEN)    [<ffff82d0801cedaa>] vpmu_do_wrmsr+0x2a/0x33
 (XEN)    [<ffff82d0801dd648>] vmx_msr_write_intercept+0x268/0x557
 (XEN)    [<ffff82d0801bcd2e>] hvm_msr_write_intercept+0x36c/0x39b
 (XEN)    [<ffff82d0801e0a0e>] vmx_vmexit_handler+0x1082/0x185b
 (XEN)    [<ffff82d0801e74c1>] vmx_asm_vmexit_handler+0x41/0xc0

If we prevent VPMU from being initialized on PVH guests we will avoid
those accesses.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
x86/PVH: properly disable vLAPIC

Rather than guarding higher level operations (like vPMU initialization
as suggested by Boris in
http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg02278.html)
mark the vLAPIC hardware disabled for PVH guests and prevent it from
getting moved out of this state.

Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
xsm/flask: add two missing domctls

Reported-by: Michael Young <m.a.young@durham.ac.uk>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
docs/commandline: Refresh document for 4.5

* Add options whose code has been committed (without a patch to this file).
* Remove options which have been deleted (without a patch to this file).
* Tweak some formatting for consistency.
* Nuke some trailing whitespace.

I believe this document now identifies the exact set of command line options
accepted by Xen, for both x86 and ARM architectures.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>