With ordinary requests allowed to come from phantom functions, the
remapping tables ought to be set up to also allow for MSI triggers to
come from other than the "real" device too.
It is not clear to me whether the alias-ID handling also needs
adjustment for this to work properly, or whether firmware can be
expected to properly express this through a device alias range
descriptor (or multiple device alias ones).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Apart from dealing duplicate conflicting entries, we also have to
handle firmware omitting IO-APIC entries in IVRS altogether. Not doing
so has resulted in c/s 26517:601139e2b0db to crash such systems during
boot (whereas with the change here the IOMMU gets disabled just as is
being done in the other cases, i.e. unless global tables are being
used).
Debugging this issue has also pointed out that the debug log output is
pretty ugly to look at - consolidate the output, and add one extra
item for the IVHD special entries, so that future issues are easier
to analyze.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The IRQs beyond nr_static_irqs do not all have an associated PCI
device, so only query the device SID if pci is not NULL.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Jan Beulich <jbeulich@suse.com>
Committed-by: Keir Fraser <keir@xen.org>
gcc 4.8 identifies several places where code of the form memset(x, 0,
sizeof(x)); is used incorrectly, meaning that less memory is set to
zero than required.
Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
Committed-by: Keir Fraser <keir@xen.org>
The maximum size of a message is part of the protocol spec in
xen/include/public/io/xs_wire.h
Before this patch a client which sends an overly large message can
cause a buffer read overrun.
Note if a badly-behaved client sends a very large message
then it will be difficult for them to make their connection
work again-- they will probably need to reboot.
Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
oxenstored makes use of the OCaml Xenbus bindings, in which the
function xs_ring_read in tools/ocaml/libs/xb/xs_ring_stubs.c is used
to read from the shared memory Xenstore ring.
This function does not correctly handle all possible (prod, cons)
states when MASK_XENSTORE_IDX(prod) > MASK_XENSTORE_IDX(cons).
The root cause is the use of the unmasked values of prod and cons to
calculate to_read. If prod is set to an out-of-range value, the ring
peer can cause to_read to be too large or even negative. This allows
the ring peer to force oxenstored to read and write out of range for
the buffers leading to a crash or possibly to privilege escalation.
Correct this by masking the values of cons and prod at the start, so
we only deal with masked values. This makes the logic simpler, as
semantically inappropriate values of the upper bits of the ring
pointers are simply ignored.
The same vulnerability does not exist in the ring writer because the
only use made of the unmasked value is the check which prevents the
prod pointer overtaking the cons pointer. A ring peer which defeats
this check will suffer only lost data.
However, additionally, precautions need to be taken to ensure that
req_cons and req_prod are only read once in each function. Without
the use of volatile or some asm construct, the compiler can "prove"
that req_cons and req_prod do not change unexpectedly and is permitted
to "amplify" the read of (say) req_cons into two reads at different
times, giving two different values for use as cons, and then use the
two sources of cons interchangeably. (The use of xen_mb() does not
forbid this.)
Therefore do the reads of req_cons and req_prod through a volatile
pointer in both xs_ring_read and xs_ring_write.
This is currently believed to be a theoretical vulnerability as we are
not aware of any compilers which amplify reads in this way.
This is a security issue, part of XSA-38 / CVE-2013-0215.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Tested-by: Matthew Daley <mattjd@gmail.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Using global interrupt remapping table may be insecure, as
described by XSA-36. This patch makes per-device mode default.
This is XSA-36 / CVE-2013-0153.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
Moved warning in amd_iov_detect() to location covering all cases.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
AMD's SP5100 chipset can be placed into SATA Combined mode
that may cause prevent dom0 from booting when IOMMU is
enabled and per-device interrupt remapping table is used.
While SP5100 erratum 28 requires BIOSes to disable this mode,
some may still use it.
This patch checks whether this mode is on and, if per-device
table is in use, disables IOMMU.
This is XSA-36 / CVE-2013-0153.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
Flipped operands of && in amd_iommu_init() to make the message issued
by amd_sp5100_erratum28() match reality (when amd_iommu_perdev_intremap
is zero, there's really no point in calling the function).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
When changing the affinity of an IRQ associated with a passed
through PCI device, clear previous mapping.
This is XSA-36 / CVE-2013-0153.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
In addition, because some BIOSes may incorrectly program IVRS
entries for IOAPIC try to check for entry's consistency. Specifically,
if conflicting entries are found disable IOMMU if per-device
remapping table is used. If entries refer to bogus IOAPIC IDs
disable IOMMU unconditionally
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
Currently, the error code returned by acpi_table_parse()'s handler
is ignored. This patch will propagate handler's return value to
acpi_table_parse()'s caller.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
Add include of xsm/xsm.h to fix:
hvm.c: In function 'do_hvm_op': hvm.c:37:9: error: implicit declaration of function 'xsm_hvm_param' [-Werror=implicit-function-declaration]
hvm.c:37:9: error: nested extern declaration of 'xsm_hvm_param' [-Werror=nested-externs]
hvm.c:37:28: error: 'XSM_TARGET' undeclared (first use in this function)
hvm.c:37:28: note: each undeclared identifier is reported only once for each function it appears in
cc1: all warnings being treated as errors
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
Currently ->xcflags remains 1 because the braces are placed incorrectly.
Put each logical unit into its own braces to fix assigment to xcflags.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
configure checks just for ocamlc, but the tools in tools/ocaml depend
also on ocamlfind. On my workstation I have just ocamlc installed, but
no ocamlfind. As a result make will fail.
Update configure.ac to check also for OCAMLFIND, update various
Makefiles and replace hardcoded ocamlfind string with $(OCAMLFIND)
Please rerun autogen.sh after applying this patch.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
Upstream QEMU doesn't support -nographic with -daemonize unless monitor,
serial and parallel outputs are all redirected:
/* According to documentation and historically, -nographic redirects
* serial port, parallel port and monitor to stdio, which does not work
* with -daemonize. We can redirect these to null instead, but since
* -nographic is legacy, let's just error out.
* We disallow -nographic only if all other ports are not redirected
* explicitly, to not break existing legacy setups which uses
* -nographic _and_ redirects all ports explicitly - this is valid
* usage, -nographic is just a no-op in this case.
*/
Considering that we do want to redirect them to /dev/null anyway, do so.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- handled reject vs 26352:9a1610c1e564 "xencommons: Stop QEMU in
do_stop()" and rewrapped the resulting long line ]
Committed-by: Ian Campbell <ian.campbell@citrix.com>
- only call check_update_timer() on REG_B writes when SET changes
- only call alarm_timer_update() on REG_B writes when relevant bits
change
- instead properly handle AF and PF when the guest is not also setting
AIE/PIE respectively (for UF this was already the case, only a
comment was slightly inaccurate), including calling the respective
update functions upon REG_C reads
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Olaf Hering <olaf@aepfle.de>
This conflicts with changes done in 26486:7648ef657fe7 and
26489:83a3fa9c8434 (i.e. the code added by them needs adjustment in
order for the change here to be correct).
While putting together the kernel side of this I realized that c/s
26397:d9c7b82aa7b1 went a little too far in requiring a buffer for the
option ROM contents - all that is really needed is handing Dom0
physical address and size of the data block.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
While emulating the INVEPT instruction in L0 VMM, the EPT pointer
should be fetched from the instruction decoding result, but not
the current loaded EPT pointer.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
Each time in virtual_vmentry(), the code needs to cover both EPT
and shadow mode for L2 guest, updating different EPT pointer to
shadow VMCS.
This fixes the issue that, launch a guest with EPT, then kill it
and launch a second guest with shadow, the second guest will hang
at the startup screen.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Acked by: Eddie Dong <eddie.dong@intel.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
This implies that the individual destroy functions will have to remain
capable of being called for a vCPU that the corresponding init function
was never run on.
Once at it, also clean up some inefficiencies in the corresponding
parameter validation code.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
SMEP is disabled if CPU is in non-paging mode in hardware.
However Xen always uses paging mode to emulate guest non-paging
mode with HAP. To emulate this behavior, SMEP needs to be manually
disabled when guest switches to non-paging mode.
We met an issue that, SMP Linux guest with recent kernel (enable
SMEP support, for example, 3.5.3) would crash with triple fault if
setting unrestricted_guest=0 in grub. This is because Xen uses an
identity mapping page table to emulate the non-paging mode, where
the page table is set with USER flag. If SMEP is still enabled in
this case, guest will meet unhandlable page fault and then crash.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
Committed-by: Keir Fraser <keir@xen.org>
So that we can easily figure out whether or not we are running a
debug build of Xen (e.g., via `xl dmesg').
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
Various fixes to mini-os needed to build lwip 1.3.2:
- Don't build the tests.
- Add BSD-style endianness macros to endian.h.
- free() is called via a function pointer so it needs to be a real
function. Do the same for malloc() and realloc().
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Committed-by: Keir Fraser <keir@xen.org>
This was recently (re?)introduced on x86 in 26447:f831d8dcf18f and is
now used in generic code (specifically tmem in 26454:38847c15d8cd).
This fixes the build on ARM.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
26470:acaf29203cf9 missed a bunch of hardcoded paths, e.g. in the
initscripts. I think at this juncture it is appropriate to revert
this change and try again after some more testing.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
Remove myself from SVM and IOMMU maintainer list, as I don't work for
AMD anymore.
Signed-off-by: Wei Huang <huangwei@gmail.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
26470:acaf29203cf9 "tools+stubdom: install under /usr/local by
default" moved more stuff under /usr/local than was desirable.
In particular SYSCONFIG_DIR (configuration for initscripts) moved to
/usr/local/etc/{sysconfig,defaults} while the initscripts themselves
(correctly) remained in /etc/init.d. Moving /etc/xen/scripts breaks
the udev bakcned rules file. Lastly stuff under /var was moved to
/usr/local/var.
Move these back to /etc/ and /var. Moving /etc wholesale rather thsn
just the problematic bits is preferable for consistency.
Although there seems to be some disagreement about /usr/local/var vs
/var using /var is compatible with the FHS and what we think most
people will expect.
Most of this impacts Linux only but NetBSD appears to have been using
/usr/local/var/lib which I have also reset to /var/lib.
Note that we already paid no attention to autoconf --sysconfdir or
--localstatedir ('etc' and 'var' respectively) so there is no change
from that PoV.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
These files were left over after
$ git clean -f -dx
$ ./configure
$ make distclean
and picked up by a subsequent.
$ git clean -f -dx
Ensure that these files are also correctly ignored.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
The current logic for handling the non-root VMREAD/VMWRITE is by
VM-Exit and emulate, which may bring certain overhead.
On new Intel platform, it introduces a new feature called VMCS
shadowing, where non-root VMREAD/VMWRITE will not trigger VM-Exit,
and the hardware will read/write the virtual VMCS instead.
This is proved to have performance improvement with the feature.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Acked-by: Jun Nakajima <jun.nakajima@intel.com>
Acked-by Eddie Dong <eddie.dong@intel.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
After we use the VMREAD/VMWRITE to build up the virtual VMCS, each
access to the virtual VMCS needs two VMPTRLD and one VMCLEAR to
switch the environment, which might be an overhead to performance.
This commit tries to handle multiple virtual VMCS access together
to improve the performance.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Acked-by Eddie Dong <eddie.dong@intel.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
Before the VMCS shadowing feature, we use memory operation to build up
the virtual VMCS. This does work since this virtual VMCS will never be
loaded into real hardware. However after we introduce the VMCS
shadowing feature, this VMCS will be loaded into hardware, which
requires all fields in the VMCS accessed by VMREAD/VMWRITE.
Besides, the virtual VMCS revision identifer should also meet the
hardware's requirement, instead of using a faked one.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Acked-by Eddie Dong <eddie.dong@intel.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
Originally we use a virtual VMCS field to store the launch state of
a certain vmcs. However if we introduce VMCS shadowing feature, this
virtual VMCS should also be able to load into real hardware,
and VMREAD/VMWRITE operate invalid fields.
The new approach is to store the launch state into a list for L1 VMM.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Acked-by Eddie Dong <eddie.dong@intel.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
It is sometimes hard to discover all the optional tools that should be
on a system to build all available Xen documentation. By checking for
documentation generation tools at ./configure time and displaying a
warning, Xen packagers will more easily learn about new optional build
dependencies, like markdown, when they are introduced.
Based on a patch by Matt Wilson. Changed to use a separate
docs/configure which is called from the top-level in the same manner
as stubdoms.
Rerun autogen.sh and "git add docs/configure" after applying this patch.
Signed-off-by: Matt Wilson <msw@amazon.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Matt Wilson <msw@amazon.com>
(For the change to introduce docs/configure)
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
In the 300+ page PDF this produces I couldn't see anything which
wasn't the autogenerated doxygen boilerplate stuff.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
Jan Beulich
Daniel De Graaf
Keir Fraser
Michael Young
Olaf Hering
Suravee Suthikulpanit
Andrew Cooper
Ian Jackson
Ian Campbell
Boris Ostrovsky
Stefano Stabellini
Dongxiao Xu
Dario Faggioli
David Vrabel
Wei Huang
Ian Campbell