xen/arm: Correctly save/restore CNTKCTL_EL1

CNTKCTL_EL1 is used by the guest to control access to the timer from
userspace.  It therefore needs to be save/restored by Xen as part of
the VCPU state.

By default Linux on ARM64 exposes the timer to userspace.  Furthermore on
ARM64, Linux provides helpers in a VDSO (gettimeofday/__do_get_tspec)
that use the timer counter.  Conversely, during CPU bring up, Xen will
set CNTKCTL_EL1 to 0 (i.e disallow timer access to the userspace).  As
a result, currently, if dom0 has 1 VCPU which is migrated to another
PCPU, init might crash.

Alternatively, a guest (malicious or not) might decide to disable
access to the timer from userspace.  If the register is not
save/restored, when a DOM0 VCPU runs again, a similar crash would
result.

Also, drop CNTKCTL_EL1 initialization in init_timer_interrupt.  Xen
should let the guest deal with this register.

This is XSA-91 / CVE-2014-3125.

Reported-by: Chen Baozi <baozich@gmail.com>
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
x86/EPT: consider page order when checking for APIC MFN

This was overlooked in 3d90d6e6 ("x86/EPT: split super pages upon
mismatching memory types").

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Tim Deegan <tim@xen.org>
x86/EPT: refine direct MMIO checking when determining EMT

With need_iommu() only ever true when iommu_enabled is also true, and
with the former getting set when a PCI device gets added to a guest,
the checks can be consolidated. The range set check are left in place
just in case raw MMIO or I/O port ranges get passed to a guest.

At once drop open-coding of cache_flush_permitted().

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Tim Deegan <tim@xen.org>
x86/EPT: fix pinned cache attribute range checking

This wasn't done properly by 4d66f069 ("x86: fix pinned cache attribute
handling"): The passed in GFN shouldn't be assumed to be order aligned.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Tim Deegan <tim@xen.org>
x86/EPT: also force EMT re-evaluation if pinned ranges change

This was inadvertently left out of aa9114ed ("x86/EPT: force
re-evaluation of memory type as necessary"). Note that this
intentionally doesn't use memory_type_changed(): Changes to the pinned
ranges are independent of IOMMU presence, which that function uses to
determine whether to call the underlying p2m_memory_type_changed().

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Tim Deegan <tim@xen.org>
x86/EPT: flush cache when (potentially) limiting cachability

While generally such guest side changes ought to be followed by guest
initiated flushes, we're flushing the cache under similar conditions
elsewhere (e.g. when the guest sets CR0.CD), so let's do so here too.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
x86/HVM: clean up HVMOP_set_mem_type processing

- drop unused variable "mfn"
- consistently do not use "else" when the prior "if" ends in "goto"
- use printk() referencing the target domain instead of gdprintk()
  (which references the current domain) and slightly shorten message
- annotate -EINVAL results in paging/shared paths to actually need
  switching to -EAGAIN (possible only when preemption logic got fixed
  to use -ERESTART)

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
tmem: drop unnecessary lock in tmem_relinquish_pages()

CID 1150562

tmem_rwlock is unnecessary in tmem_relinquish_pages(), as
such lock is used as gate for hypercalls. However
tmem_relinquish_pages deals with pages that are no longer
owned by any domain - hence there is no need for tmem_rwlock.

Also the function is protected by the 'heap_lock' which
is the only calleer of this function.

This patch drops said lock.

Signed-off-by: Bob Liu <bob.liu@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
hvm_set_ioreq_page() releases wrong page in error path

The function calls prepare_ring_for_helper() to acquire a mapping for the
given gmfn, then checks (under lock) to see if the ioreq page is already
set up but, if it is, the function then releases the in-use ioreq page
mapping on the error path rather than the one it just acquired. This patch
fixes this bug.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
amd, maintainers: Update MAINTAINERS file

Add self as co-maintainer for AMD specific components.

Signed-off-by: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
Acked-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
x86/EPT: don't walk entire page tables when globally changing types

Instead leverage the EPT_MISCONFIG VM exit by marking just the top
level entries as needing recalculation of their type, propagating the
the recalculation state down as necessary such that the actual
recalculation gets done upon access.

For this to work, we have to
- restrict the types between which conversions can be done (right now
  only the two types involved in log dirty tracking need to be taken
  care of)
- remember the ranges that log dirty tracking was requested for as well
  as whether global log dirty tracking is in effect

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
x86/EPT: don't walk page tables when changing types on a range

This requires a new P2M backend hook and a little bit of extra care on
accounting in the generic function.

Note that even on leaf entries we must not immediately set the new
type (in an attempt to avoid the EPT_MISCONFIG VM exits), since the
global accounting in p2m_change_type_range() gets intentionally done
only after updating page tables (or else the update there would
conflict with the function's own use of p2m_is_logdirty_range()), and
the correct type can only be calculated with that in place.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
x86/NPT: don't walk page tables when changing types on a range

This builds on the fact that in order for no NPF VM exit to occur,
_PAGE_USER must always be set. I.e. by clearing the flag we can force a
VM exit allowing us to do similar lazy type changes as on EPT.

That way, the generic entry-wise code can go away, and we could remove
the range restriction in enforced on HVMOP_track_dirty_vram for XSA-27.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
x86/NPT: don't walk entire page tables when globally changing types

Instead leverage the NPF VM exit enforcement by marking just the top
level entries as needing recalculation of their type, building on the
respective range type change modifications.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
libxc: allow changing max number of hypervisor cpuid leaves

Add support for changing max number of hypervisor leaves from configuration
file.

This number can be specified using xl's standard 'cpuid' option. Only lowest
8 bits of leaf's 0x4000xx00 eax register are processed, all others are ignored.

The changes allow us to revert commit 80ecb40362365ba77e68fc609de8bd3b7208ae19
which is most likely no longer needed now anyway (Solaris bug that it addressed
has been fixed and backported to earlier releases) but leave possibility of
running unpatched version of Solaris by forcing number of leaves to 2 in the
configuration file.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
x86/hvm: add HVM-specific hypervisor CPUID leaf

CPUID leaf 0x40000004 is for HVM-specific features.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-off-by: Jan Beulich <jbeulich@suse.com>
x86/hvm: indicate avaliability of HW support of APIC virtualization to HVM guests

Set bits in hypervisor CPUID leaf indicating that HW provides (and the
hypervisor enables) HW support for APIC and x2APIC virtualization.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-off-by: Jan Beulich <jbeulich@suse.com>
x86: fix guest CPUID handling

The way XEN_DOMCTL_set_cpuid got handled so far allowed for surprises
to the caller. With this set of operations
- set leaf A (using array index 0)
- set leaf B (using array index 1)
- clear leaf A (clearing array index 0)
- set leaf B (using array index 0)
- clear leaf B (clearing array index 0)
the entry for leaf B at array index 1 would still be in place, while
the caller would expect it to be cleared.

While looking at the use sites of d->arch.cpuid[] I also noticed that
the allocation of the array needlessly uses the zeroing form - the
relevant fields of the array elements get set in a loop immediately
following the allocation.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
domctl: perform initial post-XSA-77 auditing

In a number of cases, loops over each vCPU in a domain are involved
here. For large numbers of vCPU-s these may still take some time to
complete, but we're limiting them at a couple of thousand at most, so I
would think this should not by itself be an issue. I wonder though
whether it shouldn't be possible to have XSM restrict the vCPU count
that can be set through XEN_DOMCTL_max_vcpus.

XEN_DOMCTL_pausedomain:

 A loop over vcpu_sleep_sync() for each of vCPU in the domain. That
 function itself has a loop waiting for the subject vCPU to become non-
 runnable, which ought to complete quickly (involving an IPI to be sent
 and acted on). No other unbounded resource usage.

XEN_DOMCTL_unpausedomain:

 Simply a loop calling vcpu_wake() (not having any loops or other
 resource usage itself) for each of vCPU in the domain.

XEN_DOMCTL_getdomaininfo:

 Two loops (one over all domains, i.e. bounded by the limit of 32k
 domains, and another over all vCPU-s in the domain); no other
 unbounded resource usage.

XEN_DOMCTL_getpageframeinfo:

 Inquiring just a single MFN, i.e. no loops and no other unbounded
 resource usage.

XEN_DOMCTL_getpageframeinfo{2,3}:

 Number of inquired MFNs is limited to 1024. Beyond that just like
 XEN_DOMCTL_getpageframeinfo.

XEN_DOMCTL_getvcpuinfo:

 Only obtaining information on the vCPU, no loops or other resource
 usage.

XEN_DOMCTL_setdomainhandle:

 Simply a memcpy() of a very limited amount of data.

XEN_DOMCTL_setdebugging:

 A domain_{,un}pause() pair (see XEN_DOMCTL_{,un}pausedomain) framing
 the setting of a flag.

XEN_DOMCTL_hypercall_init:

 Initializing a guest provided page with hypercall stubs. No other
 resource consumption.

XEN_DOMCTL_arch_setup:

 IA64 leftover, interface structure being removed from the public
 header.

XEN_DOMCTL_settimeoffset:

 Setting a couple of guest state fields. No other resource consumption.

XEN_DOMCTL_getvcpuaffinity:
XEN_DOMCTL_getnodeaffinity:

 Involve temporary memory allocations (approximately) bounded by the
 number of CPUs in the system / number of nodes built for, which is
 okay. Beyond that trivial operation.

XEN_DOMCTL_real_mode_area:

 PPC leftover, interface structure being removed from the public
 header.

XEN_DOMCTL_resumedomain:

 A domain_{,un}pause() pair framing operation very similar to
 XEN_DOMCTL_unpausedomain (see above).

XEN_DOMCTL_sendtrigger:

 Injects an interrupt (SCI or NMI) without any other resource
 consumption.

XEN_DOMCTL_subscribe:

 Updates the suspend event channel, i.e. affecting only the controlled
 domain.

XEN_DOMCTL_disable_migrate:
XEN_DOMCTL_suppress_spurious_page_faults:

 Just setting respective flags on the domain.

XEN_DOMCTL_get_address_size:

 Simply reading the guest property.

XEN_DOMCTL_set_opt_feature:

 Was already tagged IA64-only.

XEN_DOMCTL_set_cpuid:

 MAX_CPUID_INPUT bounded loop, which is okay. No other resource
 consumption.

XEN_DOMCTL_get_machine_address_size:

 Simply obtaining the value set by XEN_DOMCTL_set_machine_address_size
 (or the default set at domain creation time).

XEN_DOMCTL_gettscinfo:
XEN_DOMCTL_settscinfo:

 Reading/writing of a couple of guest state fields wrapped in a
 domain_{,un}pause() pair.

XEN_DOMCTL_audit_p2m:

 Enabled only in debug builds.

XEN_DOMCTL_set_max_evtchn:

 While the limit set here implies other (subsequent) resource usage,
 this is the purpose of the operation.

I also verified that all removed domctls' handlers don't leak
hypervisor memory contents .

Inspected but questionable (and hence left in place for now):

XEN_DOMCTL_max_mem:

 While only setting the field capping a domain's allocation (this
 implies potential successive resource usage, but that's the purpose of
 the operation). However, XSM doesn't see the value that's being set
 here, so the net effect would be potential unbounded memory use.

XEN_DOMCTL_set_virq_handler:

 This modifies a global array. While that is the purpose of the
 operation, if multiple domains are granted permission they can badly
 interfere with one another. Hence I'd appreciate a second opinion
 here. [Andrew confirms that this being the nature of the operation,
 it's fine to be removed from the list - will be done in a 2nd round.]

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
xen/arm: timer: replace timer_dt_irq by timer_get_irq

The function is nearly only used to retrieve the IRQ number.

There is one place where the IRQ type is used (in domain_build.c) but
as the timer IRQ is virtualised for guest we might not have the same property
(e.g active-low level sensitive interrupt).

Replace timer_dt_irq by timer_get_irq which will return the IRQ number.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>