VMExit doesn't switch all state. The FS/GS/TS/LDTR/GSBASE segment
information, and SYSCALL/SYSENTER MSRs may still be cached in hardware, rather
than up-to-date in the VMCB.
Export svm_sync_vmcb() via svmdebug.h so svm_vmcb_dump() can use it, and bring
the VMCB into sync in current context.
As a minor optimisation, switch svm_sync_vmcb() to use svm_vm{load,save}_pa(),
as svm->vmcb_pa is always correct, and this avoids a redundant __pa()
translation behind the scenes.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Brian Woods <brian.woods@amd.com>
This code was never updated when the 32bit build of Xen was dropped.
* Expand the now-redundant ptr_reg macro.
* The number of iterations in the loop can be halfed by using 64bit writes,
without consuming any extra execution resource in the pipeline. Adjust all
numbers/offsets appropriately.
* Replace dec with sub to avoid a eflags stall, and position it to be
macro-fused with the related jmp.
* With no need to preserve eflags across the body of the loop, replace lea
with add which has 1/3'rd the latency on basically all 64bit hardware.
A quick userspace perf test on my Haswell dev box indicates that the old
version takes ~1385 cycles on average (ignoring outliers), and the new version
takes ~1060 cyles, or about 77% of the time.
Reported-by: Edwin Török <edvin.torok@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The current code in do_boot_cpu() makes a CMOS write (even in the case of an
FADT reduced hardware configuration) and two writes into the BDA for the
start_eip segment and offset.
BDA 0x67 and 0x69 hail from the days of the DOS and the 286, when IBM put
together the fast way to return from Protected Mode back to Real Mode (via a
deliberate triple fault). This vector, when set, redirects the early boot
logic back into OS control.
It is also used by early MP systems, before the Startup IPI message became
standard, which in practice was before Local APICs became integrated into CPU
cores.
Support for non-integrated APICs was dropped in c/s 7b0007af "xen/x86: Remove
APIC_INTEGRATED() checks" because there are no 64-bit capable systems without
them. Therefore, drop smpboot_{setup,restore}_warm_reset_vector().
Dropping smpboot_setup_warm_reset_vector() also lets us drop
TRAMPOLINE_{HIGH,LOW}, which lets us drop mach_wakecpu.h entirely. The final
function in smpboot_hooks.h is smpboot_setup_io_apic() and has a single
caller, so expand it inline and delete smpboot_hooks.h as well.
This removes all reliance on CMOS and the BDA from the AP boot path, which is
especially of interest on reduced_hardware boots and EFI systems.
This was discovered while investigating Xen's use of the BDA during kexec.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
A recent rebuild of the CI contaniers switched from Fedora 29 to 30 because
the dockerfile is targetting latest.
Unfortunately, the version of iPXE in master doesn't build with the default
GCC in Fedora 30, which is blocking all CI activity.
Switch from latest to an explicit version, to avoid future breakage.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Doug Goldstein <cardoe@cardoe.com>
Currently, booting staging fails with:
(XEN) Using APIC driver default
(XEN) ----[ Xen-4.13-unstable x86_64 debug=y Not tainted ]----
(XEN) CPU: 0
(XEN) RIP: e008:[<ffff82d08038f66e>] __x86_indirect_thunk_rax+0xe/0x10
(XEN) RFLAGS: 0000000000010016 CONTEXT: hypervisor
(XEN) rax: c2c2c2c2c2c2c2c2 rbx: ffff83003f4cc000 rcx: 0000000000000000
<snip>
(XEN) Xen code around <ffff82d08038f66e> (__x86_indirect_thunk_rax+0xe/0x10):
(XEN) ae e8 eb fb 48 89 04 24 <c3> 90 e8 05 00 00 00 0f ae e8 eb fb 48 89 0c 24
(XEN) Xen stack trace from rsp=ffff82d080827d28:
(XEN) c2c2c2c2c2c2c2c2 ffff82d080207588 ffff82d080827d68 0000000000000000
<snip>
(XEN) Xen call trace:
(XEN) [<ffff82d08038f66e>] __x86_indirect_thunk_rax+0xe/0x10
(XEN) [<ffff82d0806078a9>] setup_system_domains+0x18/0xab
(XEN) [<ffff82d08062d9c8>] __start_xen+0x1ea9/0x2935
(XEN) [<ffff82d0802000f3>] __high_start+0x53/0x55
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) GENERAL PROTECTION FAULT
(XEN) [error_code=0000]
(XEN) ****************************************
UBSAN (which I happened to have active in my build at the time) identifies the
problem explicitly:
(XEN) Using APIC driver default
(XEN) ================================================================================
(XEN) UBSAN: Undefined behaviour in /local/xen.git/xen/include/xsm/xsm.h:309:19
(XEN) member access within null pointer of type 'struct xsm_operations'
(XEN) ----[ Xen-4.13-unstable x86_64 debug=y Not tainted ]----
"adjust system domain creation (and call it earlier on x86)" didn't account
for the fact that domain_create() depends on XSM already being set up.
Therefore, domain_create() follows xsm_ops->alloc_security_domain() which is
offset 0 from a NULL pointer, meaning that we execute the 16bit IVT until
happening to explode in __x86_indirect_thunk_rax().
There is nothing very interesting that xsm_multiboot_init() does more than
allocating memory, which means that it is safe to move earlier during setup.
The resulting boot now looks like:
(XEN) Using APIC driver default
(XEN) XSM Framework v1.0.0 initialized
(XEN) Flask: 128 avtab hash slots, 283 rules.
(XEN) Flask: 128 avtab hash slots, 283 rules.
(XEN) Flask: 4 users, 3 roles, 38 types, 2 bools
(XEN) Flask: 13 classes, 283 rules
(XEN) Flask: Starting in enforcing mode.
(XEN) ACPI: v5 SLEEP INFO: control[0:0], status[0:0]
and
(XEN) Using APIC driver default
(XEN) XSM Framework v1.0.0 initialized
(XEN) Initialising XSM SILO mode
(XEN) ACPI: v5 SLEEP INFO: control[0:0], status[0:0]
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
UBSAN reports:
(XEN) ================================================================================
(XEN) UBSAN: Undefined behaviour in x86_64/mm.c:1108:31
(XEN) left shift of 255 by 24 places cannot be represented in type 'int'
(XEN) ----[ Xen-4.13-unstable x86_64 debug=y Tainted: H ]----
(XEN) CPU: 60
(XEN) RIP: e008:[<ffff82d0802a54ce>] ubsan.c#ubsan_epilogue+0xa/0xc2
<snip>
(XEN) Xen call trace:
(XEN) [<ffff82d0802a54ce>] ubsan.c#ubsan_epilogue+0xa/0xc2
(XEN) [<ffff82d0802a6009>] __ubsan_handle_shift_out_of_bounds+0x15d/0x16c
(XEN) [<ffff82d08033abd7>] check_descriptor+0x191/0x3dd
(XEN) [<ffff82d0804ef920>] do_update_descriptor+0x7f/0x2b6
(XEN) [<ffff82d0804efb75>] compat_update_descriptor+0x1e/0x20
(XEN) [<ffff82d0804fa1cc>] pv_hypercall+0x87f/0xa6f
(XEN) [<ffff82d080501acb>] do_entry_int82+0x53/0x58
(XEN) [<ffff82d08050702b>] entry_int82+0xbb/0xc0
(XEN)
(XEN) ================================================================================
As this is a constant, express it in longhand for correctness, and consistency
with the surrounding code.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
There is now enough complexity that a fuzzing harness is a good idea, and
enough supporting logic to implement one which AFL seems happy with.
Take the existing recalculate_synth() helper and export it as
x86_cpuid_policy_recalc_synth(), as it is needed by the fuzzing harness.
While editing the MAINTAINERS file, insert a related entry which was
accidentally missed from c/s 919ddc3c0 "tools/cpu-policy: Add unit tests", and
sort the lines.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
When merging a levelled policy, stale out-of-range leaves may remain.
Introduce a helper to clear them, and test a number of the subtle corner
cases.
The logic based on cpuid_policy_xstates() is liable to need changing when XCR0
has bit 63 defined. Leave BUILD_BUG_ON()'s behind with comments in all all
impacted areas, which includes in x86_cpuid_policy_fill_native().
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This #ifdef-ary isn't necessary, and the logic can live in a plain if()
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
* Drop redundant brackes, and inline qualifiers.
* Insert newlines and spaces where appropriate.
* Drop redundant NDEBUG - gdprint() is already conditional. Fix the
logging level, as gdprintk() already prefixes the guest marker.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
vm_event_resume() should use domain_vcpu(), rather than opencoding it
without its Spectre v1 safety.
vm_event_wake_blocked() can't ever be invoked in a case where d->vcpu is
NULL, so drop the outer if() and reindent, fixing up style issues.
The comment, which is left alone, is false. This algorithm still has
starvation issues when there is an asymetric rate of generated events.
However, the existing logic is sufficiently complicated and fragile that
I don't think I've followed it fully, and because we're trying to
obsolete this interface, the safest course of action is to leave it
alone, rather than to end up making things subtly different.
Therefore, no practical change that callers would notice.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
The use of (*ved)-> leads to poor code generation, as the compiler can't
assume the pointer hasn't changed, and results in hard-to-follow code.
For both vm_event_{en,dis}able(), rename the ved parameter to p_ved, and
work primarily with a local ved pointer.
This has a key advantage in vm_event_enable(), in that the partially
constructed vm_event_domain only becomes globally visible once it is
fully constructed. As a consequence, the spinlock doesn't need holding.
Furthermore, rearrange the order of operations to be more sensible.
Check for repeated enables and an bad HVM_PARAM before allocating
memory, and gather the trivial setup into one place, dropping the
redundant zeroing.
No practical change that callers will notice.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
These serve no purpose, but to add to the congnitive load of following
the code. Remove the level of indirection.
Furthermore, the lock protects all data in vm_event_domain, making
ring_lock a poor choice of name.
For vm_event_get_response() and vm_event_grab_slot(), fold the exit
paths to have a single unlock, as the compiler can't make this
optimisation itself.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
This parameter isn't used at all. Futhermore, elide the copyback in
failing cases, as it is only successful paths which generate data which
needs sending back to the caller.
Finally, drop a redundant d == NULL check, as that logic is all common
at the begining of do_domctl().
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Drop the ap2m_active boolean, and consistently use the unlocking form:
if ( p2m != hostp2m )
__put_gfn(p2m, gfn);
__put_gfn(hostp2m, gfn);
which makes it clear that we always unlock the altp2m's gfn if it is in use,
and always unlock the hostp2m's gfn. This also drops the ternary expression
in the logdirty case.
Extend the logdirty comment to identify where the locking violation is liable
to occur.
No (intended) overall change in behaviour.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
When you boot Xen with the default 256 NR_CPUS, on a box with rather more
processors, the resulting spew is unnecesserily verbose. Instead, print the
message once, e.g:
(XEN) ACPI: X2APIC (apic_id[0x115] uid[0x115] enabled)
(XEN) WARNING: NR_CPUS limit of 256 reached - ignoring further processors
(XEN) ACPI: X2APIC (apic_id[0x119] uid[0x119] enabled)
(XEN) ACPI: X2APIC (apic_id[0x11d] uid[0x11d] enabled)
(XEN) ACPI: X2APIC (apic_id[0x121] uid[0x121] enabled)
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reflow the ZynqMP message for grepability, and fix the omission of a newline.
There is a race condition where multiple cpus could race to set once_ boolean.
However, the use of this construct is mainly useful for boot time code, and
the only consequence of the race is a repeated print message.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
They are both Airmont-based and should have been included in c/s 17f74242cc
"x86/spec-ctrl: Extend repoline safey calcuations for eIBRS and Atom parts".
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The various pieces of the hypercall page infrastructure have grown
organically over time and ended up in a bit of a mess.
* Rename all functions to be of the form *_init_hypercall_page(). This
makes them somewhat shorter, and means they can actually be grepped
for in one go.
* Move init_hypercall_page() to domain.c. The 64-bit traps.c isn't a
terribly appropriate place for it to live.
* Drop an obsolete comment from hvm_init_hypercall_page() and drop the
domain parameter from hvm_funcs.init_hypercall_page() as it isn't
necessary.
* Rearrange the logic in the each function to avoid needing extra local
variables, and to write the page in one single pass.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Drop introduced trailing whitespace, excessively long lines, mal-indention,
superfluous use of PRI macros for int-or-smaller types, and incorrect PRI
macros for gfns and mfns.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
GCC 4.4 (as included in CentOS 6) is too old to handle designated initialisers
in anonymous unions. As this is just a developer tool, skip the test in this
case, rather than sacraficing the legibility/expresibility of the test cases.
This fixes the Gitlab CI tests.
While adding this logic to cpu-polcy, adjust the equivelent logic from
x86_emulator on which this was based. Printing:
Test harness not built, use newer compiler than "gcc"
isn't helpful for anyone unexpectedly encountering the error.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
We currently have an asymmetric setup where CONFIG_VERBOSE_DEBUG controls
extra diagnostics for a PV dom0, and opt_dom0_verbose controls extra
diagnostics for a PVH dom0.
Default opt_dom0_verbose to CONFIG_VERBOSE_DEBUG and use opt_dom0_verbose
consistently.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This would have been very handy when debugging some pv-l1tf issues. As there
is no cost to supporting it, wire it up.
Due to the way dom0 is constructed, switching into shadow mode must be done
after the pagetables are written, and because of partially being in dom0
context, shadow_enable() doesn't like the state it finds.
Reuse the pv_l1tf tasklet for convenience, which will switch dom0 into shadow
mode just before it starts executing.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
For consistency with other command line options.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
One path in dom0_construct_pv() returns -1 unlike all other error paths.
Switch it to returning -EINVAL.
This was last modified by c/s c84481fb XSA-55, but the bug predates that
series. However, this patch did (for no obvious reason) introduce a
bifurcated tail to the function with two subtly different elf_check_broken()
clauses.
As the elf_check_broken() is just a warning and doesn't influence the further
boot, fold the exit paths together and use a single clause.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
x86_cpuid_copy_to_buffer() currently serialises the full content of the
various subleaf unions. While leaves 4, 0xb and 0xd don't have a concrete
max_subleaf field, they do have well defined upper bounds.
Diffing the results of `xen-cpuid -p` shows the resulting saving:
@@ -1,5 +1,5 @@
Xen reports there are maximum 114 leaves and 1 MSRs
-Raw policy: 93 leaves, 1 MSRs
+Raw policy: 38 leaves, 1 MSRs
CPUID:
leaf subleaf -> eax ebx ecx edx
00000000:ffffffff -> 00000016:756e6547:6c65746e:49656e69
@@ -32,7 +32,7 @@ Raw policy: 93 leaves, 1 MSRs
MSRs:
index -> value
000000ce -> 0000000080000000
-Host policy: 93 leaves, 1 MSRs
+Host policy: 33 leaves, 1 MSRs
CPUID:
leaf subleaf -> eax ebx ecx edx
00000000:ffffffff -> 0000000d:756e6547:6c65746e:49656e69
which is mostly due to no longer writing out 64 leaves for xstate when (on
this CoffeeLake system) 8 will do.
Extend the unit tests to cover empty and partially filled subleaf unions.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This avoids opencoding the slightly-awkward logic. More uses of these
wrappers will be introduced shortly.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Lightweight Profiling was introduced in Bulldozer (Fam15h), but was dropped
from Zen (Fam17h) processors. Furthermore, LWP was dropped from Fam15/16 CPUs
when IBPB for Spectre v2 was introduced in microcode, owing to LWP not being
used in practice.
As a result, CPUs which are operating within specification (i.e. with up to
date microcode) no longer have this feature, and therefore are not using it.
Drop support from Xen. The main motivation here is to remove unnecessary
complexity from CPUID handling, but it also tidies up the SVM code nicely.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Brian Woods <brian.woods@amd.com>
During initcalls is ok, but is a rather random place to find the build-id:
(XEN) Parked 2 CPUs
(XEN) build-id: 7ff05f78ebc8141000b9feee4370a408bd935dec
(XEN) Running stub recovery selftests...
Logically, it is version information, so print with the changeset information
in console_init_preirq():
(XEN) Xen version 4.13-unstable (andrewcoop@andrecoop) (gcc (Debian 4.9.2-10+deb8u2) 4.9.2) debug=y Fri Apr 12 18:24:52 BST 2019
(XEN) Latest ChangeSet: Fri Apr 5 14:39:42 2019 git:fc6c7ae-dirty
(XEN) build-id: 7ff05f78ebc8141000b9feee4370a408bd935dec
(XEN) PVH start info: (pa 0000ffc0)
Nothing has ever cared about xen_build_init()'s return value, so convert it to
void rather than include errno.h into the !BUILD_ID case of version.h
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
They are identical, so provide a single x86emul_cpuid() instead.
As x86_emulate() now only uses the ->cpuid() hook for real CPUID instructions,
the hook can be omitted from all special-purpose emulation ops.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
For a release build of xen, this removes nearly 5k of code volume, and removes
a function pointer call from every instantiation.
add/remove: 0/1 grow/shrink: 0/3 up/down: 0/-4822 (-4822)
Function old new delta
adjust_bnd 260 244 -16
x86_decode 8915 8890 -25
vcpu_has.isra 129 - -129
x86_emulate 130040 125388 -4652
Total: Before=3326565, After=3321743, chg -0.14%
Note that one corner case changes. At the moment, it is possible for an
entity making direct DOMCTL_set_cpuid hypercalls to construct a policy with
max_leaf < 7, but feature bits set in leaf 7. By default, libxc and libxl
don't do this, and the result is properly bounded by what the hardware is
capable of (so we won't start trying to use instructions which don't exist in
the CPU).
Previously, the cpuid() hook would end up hiding these features, but they may
still be set cpuid_policy, and therefore might start being accepted by
x86_emulate().
This corner case will be fixed by the in-progress DOMCTL_set_cpu_policy work,
and a guest would only encounter the corner case if it was constructed in a
non-standard manner, and if tried using instruction which it couldn't see
CPUID feature bits for. As such, it isn't a corner case which we need to
worry about.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The Microarchitectural Data Sampling vulnerability is split into categories
with subtly different properties:
MLPDS - Microarchitectural Load Port Data Sampling
MSBDS - Microarchitectural Store Buffer Data Sampling
MFBDS - Microarchitectural Fill Buffer Data Sampling
MDSUM - Microarchitectural Data Sampling Uncacheable Memory
MDSUM is a special case of the other three, and isn't distinguished further.
These issues pertain to three microarchitectural buffers. The Load Ports, the
Store Buffers and the Fill Buffers. Each of these structures are flushed by
the new enhanced VERW functionality, but the conditions under which flushing
is necessary vary.
For this concise overview of the issues and default logic, the abbreviations
SP (Store Port), FB (Fill Buffer), LP (Load Port) and HT (Hyperthreading) are
used for brevity:
* Vulnerable hardware is divided into two categories - parts which suffer
from SP only, and parts with any other combination of vulnerabilities.
* SP only has an HT interaction when the thread goes idle, due to the static
partitioning of resources. LP and FB have HT interactions at all points,
due to the competitive sharing of resources. All issues potentially leak
data across the return-to-guest transition.
* The microcode which implements VERW flushing also extends MSR_FLUSH_CMD, so
we don't need to do both on the HVM return-to-guest path. However, some
parts are not vulnerable to L1TF (therefore have no MSR_FLUSH_CMD), but are
vulnerable to MDS, so do require VERW on the HVM path.
Note that we deliberately support mds=1 even without MD_CLEAR in case the
microcode has been updated but the feature bit not exposed.
This is part of XSA-297, CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Three synthetic features are introduced, as we need individual control of
each, depending on circumstances. A later change will enable them at
appropriate points.
The verw_sel field doesn't strictly need to live in struct cpu_info. It lives
there because there is a convenient hole it can fill, and it reduces the
complexity of the SPEC_CTRL_EXIT_TO_{PV,HVM} assembly by avoiding the need for
any temporary stack maintenance.
This is part of XSA-297, CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The MD_CLEAR feature can be automatically offered to guests. No
infrastructure is needed in Xen to support the guest making use of it.
This is part of XSA-297, CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
* Identify BTI in the spec_ctrl_{enter,exit}_idle() comments, as other
mitigations will shortly appear.
* Use alternative_input() and cover the lack of memory cobber with a further
barrier.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
* Use domain_vcpu() rather than opencoding the lookup. Amongst other things,
domain_vcpu() is spectre-v1-safe.
* Unlock the domain immediately after arch_set_info_guest() completes. There
is no need for free_vcpu_guest_context() to be within the critical region,
and moving the call simplifies the error case.
No practical change in functionality.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
* Use XFREE() instead of opencoding it in nvmx_cpu_dead()
* Avoid redundant evaluations of per_cpu()
* Don't allocate vvmcs_buf at all if it isn't going to be used. It is never
touched on hardware lacking the VMCS Shadowing feature.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
... because its already hard enough to follow. Cross reference the locations
in C which set the entrypoints up, and state the alignment requirements and
entry conditions.
Drop a redundant .align 16, and panic() in do_boot_cpu() if the AP trampoline
isn't set up properly rather than blindly continuing and letting the APs
execute junk, or shifting part of the address into unrelated fields in ICR.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
c/s ebb26b509f "xen/x86: make VGA support selectable" added an #ifdef
CONFIG_VIDEO into the middle the backing space for early_boot_opts_t,
but didn't adjust the structure definition in cmdline.c
This only functions correctly because the affected fields are at the end
of the structure, and cmdline.c doesn't write to them in this case.
To retain the slimming effect of compiling out CONFIG_VIDEO, adjust
cmdline.c with enough #ifdef-ary to make C's idea of the structure match
the declaration in asm. This requires adding __maybe_unused annotations
to two helper functions.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Currently, configuration of the SYSENTER MSRs are behind a vendor check for
Intel and Centaur, but this misses Zhaoxin.
Use the feature bit, rather than a vendor check. cpu_has_sep is cleared early
for AMD processors, which can't use SYSENTER/SYSEXIT when operating in long
mode.
Suggested-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Previous attempts to fix this leak didn't identify the root cause, and
ultimately failed. The cause is actually the CPU_UP_PREPARE case
(re)initialising ts->heap back to dummy_heap, which leaks the previous
allocation.
Rearrange the logic to only initialise ts once. This also avoids the
redundant (but benign, due to ts->inactive always being empty) initialising of
the other ts fields.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
c/s f8303458 restricted speculative access for do_vcpu_op(), but neglected its
compat counterpart, which is reachable by guests using the 32bit ABI.
Make an identical adjustment.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Norbert Manthey <nmanthey@amazon.de>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
During development of the XTF pagewalk tests, I reliably encountered this
message exactly once per run. It occurs when the first action to touch
TSS.RSP0 is an interrupt/exception taken in userspace, and the processor tries
to push the IRET frame.
Subsequently, OSSTest has demonstrated that it triggers frequently for a
KPTI-enabled kernel.
(XEN) multi.c:3324:d1v1 write to pagetable during event injection: cr2=0xffffad2646687f38, mfn=0x2415a1
[ 1411.949155] systemd-logind[2683]: New session 73 of user root.
(XEN) multi.c:3324:d1v1 write to pagetable during event injection: cr2=0xffffad264671ff38, mfn=0x240a41
(XEN) multi.c:3324:d1v1 write to pagetable during event injection: cr2=0xffffad2646837f38, mfn=0x2415c5
(XEN) multi.c:3324:d1v1 write to pagetable during event injection: cr2=0xffffad26468a7f38, mfn=0x2414e7
[ 1442.207473] systemd-logind[2683]: New session 74 of user root.
[ 1471.452206] systemd-logind[2683]: New session 75 of user root.
(XEN) multi.c:3324:d1v1 write to pagetable during event injection: cr2=0xffffad2646d17f08, mfn=0x2417c5
[ 1501.698971] systemd-logind[2683]: New session 76 of user root.
The actions performed by the shadow code are correct, and the guest continues
without error, but the emitted error is misleading. Tweak the comment to more
clearly identify why the condition exists, but drop the message.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
c/s 9338a37d "x86/svm: implement debug events" added support for introspecting
ICEBP debug exceptions, but didn't account for the fact that
svm_get_insn_len() (previously __get_instruction_length) can fail and may
already have raised #GP with the guest.
If svm_get_insn_len() fails, return back to guest context rather than
continuing and mistaking a trap-style VMExit for a fault-style one.
Spotted by Coverity.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Acked-by: Brian Woods <brian.woods@amd.com>
While boot_cpu_data.x86_num_siblings is an accurate value to use on AMD
hardware, it isn't on Intel when the user has disabled Hyperthreading in the
firmware. As a result, a user which has chosen to disable HT still gets
nagged on L1TF-vulnerable hardware when they haven't chosen an explicit
smt=<bool> setting.
Make use of the largely-undocumented MSR_INTEL_CORE_THREAD_COUNT which in
practice exists since Nehalem, when booting on real hardware. Fall back to
using the ACPI table APIC IDs.
While adjusting this logic, fix a latent bug in amd_get_topology(). The
thread count field in CPUID.0x8000001e.ebx is documented as 8 bits wide,
rather than 2 bits wide.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
This is a model specific register which details the current configuration
cores and threads in the package. Because of how Hyperthread and Core
configuration works works in firmware, the MSR it is de-facto constant and
will remain unchanged until the next system reset.
It is a read only MSR (so unilaterally reject writes), but for now retain its
leaky-on-read properties. Further CPUID/MSR work is required before we can
start virtualising a consistent topology to the guest, and retaining the old
behaviour is the safest course of action.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
It has ended up in the middle of the mitigation calculation logic. Move it to
be beside the other command line parsing.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Ever since its introducion in c/s 436fb462 "x86/microcode: enable boot
time (pre-Dom0) loading", the allocation has gone un-freed, and has its final
use as part of constructing dom0.
Xen already consideres it an error to have more than a single unaccounted-for
module (again, logic from the same change), and will only pass the first one
to dom0 as the initrd.
Instead of having an 8 byte pointer to a bitmap which won't exceed 4 bits wide
in any production scenario (dom0 kernel, initrd, XSM blob and microcode blob),
allocate module_map[] on the stack and add a sanity bound for mbi->mods_count.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
* Fix the shim build by providing a !CONFIG_HVM declaration for
hvm_get_guest_bndcfgs(), and removing the introduced
ASSERT(is_hvm_domain(d))'s. They are needed for DCE to keep the build
working. Furthermore, in this way, the risk of runtime type confusion is
removed.
* Revert the de-const'ing of the vcpu pointer in vmx_get_guest_bndcfgs().
vmx_vmcs_enter() really does mutate the vcpu, and may cause it to undergo a
full de/reschedule, which is contrary to the programmers expectation of
hvm_get_guest_bndcfgs(). guest_rdmsr() was always going to need to lose
its const parameter, and this was the correct time for it to happen.
* The MSRs in vcpu_msrs are in numeric order. Re-position XSS to match.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
c/s 9383de210 "x86/altp2m: support for setting restrictions for an array of
pages" introduced this logic, but do_hvm_op() was already capable of handling
-ERESTART correctly.
More problematic however is a continuation from compat_altp2m_op(). The arg
written back into register state points into the hypercall XLAT area, not at
the original parameter passed by the guest. It may be truncated by the
vmentry, but definitely won't be correct on the next invocation.
Delete the hypercall_create_continuation() call, and return -ERESTART, which
will cause the compat case to start working correctly.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Currently, a user can in principle combine the output of `xl info -n`, the
APCI tables, and some manual CPUID data to figure out which CPU numbers to
feed into `xen-hptool cpu-offline` to effectively disable SMT at runtime.
A more convenient option is to teach Xen how to perform this action.
Extend XEN_SYSCTL_cpu_hotplug with two new operations. Introduce a new
smt_up_down_helper() which wraps the cpu_{up,down}_helper() helpers with logic
which understands siblings based on their APIC_ID.
Add libxc stubs, and extend xen-hptool with smt-{enable,disable} options.
These are intended to be shorthands for a loop over cpu-{online,offline}.
To simplify the implemention, they will strictly enable/disable secondary
siblings (those with a non-zero thread id). This functionality is intended
for use in production scenarios where debugging options such as `maxcpus=` or
other manual plug/unplug configuration has not been used.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
c/s 597fbb8 "xen/timers: Fix memory leak with cpu unplug/plug" broke the ARM
build by being the first patch to add park_offline_cpus to common code.
While it is currently specific to Intel hardware (for reasons of being able to
handle machine check exceptions without an immediate system reset), it isn't
inherently architecture specific, so define it to be false on ARM for now.
Add a comment in both smp.h headers explaining the intended behaviour of the
option.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
timer_softirq_action() realloc's itself a larger timer heap whenever
necessary, which includes bootstrapping from the empty dummy_heap. Nothing
ever freed this allocation.
CPU plug and unplug has the side effect of zeroing the percpu data area, which
clears ts->heap. This in turn causes new timers to be put on the list rather
than the heap, and for timer_softirq_action() to bootstrap itself again.
This in practice leaks ts->heap every time a CPU is unplugged and replugged.
Implement free_percpu_timers() which includes freeing ts->heap when
appropriate, and update the notifier callback with the recent cpu parking
logic and free-avoidance across suspend.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
During a discussion in person, it was identified that Coverage doesn't
currently work for ARM yet. Also, there are a number of errors with the
existing coverage document.
Take the opportunity to rewrite it in RST, making it easier to follow for a
non-expert user.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Include (and retrofit to the user guide) an introductory paragraph describing
the intended audience.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
This hunk modifies the cpuid= documentation, which is unrelated to the
spec-ctrl= section.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
There are a number of bugs. There are no read/write hooks on the HVM side, so
guest accesses fall into the "read/write-discard" defaults, which bypass the
correct faulting behaviour and the Intel special case.
For the PV side, writes are discarded (again, bypassing proper faulting),
except for a pinned dom0, which is permitted to actually write the values
other than 0. This is pointless with read hook implementing the Intel special
case.
However, implementing the Intel special case is itself pointless. First of
all, OS software can't guarentee to read back 0 in the first place, because a)
this behaviour isn't guarenteed in the SDM, and b) there are SMM handlers
which use the CPUID instruction. Secondly, when a guest executes CPUID, this
doesn't typically result in Xen executing a CPUID instruction in practice.
With the dom0 special case removed, there are now no writes to this MSR other
than Xen's microcode loading facilities, which means that the value held in
the MSR will be properly up-to-date. Forward it directly, without jumping
through any hoops.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
CPUs from different vendors sometimes share characteristics. All users of
X86_VENDOR_* are now direct equal/not-equal comparisons. By expressing the
X86_VENDOR_* constants in a bitmap fashon, we can more concicely and
efficiently test whether a vendor is one of a group.
Update all parts of the code which can already benefit from this improvement.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
cpu_dev.c_vendor[] is a char[8] array which is printed using %s in two
locations. This leads to subtle lack-of-NUL bugs when using an 8 character
vendor name.
Introduce x86_cpuid_vendor_to_str() to turn an x86_vendor into a printable
string, use it in the two locations that c_vendor is used, and drop c_vendor.
This drops the final user of X86_VENDOR_NUM, so drop that as well.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
These helpers each fill in a single cpu_devs[] pointer, and since c/s
00b4f4d0f "x86/cpuid: Drop get_cpu_vendor() completely", this array is read
exactly once on boot.
Delete the hooks and cpu_devs[], and have early_cpu_detect() pick the
appropriate cpu_dev structure directly.
As early_cpu_init() is empty now other than a call to early_cpu_detect(), and
this isn't expected to change moving forwards, rename the latter and delete
the former.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
A future change is going to introduce two more cases. Instead of opcoding the
XSM checks and contine_hypercall logic, collect the data into local variables.
Switch the default return value to -EOPNOTSUPP to distinguish a bad op from a
bad cpu index.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
All methods of querying the online state of a CPU are racy without the hotplug
lock held, which can lead to a TOCTOU race trying to online or offline CPUs.
Distinguish this case with -EEXIST rather than -EINVAL, so the caller can take
other actions if necessary.
While adjusting this, rework the code slightly to fold the exit paths, which
results in a minor reduction in compiled code size.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
These were made redundant by c/s 23058e7b3 "x86/shadow: put PV L1TF functions
under CONFIG_PV" but makes the surrounding code read as if is outside of the
ifdef.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The is_pinned field is rather odd. It can only be activated with the
"dom0_vcpus_pin" command line option, and causes dom0 (or the late hwdom) to
have its vcpus identity pinned to pcpus.
Having dom0_vcpus_pin active disallows the use of vcpu_set_hard_affinity().
However, when a pcpu is offlined, or moved between cpupools, the affinity is
broken and reverts to cpumask_all. This results in vcpus which are no longer
pinned, and cannot be adjusted.
A related bit of functionality is the is_pinned_vcpu() predicate. This is
only used by x86 code, and permits the use of VCPUOP_get_physid and writeable
access to some extra MSRs.
The implementation however returns true for is_pinned (which will include
unpinned vcpus from the above scenario), *or* if the hard affinity mask only
has a single bit set (which is redundant with the intended effect of
is_pinned, but also includes other domains).
Rework the behaviour of "dom0_vcpus_pin" to only being an initial pinning
configuration, and permit full adjustment. This allows the user to
reconfigure dom0 after the fact or fix up from the fallout of cpu hot unplug
and cpupool manipulation.
An unprivileged domain has no business using VCPUOP_get_physid, and shouldn't
be able to just because it happens to be pinned by admin choice. All uses of
is_pinned_vcpu() should be restricted to the hardware domain, so rename it to
is_hwdom_pinned_vcpu() to avoid future misuse.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Dario Faggioli <dfaggioli@suse.com>
The {GET,SET}_HEAP_{SIZE,LIMIT}() macros implement some completely
undocumented pointer misuse to store the size and limit information. In
practice, heap[0] is never a timer pointer, and used to stash the metadata
instead.
Extend the HEAP OPERATIONS comment to include this detail. Introduce a
structure representing the heap metadata, and a static inline function to
perfom the type punning.
Replace all of the above macros with an equivelent expression involving the
heap_metadata() helper. Note that I deliberately haven't rearranged the
surrounding code - this allows the correctness of the transformation to be
checked by confirming that the compiled binary is identical.
This also removes two cases of a macro argument with side effects, which only
worked correctly because the arguments were only evaluated once.
Finally, fix up the type of dummy_heap. The old code functioned correctly,
but only by virtue of confusing a discrete object and a single-entry array.
Change its type to match the intended semantics, and drop the redundant
initialisation in timer_init().
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
When filling a policy, either from CPUID or an incomming leaf stream,
recalculate the synthesised vendor value. All callers are expected to want
this behaviour.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This doesn't address any of the assumptions that "anything which isn't AMD is
Intel". This logic is expected to be replaced wholesale with libx86 in the
longterm.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
get_cpu_vendor() tries to do a number of things, and ends up doing none of
them well.
For calculating the vendor itself, use x86_cpuid_lookup_vendor() which is
implemented in a far more efficient manner than looping over cpu_devs[].
For setting up this_cpu, set it up once on the BSP only, rather than
latest-takes-precident across the APs. Such a system is probably not going to
boot, but this feels like a less dangerous course of action. Adjust the
printed errors to be more clear in the mismatch case.
This removes the only user of cpu_dev->c_ident[], so drop that field as well.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
CentOS 6 is probably the most frequently broken build, so adding it to CI
would be a very good move.
One problem is that CentOS 6 comes with Python 2.6, and Qemu requires 2.7.
There appear to be no sensible ways to get Python 2.7 into a CentOS 6
environments, so modify the build script to skip the Qemu upstream build
instead. Additionally, SeaBIOS requires GCC 4.6 or later, so skip it as well.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
The script is mostly indented with spaces, but there are three tabs. Fix them
up to be consistent.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Recent discussion on xen-devel has demonstrated that Xen existing microcode
loading support isn't adequately documented. Take the opportunity to address
this, and start some end-user focused documentation.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Sphinx uses ReStructuredText as its markup format. Although missing the
project wide integration, individual *.rst files can be rendered by pandoc to
suppliement our existing ad-hoc documentation.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Sphinx is a documentation system, which is popular for technical writing. It
uses ReStructuredText as its markup syntax, and is designed for whole-project
documentation, rather than the misc assortment of individual files that we
currently have.
This is a skeleton setup which just enough infrastructure to render an empty
set of pages. It will become better integrated into Xen's docs system when it
becomes less WIP.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
It turns out that this code was previously dead.
c/s dcf41790 " x86/mmcfg/drhd: Move acpi_mmcfg_init() call before calling
acpi_parse_dmar()" resulted in PCI segment 0 now having been initialised
enough for acpi_parse_one_drhd() to not take the
/* Skip checking if segment is not accessible yet. */
path unconditionally. However, some systems have DMAR tables which list
devices which are disabled by user choice (in particular, Dell PowerEdge R740
with I/O AT DMA disabled), and turning off all IOMMU functionality in this
case is entirely unhelpful behaviour.
Leave the warning which identifies the problematic devices, but drop the
remaining logic. This leaves the system in better overall state, and working
in the same way that it did in previous releases.
Reported-by: Igor Druzhinin <igor.druzhinin@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Igor Druzhinin <igor.druzhinin@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
All currently-released Atom processors are in practice retpoline-safe, because
they don't fall back to a BTB prediction on RSB underflow.
However, an additional meaning of Enhanced IRBS is that the processor may not
be retpoline-safe. The Gemini Lake platform, based on the Goldmont Plus
microarchitecture is the first Atom processor to support eIBRS.
Until Xen gets full eIBRS support, Gemini Lake will still be safe using
regular IBRS.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
They are unnecesserily verbose, and ARCH_CAPS_* is already the more common
version.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Taking svm_feature_flags by pointer and using test_bit() results in generated
code which loads svm_feature_flags into a 32bit register, then does a bitwise
operation.
The logic can be expressed in terms of a straight bitwise operation, resulting
in the following minor improvement.
add/remove: 0/0 grow/shrink: 0/4 up/down: 0/-136 (-136)
Function old new delta
svm_nested_features_on_efer_update 281 273 -8
svm_create_vmcb 1404 1388 -16
svm_vmexit_handler 6271 6239 -32
start_svm 818 738 -80
Total: Before=3347569, After=3347433, chg -0.00%
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
dom0_construct_pv() has logic to transition dom0 into a compat domain when
booting an ELF32 image.
One aspect which is missing is the CPUID policy recalculation, meaning that a
32bit dom0 sees a 64bit policy, which differ by the Long Mode feature flag in
particular. Another missing item is the x87_fip_width initialisation.
Update dom0_construct_pv() to use switch_compat(), rather than retaining the
opencoding. Position the call to switch_compat() such that the compat32 local
variable can disappear entirely.
The 32bit monitor table is now created by setup_compat_l4(), avoiding the need
to for manual creation later.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Forcing a register operand hides (from the compiler) the fact that clflush
behaves as a read from the memory operand (wrt memory order, faults, etc.).
It also reduces the compilers flexibility with register scheduling.
Re-implement clfush() (and wbinvd() for consistency) as a static inline rather
than a macro, and have it take a const void pointer.
In practice, the only generated code which gets modified by this is in
mwait_idle_with_hints(), where a disp8 encoding now gets used.
While here, I noticed that &mwait_wakeup(cpu) was being calculated twice.
This is caused by the memory clobber in mb(), so take the opportunity to help
the optimiser by calculating it once, ahead of time. bloat-o-meter reports a
delta of -26 as a result of this change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
There isn't a plausible reason to insert nops into code in this manner.
The sole use is in do_debug_key(), and exists to prevent the compiler
optimising the tail of the function with 'jmp debugger_trap_fatal'
In practice, a compiler barrier suffices just as well to prevent the tailcall,
and doesn't involve inserting unnecessary instructions.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <julien.grall@arm.com>
* Use XFREE() when appropriate
* Drop stale comments and unnecessary brackets
* Fold asm constraints
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <julien.grall@arm.com>
The CPUID bit and MSR are deliberately not exposed to guests, because they
won't exist on newer processors. As vPMU isn't security supported, the
misbehaviour of PCR3 isn't expected to impact production deployments.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
These will be extended with further libx86 work.
Fix the sorting of the CPUID_GUEST_NR_* constants, noticed while writing the
unit tests.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
iremap_maddr and qinval_maddr point to the base of a block of contiguous RAM,
allocated by the driver, holding the Interrupt Remapping table, and the Queued
Invalidation ring.
Despite their name, they are actually the values of the hardware register,
including control metadata in the lower 12 bits. While uses of these fields
do appear to correctly shift out the metadata, this is very subtle behaviour
and confusing to follow.
Nothing uses the metadata, so make the fields actually point at the base of
the relevant tables.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
The logic in xstate_init() is a rementent of the pre-featuremask days.
Collect the xstate features in generic_identify(), like all other feature
leaves, after which identify_cpu() will apply the known_feature[] mask derived
from the automatically generated CPUID information.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The update to README and SUPPORT.md where correct, but XEN_EXTRAVERSION had an
additional .0 slip in.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
The issues are:
* dict.has_key() was completely removed in Py3
* dict.keys() is an iterable rather than list in Py3, so .sort() doesn't work.
* list.sort(cmp=) was deprecated in Py2.4 and removed in Py3.
The has_key() issue is trivially fixed by switching to using the in keyword.
The sorting issue could be trivially fixed, but take the opportunity to
improve the code.
The reason for the sorting is to ensure that "unsigned long" gets replaced
before "long", and the only reason sorting is necessary is because
inttypes[arch] is needlessly a dictionary. Update inttypes[arch] to be a list
of tuples rather than a dictionary, and process them in list order.
Reported-by: George Dunlap <george.dunlap@eu.citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Currently, a 64bit PV guest can appear to set and clear FSGSBASE in %cr4, but
the bit remains set in hardware. Therefore, the {RD,WR}{FS,GS}BASE are usable
even when the guest kernel believes that they are disabled.
The FSGSBASE feature isn't currently supported in Linux, and its context
switch path has some optimisations which rely on userspace being unable to use
the WR{FS,GS}BASE instructions. Xen's current behaviour undermines this
expectation.
In 64bit PV guest context, always load the guest kernels setting of FSGSBASE
into %cr4. This requires adjusting how Xen uses the {RD,WR}{FS,GS}BASE
instructions.
* Delete the cpu_has_fsgsbase helper. It is no longer safe, as users need to
check %cr4 directly.
* The raw __rd{fs,gs}base() helpers are only safe to use when %cr4.fsgsbase
is set. Comment this property.
* The {rd,wr}{fs,gs}{base,shadow}() and read_msr() helpers are updated to use
the current %cr4 value to determine which mechanism to use.
* toggle_guest_mode() and save_segments() are update to avoid reading
fs/gsbase if the values in hardware cannot be stale WRT struct vcpu. A
consequence of this is that the write_cr() path needs to cache the current
bases, as subsequent context switches will skip saving the values.
* write_cr4() is updated to ensure that the shadow %cr4.fsgsbase value is
observed in a safe way WRT the hardware setting, if an interrupt happens to
hit in the middle.
* load_segments() is updated to use the VMLOAD optimisation if FSGSBASE is
unavailable, even if only gs_shadow needs updating. As a minor perf
improvement, check cpu_has_svm first to short circuit a context-dependent
conditional on Intel hardware.
* pv_make_cr4() is updated for 64bit PV guests to use the guest kernels
choice of FSGSBASE.
This is part of XSA-293.
Reported-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The PV cr4 logic is almost impossible to follow, and leaks bits into guest
context which definitely shouldn't be visible (in particular, VMXE).
The biggest problem however, and source of the complexity, is that it derives
new real and guest cr4 values from the current value in hardware - this is
context dependent and an inappropriate source of information.
Rewrite the cr4 logic to be invariant of the current value in hardware.
First of all, modify write_ptbase() to always use mmu_cr4_features for IDLE
and HVM contexts. mmu_cr4_features *is* the correct value to use, and makes
the ASSERT() obviously redundant.
For PV guests, curr->arch.pv.ctrlreg[4] remains the guests view of cr4, but
all logic gets reworked in terms of this and mmu_cr4_features only.
Two masks are introduced; bits which the guest has control over, and bits
which are forwarded from Xen's settings. One guest-visible change here is
that Xen's VMXE setting is no longer visible at all.
pv_make_cr4() follows fairly closely from pv_guest_cr4_to_real_cr4(), but
deliberately starts with mmu_cr4_features, and only alters the minimal subset
of bits.
The boot-time {compat_,}pv_cr4_mask variables are removed, as they are a
remnant of the pre-CPUID policy days. pv_fixup_guest_cr4() gains a related
derivation from the policy.
Another guest visible change here is that a 32bit PV guest can now flip
FSGSBASE in its view of CR4. While the {RD,WR}{FS,GS}BASE instructions are
unusable outside of a 64bit code segment, the ability to modify FSGSBASE
matches real hardware behaviour, and avoids the need for any 32bit/64bit
differences in the logic.
Overall, this patch shouldn't have a practical change in guest behaviour.
VMXE will disappear from view, and an inquisitive 32bit kernel can now see
FSGSBASE changing, but this new logic is otherwise bug-compatible with before.
This is part of XSA-293.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The regression/ directory was identified as already broken in 2012 (c/s
953953cc5). The logic is intended to test *.py files in the Xen tree against
different versions of python, but every python version is obsolete as well.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
c/s 0ec9b4ef31 "x86/vmx: Fix security issue when a guest balloons out the #VE
info page" introduced a caller of altp2m_vcpu_disable_ve() in a common path,
but c/s e72ecc7615 "x86/altp2m: Rework #VE enable/disable paths" didn't have
a suitable prototype in the !CONFIG_HVM case.
Introduce one to fix the build.
Spotted by Travis.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
Andrew Cooper