xen/arm: Inject an undefined instruction when the coproc/sysreg is not handled

Currently Xen panics if it's unable to handle a coprocessor/sysreg instruction.
Replace this behavior by inject an undefined instruction to the faulty guest
and log if Xen is in debug mode.

This is CVE-2014-2915 / XSA-93.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xen/arm: Don't let the guest access the coprocessors registers

In Xen we only handle save/restore for coprocessor 10 and 11 (NEON). Other
coprocessors (0-9, 12-13) are currently exposed to the guest and may lead
to data shared between guest.

Disable access to all coprocessor except 10 and 11 by setting correctly
HCTPR.

This is CVE-2014-2915 / XSA-93.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xen/arm: Upgrade DCISW into DCCISW

A guest is allowed to use invalidate cache by set/way instruction (i.e DCISW)
without any restriction. As the cache is shared with Xen, the guest invalidate
an address being in used by Xen. This may lead a Xen crash because the memory
state is invalid.
Set the bit HCR.SWIO to upgrade invalidate cache by set/way instruction to an
invalidate and clean.

This is CVE-2014-2915 / XSA-93.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
Reported-by: Thomas Leonard <tal36@cam.ac.uk>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xen/arm: Trap cache and TCM lockdown registers

Some cp15 c9/c10/c11 encodings are used for:
     - cache control
     - TCM control
     - branch predictor control

All of them are implementation defined. For now inject an undefined exception
if the guest wants try to access it.

This is CVE-2014-2915 / XSA-93.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xen/arm: Don't expose implementation defined registers (Cp15 c15) to the guest

On Cortex-A15, CP15 c15 contains registers to retrieve data from L1/L2 RAM.

Exposing this registers to guest may result to leak data from Xen and/or
another guest.

By default trap every registers and inject an undefined instruction.

This is CVE-2014-2915 / XSA-93.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xen/arm: Don't let guess access to Debug and Performance Monitor registers

Debug and performance registers are not properly switched by Xen.

Trap them and inject an undefined instruction, except for those registers
which might be unconditionally accessed which we implement as RAZ/WI.

This is CVE-2014-2915 / XSA-93.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
x86/mm: fix checks against max_mapped_pfn

This value is an inclusive one, i.e. this fixes an off-by-one in memory
sharing and an off-by-two in shadow code.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
master commit: 088ee1d47b65d6bb92de61b404805f4ca92e3240
master date: 2014-04-03 12:08:43 +0100
xen: x86 & generic: change to __builtin_prefetch()

Quoting Andi Kleen in Linux b483570a13be from 2007:
    gcc 3.2+ supports __builtin_prefetch, so it's possible to use it on all
    architectures. Change the generic fallback in linux/prefetch.h to use it
    instead of noping it out. gcc should do the right thing when the
    architecture doesn't support prefetching

    Undefine the x86-64 inline assembler version and use the fallback.

ARM wants to use the builtins.

Fix a pair of spelling errors, one of which was from Lucas De Marchi in the
Linux tree.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Acked-by: Tim Deegan <tim@xen.org>
master commit: 630017f420f111e0c0332dbd99df30ebb8fed207
master date: 2014-04-03 17:15:41 +0100
xen/arm: vgic: Check rank in GICD_ICFGR* emulation before locking

The function vgic_irq_rank may return NULL is the IRQ is not in range handled
by the guest. This will result to derefence a NULL pointer which will crash
Xen.

I've checked the rest of the emulation and this is only place where the lock
is taken before the rank is checked.

This is CVE-2014-2986 / XSA-94.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
Reported-by: Thomas Leonard <talex5@gmail.com>
Reviewed-by: Jan Beulich <JBeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xen/arm: domain_vgic_init: Check xzalloc_* return

The allocations for shared_irqs and pending_irqs are not checked and use
later. This may lead to a Xen segfault if the hypervisor run out of memory.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
(cherry picked from commit a34f6affe799cf493640b58a794132d213288ba3)
xen: arm: prevent building with CONFIG_EARLY_PRINTK if not a debug build

early printk on ARM is tied to debug being enabled, so error out instead of silently and unexpectedly building without early printk when asked.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
(cherry picked from commit 5940d3d095661f541a843e5d4c5f9363c18cd63c)
xen/arm64: Correctly align VFP regs

On arm64, VFP instructions requires vfpregs to be 128-byte aligned.

By chance, the field is already correctly aligned. In the case if someone
decides to add a new field before, Xen will receive a data abort as soon as
it saves/restores VFP.

We are safe on arm32 as the only constraint is to be 32-byte aligned.

Reported-by: Chen Baozi <baozich@gmail.com>
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
(cherry picked from commit 9b4e96724eeb916f2cd311d9133f00c216caa321)
x86/HVM: restrict HVMOP_set_mem_type

Permitting arbitrary type changes here has the potential of creating
present P2M (and hence EPT/NPT/IOMMU) entries pointing to an invalid
MFN (INVALID_MFN truncated to the respective hardware structure field's
width). This would become a problem the latest when something real sat
at the end of the physical address space; I'm suspecting though that
other things might break with such bogus entries.

Along with that drop a bogus (and otherwise becoming stale) log
message.

Afaict the similar operation in p2m_set_mem_access() is safe.

This is XSA-92.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
master commit: 83bb5eb4d340acebf27b34108fb1dae062146a68
master date: 2014-04-29 15:11:31 +0200
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/AMD: feature masking is unavailable on Fam11

Reported-by: Aravind Gopalakrishnan<aravind.gopalakrishnan@amd.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 70e79fad6dc6f533ff83ee23b8d13de5a696d896
master date: 2014-04-09 16:13:25 +0200
x86/nested HAP: don't BUG() on legitimate error

p2m_set_entry() can fail without there being a bug in the code - crash
the domain rather than the host in that case.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
master commit: 1ca73aaf51eba14256794bf045c2eb01e88e1324
master date: 2014-04-14 12:50:56 +0200
x86/HAP: also flush TLB when altering a present 1G or intermediate entry

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
master commit: c82fbfe6ec8be597218eb943641d1f7a81c4c01e
master date: 2014-04-14 15:14:47 +0200
x86: add missing break in dom0_pit_access()

Coverity ID 1203045

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 815dc9f1dba5782dcef77d8a002a11f5b1e5cc37
master date: 2014-04-23 15:07:11 +0200
VT-d: suppress UR signaling for server chipsets

Unsupported Requests can be signaled for malformed writes to the MSI
address region, e.g. due to buggy or malicious DMA set up to that
region. These should normally result in IOMMU faults, but don't on
the server chipsets dealt with here.

IDs 0xe00, 0xe01, and 0xe04 ... 0xe0b (Ivytown) aren't needed here -
Intel confirmed the issue to be fixed in hardware there.

This is CVE-2013-3495 / XSA-59.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Don Dugger <donald.d.dugger@intel.com>
Acked-by: Tim Deegan <tim@xen.org>
Acked-by: Xiantao Zhang <xiantao.zhang@intel.com>
master commit: d061d200eb92bcb1d86f9b55c6de73e35ce63fdf
master date: 2014-04-25 12:11:55 +0200
VT-d: suppress UR signaling for desktop chipsets

Unsupported Requests can be signaled for malformed writes to the MSI
address region, e.g. due to buggy or malicious DMA set up to that
region. These should normally result in IOMMU faults, but don't on
the desktop chipsets dealt with here.

This is CVE-2013-3495 / XSA-59.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Don Dugger <donald.d.dugger@intel.com>
Acked-by: Tim Deegan <tim@xen.org>
Acked-by: Xiantao Zhang <xiantao.zhang@intel.com>
master commit: d6cb14b34ffc2a830022d059f1aa22bf19dcf55f
master date: 2014-04-25 12:12:38 +0200