Commit fac7f7 changed the value of ptr so that it points to the right memory
area, taking the page offset into account, but failed to remove this when
doing the unmap, which caused the region to not be unmapped. Fix this by not
modifying ptr and instead adding the page offset directly in the memcpy
call.
Coverity-ID: 1394285
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
There are two cases where this was wrong, albeit in a benign way (the
compiler - according to my checking - didn't leverage the wrongness
for any optimizations affecting overall outcome).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
The original code has a bug; eax and edx get unconditionally updated even when
hvm_msr_read_intercept() doesn't return X86EMUL_OKAY.
It is only by blind luck (vmce_rdmsr() eagerly initialising its msr_content
pointer) that this isn't an information leak into guests.
While fixing this bug, reduce the scope of msr_content and initialise it to 0.
This makes it obvious that a stack leak won't occur, even if there were to be
a buggy codepath in hvm_msr_read_intercept().
Also make some non-functional improvements. Make the insn_len calculation
common, and reduce the quantity of explicit casting by making better use of
the existing register names.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Commit 21550029f7 removed the
PLATFORM_QUIRK_GIC_64K_STRIDE quirk and introduced a way to
automatically detect that the two GICC pages have a 64K stride.
However the heuristic requires that the device tree for the platform
reports a GICC size == 128K, which is not the case for some versions of
XGene.
Fix the issue by partially reverting
21550029f7:
- reintroduce PLATFORM_QUIRK_GIC_64K_STRIDE for XGene
- force csize and vsize to SZ_128K if csize is initially 4K and if
PLATFORM_QUIRK_GIC_64K_STRIDE
Also add a warning in case GICC is SZ_128K but not aliased.
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Add two missing allow rules:
1. Device model domain construction uses getvcpucontext, discovered by
Andrew Cooper while chasing an unrelated issue.
2. When a domain is destroyed with a device passthrough active, the
calls to remove_{irq,ioport,iomem} can be made by the hypervisor itself
(which results in an XSM check with the source xen_t). It does not make
sense to deny these permissions; no domain should be using xen_t, and
forbidding the hypervisor from performing cleanup is not useful.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
The flask policy can be build twice -- one for hypervisor and one for
tools.
Before this patch, everything is built inside tools/flask/policy
directory. It is possible to have a race to write to the same output
file when running parallel builds.
Prepend output file names with FLASK_BUILD_DIR. Hypervisor and tools
build will set that variable to different directories, so that we can
be safe from races.
Adjust other bits of the build system as needed.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
This affects not only the layout of the data (always 2+8 bytes), but
also the contents (no truncation to 24 bits occurs).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
The variable debug is used to enable debug for the tools. As
early-printk is for the hypervisor we should use CONFIG_DEBUG.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
It is possible for PVHv2 guests to get the hardware description from ACPI
tables, add this to the documentation also.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
On PVHv2 guests the local APIC can also be used to start APs if present.
Amend the documentation in order to reflect this.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
No sane OS would deliberately try this, but make Xen's emulation match real
hardware by delivering #GP(0), rather than suffering a VMEntry failure.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <JBeulich@suse.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
That combination would cause Xen to crash.
Note that although this is a security issue, is not XSA-worthy because
ALTP2M is experimental.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Credit2 is available in tree as an "Experimental" scheduler since
a few years. Recently, effort started for making it production ready
and, eventually, the new Xen's default scheduler. As a consequence of
that, it has undergone a great deal of development, testing and
benchmarking.
In fact, Credit2's much more modern (wrt Credit1) design and cleaner
code makes it a lot easier to understand what the scheduler is doing,
fix scheduling issues that may come up, and implement new and more
advanced features, in future.
In some more details:
- key features that were missing (pinning and context switching
rate-limiting) have now been implemented, and more (soft affinity,
caps and reservations) are about to come. The gap wrt Credit1 is
therefore closing. In particular, with pinning and rate-limiting
available, the scheduler can be considered usable.
- Credit2 is tested by OSSTest since long time. Furthermore, as a
part of recent efforts, stress tests and benchmarks have been run
and shown no bugs or stability issues.
- A number of different benchmarks have been run, most of them
comparing Credit2 with Credit1. Some of the results were posted on
xen-devel, some others have been illustrated during a talk at 2016
edition of Xen-Project Developer Summit. In general, performance
look promising --if not better than Credit1 already, in some of
the cases.
It therefore appears that we are ready to mark the Credit2 scheduler
as a 'Supported' feature, and ask users to look at it and try it, if
they think it suits their needs.
Of course, declaring something 'Supported' has security implications.
So here it is how the situation looks like from a security standpoint:
1) Is guest->host privilege escalation possible?
The only interfaces exposed to unprivileged guests are the SCHEDOP
hypercalls, and timers. None of those hypercalls contain any pointers,
and they don't look to contain any privilege escalation path. Also,
they're not specific to Credit2, as they're "used" by all schedulers
(ingluding the current default, Credit1), so anything about these
interfaces would be a security concern already.
2) Is guest user->guest kernel escalation possible?
The guest kernel is not really relying on anything from the scheduler
to protect itself or any data in any way.
3) Is there any information leakage?
The only information which the scheduler exposes to unprivileged
guests is the timing information. This may be able to be used for
side-channel attacks to probabilistically infer things about other
vcpus running on the same system; but this has not traditionally
been considered within the security boundary. And, again, this is
possible with all schedulers.
The control domain can issue DOMCTL_SCHEDOP and SYSCTL_SCHEDOP
hypercalls, but the involved data structures are handled in a
way that does not leak information (which would be leaked "only"
to Dom0 anyway).
4) Can a Denial-of-Service be triggered?
This is a risk, with schedulers, and one that's hard to foresee.
For instance, it _did_ happen on Credit1, in the past (a vcpu
could "game the system" by sleeping at particular times to gain
BOOST priority and monopolize 95% of the cpu). In that case, it
was possible because of the probabilistic nature of accounting
in Credit1 (which was then fixed). Well, Credit2:
- already do accurate, rather than probabilistic, accounting;
- does not have any BOOST or, in general, any way for a vcpu to
become 'more important' than the others: they're all subjected
to the same crediting algorithm.
Also note that, the accounting and the crediting algorithm are a lot
simpler than in Credit1, and hence a lot easier to understand, debug
and audit.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
The debug option in Config.mk affects hypervisor, tools and stubdom by
appending different flags to CFLAGS. Mini-os under extra is not
affected because it already has its own build system when it is
separated from xen.git.
It is undesirable because now hypervisor build is affected by both
Kconfig and debug.
Disentangle the semantics of debug by pushing relevant options to
individual sub-systems.
For hypervisor, the flags previously added by debug option is now
controlled by CONFIG_DEBUG.
For tools, flags are moved from config/*.mk into tools/Rules.mk.
For stubdom, because it unilaterally sets debug=y before including
top-level Config.mk, we only need to move the debug build set of flags
into stubdom Makefile.
Specifically there are some considerations on what flags are picked:
1. we don't need -fno-optimize-sibling-calls anymore because gcc doc
indicates that it is not enabled for -O1, which we already set in the
debug build.
2. for tools we use -O0 -g3 in Rules.mk because they already take
precedence over the flags set in config/*.mk.
3. for hypervisor we don't add -fno-omit-frame-pointer to debug build
because that's controlled by CONFIG_FRAME_POINTER.
This patch doesn't intend to tune those flags, but to provide identical
set of effective flags as before. The debug option in Config.mk will
only affect tools components after this patch is applied.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
In a 32bit build, the ocaml code 'proposed_id >= 0x7fffffff' compiles to:
8055eac: 83 fb ff cmp $0xffffffff,%ebx
8055eaf: 7d 0f jge 8055ec0 <...+0x20>
which in C is 'proposed_id >= INT_MIN', or in other words, tautologically
true. As a result, 32bit builds of oxenstored always try to allocate the
transaction id 1, and fall into an infinite loop of trying the next id if
transaction 1 is already in use.
Restrict the range down to 1 billion, to sit in the positive half of a 31 bit
ocaml integer. The compiled code is now:
8055eac: b9 ff ff ff 7f mov $0x7fffffff,%ecx
8055eb1: 39 cb cmp %ecx,%ebx
8055eb3: 7d 0b jge 8055ec0 <...+0x20>
which (other than non-optimal code generation because of the unnecessary use
of %ecx), isn't unconditionally true.
In principle, the check could be changed to 'proposed_id == 0x7fffffff' which
would still allow for 2 billion transaction in 32bit builds. However, in
64bit builds, this reintroduces a risk that if proposed_id is initially
greater than 0x7fffffff, it will not be clipped suitably into range.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: David Scott <dave@recoil.org>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Current usage of sed in the libacpi Makefile make uses of non-POSIX options,
that are not available on all the OSes supported by the Xen tools.
The '-i' option has slightly different semantics between GNU and BSD sed
implementations, while on the GNU version the suffix is optional, on the BSD
one it is not. Also BSD sed seems to have problems parsing the script
itself, reporting "extra characters at the end of d command".
Fix those issues by using a temporary intermediate file, and replace the
script with a simpler version that achieves the same purpose (removing the
initial license header comment).
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
stubdom-vtpm needs gmp and expects it under
stubdom/cross-root-x86_64/x86_64-xen-elf/lib while gmp seems to install
it under stubdom/cross-root-x86_64/x86_64-xen-elf/lib64 at least in an
openSUSE environment.
Modify gmp configure parameters to explicitly specify --libdir.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Append --build and --host flags to GMP's configure script so that it
knows it is being cross-compiled.
This should fix the issue that GMP doesn't compile with gcc 6, because
configure script won't try to test the host environment anymore.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
make distclean tries to remove stubdom/gmp-4.3.2.tar.gz, while the
downloaded file is stubdom/gmp-4.3.2.tar.bz2
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
add_change_node() in xenstored is used to add a modified node to the
list of changed nodes of one transaction. It is being called with the
recurse parameter set to true when removing a node in order to get
watches for children of the node fired at transaction end, too.
If, however, the node to be deleted had been modified in the same
transaction the recurse parameter of add_change_node() is lost as
an entry already in the list of the changed nodes won't be entered
again.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Commit 0888d36bb2 ("x86/emul: Correct the decoding of SReg3 operands")
overlooked three places where x86_seg_cs was assumed to be zero.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
c/s 5eeca68f introduced the 64bit ABI for HVM guests, and chose to explicitly
truncate the index, despite the fact that the `mov $imm32, %eax` in the
hypercall page already provides the expected truncation.
The truncation isn't very obvious, and is counterintuitive, seeing as all
other 64bit parameters are passed without truncation. It is also different to
the PV ABI, which is otherwise identical.
As the hypercall page has always been present for HVM guests (and indeed, is
basically mandatory to abstract away vendor differences), it is exceedingly
unlikely that any code exists which enters hvm_do_hypercall() with upper bits
set in %rax.
Therefore, take the opportunity to fix the ABI before it becomes impossible to
fix.
While tweaking this area, fix one piece of trailing whitespace.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Make budget accounting code more consistent by making sure the values
used to compute how much budget has been consumed are updated together.
This makes code resilient to calling burn_budget() from more than just
one place -- in case we will need to do that -- without risking subtle
bugs.
No functional changes are intended.
Signed-off-by: Meng Xu <mengxu@cis.upenn.edu>
Acked-by: Dario Faggioli <dario.faggioli@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Bug scenario:
repl_timer_handler() may be called before rt_schedule() for a VCPU.
This situation may happen in two scenarios:
(1) The VCPU misses deadline due to the system is oversubscribed. For example,
the sum of VCPUs utilization on a core is larger than one.
(2) The VCPU has budget = period, which causes the timers for
rt_schedule() and repl_timer_handler() are fired at the same time.
When the situation happens, it causes the following incorrect behavior:
repl_timer_handler() will update the VCPU period and deadline.
If the VCPU is still the highest priority one, even with the new deadline,
it will continue to run, but with new period and deadline.
Since the budget enforcement timer for the previous period is still armed,
rt_schedule() will still be called in the new period and enforce the budget
for the previous period.
The current burn_budget() will deduct the time spent in previous period from
the budget in current period, which is incorrect.
Fix:
We keeps last_start always within the current period for a VCPU, so that
we only deduct the time spent in the current period from the VCPU budget.
We always update last_start whenever we update cur_deadline for a VCPU.
Signed-off-by: Meng Xu <mengxu@cis.upenn.edu>
Reported-by: Dagaen Golomb <dgolomb@cis.upenn.edu>
Acked-by: Dario Faggioli <dario.faggioli@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
In hindsight, this is a better position for it, as it avoids opencoding
hvmemul_inject_hw_exception() in hvmemul_cpuid(), and reduces the requirements
on other ops->cpuid() hooks wanting to implement cpuid faulting in the future.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
REX.R is ignored when considering segment register operands, and needs masking
out first.
While fixing this, reorder the user segments in x86_segment to match SReg3
encoding. This avoids needing a translation table between hardware ordering
and Xen's ordering.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
x86_emulate.h is included by the userspace test harness. Avoid using
constructs which don't come from standard header files.
Reposition the test harnesses inclusion of x86_emulate.h to avoid relying on
any definitions intended for use by x86_emulate.c alone.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
We should clear the __RTDS_depleted bit once a VCPU budget is replenished.
Because repl_timer_handler may be called after rt_schedule
but before rt_context_saved, the VCPU may be not on CPU or on queue
when the VCPU is the middle of context switch
Signed-off-by: Meng Xu <mengxu@cis.upenn.edu>
Acked-by: Dario Faggioli <dario.faggioli@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
docs/misc/xenstore.txt states that xenstored will use "0" as a valid
transaction id after 2^32 transactions. This is not true. Remove that
statement.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
The transaction id of 0 is reserved, meaning "not in a transaction". It is up
to the xenstored server to allocate transaction ids. While oxenstored starts
its ids at 1, but insufficient care is taken with truncation cases.
A 32bit oxenstored has an int with 31 bits of width, meaning that the
transaction id will wrap around to 0 after 2 billion transactions.
A 64bit oxenstored has an int with 63 bits of width, meaning that once 4
billion transactions are used, the allocated id will be truncated when written
into the uin32_t field in the ring. This causes the client to reply with the
truncated id, breaking any further attempt to use any transactions.
Limit all transaction ids to the range between 1 and 0x7ffffffe. This is the
best which can be done without making oxenstored depend on Stdint or Cstruct,
yet still work for 32bit builds.
Also check that the proposed new transaction id isn't currently in use. For
the first 2 billion transactions there is no chance of a collision, and after
that, the chance is at most 20 (the default open transaction quota) in 2
billion.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: David Scott <dave@recoil.org>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
pkg-config from FreeBSD ports doesn't have ${prefix}/share/pkgconfig in the
default search path, fix this by having a PKG_INSTALLDIR variable that can
be changed on a per-OS basis.
It would be best to use PKG_INSTALLDIR as defined by the pkg.m4 macro, but
sadly this also reports a wrong value on FreeBSD (${libdir}/pkgconfig, which
expands to /usr/local/lib/pkgconfig by default, and is also _not_ part of
the default pkg-config search path).
This patch should not change the behavior for Linux installs.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reported-by: Alexander Nusov <alexander.nusov@nfvexpress.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Cédric Bosdonnat
Roger Pau Monne
Jan Beulich
Andrew Cooper
Stefano Stabellini
Wei Liu
Daniel De Graaf
Luwei Kang
Julien Grall
Dario Faggioli
Juergen Gross
Meng Xu
Ian Jackson