... unless they're part of a fully separate pool (and hence can't ever
be used for guest allocations).
This is CVE-2014-4021 / XSA-100.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: 4bd78937ec
master date: 2014-06-17 15:21:10 +0200
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: 83bb5eb4d3
master date: 2014-04-29 15:11:31 +0200
menuentry in grub2/grub.cfg uses linux16 and initrd16 commands
instead of linux and initrd. Due to this RHEL 7 (beta) guest failed to
boot after the installation.
In addition to this, RHEL 7 menu entries have two different single-quote
delimited strings on the same line, and the greedy grouping for menuentry
parsing gets both strings, and the options inbetween.
Signed-off-by: Joby Poriyath <joby.poriyath@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: george.dunlap@citrix.com
(cherry picked from commit dd03048708)
(cherry picked from commit 607d9c98e8)
(cherry picked from commit 4481b30d5e)
(cherry picked from commit 8320ab88bf)
Processing up to 4G PFNs may take almost arbitrarily long, so
preemption is needed here.
This is CVE-2014-2599 / XSA-89.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
The original change went into a 64-bit only code section, thus leaving
the issue unfixed on 32-bit. Re-order code to address this.
This is part of CVE-2013-6885 / XSA-82.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
Avoid freeing info then returning it to the caller.
This is XSA-88.
Coverity-ID: 1056192
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
(cherry picked from commit d883c179a7)
Other than in 4.2 and newer, we're not having an overflow issue here,
but uncontrolled exposure of the operations opens the host to be driven
out of memory by an arbitrary guest. Since all operations other than
FLASK_LOAD simply deal with ASCII strings, limiting the allocations
(and incoming buffer sizes) to a page worth of memory seems like the
best thing we can do.
Consequently, in order to not expose the larger allocation to arbitrary
guests, the permission check for FLASK_LOAD needs to be pulled ahead of
the allocation (and it's perhaps worth noting that - afaict - it was
pointlessly done with the sel_sem spin lock held).
Note that this breaks FLASK_AVC_CACHESTATS on systems with sufficiently
many CPUs (as requiring a buffer bigger than PAGE_SIZE there). No
attempt is made to address this here, as it would needlessly complicate
this fix with rather little gain.
This is XSA-84.
Reported-by: Matthew Daley <mattd@bugfuzz.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
The index of boolean variables in FLASK_{GET,SET}BOOL was not always
checked against the bounds of the array.
Reported-by: John McDermott <john.mcdermott@nrl.navy.mil>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Yet this wasn't being enforced.
This is XSA-87.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 9c7e789a1b
master date: 2014-01-24 13:41:36 +0100
This patch solves XSA-60 security hole:
1. For guest w/o VT-d, and for guest with VT-d but snooped, Xen need
do nothing, since hardware snoop mechanism has ensured cache coherency.
2. For guest with VT-d but non-snooped, cache coherency can not be
guaranteed by h/w snoop, therefore it need emulate UC type to guest:
2.1). if it works w/ Intel EPT, set guest IA32_PAT fields as UC so that
guest memory type are all UC.
2.2). if it works w/ shadow, drop all shadows so that any new ones would
be created on demand w/ UC.
This patch also fix a bug of shadow cr0.cd setting. Current shadow has a
small window between cache flush and TLB invalidation, resulting in possilbe
cache pollution. This patch pause vcpus so that no vcpus context involved
into the window.
This is CVE-2013-2212 / XSA-60.
Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jun Nakajima <jun.nakajima@intel.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: 62652c00ef
master date: 2013-11-06 10:12:36 +0100
XSA-60 security hole comes from the problematic vmx_set_uc_mode.
This patch remove vmx_set_uc_mode logic, which will be replaced by
PAT approach at later patch.
This is CVE-2013-2212 / XSA-60.
Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Acked-by: Jun Nakajima <jun.nakajima@intel.com>
master commit: 1c84d04673
master date: 2013-11-06 10:12:00 +0100
Recently Oracle developers found a Xen security issue as DOS affecting,
named as XSA-60. Please refer http://xenbits.xen.org/xsa/advisory-60.html
Basically it involves how to handle guest cr0.cd setting, which under
some environment it consumes much time resulting in DOS-like behavior.
This is a preparing patch for fixing XSA-60. Later patch will fix XSA-60
via PAT under Intel EPT case, which depends on cpu_has_vmx_pat.
This is CVE-2013-2212 / XSA-60.
Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Acked-by: Jun Nakajima <jun.nakajima@intel.com>
master commit: c13b0d65dd
master date: 2013-11-06 10:11:18 +0100
The recommendation is to set a bit in an MSR - do this if the firmware
didn't, considering that otherwise we expose ourselves to a guest
induced DoS.
This is CVE-2013-6885 / XSA-82.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
master commit: 98162f256e
master date: 2013-12-03 09:49:54 +0100
Anything else would allow for privilege escalation.
This is CVE-2013-4554 / XSA-76.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
master commit: 5c447caaf4
master date: 2013-11-27 09:01:49 +0100
Coverity ID 1055652
(See the code comment.)
This is CVE-2013-4553 / XSA-74.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
master commit: 19f027cc5d
master date: 2013-11-27 09:00:41 +0100
Coverity ID 1087189
Correct a lock order reversal between a domains page allocation and grant
table locks.
This is CVE-2013-4494 / XSA-73.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Consolidate error handling.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Keir Fraser <keir@xen.org>
Tested-by: Matthew Daley <mattjd@gmail.com>
master commit: a321abc6d8
master date: 2013-11-04 10:06:36 +0100
This fixes the issue for both C and ocaml xenstored, however only the ocaml
xenstored is vulnerable in its default configuration.
Adding a new error appears to be safe, since bit libxenstore and the Linux
driver at least treat an unknown error code as EINVAL.
This is XSA-72 / CVE-2013-4416.
Original ocaml patch by Jerome Maloberti <jerome.maloberti@citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Thomas Sanders <thomas.sanders@citrix.com>
master commit: 8b2c441a1b
master date: 2013-10-29 15:45:53 +0000
When emulating such an operation from a 64-bit context (CS has long
mode set), and the data segment is overridden to FS/GS, the result of
reading the overridden segment's descriptor (read_descriptor) is not
checked. If it fails, data_base is left uninitialized.
This can lead to 8 bytes of Xen's stack being leaked to the guest
(implicitly, i.e. via the address given in a #PF).
Coverity-ID: 1055116
This is CVE-2013-4368 / XSA-67.
Signed-off-by: Matthew Daley <mattjd@gmail.com>
Fix formatting.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
master commit: 0771faba16
master date: 2013-10-10 15:19:53 +0200
Ignoring them generally implies using uninitialized data and, in all
but two of the cases dealt with here, potentially leaking hypervisor
stack contents to guests.
This is CVE-2013-4355 / XSA-63.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 6bb838e737
master date: 2013-09-30 14:17:46 +0200
In order to avoid leaking register contents from the prior use of the
registers restored through xrstor due to a guest enabling certain xcr0
bits late (particularly after the context restor in question), force
restoring of all known registers (the ones that never got saved would
be forced to their init state).
This is CVE-2013-1442 / XSA-62.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 63a75ba0de
master date: 2013-09-25 10:41:25 +0200
This change:
070ab4c505
"oxenstored: Protect oxenstored from malicious domains"
broke the build because it had an unresolved semantic (but not
textual) conflict with
c69fddbd5d
"tools/ocaml: Remove log library from tools/ocaml/libs"
(which is in 4.2 but not 4.1)
Fix this by using the 4.1.x idiom in the new error handling introduced
in 070ab4c505.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: David Scott <dave.scott@eu.citrix.com>
We shouldn't accept IVHD tables specifying IO-APIC IDs beyond the limit
we support (MAX_IO_APICS, currently 128).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Suravee Suthikulpanit <suravee.suthikulapanit@amd.com>
master commit: 3785d30efe
master date: 2013-08-29 09:31:37 +0200
... as being insecure.
Also drop the second (redundant) read DMAR_GSTS_REG from enable_intremap().
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by Xiantao Zhang <xiantao.zhang@intel.com>
master commit: c9c6abab58
master date: 2013-08-21 16:44:58 +0200
add check logic when read from IO ring, and if error happens,
then mark the reading connection as "bad", Unless vm reboot,
oxenstored will not handle message from this connection any more.
xs_ring_stubs.c: add a more strict check on ring reading
connection.ml, domain.ml: add getter and setter for bad flag
process.ml: if exception raised when reading from domain's ring,
mark this domain as "bad"
xenstored.ml: if a domain is marked as "bad", do not handle it.
Signed-off-by: John Liu <john.liuqiming@huawei.com>
Acked-by: David Scott <dave.scott@eu.citrix.com>
(cherry picked from commit 704302ce94)
(cherry picked from commit a978634bee)
Conflicts:
tools/ocaml/xenstored/domain.ml
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
(cherry picked from commit 9f93027afd)
commit 6859874b61 ("x86/HVM: fix x2APIC
APIC_ID read emulation") introduced an error for the hvm emulation of
x2apic. Any try to write to APIC_ICR MSR will result in a GP fault.
Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
master commit: 69962e19ed
master date: 2013-08-22 11:24:00 +0200
On *BSD, stdbool.h lives in /usr/include, but we don't want to have
that on the search path in case we pick up any headers from the build
host's C libraries.
Copy the equivalent hack already in place for stdarg.h: on all
supported compilers the contents of stdbool.h are trivial, so just
supply the things we need in a xen/stdbool.h header.
Signed-off-by: Tim Deegan <tim@xen.org>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Tested-by: Patrick Welche <prlw1@cam.ac.uk>
master commit: 7b9685ca4e
master date: 2013-08-15 22:00:45 +0100
Extracted from Yinghai Lu's Linux commit d5c78673 ("x86: Fix /proc/mtrr
with base/size more than 44bits").
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: f67af6d580
master date: 2013-08-14 11:20:26 +0200
This fixes the clang build, and has no effect on gcc's output.
Signed-off-by: Tim Deegan <tim@xen.org>
Committed-by: Jan Beulich <jbeulich@suse.com>
master commit: 59a28b5f04
master date: 2013-02-14 14:20:06 +0100
Note that this isn't just a build fix - if the "delta" input ends up
in memory, gas would default to 32-bit operand size (and should really
warn about the ambiguity).
domain_set_time_offset() udpates d->time_offset_seconds, but does not correct
the wallclock in the shared info, meaning that it is incorrect until the next
XENPF_settime hypercall from dom0 which resynchronises the wallclock for all
domains.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: 915a59f25c
master date: 2013-07-18 09:16:15 +0200
Dom0 uses this hypercall to pass ACPI information to Xen. It is not very
uncommon for more cpus to be listed in the ACPI tables than are present on the
system, particularly on systems with a common BIOS for a 2 and 4 socket server
varients.
As Dom0 does not control the number of entries in the ACPI tables, and is
required to pass everything it finds to Xen, change the logging.
There is now an single unconditional warning for the first unknown ID, and
further warnings if "cpuinfo" is requested by the user on the command line.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 85047d9e4f
master date: 2013-07-17 08:45:20 +0200
While debugging the issue which turned out to be XSA-58, a printk in this loop
showed that it was quite easy to never make useful progress, because of
consistently failing the preemption check.
One single l2 entry is a reasonable amount of work to do, even if an action is
pending, and also assures forwards progress across repeat continuations.
Tweak the continuation criteria to fail on the first iteration of the loop.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: d3a55d7d9b
master date: 2013-07-04 10:33:18 +0200
If there is a single colon for a given target and the target
is redefined in another place (e.g. in included file) then
make executes only new target and displays following warning:
Makefile:35: warning: overriding commands for target `clean'
tools/libfsimage/common/../../../tools/libfsimage/Rules.mk:25:
warning: ignoring old commands for target `clean'
To cope with that issue define all required targets as double-colon
rules. Additionally, remove some redundant stuff.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
(cherry picked from commit 667d8a84b2)
Booting a fedora 19 domU failed because a it could not properly
parse the grub.cfg file. This was cased by
set default="${next_entry}"
This statement actually is within an 'if' statement, so maybe it would
be better to skip code within if/fi blocks...
But this patch seems to work fine.
Signed-off-by: Marcel Mol <marcel@mesa.nl>
Acked-by: Ian Campbell <ian.campbell@citix.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
(cherry picked from commit d513814db6)
The IOMMU interrupt handling in bottom half must clear the PPR log interrupt
and event log interrupt bits to re-enable the interrupt. This is done by
writing 1 to the memory mapped register to clear the bit. Due to hardware bug,
if the driver tries to clear this bit while the IOMMU hardware also setting
this bit, the conflict will result with the bit being set. If the interrupt
handling code does not make sure to clear this bit, subsequent changes in the
event/PPR logs will no longer generating interrupts, and would result if
buffer overflow. After clearing the bits, the driver must read back
the register to verify.
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Adjust to apply on top of heavily modified patch 1. Adjust flow to get away
with a single readl() in each instance of the status register checks.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
master commit: 9eabb07354
master date: 2013-07-02 08:50:41 +0200
The IOMMU interrupt bits in the IOMMU status registers are
"read-only, and write-1-to-clear (RW1C). Therefore, the existing
logic which reads the register, set the bit, and then writing back
the values could accidentally clear certain bits if it has been set.
The correct logic would just be writing only the value which only
set the interrupt bits, and leave the rest to zeros.
This patch also, clean up #define masks as Jan has suggested.
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
With iommu_interrupt_handler() properly having got switched its readl()
from status to control register, the subsequent writel() needed to be
switched too (and the RW1C comment there was bogus).
Some of the cleanup went too far - undone.
Further, with iommu_interrupt_handler() now actually disabling the
interrupt sources, they also need to get re-enabled by the tasklet once
it finished processing the respective log. This also implies re-running
the tasklet so that log entries added between reading the log and re-
enabling the interrupt will get handled in a timely manner.
Finally, guest write emulation to the status register needs to be done
with the RW1C (and RO for all other bits) semantics in mind too.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
master commit: 2823a0c7df
master date: 2013-07-02 08:49:43 +0200
This mostly reverts commit eb60be3d ("x86: don't pass negative time to
gtime_to_gtsc()") and instead corrects __update_vcpu_system_time()'s
handling of this_cpu(cpu_time).stime_local_stamp dating back before the
start of a HVM guest (which would otherwise lead to a negative value
getting passed to gtime_to_gtsc(), causing scale_delta() to produce
meaningless output).
Flushing the value to zero was wrong, and printing a message for
something that can validly happen wasn't very useful either.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: 5ad914bc86
master date: 2013-07-02 08:48:03 +0200
XSA-36 changed the default vector map mode from global to per-device. This is
because a global vector map does not prevent one PCI device from impersonating
another and launching a DoS on the system.
However, the per-device vector map logic is broken for devices with multiple
MSI-X vectors, which can either result in a failed ASSERT() or misprogramming
of a guests interrupt remapping tables. The core problem is not trivial to
fix.
In an effort to get AMD systems back to a non-regressed state, introduce a new
type of vector map called per-device-global. This uses per-device vector maps
in the IOMMU, but uses a single used_vector map for the core IRQ logic.
This patch is intended to be removed as soon as the per-device logic is fixed
correctly.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
master commit: f0fe822762
master date: 2013-06-27 14:01:18 +0200
Printing them as decimal number, the more with 0x prefix, is confusing
and presumably relatively useless to most of us.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
master commit: 59912eb06f
master date: 2013-06-26 14:43:52 +0100
Ian Jackson
Jan Beulich
Joby Poriyath
Andrew Cooper
Liu Jinsong
Ian Campbell
Matthew Daley
Juergen Gross
Tim Deegan
Patrick Welche
Daniel Kiper
Marcel J.E. Mol
Suravee Suthikulpanit