Hello community, here is the log from the commit of package xen for openSUSE:Factory checked in at 2019-05-17 23:39:15 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Comparing /work/SRC/openSUSE:Factory/xen (Old) and /work/SRC/openSUSE:Factory/.xen.new.5148 (New) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "xen" Fri May 17 23:39:15 2019 rev:266 rq:702959 version:4.12.0_12 Changes: -------- --- /work/SRC/openSUSE:Factory/xen/xen.changes 2019-04-18 13:58:17.887992681 +0200 +++ /work/SRC/openSUSE:Factory/.xen.new.5148/xen.changes 2019-05-17 23:39:19.322039407 +0200 @@ -1,0 +2,25 @@ +Tue May 14 15:35:17 UTC 2019 - Martin Liška <[email protected]> + +- Disable LTO (boo#1133296). + +------------------------------------------------------------------- +Mon May 13 20:20:00 UTC 2019 - [email protected] + +- Remove arm32 from ExclusiveArch to fix build + +------------------------------------------------------------------- +Mon Apr 29 08:54:04 MDT 2019 - [email protected] + +- bsc#1111331 - VUL-0: CPU issues Q2 2019 aka "Group 4" + xsa297-0a.patch + xsa297-0b.patch + xsa297-0c.patch + xsa297-0d.patch + xsa297-1.patch + xsa297-2.patch + xsa297-3.patch +- Update 5cab1f66-timers-fix-memory-leak-with-cpu-plug.patch and + drop 5cac6219-xen-cpu-Fix-ARM-build-following-cs-597fbb8.patch + Refresh 5cac6cba-vmx-Fixup-removals-of-MSR-load-save-list-entries.patch + +------------------------------------------------------------------- Old: ---- 5cac6219-xen-cpu-Fix-ARM-build-following-cs-597fbb8.patch New: ---- xsa297-0a.patch xsa297-0b.patch xsa297-0c.patch xsa297-0d.patch xsa297-1.patch xsa297-2.patch xsa297-3.patch ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Other differences: ------------------ ++++++ xen.spec ++++++ --- /var/tmp/diff_new_pack.EPEEdb/_old 2019-05-17 23:39:21.242038352 +0200 +++ /var/tmp/diff_new_pack.EPEEdb/_new 2019-05-17 23:39:21.246038350 +0200 @@ -23,7 +23,7 @@ %endif Name: xen -ExclusiveArch: %ix86 x86_64 %arm aarch64 +ExclusiveArch: %ix86 x86_64 aarch64 %define changeset 38667 %define xen_build_dir xen-4.12.0-testing # @@ -127,7 +127,7 @@ BuildRequires: pesign-obs-integration %endif -Version: 4.12.0_10 +Version: 4.12.0_12 Release: 0 Summary: Xen Virtualization: Hypervisor (aka VMM aka Microkernel) License: GPL-2.0-only @@ -174,8 +174,14 @@ Patch10: 5ca46b68-x86emul-no-GPR-update-upon-AVX-gather-failures.patch Patch11: 5ca773d1-x86emul-dont-read-mask-reg-without-AVX512F.patch Patch12: 5cab1f66-timers-fix-memory-leak-with-cpu-plug.patch -Patch13: 5cac6219-xen-cpu-Fix-ARM-build-following-cs-597fbb8.patch -Patch14: 5cac6cba-vmx-Fixup-removals-of-MSR-load-save-list-entries.patch +Patch13: 5cac6cba-vmx-Fixup-removals-of-MSR-load-save-list-entries.patch +Patch29701: xsa297-0a.patch +Patch29702: xsa297-0b.patch +Patch29703: xsa297-0c.patch +Patch29704: xsa297-0d.patch +Patch29711: xsa297-1.patch +Patch29712: xsa297-2.patch +Patch29713: xsa297-3.patch # Our platform specific patches Patch400: xen-destdir.patch Patch401: vif-bridge-no-iptables.patch @@ -387,7 +393,13 @@ %patch11 -p1 %patch12 -p1 %patch13 -p1 -%patch14 -p1 +%patch29701 -p1 +%patch29702 -p1 +%patch29703 -p1 +%patch29704 -p1 +%patch29711 -p1 +%patch29712 -p1 +%patch29713 -p1 # Our platform specific patches %patch400 -p1 %patch401 -p1 @@ -443,6 +455,7 @@ %patch99999 -p1 %build +%define _lto_cflags %{nil} # JWF: Anthony's series to load BIOS from toolstack requires autogen.sh. # http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg01626.html ./autogen.sh @@ -785,12 +798,6 @@ make -C xen install DEBUG_DIR=/boot DESTDIR=%{buildroot} CC=$CC %{?_smp_mflags} install_xen make -C xen clean -echo > xen.files.txt -# EFI depends on gcc47 or newer -if test -d %{buildroot}/%{_datadir}/efi/$arch -then - echo %{_datadir}/efi/$arch >> xen.files.txt -fi %endif # On x86_64, qemu-xen was installed as /usr/lib/xen/bin/qemu-system-i386 @@ -945,7 +952,7 @@ %if %{?with_dom0_support}0 -%files -f xen.files.txt +%files %defattr(-,root,root) /boot/* %{_libdir}/efi ++++++ 5cab1f66-timers-fix-memory-leak-with-cpu-plug.patch ++++++ --- /var/tmp/diff_new_pack.EPEEdb/_old 2019-05-17 23:39:21.302038319 +0200 +++ /var/tmp/diff_new_pack.EPEEdb/_new 2019-05-17 23:39:21.306038317 +0200 @@ -1,6 +1,3 @@ - -WARNING: Breaks Arm build! Fix is being discussed upstream. - # Commit 597fbb8be6021440cd53493c14201c32671bade1 # Date 2019-04-08 11:16:06 +0100 # Author Andrew Cooper <[email protected]> @@ -24,9 +21,54 @@ Signed-off-by: Andrew Cooper <[email protected]> Reviewed-by: Jan Beulich <[email protected]> +# Commit a6448adfd3d537aacbbd784e5bf1777ab3ff5f85 +# Date 2019-04-09 10:12:57 +0100 +# Author Andrew Cooper <[email protected]> +# Committer Wei Liu <[email protected]> +xen/cpu: Fix ARM build following c/s 597fbb8 + +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 <[email protected]> +Reviewed-by: Julien Grall <[email protected]> +Reviewed-by: Wei Liu <[email protected]> + +# Commit 1aec95350ac8261cba516371710d4d837c26f6a0 +# Date 2019-04-15 17:51:30 +0100 +# Author Jan Beulich <[email protected]> +# Committer Andrew Cooper <[email protected]> +timers: move back migrate_timers_from_cpu() invocation + +Commit 597fbb8be6 ("xen/timers: Fix memory leak with cpu unplug/plug") +went a little too far: Migrating timers away from a CPU being offlined +needs to heppen independent of whether it get parked or fully offlined. + +Signed-off-by: Jan Beulich <[email protected]> + +xen/timers: Fix memory leak with cpu unplug/plug (take 2) + +Previous attempts to fix this leak failed to identify the root cause, and +ultimately failed. The cause is 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 <[email protected]> +Reviewed-by: Jan Beulich <[email protected]> + --- a/xen/common/timer.c +++ b/xen/common/timer.c -@@ -601,6 +601,22 @@ static void migrate_timers_from_cpu(unsi +@@ -601,6 +601,20 @@ static void migrate_timers_from_cpu(unsi static struct timer *dummy_heap; @@ -34,8 +76,6 @@ +{ + struct timers *ts = &per_cpu(timers, cpu); + -+ migrate_timers_from_cpu(cpu); -+ + ASSERT(GET_HEAP_SIZE(ts->heap) == 0); + if ( GET_HEAP_LIMIT(ts->heap) ) + { @@ -49,14 +89,26 @@ static int cpu_callback( struct notifier_block *nfb, unsigned long action, void *hcpu) { -@@ -614,10 +630,18 @@ static int cpu_callback( - spin_lock_init(&ts->lock); - ts->heap = &dummy_heap; +@@ -610,14 +624,28 @@ static int cpu_callback( + switch ( action ) + { + case CPU_UP_PREPARE: +- INIT_LIST_HEAD(&ts->inactive); +- spin_lock_init(&ts->lock); +- ts->heap = &dummy_heap; ++ /* Only initialise ts once. */ ++ if ( !ts->heap ) ++ { ++ INIT_LIST_HEAD(&ts->inactive); ++ spin_lock_init(&ts->lock); ++ ts->heap = &dummy_heap; ++ } break; + case CPU_UP_CANCELED: case CPU_DEAD: -- migrate_timers_from_cpu(cpu); + migrate_timers_from_cpu(cpu); ++ + if ( !park_offline_cpus && system_state != SYS_STATE_suspend ) + free_percpu_timers(cpu); break; @@ -69,3 +121,31 @@ default: break; } +--- a/xen/include/asm-arm/smp.h ++++ b/xen/include/asm-arm/smp.h +@@ -14,6 +14,12 @@ DECLARE_PER_CPU(cpumask_var_t, cpu_core_ + + #define raw_smp_processor_id() (get_processor_id()) + ++/* ++ * Do we, for platform reasons, need to actually keep CPUs online when we ++ * would otherwise prefer them to be off? ++ */ ++#define park_offline_cpus false ++ + extern void noreturn stop_cpu(void); + + extern int arch_smp_init(void); +--- a/xen/include/asm-x86/smp.h ++++ b/xen/include/asm-x86/smp.h +@@ -26,6 +26,10 @@ DECLARE_PER_CPU(cpumask_var_t, cpu_sibli + DECLARE_PER_CPU(cpumask_var_t, cpu_core_mask); + DECLARE_PER_CPU(cpumask_var_t, scratch_cpumask); + ++/* ++ * Do we, for platform reasons, need to actually keep CPUs online when we ++ * would otherwise prefer them to be off? ++ */ + extern bool park_offline_cpus; + + void smp_send_nmi_allbutself(void); ++++++ 5cac6cba-vmx-Fixup-removals-of-MSR-load-save-list-entries.patch ++++++ --- /var/tmp/diff_new_pack.EPEEdb/_old 2019-05-17 23:39:21.322038308 +0200 +++ /var/tmp/diff_new_pack.EPEEdb/_new 2019-05-17 23:39:21.322038308 +0200 @@ -1,7 +1,10 @@ -Subject: x86/vmx: Fixup removals of MSR load/save list entries -From: Igor Druzhinin [email protected] Thu Apr 4 17:25:10 2019 +0100 -Date: Tue Apr 9 10:58:18 2019 +0100: -Git: e28c0ee3356f52f589bbae54e89aaed25c1f599d +References: bsc#1124560 + +# Commit e28c0ee3356f52f589bbae54e89aaed25c1f599d +# Date 2019-04-09 10:58:18 +0100 +# Author Igor Druzhinin <[email protected]> +# Committer Andrew Cooper <[email protected]> +x86/vmx: Fixup removals of MSR load/save list entries Commit 540d5422 ("x86/vmx: Support removing MSRs from the host/guest load/save lists") introduced infrastructure finally exposed by @@ -18,11 +21,9 @@ Reviewed-by: Andrew Cooper <[email protected]> Acked-by: Kevin Tian <[email protected]> -diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c -index 74f2a08cfd..45d18493df 100644 --- a/xen/arch/x86/hvm/vmx/vmcs.c +++ b/xen/arch/x86/hvm/vmx/vmcs.c -@@ -1490,15 +1490,15 @@ int vmx_del_msr(struct vcpu *v, uint32_t msr, enum vmx_msr_list_type type) +@@ -1490,15 +1490,15 @@ int vmx_del_msr(struct vcpu *v, uint32_t switch ( type ) { case VMX_MSR_HOST: ++++++ xsa297-0a.patch ++++++ # Commit b038dbd0c1f6832e7db4fad9255c7ddc58036332 # Date 2019-04-18 14:31:58 +0100 # Author Andrew Cooper <[email protected]> # Committer Andrew Cooper <[email protected]> x86/spec-ctrl: Reposition the XPTI command line parsing logic 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 <[email protected]> Acked-by: Jan Beulich <[email protected]> --- a/xen/arch/x86/spec_ctrl.c +++ b/xen/arch/x86/spec_ctrl.c @@ -167,6 +167,73 @@ static int __init parse_spec_ctrl(const } custom_param("spec-ctrl", parse_spec_ctrl); +int8_t __read_mostly opt_xpti_hwdom = -1; +int8_t __read_mostly opt_xpti_domu = -1; + +static __init void xpti_init_default(uint64_t caps) +{ + if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD ) + caps = ARCH_CAPS_RDCL_NO; + + if ( caps & ARCH_CAPS_RDCL_NO ) + { + if ( opt_xpti_hwdom < 0 ) + opt_xpti_hwdom = 0; + if ( opt_xpti_domu < 0 ) + opt_xpti_domu = 0; + } + else + { + if ( opt_xpti_hwdom < 0 ) + opt_xpti_hwdom = 1; + if ( opt_xpti_domu < 0 ) + opt_xpti_domu = 1; + } +} + +static __init int parse_xpti(const char *s) +{ + const char *ss; + int val, rc = 0; + + /* Interpret 'xpti' alone in its positive boolean form. */ + if ( *s == '\0' ) + opt_xpti_hwdom = opt_xpti_domu = 1; + + do { + ss = strchr(s, ','); + if ( !ss ) + ss = strchr(s, '\0'); + + switch ( parse_bool(s, ss) ) + { + case 0: + opt_xpti_hwdom = opt_xpti_domu = 0; + break; + + case 1: + opt_xpti_hwdom = opt_xpti_domu = 1; + break; + + default: + if ( !strcmp(s, "default") ) + opt_xpti_hwdom = opt_xpti_domu = -1; + else if ( (val = parse_boolean("dom0", s, ss)) >= 0 ) + opt_xpti_hwdom = val; + else if ( (val = parse_boolean("domu", s, ss)) >= 0 ) + opt_xpti_domu = val; + else if ( *s ) + rc = -EINVAL; + break; + } + + s = ss + 1; + } while ( *ss ); + + return rc; +} +custom_param("xpti", parse_xpti); + int8_t __read_mostly opt_pv_l1tf_hwdom = -1; int8_t __read_mostly opt_pv_l1tf_domu = -1; @@ -627,73 +694,6 @@ static __init void l1tf_calculations(uin : (3ul << (paddr_bits - 2)))); } -int8_t __read_mostly opt_xpti_hwdom = -1; -int8_t __read_mostly opt_xpti_domu = -1; - -static __init void xpti_init_default(uint64_t caps) -{ - if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD ) - caps = ARCH_CAPS_RDCL_NO; - - if ( caps & ARCH_CAPS_RDCL_NO ) - { - if ( opt_xpti_hwdom < 0 ) - opt_xpti_hwdom = 0; - if ( opt_xpti_domu < 0 ) - opt_xpti_domu = 0; - } - else - { - if ( opt_xpti_hwdom < 0 ) - opt_xpti_hwdom = 1; - if ( opt_xpti_domu < 0 ) - opt_xpti_domu = 1; - } -} - -static __init int parse_xpti(const char *s) -{ - const char *ss; - int val, rc = 0; - - /* Interpret 'xpti' alone in its positive boolean form. */ - if ( *s == '\0' ) - opt_xpti_hwdom = opt_xpti_domu = 1; - - do { - ss = strchr(s, ','); - if ( !ss ) - ss = strchr(s, '\0'); - - switch ( parse_bool(s, ss) ) - { - case 0: - opt_xpti_hwdom = opt_xpti_domu = 0; - break; - - case 1: - opt_xpti_hwdom = opt_xpti_domu = 1; - break; - - default: - if ( !strcmp(s, "default") ) - opt_xpti_hwdom = opt_xpti_domu = -1; - else if ( (val = parse_boolean("dom0", s, ss)) >= 0 ) - opt_xpti_hwdom = val; - else if ( (val = parse_boolean("domu", s, ss)) >= 0 ) - opt_xpti_domu = val; - else if ( *s ) - rc = -EINVAL; - break; - } - - s = ss + 1; - } while ( *ss ); - - return rc; -} -custom_param("xpti", parse_xpti); - void __init init_speculation_mitigations(void) { enum ind_thunk thunk = THUNK_DEFAULT; ++++++ xsa297-0b.patch ++++++ # Commit 5eb160ef7339a076cb21132c7fc101f043d1c98b # Date 2019-04-18 14:31:58 +0100 # Author Andrew Cooper <[email protected]> # Committer Andrew Cooper <[email protected]> x86/msr: Definitions for MSR_INTEL_CORE_THREAD_COUNT 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 <[email protected]> Acked-by: Jan Beulich <[email protected]> --- a/xen/arch/x86/msr.c +++ b/xen/arch/x86/msr.c @@ -200,6 +200,10 @@ int guest_rdmsr(const struct vcpu *v, ui ARRAY_SIZE(msrs->dr_mask))]; break; + /* + * TODO: Implement when we have better topology representation. + case MSR_INTEL_CORE_THREAD_COUNT: + */ default: return X86EMUL_UNHANDLEABLE; } @@ -229,6 +233,7 @@ int guest_wrmsr(struct vcpu *v, uint32_t { uint64_t rsvd; + case MSR_INTEL_CORE_THREAD_COUNT: case MSR_INTEL_PLATFORM_INFO: case MSR_ARCH_CAPABILITIES: /* Read-only */ --- a/xen/include/asm-x86/msr-index.h +++ b/xen/include/asm-x86/msr-index.h @@ -32,6 +32,10 @@ #define EFER_KNOWN_MASK (EFER_SCE | EFER_LME | EFER_LMA | EFER_NX | \ EFER_SVME | EFER_FFXSE) +#define MSR_INTEL_CORE_THREAD_COUNT 0x00000035 +#define MSR_CTC_THREAD_MASK 0x0000ffff +#define MSR_CTC_CORE_MASK 0xffff0000 + /* Speculation Controls. */ #define MSR_SPEC_CTRL 0x00000048 #define SPEC_CTRL_IBRS (_AC(1, ULL) << 0) ++++++ xsa297-0c.patch ++++++ # Commit 1c36f6103ee6dafa6f938c19aab71151a641f127 # Date 2019-04-18 14:31:58 +0100 # Author Andrew Cooper <[email protected]> # Committer Andrew Cooper <[email protected]> x86/boot: Detect the firmware SMT setting correctly on Intel hardware 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 <[email protected]> Acked-by: Jan Beulich <[email protected]> --- a/xen/arch/x86/cpu/amd.c +++ b/xen/arch/x86/cpu/amd.c @@ -507,7 +507,7 @@ static void amd_get_topology(struct cpui u32 eax, ebx, ecx, edx; cpuid(0x8000001e, &eax, &ebx, &ecx, &edx); - c->x86_num_siblings = ((ebx >> 8) & 0x3) + 1; + c->x86_num_siblings = ((ebx >> 8) & 0xff) + 1; if (c->x86 < 0x17) c->compute_unit_id = ebx & 0xFF; --- a/xen/arch/x86/spec_ctrl.c +++ b/xen/arch/x86/spec_ctrl.c @@ -368,6 +368,45 @@ static void __init print_details(enum in #endif } +static bool __init check_smt_enabled(void) +{ + uint64_t val; + unsigned int cpu; + + /* + * x86_num_siblings defaults to 1 in the absence of other information, and + * is adjusted based on other topology information found in CPUID leaves. + * + * On AMD hardware, it will be the current SMT configuration. On Intel + * hardware, it will represent the maximum capability, rather than the + * current configuration. + */ + if ( boot_cpu_data.x86_num_siblings < 2 ) + return false; + + /* + * Intel Nehalem and later hardware does have an MSR which reports the + * current count of cores/threads in the package. + * + * At the time of writing, it is almost completely undocumented, so isn't + * virtualised reliably. + */ + if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL && !cpu_has_hypervisor && + !rdmsr_safe(MSR_INTEL_CORE_THREAD_COUNT, val) ) + return (MASK_EXTR(val, MSR_CTC_CORE_MASK) != + MASK_EXTR(val, MSR_CTC_THREAD_MASK)); + + /* + * Search over the CPUs reported in the ACPI tables. Any whose APIC ID + * has a non-zero thread id component indicates that SMT is active. + */ + for_each_present_cpu ( cpu ) + if ( x86_cpu_to_apicid[cpu] & (boot_cpu_data.x86_num_siblings - 1) ) + return true; + + return false; +} + /* Calculate whether Retpoline is known-safe on this CPU. */ static bool __init retpoline_safe(uint64_t caps) { @@ -697,12 +736,14 @@ static __init void l1tf_calculations(uin void __init init_speculation_mitigations(void) { enum ind_thunk thunk = THUNK_DEFAULT; - bool use_spec_ctrl = false, ibrs = false; + bool use_spec_ctrl = false, ibrs = false, hw_smt_enabled; uint64_t caps = 0; if ( boot_cpu_has(X86_FEATURE_ARCH_CAPS) ) rdmsrl(MSR_ARCH_CAPABILITIES, caps); + hw_smt_enabled = check_smt_enabled(); + /* * Has the user specified any custom BTI mitigations? If so, follow their * instructions exactly and disable all heuristics. @@ -873,8 +914,7 @@ void __init init_speculation_mitigations * However, if we are on affected hardware, with HT enabled, and the user * hasn't explicitly chosen whether to use HT or not, nag them to do so. */ - if ( opt_smt == -1 && cpu_has_bug_l1tf && !pv_shim && - boot_cpu_data.x86_num_siblings > 1 ) + if ( opt_smt == -1 && cpu_has_bug_l1tf && !pv_shim && hw_smt_enabled ) warning_add( "Booted on L1TF-vulnerable hardware with SMT/Hyperthreading\n" "enabled. Please assess your configuration and choose an\n" ++++++ xsa297-0d.patch ++++++ # Commit 6f03ece182429a8899084418ba02a2d909bde891 # Date 2019-04-18 14:31:59 +0100 # Author Andrew Cooper <[email protected]> # Committer Andrew Cooper <[email protected]> x86/spec-ctrl: Misc non-functional cleanup * 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 <[email protected]> Reviewed-by: Jan Beulich <[email protected]> --- a/xen/include/asm-x86/spec_ctrl.h +++ b/xen/include/asm-x86/spec_ctrl.h @@ -68,6 +68,8 @@ static always_inline void spec_ctrl_ente uint32_t val = 0; /* + * Branch Target Injection: + * * Latch the new shadow value, then enable shadowing, then update the MSR. * There are no SMP issues here; only local processor ordering concerns. */ @@ -75,8 +77,9 @@ static always_inline void spec_ctrl_ente barrier(); info->spec_ctrl_flags |= SCF_use_shadow; barrier(); - asm volatile ( ALTERNATIVE("", "wrmsr", X86_FEATURE_SC_MSR_IDLE) - :: "a" (val), "c" (MSR_SPEC_CTRL), "d" (0) : "memory" ); + alternative_input("", "wrmsr", X86_FEATURE_SC_MSR_IDLE, + "a" (val), "c" (MSR_SPEC_CTRL), "d" (0)); + barrier(); } /* WARNING! `ret`, `call *`, `jmp *` not safe before this call. */ @@ -85,13 +88,16 @@ static always_inline void spec_ctrl_exit uint32_t val = info->xen_spec_ctrl; /* + * Branch Target Injection: + * * Disable shadowing before updating the MSR. There are no SMP issues * here; only local processor ordering concerns. */ info->spec_ctrl_flags &= ~SCF_use_shadow; barrier(); - asm volatile ( ALTERNATIVE("", "wrmsr", X86_FEATURE_SC_MSR_IDLE) - :: "a" (val), "c" (MSR_SPEC_CTRL), "d" (0) : "memory" ); + alternative_input("", "wrmsr", X86_FEATURE_SC_MSR_IDLE, + "a" (val), "c" (MSR_SPEC_CTRL), "d" (0)); + barrier(); } #endif /* __ASSEMBLY__ */ ++++++ xsa297-1.patch ++++++ # Commit ad12c2971f50b0d951331b963093964c89938327 # Date 2019-04-18 14:31:59 +0100 # Author Andrew Cooper <[email protected]> # Committer Andrew Cooper <[email protected]> x86/spec-ctrl: CPUID/MSR definitions for Microarchitectural Data Sampling 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. Signed-off-by: Andrew Cooper <[email protected]> Reviewed-by: Jan Beulich <[email protected]> --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -483,7 +483,7 @@ accounting for hardware capabilities as Currently accepted: -The Speculation Control hardware features `ibrsb`, `stibp`, `ibpb`, +The Speculation Control hardware features `md-clear`, `ibrsb`, `stibp`, `ibpb`, `l1d-flush` and `ssbd` are used by default if available and applicable. They can be ignored, e.g. `no-ibrsb`, at which point Xen won't use them itself, and won't offer them to guests. --- a/tools/libxl/libxl_cpuid.c +++ b/tools/libxl/libxl_cpuid.c @@ -202,6 +202,7 @@ int libxl_cpuid_parse_config(libxl_cpuid {"avx512-4vnniw",0x00000007, 0, CPUID_REG_EDX, 2, 1}, {"avx512-4fmaps",0x00000007, 0, CPUID_REG_EDX, 3, 1}, + {"md-clear", 0x00000007, 0, CPUID_REG_EDX, 10, 1}, {"ibrsb", 0x00000007, 0, CPUID_REG_EDX, 26, 1}, {"stibp", 0x00000007, 0, CPUID_REG_EDX, 27, 1}, {"l1d-flush", 0x00000007, 0, CPUID_REG_EDX, 28, 1}, --- a/tools/misc/xen-cpuid.c +++ b/tools/misc/xen-cpuid.c @@ -146,6 +146,7 @@ static const char *str_7d0[32] = { [ 2] = "avx512_4vnniw", [ 3] = "avx512_4fmaps", + [10] = "md-clear", /* 12 */ [13] = "tsx-force-abort", [26] = "ibrsb", [27] = "stibp", --- a/xen/arch/x86/cpuid.c +++ b/xen/arch/x86/cpuid.c @@ -29,7 +29,12 @@ static int __init parse_xen_cpuid(const if ( !ss ) ss = strchr(s, '\0'); - if ( (val = parse_boolean("ibpb", s, ss)) >= 0 ) + if ( (val = parse_boolean("md-clear", s, ss)) >= 0 ) + { + if ( !val ) + setup_clear_cpu_cap(X86_FEATURE_MD_CLEAR); + } + else if ( (val = parse_boolean("ibpb", s, ss)) >= 0 ) { if ( !val ) setup_clear_cpu_cap(X86_FEATURE_IBPB); --- a/xen/arch/x86/spec_ctrl.c +++ b/xen/arch/x86/spec_ctrl.c @@ -291,17 +291,19 @@ static void __init print_details(enum in printk("Speculative mitigation facilities:\n"); /* Hardware features which pertain to speculative mitigations. */ - printk(" Hardware features:%s%s%s%s%s%s%s%s%s%s\n", + printk(" Hardware features:%s%s%s%s%s%s%s%s%s%s%s%s\n", (_7d0 & cpufeat_mask(X86_FEATURE_IBRSB)) ? " IBRS/IBPB" : "", (_7d0 & cpufeat_mask(X86_FEATURE_STIBP)) ? " STIBP" : "", (_7d0 & cpufeat_mask(X86_FEATURE_L1D_FLUSH)) ? " L1D_FLUSH" : "", (_7d0 & cpufeat_mask(X86_FEATURE_SSBD)) ? " SSBD" : "", + (_7d0 & cpufeat_mask(X86_FEATURE_MD_CLEAR)) ? " MD_CLEAR" : "", (e8b & cpufeat_mask(X86_FEATURE_IBPB)) ? " IBPB" : "", (caps & ARCH_CAPS_IBRS_ALL) ? " IBRS_ALL" : "", (caps & ARCH_CAPS_RDCL_NO) ? " RDCL_NO" : "", (caps & ARCH_CAPS_RSBA) ? " RSBA" : "", (caps & ARCH_CAPS_SKIP_L1DFL) ? " SKIP_L1DFL": "", - (caps & ARCH_CAPS_SSB_NO) ? " SSB_NO" : ""); + (caps & ARCH_CAPS_SSB_NO) ? " SSB_NO" : "", + (caps & ARCH_CAPS_MDS_NO) ? " MDS_NO" : ""); /* Compiled-in support which pertains to mitigations. */ if ( IS_ENABLED(CONFIG_INDIRECT_THUNK) || IS_ENABLED(CONFIG_SHADOW_PAGING) ) @@ -339,23 +341,25 @@ static void __init print_details(enum in * mitigation support for guests. */ #ifdef CONFIG_HVM - printk(" Support for HVM VMs:%s%s%s%s\n", + printk(" Support for HVM VMs:%s%s%s%s%s\n", (boot_cpu_has(X86_FEATURE_SC_MSR_HVM) || boot_cpu_has(X86_FEATURE_SC_RSB_HVM) || opt_eager_fpu) ? "" : " None", boot_cpu_has(X86_FEATURE_SC_MSR_HVM) ? " MSR_SPEC_CTRL" : "", boot_cpu_has(X86_FEATURE_SC_RSB_HVM) ? " RSB" : "", - opt_eager_fpu ? " EAGER_FPU" : ""); + opt_eager_fpu ? " EAGER_FPU" : "", + boot_cpu_has(X86_FEATURE_MD_CLEAR) ? " MD_CLEAR" : ""); #endif #ifdef CONFIG_PV - printk(" Support for PV VMs:%s%s%s%s\n", + printk(" Support for PV VMs:%s%s%s%s%s\n", (boot_cpu_has(X86_FEATURE_SC_MSR_PV) || boot_cpu_has(X86_FEATURE_SC_RSB_PV) || opt_eager_fpu) ? "" : " None", boot_cpu_has(X86_FEATURE_SC_MSR_PV) ? " MSR_SPEC_CTRL" : "", boot_cpu_has(X86_FEATURE_SC_RSB_PV) ? " RSB" : "", - opt_eager_fpu ? " EAGER_FPU" : ""); + opt_eager_fpu ? " EAGER_FPU" : "", + boot_cpu_has(X86_FEATURE_MD_CLEAR) ? " MD_CLEAR" : ""); printk(" XPTI (64-bit PV only): Dom0 %s, DomU %s (with%s PCID)\n", opt_xpti_hwdom ? "enabled" : "disabled", --- a/xen/include/asm-x86/msr-index.h +++ b/xen/include/asm-x86/msr-index.h @@ -51,6 +51,7 @@ #define ARCH_CAPS_RSBA (_AC(1, ULL) << 2) #define ARCH_CAPS_SKIP_L1DFL (_AC(1, ULL) << 3) #define ARCH_CAPS_SSB_NO (_AC(1, ULL) << 4) +#define ARCH_CAPS_MDS_NO (_AC(1, ULL) << 5) #define MSR_FLUSH_CMD 0x0000010b #define FLUSH_CMD_L1D (_AC(1, ULL) << 0) --- a/xen/include/public/arch-x86/cpufeatureset.h +++ b/xen/include/public/arch-x86/cpufeatureset.h @@ -242,6 +242,7 @@ XEN_CPUFEATURE(IBPB, 8*32+12) / /* Intel-defined CPU features, CPUID level 0x00000007:0.edx, word 9 */ XEN_CPUFEATURE(AVX512_4VNNIW, 9*32+ 2) /*A AVX512 Neural Network Instructions */ XEN_CPUFEATURE(AVX512_4FMAPS, 9*32+ 3) /*A AVX512 Multiply Accumulation Single Precision */ +XEN_CPUFEATURE(MD_CLEAR, 9*32+10) /*A VERW clears microarchitectural buffers */ XEN_CPUFEATURE(TSX_FORCE_ABORT, 9*32+13) /* MSR_TSX_FORCE_ABORT.RTM_ABORT */ XEN_CPUFEATURE(IBRSB, 9*32+26) /*A IBRS and IBPB support (used by Intel) */ XEN_CPUFEATURE(STIBP, 9*32+27) /*A STIBP */ ++++++ xsa297-2.patch ++++++ # Commit 0eb1f25784706d810ce391a3c4187c0285c41f88 # Date 2019-04-18 14:31:59 +0100 # Author Andrew Cooper <[email protected]> # Committer Andrew Cooper <[email protected]> x86/spec-ctrl: Infrastructure to use VERW to flush pipeline buffers 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. Signed-off-by: Andrew Cooper <[email protected]> Reviewed-by: Jan Beulich <[email protected]> --- a/xen/arch/x86/x86_64/asm-offsets.c +++ b/xen/arch/x86/x86_64/asm-offsets.c @@ -110,6 +110,7 @@ void __dummy__(void) BLANK(); OFFSET(CPUINFO_guest_cpu_user_regs, struct cpu_info, guest_cpu_user_regs); + OFFSET(CPUINFO_verw_sel, struct cpu_info, verw_sel); OFFSET(CPUINFO_current_vcpu, struct cpu_info, current_vcpu); OFFSET(CPUINFO_cr4, struct cpu_info, cr4); OFFSET(CPUINFO_xen_cr3, struct cpu_info, xen_cr3); --- a/xen/include/asm-x86/cpufeatures.h +++ b/xen/include/asm-x86/cpufeatures.h @@ -31,3 +31,6 @@ XEN_CPUFEATURE(SC_RSB_PV, (FSCAPIN XEN_CPUFEATURE(SC_RSB_HVM, (FSCAPINTS+0)*32+19) /* RSB overwrite needed for HVM */ XEN_CPUFEATURE(SC_MSR_IDLE, (FSCAPINTS+0)*32+21) /* (SC_MSR_PV || SC_MSR_HVM) && default_xen_spec_ctrl */ XEN_CPUFEATURE(XEN_LBR, (FSCAPINTS+0)*32+22) /* Xen uses MSR_DEBUGCTL.LBR */ +XEN_CPUFEATURE(SC_VERW_PV, (FSCAPINTS+0)*32+23) /* VERW used by Xen for PV */ +XEN_CPUFEATURE(SC_VERW_HVM, (FSCAPINTS+0)*32+24) /* VERW used by Xen for HVM */ +XEN_CPUFEATURE(SC_VERW_IDLE, (FSCAPINTS+0)*32+25) /* VERW used by Xen for idle */ --- a/xen/include/asm-x86/current.h +++ b/xen/include/asm-x86/current.h @@ -38,6 +38,7 @@ struct vcpu; struct cpu_info { struct cpu_user_regs guest_cpu_user_regs; unsigned int processor_id; + unsigned int verw_sel; struct vcpu *current_vcpu; unsigned long per_cpu_offset; unsigned long cr4; --- a/xen/include/asm-x86/spec_ctrl.h +++ b/xen/include/asm-x86/spec_ctrl.h @@ -60,6 +60,13 @@ static inline void init_shadow_spec_ctrl info->shadow_spec_ctrl = 0; info->xen_spec_ctrl = default_xen_spec_ctrl; info->spec_ctrl_flags = default_spec_ctrl_flags; + + /* + * For least latency, the VERW selector should be a writeable data + * descriptor resident in the cache. __HYPERVISOR_DS32 shares a cache + * line with __HYPERVISOR_CS, so is expected to be very cache-hot. + */ + info->verw_sel = __HYPERVISOR_DS32; } /* WARNING! `ret`, `call *`, `jmp *` not safe after this call. */ @@ -80,6 +87,22 @@ static always_inline void spec_ctrl_ente alternative_input("", "wrmsr", X86_FEATURE_SC_MSR_IDLE, "a" (val), "c" (MSR_SPEC_CTRL), "d" (0)); barrier(); + + /* + * Microarchitectural Store Buffer Data Sampling: + * + * On vulnerable systems, store buffer entries are statically partitioned + * between active threads. When entering idle, our store buffer entries + * are re-partitioned to allow the other threads to use them. + * + * Flush the buffers to ensure that no sensitive data of ours can be + * leaked by a sibling after it gets our store buffer entries. + * + * Note: VERW must be encoded with a memory operand, as it is only that + * form which causes a flush. + */ + alternative_input("", "verw %[sel]", X86_FEATURE_SC_VERW_IDLE, + [sel] "m" (info->verw_sel)); } /* WARNING! `ret`, `call *`, `jmp *` not safe before this call. */ @@ -98,6 +121,17 @@ static always_inline void spec_ctrl_exit alternative_input("", "wrmsr", X86_FEATURE_SC_MSR_IDLE, "a" (val), "c" (MSR_SPEC_CTRL), "d" (0)); barrier(); + + /* + * Microarchitectural Store Buffer Data Sampling: + * + * On vulnerable systems, store buffer entries are statically partitioned + * between active threads. When exiting idle, the other threads store + * buffer entries are re-partitioned to give us some. + * + * We now have store buffer entries with stale data from sibling threads. + * A flush if necessary will be performed on the return to guest path. + */ } #endif /* __ASSEMBLY__ */ --- a/xen/include/asm-x86/spec_ctrl_asm.h +++ b/xen/include/asm-x86/spec_ctrl_asm.h @@ -241,12 +241,16 @@ /* Use when exiting to PV guest context. */ #define SPEC_CTRL_EXIT_TO_PV \ ALTERNATIVE "", \ - DO_SPEC_CTRL_EXIT_TO_GUEST, X86_FEATURE_SC_MSR_PV + DO_SPEC_CTRL_EXIT_TO_GUEST, X86_FEATURE_SC_MSR_PV; \ + ALTERNATIVE "", __stringify(verw CPUINFO_verw_sel(%rsp)), \ + X86_FEATURE_SC_VERW_PV /* Use when exiting to HVM guest context. */ #define SPEC_CTRL_EXIT_TO_HVM \ ALTERNATIVE "", \ - DO_SPEC_CTRL_EXIT_TO_GUEST, X86_FEATURE_SC_MSR_HVM + DO_SPEC_CTRL_EXIT_TO_GUEST, X86_FEATURE_SC_MSR_HVM; \ + ALTERNATIVE "", __stringify(verw CPUINFO_verw_sel(%rsp)), \ + X86_FEATURE_SC_VERW_HVM /* * Use in IST interrupt/exception context. May interrupt Xen or PV context. ++++++ xsa297-3.patch ++++++ # Commit b01017a0a8ae283e714584f6dae0dc5f5a86456c # Date 2019-04-18 14:31:59 +0100 # Author Andrew Cooper <[email protected]> # Committer Andrew Cooper <[email protected]> x86/spec-ctrl: Introduce options to control VERW flushing The Microarchitectural Data Sampling vulnerability is split into categories with subtly different properties: * Microarchitectural Load Port Data Sampling * Microarchitectural Store Buffer Data Sampling * Microarchitectural Fill Buffer Data Sampling All 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 with SP only, and parts with LP or FB in addition to SP. * 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, the Knights range of processors are immune 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. Signed-off-by: Andrew Cooper <[email protected]> --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -1895,7 +1895,7 @@ not be able to control the state of the By default SSBD will be mitigated at runtime (i.e `ssbd=runtime`). ### spec-ctrl (x86) -> `= List of [ <bool>, xen=<bool>, {pv,hvm,msr-sc,rsb}=<bool>, +> `= List of [ <bool>, xen=<bool>, {pv,hvm,msr-sc,rsb,mds}=<bool>, > bti-thunk=retpoline|lfence|jmp, {ibrs,ibpb,ssbd,eager-fpu, > l1d-flush}=<bool> ]` @@ -1919,9 +1919,9 @@ in place for guests to use. Use of a positive boolean value for either of these options is invalid. -The booleans `pv=`, `hvm=`, `msr-sc=` and `rsb=` offer fine grained control -over the alternative blocks used by Xen. These impact Xen's ability to -protect itself, and Xen's ability to virtualise support for guests to use. +The booleans `pv=`, `hvm=`, `msr-sc=`, `rsb=` and `mds=` offer fine grained +control over the alternative blocks used by Xen. These impact Xen's ability +to protect itself, and Xen's ability to virtualise support for guests to use. * `pv=` and `hvm=` offer control over all suboptions for PV and HVM guests respectively. @@ -1930,6 +1930,8 @@ protect itself, and Xen's ability to vir guests and if disabled, guests will be unable to use IBRS/STIBP/SSBD/etc. * `rsb=` offers control over whether to overwrite the Return Stack Buffer / Return Address Stack on entry to Xen. +* `mds=` offers control over whether to VERW to flush microarchitectural + buffers on idle and exit from Xen. If Xen was compiled with INDIRECT_THUNK support, `bti-thunk=` can be used to select which of the thunks gets patched into the `__x86_indirect_thunk_%reg` --- a/xen/arch/x86/spec_ctrl.c +++ b/xen/arch/x86/spec_ctrl.c @@ -35,6 +35,8 @@ static bool __initdata opt_msr_sc_pv = t static bool __initdata opt_msr_sc_hvm = true; static bool __initdata opt_rsb_pv = true; static bool __initdata opt_rsb_hvm = true; +static int8_t __initdata opt_mds_pv = -1; +static int8_t __initdata opt_mds_hvm = -1; /* Cmdline controls for Xen's speculative settings. */ static enum ind_thunk { @@ -59,6 +61,9 @@ paddr_t __read_mostly l1tf_addr_mask, __ static bool __initdata cpu_has_bug_l1tf; static unsigned int __initdata l1d_maxphysaddr; +static bool __initdata cpu_has_bug_mds; /* MLPDS and/or MFBDS. */ +static bool __initdata cpu_has_bug_msbds_only; + static int __init parse_spec_ctrl(const char *s) { const char *ss; @@ -94,6 +99,8 @@ static int __init parse_spec_ctrl(const disable_common: opt_rsb_pv = false; opt_rsb_hvm = false; + opt_mds_pv = 0; + opt_mds_hvm = 0; opt_thunk = THUNK_JMP; opt_ibrs = 0; @@ -116,11 +123,13 @@ static int __init parse_spec_ctrl(const { opt_msr_sc_pv = val; opt_rsb_pv = val; + opt_mds_pv = val; } else if ( (val = parse_boolean("hvm", s, ss)) >= 0 ) { opt_msr_sc_hvm = val; opt_rsb_hvm = val; + opt_mds_hvm = val; } else if ( (val = parse_boolean("msr-sc", s, ss)) >= 0 ) { @@ -132,6 +141,11 @@ static int __init parse_spec_ctrl(const opt_rsb_pv = val; opt_rsb_hvm = val; } + else if ( (val = parse_boolean("mds", s, ss)) >= 0 ) + { + opt_mds_pv = val; + opt_mds_hvm = val; + } /* Xen's speculative sidechannel mitigation settings. */ else if ( !strncmp(s, "bti-thunk=", 10) ) @@ -317,7 +331,7 @@ static void __init print_details(enum in "\n"); /* Settings for Xen's protection, irrespective of guests. */ - printk(" Xen settings: BTI-Thunk %s, SPEC_CTRL: %s%s, Other:%s%s\n", + printk(" Xen settings: BTI-Thunk %s, SPEC_CTRL: %s%s, Other:%s%s%s\n", thunk == THUNK_NONE ? "N/A" : thunk == THUNK_RETPOLINE ? "RETPOLINE" : thunk == THUNK_LFENCE ? "LFENCE" : @@ -327,7 +341,8 @@ static void __init print_details(enum in !boot_cpu_has(X86_FEATURE_SSBD) ? "" : (default_xen_spec_ctrl & SPEC_CTRL_SSBD) ? " SSBD+" : " SSBD-", opt_ibpb ? " IBPB" : "", - opt_l1d_flush ? " L1D_FLUSH" : ""); + opt_l1d_flush ? " L1D_FLUSH" : "", + opt_mds_pv || opt_mds_hvm ? " VERW" : ""); /* L1TF diagnostics, printed if vulnerable or PV shadowing is in use. */ if ( cpu_has_bug_l1tf || opt_pv_l1tf_hwdom || opt_pv_l1tf_domu ) @@ -737,6 +752,107 @@ static __init void l1tf_calculations(uin : (3ul << (paddr_bits - 2)))); } +/* Calculate whether this CPU is vulnerable to MDS. */ +static __init void mds_calculations(uint64_t caps) +{ + /* MDS is only known to affect Intel Family 6 processors at this time. */ + if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL || + boot_cpu_data.x86 != 6 ) + return; + + /* Any processor advertising MDS_NO should be not vulnerable to MDS. */ + if ( caps & ARCH_CAPS_MDS_NO ) + return; + + switch ( boot_cpu_data.x86_model ) + { + /* + * Core processors since at least Nehalem are vulnerable. + */ + case 0x1f: /* Auburndale / Havendale */ + case 0x1e: /* Nehalem */ + case 0x1a: /* Nehalem EP */ + case 0x2e: /* Nehalem EX */ + case 0x25: /* Westmere */ + case 0x2c: /* Westmere EP */ + case 0x2f: /* Westmere EX */ + case 0x2a: /* SandyBridge */ + case 0x2d: /* SandyBridge EP/EX */ + case 0x3a: /* IvyBridge */ + case 0x3e: /* IvyBridge EP/EX */ + case 0x3c: /* Haswell */ + case 0x3f: /* Haswell EX/EP */ + case 0x45: /* Haswell D */ + case 0x46: /* Haswell H */ + case 0x3d: /* Broadwell */ + case 0x47: /* Broadwell H */ + case 0x4f: /* Broadwell EP/EX */ + case 0x56: /* Broadwell D */ + case 0x4e: /* Skylake M */ + case 0x5e: /* Skylake D */ + cpu_has_bug_mds = true; + break; + + /* + * Some Core processors have per-stepping vulnerability. + */ + case 0x55: /* Skylake-X / Cascade Lake */ + if ( boot_cpu_data.x86_mask <= 5 ) + cpu_has_bug_mds = true; + break; + + case 0x8e: /* Kaby / Coffee / Whiskey Lake M */ + if ( boot_cpu_data.x86_mask <= 0xb ) + cpu_has_bug_mds = true; + break; + + case 0x9e: /* Kaby / Coffee / Whiskey Lake D */ + if ( boot_cpu_data.x86_mask <= 0xc ) + cpu_has_bug_mds = true; + break; + + /* + * Very old and very new Atom processors are not vulnerable. + */ + case 0x1c: /* Pineview */ + case 0x26: /* Lincroft */ + case 0x27: /* Penwell */ + case 0x35: /* Cloverview */ + case 0x36: /* Cedarview */ + case 0x7a: /* Goldmont */ + break; + + /* + * Middling Atom processors are vulnerable to just the Store Buffer + * aspect. + */ + case 0x37: /* Baytrail / Valleyview (Silvermont) */ + case 0x4a: /* Merrifield */ + case 0x4c: /* Cherrytrail / Brasswell */ + case 0x4d: /* Avaton / Rangely (Silvermont) */ + case 0x5a: /* Moorefield */ + case 0x5d: + case 0x65: + case 0x6e: + case 0x75: + /* + * Knights processors (which are based on the Silvermont/Airmont + * microarchitecture) are similarly only affected by the Store Buffer + * aspect. + */ + case 0x57: /* Knights Landing */ + case 0x85: /* Knights Mill */ + cpu_has_bug_msbds_only = true; + break; + + default: + printk("Unrecognised CPU model %#x - assuming vulnerable to MDS\n", + boot_cpu_data.x86_model); + cpu_has_bug_mds = true; + break; + } +} + void __init init_speculation_mitigations(void) { enum ind_thunk thunk = THUNK_DEFAULT; @@ -924,6 +1040,47 @@ void __init init_speculation_mitigations "enabled. Please assess your configuration and choose an\n" "explicit 'smt=<bool>' setting. See XSA-273.\n"); + mds_calculations(caps); + + /* + * By default, enable PV and HVM mitigations on MDS-vulnerable hardware. + * This will only be a token effort for MLPDS/MFBDS when HT is enabled, + * but it is somewhat better than nothing. + */ + if ( opt_mds_pv == -1 ) + opt_mds_pv = ((cpu_has_bug_mds || cpu_has_bug_msbds_only) && + boot_cpu_has(X86_FEATURE_MD_CLEAR)); + if ( opt_mds_hvm == -1 ) + opt_mds_hvm = ((cpu_has_bug_mds || cpu_has_bug_msbds_only) && + boot_cpu_has(X86_FEATURE_MD_CLEAR)); + + /* + * Enable MDS defences as applicable. The PV blocks need using all the + * time, and the Idle blocks need using if either PV or HVM defences are + * used. + * + * HVM is more complicated. The MD_CLEAR microcode extends L1D_FLUSH with + * equivelent semantics to avoid needing to perform both flushes on the + * HVM path. The HVM blocks don't need activating if our hypervisor told + * us it was handling L1D_FLUSH, or we are using L1D_FLUSH ourselves. + */ + if ( opt_mds_pv ) + setup_force_cpu_cap(X86_FEATURE_SC_VERW_PV); + if ( opt_mds_pv || opt_mds_hvm ) + setup_force_cpu_cap(X86_FEATURE_SC_VERW_IDLE); + if ( opt_mds_hvm && !(caps & ARCH_CAPS_SKIP_L1DFL) && !opt_l1d_flush ) + setup_force_cpu_cap(X86_FEATURE_SC_VERW_HVM); + + /* + * Warn the user if they are on MLPDS/MFBDS-vulnerable hardware with HT + * active and no explicit SMT choice. + */ + if ( opt_smt == -1 && cpu_has_bug_mds && hw_smt_enabled ) + warning_add( + "Booted on MLPDS/MFBDS-vulnerable hardware with SMT/Hyperthreading\n" + "enabled. Mitigations will not be fully effective. Please\n" + "choose an explicit smt=<bool> setting. See XSA-297.\n"); + print_details(thunk, caps); /*
