Andrew Cooper [Fri, 13 Apr 2018 15:42:34 +0000 (15:42 +0000)]
x86/msr: Virtualise MSR_SPEC_CTRL.SSBD for guests to use
Almost all infrastructure is already in place. Update the reserved bits
calculation in guest_wrmsr(), and offer SSBD to guests by default.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Gbp-Pq: Name x86msr-virtualise-msr_spec_ctrl.ssbd-for.patch
Andrew Cooper [Wed, 28 Mar 2018 14:21:39 +0000 (15:21 +0100)]
x86/Intel: Mitigations for GPZ SP4 - Speculative Store Bypass
To combat GPZ SP4 "Speculative Store Bypass", Intel have extended their
speculative sidechannel mitigations specification as follows:
* A feature bit to indicate that Speculative Store Bypass Disable is
supported.
* A new bit in MSR_SPEC_CTRL which, when set, disables memory disambiguation
in the pipeline.
* A new bit in MSR_ARCH_CAPABILITIES, which will be set in future hardware,
indicating that the hardware is not susceptible to Speculative Store Bypass
sidechannels.
For contemporary processors, this interface will be implemented via a
microcode update.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Gbp-Pq: Name x86intel-mitigations-for-gpz-sp4---specu.patch
Andrew Cooper [Thu, 26 Apr 2018 09:56:28 +0000 (10:56 +0100)]
x86/AMD: Mitigations for GPZ SP4 - Speculative Store Bypass
AMD processors will execute loads and stores with the same base register in
program order, which is typically how a compiler emits code.
Therefore, by default no mitigating actions are taken, despite there being
corner cases which are vulnerable to the issue.
For performance testing, or for users with particularly sensitive workloads,
the `spec-ctrl=ssbd` command line option is available to force Xen to disable
Memory Disambiguation on applicable hardware.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Gbp-Pq: Name x86amd-mitigations-for-gpz-sp4---specula.patch
Andrew Cooper [Thu, 26 Apr 2018 09:52:55 +0000 (10:52 +0100)]
x86/spec_ctrl: Introduce a new `spec-ctrl=` command line argument to replace `bti=`
In hindsight, the options for `bti=` aren't as flexible or useful as expected
(including several options which don't appear to behave as intended).
Changing the behaviour of an existing option is problematic for compatibility,
so introduce a new `spec-ctrl=` in the hopes that we can do better.
One common way of deploying Xen is with a single PV dom0 and all domUs being
HVM domains. In such a setup, an administrator who has weighed up the risks
may wish to forgo protection against malicious PV domains, to reduce the
overall performance hit. To cater for this usecase, `spec-ctrl=no-pv` will
disable all speculative protection for PV domains, while leaving all
speculative protection for HVM domains intact.
For coding clarity as much as anything else, the suboptions are grouped by
logical area; those which affect the alternatives blocks, and those which
affect Xen's in-hypervisor settings. See the xen-command-line.markdown for
full details of the new options.
While changing the command line options, take the time to change how the data
is reported to the user. The three DEBUG printks are upgraded to unilateral,
as they are all relevant pieces of information, and the old "mitigations:"
line is split in the two logical areas described above.
Sample output from booting with `spec-ctrl=no-pv` looks like:
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Release-acked-by: Juergen Gross <jgross@suse.com>
(cherry picked from commit 3352afc26c497d26ecb70527db3cb29daf7b1422)
Gbp-Pq: Name x86spec_ctrl-introduce-a-new-spec-ctrl=-.patch
Andrew Cooper [Tue, 1 May 2018 10:59:03 +0000 (11:59 +0100)]
x86/cpuid: Improvements to guest policies for speculative sidechannel features
If Xen isn't virtualising MSR_SPEC_CTRL for guests, IBRSB shouldn't be
advertised. It is not currently possible to express this via the existing
command line options, but such an ability will be introduced.
Another useful option in some usecases is to offer IBPB without IBRS. When a
guest kernel is known to be compatible (uses retpoline and knows about the AMD
IBPB feature bit), an administrator with pre-Skylake hardware may wish to hide
IBRS. This allows the VM to have full protection, without Xen or the VM
needing to touch MSR_SPEC_CTRL, which can reduce the overhead of Spectre
mitigations.
Break the logic common to both PV and HVM CPUID calculations into a common
helper, to avoid duplication.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Release-acked-by: Juergen Gross <jgross@suse.com>
(cherry picked from commit cb06b308ec71b23f37a44f5e2351fe2cae0306e9)
Gbp-Pq: Name x86cpuid-improvements-to-guest-policies-.patch
Andrew Cooper [Wed, 9 May 2018 12:59:56 +0000 (13:59 +0100)]
x86/spec_ctrl: Explicitly set Xen's default MSR_SPEC_CTRL value
With the impending ability to disable MSR_SPEC_CTRL handling on a
per-guest-type basis, the first exit-from-guest may not have the side effect
of loading Xen's choice of value. Explicitly set Xen's default during the BSP
and AP boot paths.
For the BSP however, delay setting a non-zero MSR_SPEC_CTRL default until
after dom0 has been constructed when safe to do so. Oracle report that this
speeds up boots of some hardware by 50s.
"when safe to do so" is based on whether we are virtualised. A native boot
won't have any other code running in a position to mount an attack.
Reported-by: Zhenzhong Duan <zhenzhong.duan@oracle.com> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Release-acked-by: Juergen Gross <jgross@suse.com>
(cherry picked from commit cb8c12020307b39a89273d7699e89000451987ab)
Gbp-Pq: Name x86spec_ctrl-explicitly-set-xens-default.patch
Andrew Cooper [Tue, 17 Apr 2018 13:15:04 +0000 (14:15 +0100)]
x86/spec_ctrl: Split X86_FEATURE_SC_MSR into PV and HVM variants
In order to separately control whether MSR_SPEC_CTRL is virtualised for PV and
HVM guests, split the feature used to control runtime alternatives into two.
Xen will use MSR_SPEC_CTRL itself if either of these features are active.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Release-acked-by: Juergen Gross <jgross@suse.com>
(cherry picked from commit fa9eb09d446a1279f5e861e6b84fa8675dabf148)
Gbp-Pq: Name x86spec_ctrl-split-x86_feature_sc_msr-in.patch
Andrew Cooper [Mon, 7 May 2018 13:06:16 +0000 (14:06 +0100)]
x86/spec_ctrl: Elide MSR_SPEC_CTRL handling in idle context when possible
If Xen is virtualising MSR_SPEC_CTRL handling for guests, but using 0 as its
own MSR_SPEC_CTRL value, spec_ctrl_{enter,exit}_idle() need not write to the
MSR.
Requested-by: Jan Beulich <JBeulich@suse.com> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Release-acked-by: Juergen Gross <jgross@suse.com>
(cherry picked from commit 94df6e8588e35cc2028ccb3fd2921c6e6360605e)
Gbp-Pq: Name x86spec_ctrl-elide-msr_spec_ctrl-handlin.patch
Andrew Cooper [Mon, 30 Apr 2018 13:20:23 +0000 (14:20 +0100)]
x86/spec_ctrl: Rename bits of infrastructure to avoid NATIVE and VMEXIT
In hindsight, using NATIVE and VMEXIT as naming terminology was not clever.
A future change wants to split SPEC_CTRL_EXIT_TO_GUEST into PV and HVM
specific implementations, and using VMEXIT as a term is completely wrong.
Take the opportunity to fix some stale documentation in spec_ctrl_asm.h. The
IST helpers were missing from the large comment block, and since
SPEC_CTRL_ENTRY_FROM_INTR_IST was introduced, we've gained a new piece of
functionality which currently depends on the fine grain control, which exists
in lieu of livepatching. Note this in the comment.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Release-acked-by: Juergen Gross <jgross@suse.com>
(cherry picked from commit d9822b8a38114e96e4516dc998f4055249364d5d)
Gbp-Pq: Name x86spec_ctrl-rename-bits-of-infrastructu.patch
Andrew Cooper [Tue, 17 Apr 2018 13:15:04 +0000 (14:15 +0100)]
x86/spec_ctrl: Fold the XEN_IBRS_{SET,CLEAR} ALTERNATIVES together
Currently, the SPEC_CTRL_{ENTRY,EXIT}_* macros encode Xen's choice of
MSR_SPEC_CTRL as an immediate constant, and chooses between IBRS or not by
doubling up the entire alternative block.
There is now a variable holding Xen's choice of value, so use that and
simplify the alternatives.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Release-acked-by: Juergen Gross <jgross@suse.com>
(cherry picked from commit af949407eaba7af71067f23d5866cd0bf1f1144d)
Gbp-Pq: Name x86spec_ctrl-fold-the-xen_ibrs_setclear-.patch
Andrew Cooper [Tue, 17 Apr 2018 13:15:04 +0000 (14:15 +0100)]
x86/spec_ctrl: Merge bti_ist_info and use_shadow_spec_ctrl into spec_ctrl_flags
All 3 bits of information here are control flags for the entry/exit code
behaviour. Treat them as such, rather than having two different variables.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Release-acked-by: Juergen Gross <jgross@suse.com>
(cherry picked from commit 5262ba2e7799001402dfe139ff944e035dfff928)
Gbp-Pq: Name x86spec_ctrl-merge-bti_ist_info-and-use_.patch
Andrew Cooper [Tue, 17 Apr 2018 13:15:04 +0000 (14:15 +0100)]
x86/spec_ctrl: Express Xen's choice of MSR_SPEC_CTRL value as a variable
At the moment, we have two different encodings of Xen's MSR_SPEC_CTRL value,
which is a side effect of how the Spectre series developed. One encoding is
via an alias with the bottom bit of bti_ist_info, and can encode IBRS or not,
but not other configurations such as STIBP.
Break Xen's value out into a separate variable (in the top of stack block for
XPTI reasons) and use this instead of bti_ist_info in the IST path.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Release-acked-by: Juergen Gross <jgross@suse.com>
(cherry picked from commit 66dfae0f32bfbc899c2f3446d5ee57068cb7f957)
Gbp-Pq: Name x86spec_ctrl-express-xens-choice-of-msr_.patch
Andrew Cooper [Thu, 26 Apr 2018 11:21:00 +0000 (12:21 +0100)]
x86/spec_ctrl: Read MSR_ARCH_CAPABILITIES only once
Make it available from the beginning of init_speculation_mitigations(), and
pass it into appropriate functions. Fix an RSBA typo while moving the
affected comment.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Release-acked-by: Juergen Gross <jgross@suse.com>
(cherry picked from commit d6c65187252a6c1810fd24c4d46f812840de8d3c)
Gbp-Pq: Name x86spec_ctrl-read-msr_arch_capabilities-.patch
Andrew Cooper [Tue, 15 May 2018 15:37:59 +0000 (16:37 +0100)]
x86: Fix "x86: further CPUID handling adjustments"
c/s f9616884e (a backport of c/s 0d703a701 "x86/feature: Definitions for
Indirect Branch Controls") missed a CPUID adjustment when calculating the raw
featureset. This impacts host administrator diagnostics.
Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>
c/s 62b187969 "x86: further CPUID handling adjustments" make some adjustments.
However, it breaks levelling of guests, making it impossible for the toolstack
to hide STIBP or IBPB from guests on hardware with up-to-date microcode.
The dom0 issue referenced in the commit message was fixed by the hunk
adjusting the zeroing alone. STIBP and IBPB don't need (and indeed, must not
be for levelling purposes) OR'd into the leaf.
One final item which was missed in backport was the need to ignore the
toolstack choice of STIBP, and set it equal to IBRSB. This needs doing after
the mask has been applied.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Gbp-Pq: Name x86-fix-x86-further-cpuid-handling-adjus.patch
George Dunlap [Fri, 18 May 2018 10:12:54 +0000 (12:12 +0200)]
xen/schedule: Fix races in vcpu migration
The current sequence to initiate vcpu migration is inefficent and error-prone:
- The initiator sets VPF_migraging with the lock held, then drops the
lock and calls vcpu_sleep_nosync(), which immediately grabs the lock
again
- A number of places unnecessarily check for v->pause_flags in between
those two
- Every call to vcpu_migrate() must be prefaced with
vcpu_sleep_nosync() or introduce a race condition; this code
duplication is error-prone
- In the event that v->is_running is true at the beginning of
vcpu_migrate(), it's almost certain that vcpu_migrate() will end up
being called in context_switch() as well; we might as well simply
let it run there and save the duplicated effort (which will be
non-negligible).
The result is that Credit1 has several races which result in runqueue
<-> v->processor invariants being violated (triggering ASSERTs in
debug builds and strange bugs in production builds).
Instead, introduce vcpu_migrate_start() to initiate the process.
vcpu_migrate_start() is called with the scheduling lock held. It not
only sets VPF_migrating, but also calls vcpu_sleep_nosync_locked()
(which will automatically do nothing if there's nothing to do).
Rename vcpu_migrate() to vcpu_migrate_finish(). Check for v->is_running and
pause_flags & VPF_migrating at the top and return if appropriate.
Then the way to initiate migration is consistently:
George Dunlap [Fri, 18 May 2018 10:12:25 +0000 (12:12 +0200)]
xen: Introduce vcpu_sleep_nosync_locked()
There are a lot of places which release a lock before calling
vcpu_sleep_nosync(), which then just grabs the lock again. This is
not only a waste of time, but leads to more code duplication (since
you have to copy-and-paste recipes rather than calling a unified
function), which in turn leads to an increased chance of bugs.
Introduce vcpu_sleep_nosync_locked(), which can be called if you
already hold the schedule lock.
That is, Dom0's ACPI processor driver is in the process of uploading Px
and Cx data. Looking at the ticket lock state in CPU1's registers, it is
waiting for ticket 0x0000 to have its turn, while the supposed current
owner's ticket is 0x0001, which is an invalid state (and neither of the
other two CPUs holds the lock anyway). Hence I can only conclude that
cpuidle_init_cpu(1) ran on CPU 0 while some other CPU held the lock (the
unlock then put the lock in the state that CPU1 is observing).
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 2f64a251fa10dd4d62f84967e3dafa709f5e96ab
master date: 2018-04-27 14:35:35 +0200
Juergen Gross [Fri, 18 May 2018 10:10:49 +0000 (12:10 +0200)]
xpti: fix bug in double fault handling
When entering the hypervisor via the double fault handler resetting
xen_cr3 was missing. This led to switching to pv_cr3 when returning
from the next following exception, so repair this in order to allow
exception handling to work even after a double fault.
Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Tested-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: d80af845de7a4db01a4a3b4d779e0e0dcb5e738b
master date: 2018-04-23 16:13:01 +0200
Jan Beulich [Fri, 18 May 2018 10:10:11 +0000 (12:10 +0200)]
x86/HVM: never retain emulated insn cache when exiting back to guest
Commit 5fcb26e69e ("x86/HVM: don't retain emulated insn cache when
exiting back to guest") didn't go quite far enough: The insn emulator
may itself decide to return X86EMUL_RETRY (currently for certain
CMPXCHG failures and AVX2 gather insns), in which case we'd also exit
back to guest context. Tie the caching to whether we have an I/O
completion pending, instead of x86_emulate()'s return value.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
master commit: 25b0dad541e31bd892d57cbeafe8e0c0bf4e8385
master date: 2018-04-23 11:01:09 +0200
CPUs may share an in-use channel. Hence clearing of a bit from the
cpumask (in hpet_broadcast_exit()) as well as setting one (in
hpet_broadcast_enter()) must not race evaluation of that same cpumask.
Therefore avoid evaluating the cpumask twice in hpet_detach_channel().
Otherwise cpumask_empty() may e.g.return false while the subsequent
cpumask_first() could return nr_cpu_ids, which then triggers the
assertion in cpumask_of() reached through set_channel_irq_affinity().
Signed-off-by: David Wang <davidwang@zhaoxin.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 8c02a19230502a9522b097ee15742599091064aa
master date: 2018-04-23 11:00:07 +0200
The 'RSB Alternative' bit in MSR_ARCH_CAPABILITIES may be set by a hypervisor
to indicate that the virtual machine may migrate to a processor which isn't
retpoline-safe. Introduce a shortened name (to reduce code volume), treat it
as authorative in retpoline_safe(), and print its value along with the other
ARCH_CAPS bits.
The exact processor models which do have RSB semantics which fall back to BTB
predictions are enumerated, and include Kabylake and Coffeelake. Leave a
printk() in the default case to help identify cases which aren't covered.
The exact microcode versions from Broadwell RSB-safety are taken from the
referenced microcode update file (adjusting for the known-bad microcode
versions). Despite the exact wording of the text, it is only Broadwell
processors which need a microcode check.
In practice, this means that all Broadwell hardware with up-to-date microcode
will use retpoline in preference to IBRS, which will be a performance
improvement for desktop and server systems which would previously always opt
for IBRS over retpoline.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
x86/spec_ctrl: Fix typo in ARCH_CAPS decode
Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
master commit: 1232378bd2fef45f613db049b33852fdf84d7ddf
master date: 2018-04-19 17:28:23 +0100
master commit: 27170adb54a558e11defcd51989326a9beb95afe
master date: 2018-04-24 13:34:12 +0100
Jan Beulich [Fri, 18 May 2018 10:08:25 +0000 (12:08 +0200)]
x86: suppress BTI mitigations around S3 suspend/resume
NMI and #MC can occur at any time after S3 resume, yet the MSR_SPEC_CTRL
may become available only once we're reloaded microcode. Make
SPEC_CTRL_ENTRY_FROM_INTR_IST and DO_SPEC_CTRL_EXIT_TO_XEN no-ops for
the critical period of time.
Also set the MSR back to its intended value.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
x86: Use spec_ctrl_{enter,exit}_idle() in the S3/S5 path
The main purpose of this patch is to avoid opencoding the recovery logic at
the end, but also has the positive side effect of relaxing the SPEC_CTRL
mitigations when working to shut the final CPU down.
Jan Beulich [Fri, 18 May 2018 10:07:41 +0000 (12:07 +0200)]
x86: correct ordering of operations during S3 resume
Microcode loading needs to happen before re-enabling interrupts, in case
only updated microcode allows the use of e.g. the SPEC_{CTRL,CMD} MSRs.
Otoh it doesn't need to happen at all when we didn't suspend in the
first place. It needs to happen before spin_debug_enable() though, as it
acquires a lock and hence would otherwise make
common/spinlock.c:check_lock() unhappy. As micrcode loading can be
pretty verbose, also make sure it only runs after console_end_sync().
cpufreq_add_cpu() doesn't need calling on the only "goto enable_cpu"
path, which sits ahead of cpufreq_del_cpu().
Reported-by: Simon Gaiser <simon@invisiblethingslab.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: cb2a4a449dfd50af309a333aa805835015fbc8c8
master date: 2018-04-16 14:08:30 +0200
Andrew Cooper [Wed, 9 May 2018 15:25:14 +0000 (16:25 +0100)]
x86/emul: Fix emulator test harness build following a91b2ec337a
Versions of Xen before c/s 5c6c3ac in Xen 4.9 don't use msr-index.h for the
test harness.
Reported-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
(cherry picked from commit e017133490d35eab64c0a61bfb233162fdacccc4)
Gbp-Pq: Name x86emul-fix-emulator-test-harness-build-.patch
As both xen-netfront and xen-blkfront support multi-queue, they would
consume a lot of grant table references when there are many paravirtual
devices and vcpus assigned to guest. Guest domU might panic or hang due to
grant allocation failure when nr_grant_frames in guest has reached its max
value.
This utility would help the administrators to diagnose xen issue. There is
only one command gnttab_query_size so far to monitor the guest grant table
frame usage on dom0 side so that it is not required to debug on guest
kernel side for crash/hang analysis anymore.
It is extensible for adding new commands for more diagnostic functions and
the framework of xen-diag.c is from xen-livepatch.c.
Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
(cherry picked from commit df36d82e3fc91bee2ff1681fd438c815fa324b6a)
Gbp-Pq: Name tools-utility-to-dump-guest-grant-table-.patch
This is due to the combination of GCC6, and Debian's decision to
enable some hardening flags by default (to try to make runtime
addresses less predictable):
https://wiki.debian.org/Hardening/PIEByDefaultTransition
This is of no benefit for the x86 instruction emulator test, which is
a rebuild of the emulator code for testing purposes only. So pass
options to disable this.
These options will be no-ops if they are the same as the compiler
default.
On amd64, the -fno-pic breaks the build in a different way. So do
this only on i386.
Signed-off-by: Ian Jackson <ian.jackson@citrix.com> CC: Jan Beulich <jbeulich@suse.com> CC: Andrew Cooper <andrew.cooper3@citrix.com>
squash! tools/tests/x86_emulator: Pass -no-pie -fno-pic to gcc
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
Gbp-Pq: Name toolstestsx86_emulator-pass--no-pie--fno.patch
* Include upstream XSA-263 (speculative store bypass) fixes for x86.
I hear that ARM fixes will be forthcoming RSN. Ie,
XSA-263 CVE-2018-3639 (amd64/i386; armhf/arm64 still vuln.)
* Include a number of upstream bugfixes, including fixes to previous
security fixes, some of which are security-relevant:
x86: correct ordering of operations during S3 resume
x86: suppress BTI mitigations around S3 suspend/resume
x86/spec_ctrl: Updates to retpoline-safety decision making
x86/HPET: fix race triggering ASSERT(cpu < nr_cpu_ids)
x86/HVM: never retain emulated insn cache when exiting back to guest
xpti: fix bug in double fault handling
x86/cpuidle: don't init stats lock more than once
xen: Introduce vcpu_sleep_nosync_locked()
xen/schedule: Fix races in vcpu migration
x86: Fix "x86: further CPUID handling adjustments"
The result is very similar to upstream staging-4.8. However, as
upstream staging-4.8 has not yet passed upstream CI, I have chosen to
cherry pick fixes so that I can drop a couple that don't look
immediately important. We will expect to resynchronise with
upstream's 4.8 stable branch soon.
* Drop our patch `tools: fix arm build after bdf693ee61b48' (which was
needed to build the upstream 4.8 comet branch on ARM but is not needed
for the the upstream staging/stable branch). Closes:#898898.
* Update changelog for 4.8.3+xsa262+shim4.10.0+comet3-1+deb9u6 to
mention branch switch from upstream 4.8 comet to upstream main 4.8,
and add some missing CVEs.
Andrew Cooper [Wed, 9 May 2018 15:25:14 +0000 (16:25 +0100)]
x86/emul: Fix emulator test harness build following a91b2ec337a
Versions of Xen before c/s 5c6c3ac in Xen 4.9 don't use msr-index.h for the
test harness.
Reported-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
(cherry picked from commit e017133490d35eab64c0a61bfb233162fdacccc4)
Gbp-Pq: Name x86emul-fix-emulator-test-harness-build-.patch
As both xen-netfront and xen-blkfront support multi-queue, they would
consume a lot of grant table references when there are many paravirtual
devices and vcpus assigned to guest. Guest domU might panic or hang due to
grant allocation failure when nr_grant_frames in guest has reached its max
value.
This utility would help the administrators to diagnose xen issue. There is
only one command gnttab_query_size so far to monitor the guest grant table
frame usage on dom0 side so that it is not required to debug on guest
kernel side for crash/hang analysis anymore.
It is extensible for adding new commands for more diagnostic functions and
the framework of xen-diag.c is from xen-livepatch.c.
Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
(cherry picked from commit df36d82e3fc91bee2ff1681fd438c815fa324b6a)
Gbp-Pq: Name tools-utility-to-dump-guest-grant-table-.patch
The ramdisk fields were removed. We should use modules[0] instead.
Signed-off-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
(cherry picked from commit db3ae8becc2b4f9f544eafa06a7c858c7cc9f029)
Gbp-Pq: Name tools-fix-arm-build-after-bdf693ee61b48.patch
This is due to the combination of GCC6, and Debian's decision to
enable some hardening flags by default (to try to make runtime
addresses less predictable):
https://wiki.debian.org/Hardening/PIEByDefaultTransition
This is of no benefit for the x86 instruction emulator test, which is
a rebuild of the emulator code for testing purposes only. So pass
options to disable this.
These options will be no-ops if they are the same as the compiler
default.
On amd64, the -fno-pic breaks the build in a different way. So do
this only on i386.
Signed-off-by: Ian Jackson <ian.jackson@citrix.com> CC: Jan Beulich <jbeulich@suse.com> CC: Andrew Cooper <andrew.cooper3@citrix.com>
squash! tools/tests/x86_emulator: Pass -no-pie -fno-pic to gcc
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
Gbp-Pq: Name toolstestsx86_emulator-pass--no-pie--fno.patch
* Update to new upstream version 4.8.3+xsa262+shim4.10.0+comet3.
(This is the upstream staging-4.8 branch, which is ahead of the
upstream CI-tested stable-4.8 branch by precisely the three
most recent XSA fixes.)
* Resulting security fixes:
XSA-258 CVE-2018-10472
XSA-259 CVE-2018-10471
XSA-260 CVE-2018-8897
XSA-261 (No CVE yet)
XSA-262 (No CVE yet)
* Apply two further build fixes from upstream staging-4.8.
Andrew Cooper [Fri, 2 Mar 2018 15:41:29 +0000 (15:41 +0000)]
x86/hvm: Disallow the creation of HVM domains without Local APIC emulation
There are multiple problems, not necesserily limited to:
* Guests which configure event channels via hvmop_set_evtchn_upcall_vector(),
or which hit %cr8 emulation will cause Xen to fall over a NULL vlapic->regs
pointer.
* On Intel hardware, disabling the TPR_SHADOW execution control without
reenabling CR8_{LOAD,STORE} interception means that the guests %cr8
accesses interact with the real TPR. Amongst other things, setting the
real TPR to 0xf blocks even IPIs from interrupting this CPU.
* On hardware which sets up the use of Interrupt Posting, including
IOMMU-Posting, guests run without the appropriate non-root configuration,
which at a minimum will result in dropped interrupts.
Whether no-LAPIC mode is of any use at all remains to be seen.
projects / xen.git / log