Merge version 4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u8+rpi1 and 4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9 to produce 4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9+rpi1

Merge xen (4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9) import into refs/heads/workingbranch

libxl: restore passing "readonly=" to qemu for SCSI disks

A read-only check was introduced for XSA-142, commit ef6cb76026 ("libxl:
relax readonly check introduced by XSA-142 fix") added the passing of
the extra setting, but commit dab0539568 ("Introduce COLO mode and
refactor relevant function") dropped the passing of the setting again,
quite likely due to improper re-basing.

Restore the readonly= parameter to SCSI disks.  For IDE disks this is
supposed to be rejected; add an assert.  And there is a bare ad-hoc
disk drive string in libxl__build_device_model_args_new, which we also
update.

This is XSA-266.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Gbp-Pq: Name libxl-restore-passing-readonly=-to-qemu-.patch

libxl: qemu_disk_scsi_drive_string: Break out common parts of disk config

The generated configurations are identical apart from, in some cases,
reordering of the id=%s element.  So, overall, no functional change.

This is part of XSA-266.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Gbp-Pq: Name libxl-qemu_disk_scsi_drive_string-break-.patch

x86: Refine checks in #DB handler for faulting conditions

One of the fix for XSA-260 (c/s 75d6828bc2 "x86/traps: Fix handling of #DB
exceptions in hypervisor context") added some safety checks to help avoid
livelocks of #DB faults.

While a General Detect #DB exception does have fault semantics, hardware
clears %dr7.gd on entry to the handler, meaning that it is actually safe to
return to.  Furthermore, %dr6.gd is guest controlled and sticky (never cleared
by hardware).  A malicious PV guest can therefore trigger the fatal_trap() and
crash Xen.

Instruction breakpoints are more tricky.  The breakpoint match bits in %dr6
are not sticky, but the Intel manual warns that they may be set for
non-enabled breakpoints, so add a breakpoint enabled check.

Beyond that, because of the restriction on the linear addresses PV guests can
set, and the fault (rather than trap) nature of instruction breakpoints
(i.e. can't be deferred by a MovSS shadow), there should be no way to
encounter an instruction breakpoint in Xen context.  However, for extra
robustness, deal with this situation by clearing the breakpoint configuration,
rather than crashing.

This is XSA-265

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Gbp-Pq: Name x86-refine-checks-in-db-handler-for-faul.patch

x86/mm: don't bypass preemption checks

While unlikely, it is not impossible for a multi-vCPU guest to leverage
bypasses of preemption checks to drive Xen into an unbounded loop.

This is XSA-264.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Gbp-Pq: Name x86mm-dont-bypass-preemption-checks.patch

gitignore: add tools/misc/xen-diag to .gitignore

Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
(cherry picked from commit d23afa6399a78ca7d0ed3294119632535828c9d8)

Gbp-Pq: Name 0031-gitignore-add-tools-misc-xen-diag-to-.gitignore.patch

tools: utility to dump guest grant table info

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 0030-tools-utility-to-dump-guest-grant-table-info.patch

Copy README.pti and README.comet from the XSA-254 advisory

We would like these to be installed with the Debian Xen packages
because they contain usage instructions too.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
Gbp-Pq: Name 0029-Copy-README.pti-and-README.comet-from-the-XSA-254-ad.patch

tools/tests/x86_emulator: Pass -no-pie -fno-pic to gcc on x86_32

The current build fails with GCC6 on Debian sid i386 (unstable):

 /tmp/ccqjaueF.s: Assembler messages:
 /tmp/ccqjaueF.s:3713: Error: missing or invalid displacement expression `vmovd_to_reg_len@GOT'

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 0028-tools-tests-x86_emulator-Pass-no-pie-fno-pic-to-gcc-.patch

ubuntu-tools-libs-abiname

Gbp-Pq: Name ubuntu-tools-libs-abiname.diff

tools-xenstore-compatibility.diff

Patch-Name: tools-xenstore-compatibility.diff

Gbp-Pq: Name tools-xenstore-compatibility.diff

tools-xenmon-install.diff

Patch-Name: tools-xenmon-install.diff

Gbp-Pq: Name tools-xenmon-install.diff

tools-include-install.diff

Patch-Name: tools-include-install.diff

Gbp-Pq: Name tools-include-install.diff

Remove static solaris support from pygrub

Patch-Name: tools-pygrub-remove-static-solaris-support

Gbp-Pq: Name tools-pygrub-remove-static-solaris-support

tools-xentrace-prefix.diff

Patch-Name: tools-xentrace-prefix.diff

Gbp-Pq: Name tools-xentrace-prefix.diff

tools-xenstore-prefix.diff

Patch-Name: tools-xenstore-prefix.diff

Gbp-Pq: Name tools-xenstore-prefix.diff

tools-xenstat-prefix.diff

Patch-Name: tools-xenstat-prefix.diff

Gbp-Pq: Name tools-xenstat-prefix.diff

tools-xenpmd-prefix.diff

Patch-Name: tools-xenpmd-prefix.diff

Gbp-Pq: Name tools-xenpmd-prefix.diff

tools-xenpaging-prefix.diff

Patch-Name: tools-xenpaging-prefix.diff

Gbp-Pq: Name tools-xenpaging-prefix.diff

tools-xenmon-prefix.diff

Patch-Name: tools-xenmon-prefix.diff

Gbp-Pq: Name tools-xenmon-prefix.diff

tools-xcutils-rpath.diff

Patch-Name: tools-xcutils-rpath.diff

Gbp-Pq: Name tools-xcutils-rpath.diff

tools-python-prefix.diff

Patch-Name: tools-python-prefix.diff

Gbp-Pq: Name tools-python-prefix.diff

tools-pygrub-prefix.diff

Patch-Name: tools-pygrub-prefix.diff

Gbp-Pq: Name tools-pygrub-prefix.diff

tools-misc-prefix.diff

Patch-Name: tools-misc-prefix.diff

Gbp-Pq: Name tools-misc-prefix.diff

tools-libxl-prefix.diff

Patch-Name: tools-libxl-prefix.diff

Gbp-Pq: Name tools-libxl-prefix.diff

tools-libfsimage-prefix.diff

Patch-Name: tools-libfsimage-prefix.diff

Gbp-Pq: Name tools-libfsimage-prefix.diff

tools-console-prefix.diff

Patch-Name: tools-console-prefix.diff

Gbp-Pq: Name tools-console-prefix.diff

tools-blktap2-prefix.diff

Patch-Name: tools-blktap2-prefix.diff

Gbp-Pq: Name tools-blktap2-prefix.diff

tools-rpath.diff

Patch-Name: tools-rpath.diff

Gbp-Pq: Name tools-rpath.diff

tools-xenstat-abiname.diff

Patch-Name: tools-xenstat-abiname.diff

Gbp-Pq: Name tools-xenstat-abiname.diff

tools-libxl-abiname.diff

Patch-Name: tools-libxl-abiname.diff

Gbp-Pq: Name tools-libxl-abiname.diff

tools-libxc-abiname.diff

Patch-Name: tools-libxc-abiname.diff

Gbp-Pq: Name tools-libxc-abiname.diff

tools-libfsimage-abiname.diff

Patch-Name: tools-libfsimage-abiname.diff

Gbp-Pq: Name tools-libfsimage-abiname.diff

config-prefix.diff

Patch-Name: config-prefix.diff

Gbp-Pq: Name config-prefix.diff

version

Patch-Name: version.diff

Gbp-Pq: Name version.diff

Rerun autogen.sh (stretch)

Using autoconf 2.69-10 (amd64)

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
Gbp-Pq: Name 0001-Rerun-autogen.sh-stretch.patch

xen (4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9) stretch-security; urgency=high

  * Security upload [thanks to Wolodja Wentland]:
       XSA-264 (no CVE yet)
       XSA-265 (no CVE yet)
       XSA-266 (no CVE yet)

[dgit import unpatched xen 4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9]

Import xen_4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9.debian.tar.xz

[dgit import tarball xen 4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9 xen_4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9.debian.tar.xz]

Merge version 4.8.3+xsa262+shim4.10.0+comet3-1+deb9u7+rpi1 and 4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u8 to produce 4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u8+rpi1

Merge xen (4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u8) import into refs/heads/workingbranch

Import xen_4.8.3+xsa267+shim4.10.1+xsa267.orig.tar.xz

[dgit import orig xen_4.8.3+xsa267+shim4.10.1+xsa267.orig.tar.xz]

Import xen_4.8.3+xsa267+shim4.10.1+xsa267.orig-shim.tar.xz

[dgit import orig xen_4.8.3+xsa267+shim4.10.1+xsa267.orig-shim.tar.xz]

gitignore: add tools/misc/xen-diag to .gitignore

Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
(cherry picked from commit d23afa6399a78ca7d0ed3294119632535828c9d8)

Gbp-Pq: Name 0031-gitignore-add-tools-misc-xen-diag-to-.gitignore.patch

tools: utility to dump guest grant table info

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 0030-tools-utility-to-dump-guest-grant-table-info.patch

Copy README.pti and README.comet from the XSA-254 advisory

We would like these to be installed with the Debian Xen packages
because they contain usage instructions too.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
Gbp-Pq: Name 0029-Copy-README.pti-and-README.comet-from-the-XSA-254-ad.patch

tools/tests/x86_emulator: Pass -no-pie -fno-pic to gcc on x86_32

The current build fails with GCC6 on Debian sid i386 (unstable):

 /tmp/ccqjaueF.s: Assembler messages:
 /tmp/ccqjaueF.s:3713: Error: missing or invalid displacement expression `vmovd_to_reg_len@GOT'

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 0028-tools-tests-x86_emulator-Pass-no-pie-fno-pic-to-gcc-.patch

ubuntu-tools-libs-abiname

Gbp-Pq: Name ubuntu-tools-libs-abiname.diff

tools-xenstore-compatibility.diff

Patch-Name: tools-xenstore-compatibility.diff

Gbp-Pq: Name tools-xenstore-compatibility.diff

tools-xenmon-install.diff

Patch-Name: tools-xenmon-install.diff

Gbp-Pq: Name tools-xenmon-install.diff

tools-include-install.diff

Patch-Name: tools-include-install.diff

Gbp-Pq: Name tools-include-install.diff

Remove static solaris support from pygrub

Patch-Name: tools-pygrub-remove-static-solaris-support

Gbp-Pq: Name tools-pygrub-remove-static-solaris-support

tools-xentrace-prefix.diff

Patch-Name: tools-xentrace-prefix.diff

Gbp-Pq: Name tools-xentrace-prefix.diff

tools-xenstore-prefix.diff

Patch-Name: tools-xenstore-prefix.diff

Gbp-Pq: Name tools-xenstore-prefix.diff

tools-xenstat-prefix.diff

Patch-Name: tools-xenstat-prefix.diff

Gbp-Pq: Name tools-xenstat-prefix.diff

tools-xenpmd-prefix.diff

Patch-Name: tools-xenpmd-prefix.diff

Gbp-Pq: Name tools-xenpmd-prefix.diff

tools-xenpaging-prefix.diff

Patch-Name: tools-xenpaging-prefix.diff

Gbp-Pq: Name tools-xenpaging-prefix.diff

tools-xenmon-prefix.diff

Patch-Name: tools-xenmon-prefix.diff

Gbp-Pq: Name tools-xenmon-prefix.diff

tools-xcutils-rpath.diff

Patch-Name: tools-xcutils-rpath.diff

Gbp-Pq: Name tools-xcutils-rpath.diff

tools-python-prefix.diff

Patch-Name: tools-python-prefix.diff

Gbp-Pq: Name tools-python-prefix.diff

tools-pygrub-prefix.diff

Patch-Name: tools-pygrub-prefix.diff

Gbp-Pq: Name tools-pygrub-prefix.diff

tools-misc-prefix.diff

Patch-Name: tools-misc-prefix.diff

Gbp-Pq: Name tools-misc-prefix.diff

tools-libxl-prefix.diff

Patch-Name: tools-libxl-prefix.diff

Gbp-Pq: Name tools-libxl-prefix.diff

tools-libfsimage-prefix.diff

Patch-Name: tools-libfsimage-prefix.diff

Gbp-Pq: Name tools-libfsimage-prefix.diff

tools-console-prefix.diff

Patch-Name: tools-console-prefix.diff

Gbp-Pq: Name tools-console-prefix.diff

tools-blktap2-prefix.diff

Patch-Name: tools-blktap2-prefix.diff

Gbp-Pq: Name tools-blktap2-prefix.diff

tools-rpath.diff

Patch-Name: tools-rpath.diff

Gbp-Pq: Name tools-rpath.diff

tools-xenstat-abiname.diff

Patch-Name: tools-xenstat-abiname.diff

Gbp-Pq: Name tools-xenstat-abiname.diff

tools-libxl-abiname.diff

Patch-Name: tools-libxl-abiname.diff

Gbp-Pq: Name tools-libxl-abiname.diff

tools-libxc-abiname.diff

Patch-Name: tools-libxc-abiname.diff

Gbp-Pq: Name tools-libxc-abiname.diff

tools-libfsimage-abiname.diff

Patch-Name: tools-libfsimage-abiname.diff

Gbp-Pq: Name tools-libfsimage-abiname.diff

config-prefix.diff

Patch-Name: config-prefix.diff

Gbp-Pq: Name config-prefix.diff

version

Patch-Name: version.diff

Gbp-Pq: Name version.diff

Rerun autogen.sh (stretch)

Using autoconf 2.69-10 (amd64)

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
Gbp-Pq: Name 0001-Rerun-autogen.sh-stretch.patch

xen (4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u8) stretch-security; urgency=high

  * Update to new upstream version 4.8.3+xsa267+shim4.10.1+xsa267.
       XSA-267 CVE-2018-3665

    I have actually taken upstream's staging-4.8 CI input branch, which is
    identical to the CI-tested stable-4.8 except that it also has the
    XSA-267 patches.  There are additional patches in upstream's
    stable-4.8 branch, beyond what was in the previous Debian stretch
    security update, which are prerequisites for the XSA-267 patches.

    For the shim, I have updated to upstream's staging-4.10, which is
    identical to the CI-tested stable-4.10q except, again, for
    XSA-267-related patches.  The 4.10.0-comet branch lacks speculation
    control entirely and has been superseded upstream.

[dgit import unpatched xen 4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u8]

Import xen_4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u8.debian.tar.xz

[dgit import tarball xen 4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u8 xen_4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u8.debian.tar.xz]

Merge version 4.8.3+comet2+shim4.10.0+comet3-1+deb9u5+rpi1 and 4.8.3+xsa262+shim4.10.0+comet3-1+deb9u7 to produce 4.8.3+xsa262+shim4.10.0+comet3-1+deb9u7+rpi1

Merge xen (4.8.3+xsa262+shim4.10.0+comet3-1+deb9u7) import into refs/heads/workingbranch

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

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

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

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:

  (XEN) Speculative mitigation facilities:
  (XEN)   Hardware features: IBRS/IBPB STIBP IBPB
  (XEN)   Compiled-in support: INDIRECT_THUNK
  (XEN)   Xen settings: BTI-Thunk RETPOLINE, SPEC_CTRL: IBRS-, Other: IBPB
  (XEN)   Support for VMs: PV: None, HVM: MSR_SPEC_CTRL RSB
  (XEN)   XPTI (64-bit PV only): Dom0 enabled, DomU enabled

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

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

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

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

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

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

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

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

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

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

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

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:

* Grab lock
* vcpu_migrate_start()
* Release lock
* vcpu_migrate_finish()

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Reviewed-by: Dario Faggioli <dfaggioli@suse.com>
Tested-by: Olaf Hering <olaf@aepfle.de>
master commit: 9a36de177c16d6423a07ad61f1c7af5274769aae
master date: 2018-05-03 11:56:48 +0100

(cherry picked from commit eaa9d0a9ae016901801889cac9ef4d37374e5215)

Gbp-Pq: Name xenschedule-fix-races-in-vcpu-migration.patch

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.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Reviewed-by: Dario Faggioli <dfaggioli@suse.com>
master commit: da0a5e00de8aa93f2a7482d138dbee9dec2aa5c2
master date: 2018-05-03 11:56:36 +0100

(cherry picked from commit d66898a15d47779a608f30413cdf629389f5037a)

Gbp-Pq: Name xen-introduce-vcpu_sleep_nosync_locked.patch

x86/cpuidle: don't init stats lock more than once

Osstest flight 122363, having hit an NMI watchdog timeout, shows CPU1 at

Xen call trace:
   [<ffff82d08023d3f4>] _spin_lock+0x30/0x57
   [<ffff82d0802d9346>] update_last_cx_stat+0x29/0x42
   [<ffff82d0802d96f3>] cpu_idle.c#acpi_processor_idle+0x2ff/0x596
   [<ffff82d080276713>] domain.c#idle_loop+0xa8/0xc3

and CPU0 at

Xen call trace:
   [<ffff82d08023d173>] on_selected_cpus+0xb7/0xde
   [<ffff82d0802dbe22>] powernow.c#powernow_cpufreq_target+0x110/0x1cb
   [<ffff82d080257973>] __cpufreq_driver_target+0x43/0xa6
   [<ffff82d080256b0d>] cpufreq_governor_dbs+0x324/0x37a
   [<ffff82d080257bf2>] __cpufreq_set_policy+0xfa/0x19d
   [<ffff82d080256044>] cpufreq_add_cpu+0x3a1/0x5df
   [<ffff82d0802dbab4>] cpufreq_cpu_init+0x17/0x1a
   [<ffff82d0802567a8>] set_px_pminfo+0x2b6/0x2f7
   [<ffff82d08029f1bf>] do_platform_op+0xe75/0x1977
   [<ffff82d0803712c5>] pv_hypercall+0x1f4/0x440
   [<ffff82d0803784a5>] lstar_enter+0x115/0x120

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

(cherry picked from commit f2837b5f11394fc8107f0a06b2cebaa4f8d42d7c)

Gbp-Pq: Name x86cpuidle-dont-init-stats-lock-more-tha.patch

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

(cherry picked from commit 210bd51a2e7ba0063fe5695fef441ac2d52d8f2e)

Gbp-Pq: Name xpti-fix-bug-in-double-fault-handling.patch

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

(cherry picked from commit b4ad8a6f152efbd426ce6d11a13f955798fde2cf)

Gbp-Pq: Name x86hvm-never-retain-emulated-insn-cache-.patch

x86/HPET: fix race triggering ASSERT(cpu < nr_cpu_ids)

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

(cherry picked from commit 4cdd4cc106433921dd46a471148411cb91150a4a)

Gbp-Pq: Name x86hpet-fix-race-triggering-assertcpu--n.patch

x86/spec_ctrl: Updates to retpoline-safety decision making

All of this is as recommended by the Intel whitepaper:

https://software.intel.com/sites/default/files/managed/1d/46/Retpoline-A-Branch-Target-Injection-Mitigation.pdf

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

(cherry picked from commit 193130f53f2206354e9f4226a2b3566d472d1a2c)

Gbp-Pq: Name x86spec_ctrl-updates-to-retpoline-safety.patch

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.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 710a8ebf2bc111a34bba04d1c85b6d07ed3d9389
master date: 2018-04-16 14:09:55 +0200
master commit: ef3ab46493f650b7e5cca2b2578a99ca0cbff195
master date: 2018-04-19 10:55:59 +0100

(cherry picked from commit 7f2959f8f6d0ad9fc92fe020ae6ad9a5708dd45e)

Gbp-Pq: Name x86-suppress-bti-mitigations-around-s3-s.patch