4.4.202-stable review
Subsystems (3)
Greg Kroah-Hartman
maintainercover 4.4.202-stable review
This is the start of the stable review cycle for the 4.4.202 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 17 Nov 2019 06:18:31 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.202-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.4.202-rc1
Vineela Tummalapalli <[email protected]>
x86/bugs: Add ITLB_MULTIHIT bug infrastructure
Josh Poimboeuf <[email protected]>
x86/speculation/taa: Fix printing of TAA_MSG_SMT on IBRS_ALL CPUs
Michal Hocko <[email protected]>
x86/tsx: Add config options to set tsx=on|off|auto
Pawan Gupta <[email protected]>
x86/speculation/taa: Add documentation for TSX Async Abort
Pawan Gupta <[email protected]>
x86/tsx: Add "auto" option to the tsx= cmdline parameter
Pawan Gupta <[email protected]>
kvm/x86: Export MDS_NO=0 to guests when TSX is enabled
Pawan Gupta <[email protected]>
x86/speculation/taa: Add sysfs reporting for TSX Async Abort
Pawan Gupta <[email protected]>
x86/speculation/taa: Add mitigation for TSX Async Abort
Pawan Gupta <[email protected]>
x86/cpu: Add a "tsx=" cmdline option with TSX disabled by default
Pawan Gupta <[email protected]>
x86/cpu: Add a helper function x86_read_arch_cap_msr()
Pawan Gupta <[email protected]>
x86/msr: Add the IA32_TSX_CTRL MSR
Paolo Bonzini <[email protected]>
KVM: x86: use Intel speculation bugs and features as derived in generic x86 code
Jim Mattson <[email protected]>
kvm: x86: IA32_ARCH_CAPABILITIES is always supported
Sean Christopherson <[email protected]>
KVM: x86: Emulate MSR_IA32_ARCH_CAPABILITIES on AMD hosts
Ben Hutchings <[email protected]>
KVM: Introduce kvm_get_arch_capabilities()
Nicholas Piggin <[email protected]>
powerpc/boot: Request no dynamic linker for boot wrapper
Nicholas Piggin <[email protected]>
powerpc: Fix compiling a BE kernel with a powerpc64le toolchain
Michael Ellerman <[email protected]>
powerpc/Makefile: Use cflags-y/aflags-y for setting endian options
Jonas Gorski <[email protected]>
MIPS: BCM63XX: fix switch core reset on BCM6368
Junaid Shahid <[email protected]>
kvm: mmu: Don't read PDPTEs when paging is not enabled
-------------
Diffstat:
Documentation/ABI/testing/sysfs-devices-system-cpu | 2 + Documentation/hw-vuln/tsx_async_abort.rst | 268 +++++++++++++++++++++ Documentation/kernel-parameters.txt | 62 +++++ Documentation/x86/tsx_async_abort.rst | 117 +++++++++ Makefile | 4 +- arch/mips/bcm63xx/reset.c | 2 +- arch/powerpc/Makefile | 31 ++- arch/powerpc/boot/wrapper | 24 +- arch/x86/Kconfig | 45 ++++ arch/x86/include/asm/cpufeatures.h | 2 + arch/x86/include/asm/kvm_host.h | 2 + arch/x86/include/asm/msr-index.h | 16 ++ arch/x86/include/asm/nospec-branch.h | 4 +- arch/x86/include/asm/processor.h | 7 + arch/x86/kernel/cpu/Makefile | 2 +- arch/x86/kernel/cpu/bugs.c | 143 ++++++++++- arch/x86/kernel/cpu/common.c | 93 ++++--- arch/x86/kernel/cpu/cpu.h | 18 ++ arch/x86/kernel/cpu/intel.c | 5 + arch/x86/kernel/cpu/tsx.c | 140 +++++++++++ arch/x86/kvm/cpuid.c | 12 + arch/x86/kvm/vmx.c | 15 -- arch/x86/kvm/x86.c | 53 +++- drivers/base/cpu.c | 17 ++ include/linux/cpu.h | 5 + 25 files changed, 1019 insertions(+), 70 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/20 kvm: mmu: Dont read PDPTEs when paging is not enabled
From: Junaid Shahid <[email protected]>
[ Upstream commit d35b34a9a70edae7ef923f100e51b8b5ae9fe899 ]
kvm should not attempt to read guest PDPTEs when CR0.PG = 0 and CR4.PAE = 1.
--- arch/x86/kvm/x86.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/x86/kvm/x86.c +2 -2
@@ -575,7 +575,7 @@ static bool pdptrs_changed(struct kvm_vcgfn_t gfn;int r; -if (is_long_mode (vcpu) || !is_pae (vcpu)) +if (is_long_mode (vcpu) || !is_pae (vcpu) || !is_paging (vcpu))return false; if (!test_bit(VCPU_EXREG_PDPTR,
@@ -7168,7 +7168,7 @@ int kvm_arch_vcpu_ioctl_set_sregs(structkvm_update_cpuid (vcpu); idx =srcu_read_lock (&vcpu->kvm->srcu); -if (!is_long_mode (vcpu) &&is_pae (vcpu)) { +if (!is_long_mode (vcpu) &&is_pae (vcpu) &&is_paging (vcpu)) {load_pdptrs (vcpu, vcpu->arch.walk_mmu,kvm_read_cr3 (vcpu)); mmu_reset_needed =1 ; }
Greg Kroah-Hartman
maintainerPATCH 2/20 MIPS: BCM63XX: fix switch core reset on BCM6368
In reply to Greg Kroah-HartmanFrom: Jonas Gorski <[email protected]>
commit 8a38dacf87180738d42b058334c951eba15d2d47 upstream.
The Ethernet Switch core mask was set to 0, causing the switch core to be not reset on BCM6368 on boot. Provide the proper mask so the switch core gets reset to a known good state.
--- arch/mips/bcm63xx/reset.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/mips/bcm63xx/reset.c +1 -1
@@ -119,7 +119,7 @@#define BCM6368_RESET_DSL 0#define BCM6368_RESET_SAR SOFTRESET_6368_SAR_MASK#define BCM6368_RESET_EPHY SOFTRESET_6368_EPHY_MASK -#define BCM6368_RESET_ENETSW 0 +#define BCM6368_RESET_ENETSW SOFTRESET_6368_ENETSW_MASK#define BCM6368_RESET_PCM SOFTRESET_6368_PCM_MASK#define BCM6368_RESET_MPI SOFTRESET_6368_MPI_MASK#define BCM6368_RESET_PCIE 0
Greg Kroah-Hartman
maintainerPATCH 3/20 powerpc/Makefile: Use cflags-y/aflags-y for setting endian options
In reply to Greg Kroah-HartmanFrom: Michael Ellerman <[email protected]>
commit 164af597ce945751e2dcd53d0a86e84203a6d117 upstream.
When we introduced the little endian support, we added the endian flags to CC directly using override. I don't know the history of why we did that, I suspect no one does.
Although this mostly works, it has one bug, which is that CROSS32CC doesn't get -mbig-endian. That means when the compiler is little endian by default and the user is building big endian, vdso32 is incorrectly compiled as little endian and the kernel fails to build.
Instead we can add the endian flags to cflags-y/aflags-y, and then append those to KBUILD_CFLAGS/KBUILD_AFLAGS.
This has the advantage of being 1) less ugly, 2) the documented way of adding flags in the arch Makefile and 3) it fixes building vdso32 with a LE toolchain.
--- arch/powerpc/Makefile | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-)
arch/powerpc/Makefile +12 -10
@@ -66,29 +66,28 @@ endif UTS_MACHINE := $(OLDARCH) ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y) -override CC += -mlittle-endian -ifneq ($(cc-name),clang) -override CC += -mno-strict-align -endif -override AS += -mlittle-endian override LD += -EL -override CROSS32CC += -mlittle-endian override CROSS32AS += -mlittle-endian LDEMULATION := lppc GNUTARGET := powerpcle MULTIPLEWORD := -mno-multiple KBUILD_CFLAGS_MODULE += $(call cc-option,-mno-save-toc-indirect) else -ifeq ($(call cc-option-yn,-mbig-endian),y) -override CC += -mbig-endian -override AS += -mbig-endian -endif override LD += -EB LDEMULATION := ppc GNUTARGET := powerpc MULTIPLEWORD := -mmultiple endif +cflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mbig-endian) +cflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mlittle-endian +ifneq ($(cc-name),clang) + cflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mno-strict-align +endif + +aflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mbig-endian) +aflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mlittle-endian + ifeq ($(HAS_BIARCH),y) override AS += -a$(CONFIG_WORD_SIZE) override LD += -m elf$(CONFIG_WORD_SIZE)$(LDEMULATION)
@@ -212,6 +211,9 @@ cpu-as-$(CONFIG_E200) += -Wa,-me200 KBUILD_AFLAGS += $(cpu-as-y) KBUILD_CFLAGS += $(cpu-as-y) +KBUILD_AFLAGS += $(aflags-y) +KBUILD_CFLAGS += $(cflags-y) + head-y := arch/powerpc/kernel/head_$(CONFIG_WORD_SIZE).o head-$(CONFIG_8xx) := arch/powerpc/kernel/head_8xx.o head-$(CONFIG_40x) := arch/powerpc/kernel/head_40x.o
Greg Kroah-Hartman
maintainerPATCH 4/20 powerpc: Fix compiling a BE kernel with a powerpc64le toolchain
In reply to Greg Kroah-HartmanFrom: Nicholas Piggin <[email protected]>
commit 4dc831aa88132f835cefe876aa0206977c4d7710 upstream.
GCC can compile with either endian, but the default ABI version is set based on the default endianness of the toolchain. Alan Modra says:
you need both -mbig and -mabi=elfv1 to make a powerpc64le gcc generate powerpc64 code
The opposite is true for powerpc64 when generating -mlittle it requires -mabi=elfv2 to generate v2 ABI, which we were already doing.
This change adds ABI annotations together with endianness for all cases, LE and BE. This fixes the case of building a BE kernel with a toolchain that is LE by default.
--- arch/powerpc/Makefile | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
arch/powerpc/Makefile +10 -1
@@ -79,8 +79,15 @@ GNUTARGET := powerpc MULTIPLEWORD := -mmultiple endif -cflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mbig-endian) +ifdef CONFIG_PPC64 +cflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mabi=elfv1) +cflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mcall-aixdesc) +aflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mabi=elfv1) +aflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mabi=elfv2 +endif + cflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mlittle-endian +cflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mbig-endian) ifneq ($(cc-name),clang) cflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mno-strict-align endif
@@ -120,7 +127,9 @@ ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y) CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2,$(call cc-option,-mcall-aixdesc)) AFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2) else +CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv1) CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcall-aixdesc) +AFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv1) endif CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcmodel=medium,$(call cc-option,-mminimal-toc)) CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mno-pointers-to-nested-functions)
Greg Kroah-Hartman
maintainerPATCH 5/20 powerpc/boot: Request no dynamic linker for boot wrapper
In reply to Greg Kroah-HartmanFrom: Nicholas Piggin <[email protected]>
commit ff45000fcb56b5b0f1a14a865d3541746d838a0a upstream.
The boot wrapper performs its own relocations and does not require PT_INTERP segment. However currently we don't tell the linker that.
Prior to binutils 2.28 that works OK. But since binutils commit 1a9ccd70f9a7 ("Fix the linker so that it will not silently generate ELF binaries with invalid program headers. Fix readelf to report such invalid binaries.") binutils tries to create a program header segment due to PT_INTERP, and the link fails because there is no space for it:
ld: arch/powerpc/boot/zImage.pseries: Not enough room for program headers, try linking with -N
ld: final link failed: Bad value
So tell the linker not to do that, by passing --no-dynamic-linker.
--- arch/powerpc/boot/wrapper | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-)
arch/powerpc/boot/wrapper +23 -1
@@ -161,6 +161,28 @@ case "$elfformat" in elf32-powerpc) format=elf32ppc ;; esac +ld_version() +{ + # Poached from scripts/ld-version.sh, but we don't want to call that because + # this script (wrapper) is distributed separately from the kernel source. + # Extract linker version number from stdin and turn into single number. + awk '{ + gsub(".*\\)", ""); + gsub(".*version ", ""); + gsub("-.*", ""); + split($1,a, "."); + print a[1]*100000000 + a[2]*1000000 + a[3]*10000; + exit + }' +} + +# Do not include PT_INTERP segment when linking pie. Non-pie linking +# just ignores this option. +LD_VERSION=$(${CROSS}ld --version | ld_version) +LD_NO_DL_MIN_VERSION=$(echo 2.26 | ld_version) +if [ "$LD_VERSION" -ge "$LD_NO_DL_MIN_VERSION" ] ; then + nodl="--no-dynamic-linker" +fi platformo=$object/"$platform".o lds=$object/zImage.lds
@@ -412,7 +434,7 @@ if [ "$platform" != "miboot" ]; then if [ -n "$link_address" ] ; then text_start="-Ttext $link_address" fi - ${CROSS}ld -m $format -T $lds $text_start $pie -o "$ofile" \ + ${CROSS}ld -m $format -T $lds $text_start $pie $nodl -o "$ofile" \ $platformo $tmp $object/wrapper.a rm $tmp fi
Greg Kroah-Hartman
maintainerPATCH 6/20 KVM: Introduce kvm_get_arch_capabilities()
In reply to Greg Kroah-HartmanFrom: Ben Hutchings <[email protected]>
Extracted from commit 5b76a3cff011 "KVM: VMX: Tell the nested hypervisor to skip L1D flush on vmentry". We will need this to let a nested hypervisor know that we have applied the mitigation for TAA.
--- arch/x86/include/asm/kvm_host.h | 1 + arch/x86/kvm/vmx.c | 3 +-- arch/x86/kvm/x86.c | 10 ++++++++++ 3 files changed, 12 insertions(+), 2 deletions(-)
arch/x86/include/asm/kvm_host.h +1 -0
@@ -1226,6 +1226,7 @@ void kvm_vcpu_reload_apic_access_page(stvoid kvm_arch_mmu_notifier_invalidate_page (struct kvm *kvm,unsigned long address); +u64 kvm_get_arch_capabilities (void );void kvm_define_shared_msr (unsigned index,u32 msr);int kvm_set_shared_msr (unsigned index,u64 val,u64 mask);
arch/x86/kvm/vmx.c +1 -2
@@ -5079,8 +5079,7 @@ static int vmx_vcpu_setup(struct vcpu_vm ++vmx->nmsrs; } -if (boot_cpu_has (X86_FEATURE_ARCH_CAPABILITIES )) -rdmsrl (MSR_IA32_ARCH_CAPABILITIES , vmx->arch_capabilities); + vmx->arch_capabilities =kvm_get_arch_capabilities ();vm_exit_controls_init (vmx, vmcs_config.vmexit_ctrl);
arch/x86/kvm/x86.c +10 -0
@@ -995,6 +995,16 @@ static u32 emulated_msrs[] = {static unsigned num_emulated_msrs; +u64 kvm_get_arch_capabilities (void ) +{ +u64 data; + +rdmsrl_safe (MSR_IA32_ARCH_CAPABILITIES , &data); + +return data; +} +EXPORT_SYMBOL_GPL (kvm_get_arch_capabilities); +static bool __kvm_valid_efer (struct kvm_vcpu *vcpu,u64 efer) {if (efer &EFER_FFXSR ) {
Greg Kroah-Hartman
maintainerPATCH 7/20 KVM: x86: Emulate MSR_IA32_ARCH_CAPABILITIES on AMD hosts
In reply to Greg Kroah-HartmanFrom: Sean Christopherson <[email protected]>
commit 0cf9135b773bf32fba9dd8e6699c1b331ee4b749 upstream.
The CPUID flag ARCH_CAPABILITIES is unconditioinally exposed to host userspace for all x86 hosts, i.e. KVM advertises ARCH_CAPABILITIES regardless of hardware support under the pretense that KVM fully emulates MSR_IA32_ARCH_CAPABILITIES. Unfortunately, only VMX hosts handle accesses to MSR_IA32_ARCH_CAPABILITIES (despite KVM_GET_MSRS also reporting MSR_IA32_ARCH_CAPABILITIES for all hosts).
Move the MSR_IA32_ARCH_CAPABILITIES handling to common x86 code so that it's emulated on AMD hosts.
--- arch/x86/include/asm/kvm_host.h | 1 + arch/x86/kvm/vmx.c | 14 -------------- arch/x86/kvm/x86.c | 12 ++++++++++++ 3 files changed, 13 insertions(+), 14 deletions(-)
arch/x86/include/asm/kvm_host.h +1 -0
@@ -408,6 +408,7 @@ struct kvm_vcpu_arch {u64 smbase;bool tpr_access_reporting;u64 ia32_xss; +u64 arch_capabilities;/* * Paging state of the vcpu
arch/x86/kvm/vmx.c +0 -14
@@ -546,7 +546,6 @@ struct vcpu_vmx {u64 msr_guest_kernel_gs_base;#endif -u64 arch_capabilities;u64 spec_ctrl;u32 vm_entry_controls_shadow;
@@ -2866,12 +2865,6 @@ static int vmx_get_msr(struct kvm_vcpu * msr_info->data =to_vmx (vcpu)->spec_ctrl;break ; -case MSR_IA32_ARCH_CAPABILITIES : -if (!msr_info->host_initiated && - !guest_cpuid_has_arch_capabilities (vcpu)) -return 1 ; - msr_info->data =to_vmx (vcpu)->arch_capabilities; -break ;case MSR_IA32_SYSENTER_CS : msr_info->data =vmcs_read32 (GUEST_SYSENTER_CS );break ;
@@ -3028,11 +3021,6 @@ static int vmx_set_msr(struct kvm_vcpu *vmx_disable_intercept_for_msr (vmx->vmcs01.msr_bitmap,MSR_IA32_PRED_CMD ,MSR_TYPE_W );break ; -case MSR_IA32_ARCH_CAPABILITIES : -if (!msr_info->host_initiated) -return 1 ; - vmx->arch_capabilities = data; -break ;case MSR_IA32_CR_PAT :if (vmcs_config.vmentry_ctrl &VM_ENTRY_LOAD_IA32_PAT ) {if (!kvm_mtrr_valid (vcpu,MSR_IA32_CR_PAT , data))
@@ -5079,8 +5067,6 @@ static int vmx_vcpu_setup(struct vcpu_vm ++vmx->nmsrs; } - vmx->arch_capabilities =kvm_get_arch_capabilities (); -vm_exit_controls_init (vmx, vmcs_config.vmexit_ctrl);/* 22.2.1, 20.8.1 */
arch/x86/kvm/x86.c +12 -0
@@ -2080,6 +2080,11 @@ int kvm_set_msr_common(struct kvm_vcpu *case MSR_AMD64_BU_CFG2 :break ; +case MSR_IA32_ARCH_CAPABILITIES : +if (!msr_info->host_initiated) +return 1 ; + vcpu->arch.arch_capabilities = data; +break ;case MSR_EFER :return set_efer (vcpu, msr_info);case MSR_K7_HWCR :
@@ -2354,6 +2359,12 @@ int kvm_get_msr_common(struct kvm_vcpu *case MSR_IA32_UCODE_REV : msr_info->data =0x100000000ULL ;break ; +case MSR_IA32_ARCH_CAPABILITIES : +if (!msr_info->host_initiated && + !guest_cpuid_has_arch_capabilities (vcpu)) +return 1 ; + msr_info->data = vcpu->arch.arch_capabilities; +break ;case MSR_MTRRcap: case 0x200 ... 0x2ff:return kvm_mtrr_get_msr (vcpu, msr_info->index, &msr_info->data);
@@ -7402,6 +7413,7 @@ int kvm_arch_vcpu_setup(struct kvm_vcpu {int r; + vcpu->arch.arch_capabilities =kvm_get_arch_capabilities ();kvm_vcpu_mtrr_init (vcpu); r =vcpu_load (vcpu);if (r)
Greg Kroah-Hartman
maintainerPATCH 8/20 kvm: x86: IA32_ARCH_CAPABILITIES is always supported
In reply to Greg Kroah-HartmanFrom: Jim Mattson <[email protected]>
commit 1eaafe91a0df4157521b6417b3dd8430bf5f52f0 upstream.
If there is a possibility that a VM may migrate to a Skylake host, then the hypervisor should report IA32_ARCH_CAPABILITIES.RSBA[bit 2] as being set (future work, of course). This implies that CPUID.(EAX=7,ECX=0):EDX.ARCH_CAPABILITIES[bit 29] should be set. Therefore, kvm should report this CPUID bit as being supported whether or not the host supports it. Userspace is still free to clear the bit if it chooses.
For more information on RSBA, see Intel's white paper, "Retpoline: A Branch Target Injection Mitigation" (Document Number 337131-001), currently available at https://bugzilla.kernel.org/show_bug.cgi?id=199511.
Since the IA32_ARCH_CAPABILITIES MSR is emulated in kvm, there is no dependency on hardware support for this feature.
--- arch/x86/kvm/cpuid.c | 5 +++++ 1 file changed, 5 insertions(+)
arch/x86/kvm/cpuid.c +5 -0
@@ -447,6 +447,11 @@ static inline int __do_cpuid_ent(struct entry->ebx |=F (TSC_ADJUST ); entry->edx &= kvm_cpuid_7_0_edx_x86_features;cpuid_mask (&entry->edx,CPUID_7_EDX ); +/* +* We emulate ARCH_CAPABILITIES in software even +* if the host doesn't support it. +*/ + entry->edx |=F (ARCH_CAPABILITIES ); }else { entry->ebx =0 ; entry->edx =0 ;
Greg Kroah-Hartman
maintainerPATCH 9/20 KVM: x86: use Intel speculation bugs and features as derived in generic x86 code
In reply to Greg Kroah-HartmanFrom: Paolo Bonzini <[email protected]>
commit 0c54914d0c52a15db9954a76ce80fee32cf318f4 upstream.
Similar to AMD bits, set the Intel bits from the vendor-independent feature and bug flags, because KVM_GET_SUPPORTED_CPUID does not care about the vendor and they should be set on AMD processors as well.
--- arch/x86/kvm/cpuid.c | 7 +++++++ arch/x86/kvm/x86.c | 8 ++++++++ 2 files changed, 15 insertions(+)
arch/x86/kvm/cpuid.c +7 -0
@@ -447,6 +447,13 @@ static inline int __do_cpuid_ent(struct entry->ebx |=F (TSC_ADJUST ); entry->edx &= kvm_cpuid_7_0_edx_x86_features;cpuid_mask (&entry->edx,CPUID_7_EDX ); +if (boot_cpu_has (X86_FEATURE_IBPB ) && +boot_cpu_has (X86_FEATURE_IBRS )) + entry->edx |=F (SPEC_CTRL ); +if (boot_cpu_has (X86_FEATURE_STIBP )) + entry->edx |=F (INTEL_STIBP ); +if (boot_cpu_has (X86_FEATURE_SSBD )) + entry->edx |=F (SPEC_CTRL_SSBD );/* * We emulate ARCH_CAPABILITIES in software even * if the host doesn't support it.
arch/x86/kvm/x86.c +8 -0
@@ -1001,8 +1001,16 @@ u64 kvm_get_arch_capabilities(void)rdmsrl_safe (MSR_IA32_ARCH_CAPABILITIES , &data); +if (!boot_cpu_has_bug (X86_BUG_CPU_MELTDOWN )) + data |=ARCH_CAP_RDCL_NO ; +if (!boot_cpu_has_bug (X86_BUG_SPEC_STORE_BYPASS )) + data |=ARCH_CAP_SSB_NO ; +if (!boot_cpu_has_bug (X86_BUG_MDS )) + data |=ARCH_CAP_MDS_NO ; +return data; } +EXPORT_SYMBOL_GPL (kvm_get_arch_capabilities);static bool __kvm_valid_efer (struct kvm_vcpu *vcpu,u64 efer)
Greg Kroah-Hartman
maintainerPATCH 10/20 x86/msr: Add the IA32_TSX_CTRL MSR
In reply to Greg Kroah-HartmanFrom: Pawan Gupta <[email protected]>
commit c2955f270a84762343000f103e0640d29c7a96f3 upstream.
Transactional Synchronization Extensions (TSX) may be used on certain processors as part of a speculative side channel attack. A microcode update for existing processors that are vulnerable to this attack will add a new MSR - IA32_TSX_CTRL to allow the system administrator the option to disable TSX as one of the possible mitigations.
The CPUs which get this new MSR after a microcode upgrade are the ones which do not set MSR_IA32_ARCH_CAPABILITIES.MDS_NO (bit 5) because those CPUs have CPUID.MD_CLEAR, i.e., the VERW implementation which clears all CPU buffers takes care of the TAA case as well.
[ Note that future processors that are not vulnerable will also
support the IA32_TSX_CTRL MSR. ]
Add defines for the new IA32_TSX_CTRL MSR and its bits.
TSX has two sub-features:
1. Restricted Transactional Memory (RTM) is an explicitly-used feature where new instructions begin and end TSX transactions.
2. Hardware Lock Elision (HLE) is implicitly used when certain kinds of "old" style locks are used by software.
Bit 7 of the IA32_ARCH_CAPABILITIES indicates the presence of the IA32_TSX_CTRL MSR.
There are two control bits in IA32_TSX_CTRL MSR:
Bit 0: When set, it disables the Restricted Transactional Memory (RTM)
sub-feature of TSX (will force all transactions to abort on the XBEGIN instruction).
Bit 1: When set, it disables the enumeration of the RTM and HLE feature
(i.e. it will make CPUID(EAX=7).EBX{bit4} and
CPUID(EAX=7).EBX{bit11} read as 0).
The other TSX sub-feature, Hardware Lock Elision (HLE), is unconditionally disabled by the new microcode but still enumerated as present by CPUID(EAX=7).EBX{bit4}, unless disabled by IA32_TSX_CTRL_MSR[1] - TSX_CTRL_CPUID_CLEAR.
--- arch/x86/include/asm/msr-index.h | 5 +++++ 1 file changed, 5 insertions(+)
arch/x86/include/asm/msr-index.h +5 -0
@@ -71,10 +71,15 @@* Microarchitectural Data * Sampling (MDS) vulnerabilities. */ +#define ARCH_CAP_TSX_CTRL_MSR BIT(7)/* MSR for TSX control is available. */ #define MSR_IA32_BBL_CR_CTL 0x00000119#define MSR_IA32_BBL_CR_CTL3 0x0000011e +#define MSR_IA32_TSX_CTRL 0x00000122 +#define TSX_CTRL_RTM_DISABLE BIT(0)/* Disable RTM feature */ +#define TSX_CTRL_CPUID_CLEAR BIT(1)/* Disable TSX enumeration */ +#define MSR_IA32_SYSENTER_CS 0x00000174#define MSR_IA32_SYSENTER_ESP 0x00000175#define MSR_IA32_SYSENTER_EIP 0x00000176
Greg Kroah-Hartman
maintainerPATCH 11/20 x86/cpu: Add a helper function x86_read_arch_cap_msr()
In reply to Greg Kroah-HartmanFrom: Pawan Gupta <[email protected]>
commit 286836a70433fb64131d2590f4bf512097c255e1 upstream.
Add a helper function to read the IA32_ARCH_CAPABILITIES MSR.
--- arch/x86/kernel/cpu/common.c | 15 +++++++++++---- arch/x86/kernel/cpu/cpu.h | 2 ++ 2 files changed, 13 insertions(+), 4 deletions(-)
arch/x86/kernel/cpu/common.c +11 -4
@@ -918,19 +918,26 @@ static bool __init cpu_matches(unsignedreturn m && !!(m->driver_data & which); } -static void __init cpu_set_bug_bits (struct cpuinfo_x86 *c) +u64 x86_read_arch_cap_msr (void ) {u64 ia32_cap =0 ; +if (boot_cpu_has (X86_FEATURE_ARCH_CAPABILITIES )) +rdmsrl (MSR_IA32_ARCH_CAPABILITIES , ia32_cap); + +return ia32_cap; +} + +static void __init cpu_set_bug_bits (struct cpuinfo_x86 *c) +{ +u64 ia32_cap =x86_read_arch_cap_msr (); +if (cpu_matches (NO_SPECULATION ))return ;setup_force_cpu_bug (X86_BUG_SPECTRE_V1 );setup_force_cpu_bug (X86_BUG_SPECTRE_V2 ); -if (cpu_has (c,X86_FEATURE_ARCH_CAPABILITIES )) -rdmsrl (MSR_IA32_ARCH_CAPABILITIES , ia32_cap); -if (!cpu_matches (NO_SSB ) && !(ia32_cap &ARCH_CAP_SSB_NO ) && !cpu_has (c,X86_FEATURE_AMD_SSB_NO ))setup_force_cpu_bug (X86_BUG_SPEC_STORE_BYPASS );
arch/x86/kernel/cpu/cpu.h +2 -0
@@ -49,4 +49,6 @@ extern void cpu_detect_cache_sizes(strucextern void x86_spec_ctrl_setup_ap (void ); +extern u64 x86_read_arch_cap_msr (void ); +#endif /* ARCH_X86_CPU_H */
Greg Kroah-Hartman
maintainerPATCH 12/20 x86/cpu: Add a "tsx=" cmdline option with TSX disabled by default
In reply to Greg Kroah-HartmanFrom: Pawan Gupta <[email protected]>
commit 95c5824f75f3ba4c9e8e5a4b1a623c95390ac266 upstream.
Add a kernel cmdline parameter "tsx" to control the Transactional Synchronization Extensions (TSX) feature. On CPUs that support TSX control, use "tsx=on|off" to enable or disable TSX. Not specifying this option is equivalent to "tsx=off". This is because on certain processors TSX may be used as a part of a speculative side channel attack.
Carve out the TSX controlling functionality into a separate compilation unit because TSX is a CPU feature while the TSX async abort control machinery will go to cpu/bugs.c.
[ bp: - Massage, shorten and clear the arg buffer.
- Clarifications of the tsx= possible options - Josh.
- Expand on TSX_CTRL availability - Pawan. ]
[bwh: Backported to 4.4:
- Drop __ro_after_init attribute
- Adjust filenames, context]
--- Documentation/kernel-parameters.txt | 26 +++++++ arch/x86/kernel/cpu/Makefile | 2 arch/x86/kernel/cpu/common.c | 2 arch/x86/kernel/cpu/cpu.h | 16 ++++ arch/x86/kernel/cpu/intel.c | 5 + arch/x86/kernel/cpu/tsx.c | 125 ++++++++++++++++++++++++++++++++++++ 6 files changed, 175 insertions(+), 1 deletion(-) create mode 100644 arch/x86/kernel/cpu/tsx.c
Documentation/kernel-parameters.txt +26 -0
@@ -4052,6 +4052,32 @@ bytes respectively. Such letter suffixes platforms where RDTSC is slow and this accounting can add overhead. + tsx= [X86] Control Transactional Synchronization + Extensions (TSX) feature in Intel processors that + support TSX control. + + This parameter controls the TSX feature. The options are: + + on - Enable TSX on the system. Although there are + mitigations for all known security vulnerabilities, + TSX has been known to be an accelerator for + several previous speculation-related CVEs, and + so there may be unknown security risks associated + with leaving it enabled. + + off - Disable TSX on the system. (Note that this + option takes effect only on newer CPUs which are + not vulnerable to MDS, i.e., have + MSR_IA32_ARCH_CAPABILITIES.MDS_NO=1 and which get + the new IA32_TSX_CTRL MSR through a microcode + update. This new MSR allows for the reliable + deactivation of the TSX functionality.) + + Not specifying this option is equivalent to tsx=off. + + See Documentation/hw-vuln/tsx_async_abort.rst + for more details. + turbografx.map[2|3]= [HW,JOY] TurboGraFX parallel port interface Format:
arch/x86/kernel/cpu/Makefile +1 -1
@@ -21,7 +21,7 @@ obj-y += bugs.o obj-$(CONFIG_PROC_FS) += proc.o obj-$(CONFIG_X86_FEATURE_NAMES) += capflags.o powerflags.o -obj-$(CONFIG_CPU_SUP_INTEL) += intel.o +obj-$(CONFIG_CPU_SUP_INTEL) += intel.o tsx.o obj-$(CONFIG_CPU_SUP_AMD) += amd.o obj-$(CONFIG_CPU_SUP_CYRIX_32) += cyrix.o obj-$(CONFIG_CPU_SUP_CENTAUR) += centaur.o
arch/x86/kernel/cpu/common.c +2 -0
@@ -1294,6 +1294,8 @@ void __init identify_boot_cpu(void)enable_sep_cpu ();#endif cpu_detect_tlb (&boot_cpu_data); + +tsx_init (); }void identify_secondary_cpu (struct cpuinfo_x86 *c)
arch/x86/kernel/cpu/cpu.h +16 -0
@@ -44,6 +44,22 @@ struct _tlb_table {extern const struct cpu_dev *const __x86_cpu_dev_start[], *const __x86_cpu_dev_end[]; +#ifdef CONFIG_CPU_SUP_INTEL +enum tsx_ctrl_states { +TSX_CTRL_ENABLE , +TSX_CTRL_DISABLE , +TSX_CTRL_NOT_SUPPORTED , +}; + +extern enum tsx_ctrl_states tsx_ctrl_state; + +extern void __init tsx_init (void ); +extern void tsx_enable (void ); +extern void tsx_disable (void ); +#else +static inline void tsx_init (void ) { } +#endif /* CONFIG_CPU_SUP_INTEL */ +extern void get_cpu_cap (struct cpuinfo_x86 *c);extern void cpu_detect_cache_sizes (struct cpuinfo_x86 *c);
arch/x86/kernel/cpu/intel.c +5 -0
@@ -582,6 +582,11 @@ static void init_intel(struct cpuinfo_x8detect_vmx_virtcap (c);init_intel_energy_perf (c); + +if (tsx_ctrl_state ==TSX_CTRL_ENABLE ) +tsx_enable (); +if (tsx_ctrl_state ==TSX_CTRL_DISABLE ) +tsx_disable (); }#ifdef CONFIG_X86_32
arch/x86/kernel/cpu/tsx.c new file +125 -0
125 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 13/20 x86/speculation/taa: Add mitigation for TSX Async Abort
In reply to Greg Kroah-HartmanFrom: Pawan Gupta <[email protected]>
commit 1b42f017415b46c317e71d41c34ec088417a1883 upstream.
TSX Async Abort (TAA) is a side channel vulnerability to the internal buffers in some Intel processors similar to Microachitectural Data Sampling (MDS). In this case, certain loads may speculatively pass invalid data to dependent operations when an asynchronous abort condition is pending in a TSX transaction.
This includes loads with no fault or assist condition. Such loads may speculatively expose stale data from the uarch data structures as in MDS. Scope of exposure is within the same-thread and cross-thread. This issue affects all current processors that support TSX, but do not have ARCH_CAP_TAA_NO (bit 8) set in MSR_IA32_ARCH_CAPABILITIES.
On CPUs which have their IA32_ARCH_CAPABILITIES MSR bit MDS_NO=0, CPUID.MD_CLEAR=1 and the MDS mitigation is clearing the CPU buffers using VERW or L1D_FLUSH, there is no additional mitigation needed for TAA. On affected CPUs with MDS_NO=1 this issue can be mitigated by disabling the Transactional Synchronization Extensions (TSX) feature.
A new MSR IA32_TSX_CTRL in future and current processors after a microcode update can be used to control the TSX feature. There are two bits in that MSR:
* TSX_CTRL_RTM_DISABLE disables the TSX sub-feature Restricted Transactional Memory (RTM).
* TSX_CTRL_CPUID_CLEAR clears the RTM enumeration in CPUID. The other TSX sub-feature, Hardware Lock Elision (HLE), is unconditionally disabled with updated microcode but still enumerated as present by CPUID(EAX=7).EBX{bit4}.
The second mitigation approach is similar to MDS which is clearing the affected CPU buffers on return to user space and when entering a guest. Relevant microcode update is required for the mitigation to work. More details on this approach can be found here:
https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html
The TSX feature can be controlled by the "tsx" command line parameter. If it is force-enabled then "Clear CPU buffers" (MDS mitigation) is deployed. The effective mitigation state can be read from sysfs.
[ bp:
- massage + comments cleanup
- s/TAA_MITIGATION_TSX_DISABLE/TAA_MITIGATION_TSX_DISABLED/g - Josh.
- remove partial TAA mitigation in update_mds_branch_idle() - Josh.
- s/tsx_async_abort_cmdline/tsx_async_abort_parse_cmdline/g
]
[bwh: Backported to 4.4:
- Add #include "cpu.h" in bugs.c
- Drop __ro_after_init attribute
- Drop "nosmt" support
- Adjust context, indentation]
--- arch/x86/include/asm/cpufeatures.h | 1 arch/x86/include/asm/msr-index.h | 4 + arch/x86/include/asm/nospec-branch.h | 4 - arch/x86/include/asm/processor.h | 7 ++ arch/x86/kernel/cpu/bugs.c | 103 +++++++++++++++++++++++++++++++++++ arch/x86/kernel/cpu/common.c | 15 +++++ 6 files changed, 132 insertions(+), 2 deletions(-)
arch/x86/include/asm/cpufeatures.h +1 -0
@@ -340,5 +340,6 @@#define X86_BUG_MDS X86_BUG(19)/* CPU is affected by Microarchitectural data sampling */ #define X86_BUG_MSBDS_ONLY X86_BUG(20)/* CPU is only affected by the MSDBS variant of BUG_MDS */ #define X86_BUG_SWAPGS X86_BUG(21)/* CPU is affected by speculation through SWAPGS */ +#define X86_BUG_TAA X86_BUG(22)/* CPU is affected by TSX Async Abort(TAA) */ #endif /* _ASM_X86_CPUFEATURES_H */
arch/x86/include/asm/msr-index.h +4 -0
@@ -72,6 +72,10 @@* Sampling (MDS) vulnerabilities. */ #define ARCH_CAP_TSX_CTRL_MSR BIT(7)/* MSR for TSX control is available. */ +#define ARCH_CAP_TAA_NO BIT(8)/* +* Not susceptible to +* TSX Async Abort (TAA) vulnerabilities. +*/ #define MSR_IA32_BBL_CR_CTL 0x00000119#define MSR_IA32_BBL_CR_CTL3 0x0000011e
arch/x86/include/asm/nospec-branch.h +2 -2
@@ -268,7 +268,7 @@ DECLARE_STATIC_KEY_FALSE(mds_idle_clear)#include <asm/segment.h> /** -* mds_clear_cpu_buffers - Mitigation for MDS vulnerability +* mds_clear_cpu_buffers - Mitigation for MDS and TAA vulnerability * * This uses the otherwise unused and obsolete VERW instruction in * combination with microcode which triggers a CPU buffer flush when the
@@ -291,7 +291,7 @@ static inline void mds_clear_cpu_buffers }/** -* mds_user_clear_cpu_buffers - Mitigation for MDS vulnerability +* mds_user_clear_cpu_buffers - Mitigation for MDS and TAA vulnerability * * Clear CPU buffers if the corresponding static key is enabled */
arch/x86/include/asm/processor.h +7 -0
@@ -852,4 +852,11 @@ enum mds_mitigations { MDS_MITIGATION_VMWERV, }; +enum taa_mitigations { +TAA_MITIGATION_OFF , +TAA_MITIGATION_UCODE_NEEDED , +TAA_MITIGATION_VERW , +TAA_MITIGATION_TSX_DISABLED , +}; +#endif /* _ASM_X86_PROCESSOR_H */
arch/x86/kernel/cpu/bugs.c +103 -0
138 lines not on this page · raw message
arch/x86/kernel/cpu/common.c +15 -0
@@ -954,6 +954,21 @@ static void __init cpu_set_bug_bits(struif (!cpu_matches (NO_SWAPGS ))setup_force_cpu_bug (X86_BUG_SWAPGS ); +/* +* When the CPU is not mitigated for TAA (TAA_NO=0) set TAA bug when: +* - TSX is supported or +* - TSX_CTRL is present +* +* TSX_CTRL check is needed for cases when TSX could be disabled before +* the kernel boot e.g. kexec. +* TSX_CTRL check alone is not sufficient for cases when the microcode +* update is not present or running as guest that don't get TSX_CTRL. +*/ +if (!(ia32_cap &ARCH_CAP_TAA_NO ) && + (cpu_has (c,X86_FEATURE_RTM ) || + (ia32_cap &ARCH_CAP_TSX_CTRL_MSR ))) +setup_force_cpu_bug (X86_BUG_TAA ); +if (cpu_matches (NO_MELTDOWN ))return ;
Greg Kroah-Hartman
maintainerPATCH 14/20 x86/speculation/taa: Add sysfs reporting for TSX Async Abort
In reply to Greg Kroah-HartmanFrom: Pawan Gupta <[email protected]>
commit 6608b45ac5ecb56f9e171252229c39580cc85f0f upstream.
Add the sysfs reporting file for TSX Async Abort. It exposes the vulnerability and the mitigation state similar to the existing files for the other hardware vulnerabilities.
Sysfs file path is:/sys/devices/system/cpu/vulnerabilities/tsx_async_abort
--- arch/x86/kernel/cpu/bugs.c | 23 +++++++++++++++++++++++ drivers/base/cpu.c | 9 +++++++++ include/linux/cpu.h | 3 +++ 3 files changed, 35 insertions(+)
arch/x86/kernel/cpu/bugs.c +23 -0
@@ -1300,6 +1300,21 @@ static ssize_t mds_show_state(char *buf) sched_smt_active() ? "vulnerable" : "disabled"); } +static ssize_t tsx_async_abort_show_state (char *buf) +{ +if ((taa_mitigation ==TAA_MITIGATION_TSX_DISABLED ) || + (taa_mitigation ==TAA_MITIGATION_OFF )) +return sprintf (buf,"%s\n" , taa_strings[taa_mitigation]); + +if (boot_cpu_has (X86_FEATURE_HYPERVISOR )) { +return sprintf (buf,"%s; SMT Host state unknown\n" , + taa_strings[taa_mitigation]); + } + +return sprintf (buf,"%s; SMT %s\n" , taa_strings[taa_mitigation], +sched_smt_active () ?"vulnerable" :"disabled" ); +} +static char *stibp_state (void ) {if (spectre_v2_enabled ==SPECTRE_V2_IBRS_ENHANCED )
@@ -1365,6 +1380,9 @@ static ssize_t cpu_show_common(struct decase X86_BUG_MDS :return mds_show_state (buf); +case X86_BUG_TAA : +return tsx_async_abort_show_state (buf); +default :break ; }
@@ -1401,4 +1419,9 @@ ssize_t cpu_show_mds(struct device *dev, {return cpu_show_common (dev, attr, buf,X86_BUG_MDS ); } + +ssize_t cpu_show_tsx_async_abort (struct device *dev,struct device_attribute *attr,char *buf) +{ +return cpu_show_common (dev, attr, buf,X86_BUG_TAA ); +}#endif
drivers/base/cpu.c +9 -0
@@ -536,12 +536,20 @@ ssize_t __weak cpu_show_mds(struct devicreturn sprintf (buf,"Not affected\n" ); } +ssize_t __weak cpu_show_tsx_async_abort (struct device *dev, +struct device_attribute *attr, +char *buf) +{ +return sprintf (buf,"Not affected\n" ); +} + static DEVICE_ATTR(meltdown, 0444, cpu_show_meltdown, NULL); static DEVICE_ATTR(spectre_v1, 0444, cpu_show_spectre_v1, NULL); static DEVICE_ATTR(spectre_v2, 0444, cpu_show_spectre_v2, NULL); static DEVICE_ATTR(spec_store_bypass, 0444, cpu_show_spec_store_bypass, NULL); static DEVICE_ATTR(l1tf, 0444, cpu_show_l1tf, NULL); static DEVICE_ATTR(mds, 0444, cpu_show_mds, NULL); +static DEVICE_ATTR(tsx_async_abort, 0444, cpu_show_tsx_async_abort, NULL);static struct attribute *cpu_root_vulnerabilities_attrs[] = { &dev_attr_meltdown.attr,
@@ -550,6 +558,7 @@ static struct attribute *cpu_root_vulner &dev_attr_spec_store_bypass.attr, &dev_attr_l1tf.attr, &dev_attr_mds.attr, + &dev_attr_tsx_async_abort.attr, NULL };
include/linux/cpu.h +3 -0
@@ -52,6 +52,9 @@ extern ssize_t cpu_show_l1tf(struct devi struct device_attribute *attr, char *buf);extern ssize_t cpu_show_mds (struct device *dev,struct device_attribute *attr,char *buf); +extern ssize_t cpu_show_tsx_async_abort (struct device *dev, +struct device_attribute *attr, +char *buf); extern __printf(4, 5) struct device *cpu_device_create(struct device *parent, void *drvdata,
Greg Kroah-Hartman
maintainerPATCH 15/20 kvm/x86: Export MDS_NO=0 to guests when TSX is enabled
In reply to Greg Kroah-HartmanFrom: Pawan Gupta <[email protected]>
commit e1d38b63acd843cfdd4222bf19a26700fd5c699e upstream.
Export the IA32_ARCH_CAPABILITIES MSR bit MDS_NO=0 to guests on TSX Async Abort(TAA) affected hosts that have TSX enabled and updated microcode. This is required so that the guests don't complain,
"Vulnerable: Clear CPU buffers attempted, no microcode"
when the host has the updated microcode to clear CPU buffers.
Microcode update also adds support for MSR_IA32_TSX_CTRL which is enumerated by the ARCH_CAP_TSX_CTRL bit in IA32_ARCH_CAPABILITIES MSR. Guests can't do this check themselves when the ARCH_CAP_TSX_CTRL bit is not exported to the guests.
In this case export MDS_NO=0 to the guests. When guests have CPUID.MD_CLEAR=1, they deploy MDS mitigation which also mitigates TAA.
--- arch/x86/kvm/x86.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
arch/x86/kvm/x86.c +19 -0
@@ -1008,6 +1008,25 @@ u64 kvm_get_arch_capabilities(void)if (!boot_cpu_has_bug (X86_BUG_MDS )) data |=ARCH_CAP_MDS_NO ; +/* +* On TAA affected systems, export MDS_NO=0 when: +* - TSX is enabled on the host, i.e. X86_FEATURE_RTM=1. +* - Updated microcode is present. This is detected by +* the presence of ARCH_CAP_TSX_CTRL_MSR and ensures +* that VERW clears CPU buffers. +* +* When MDS_NO=0 is exported, guests deploy clear CPU buffer +* mitigation and don't complain: +* +* "Vulnerable: Clear CPU buffers attempted, no microcode" +* +* If TSX is disabled on the system, guests are also mitigated against +* TAA and clear CPU buffer mitigation is not required for guests. +*/ +if (boot_cpu_has_bug (X86_BUG_TAA ) &&boot_cpu_has (X86_FEATURE_RTM ) && + (data &ARCH_CAP_TSX_CTRL_MSR )) + data &= ~ARCH_CAP_MDS_NO ; +return data; }
Greg Kroah-Hartman
maintainerPATCH 16/20 x86/tsx: Add "auto" option to the tsx= cmdline parameter
In reply to Greg Kroah-HartmanFrom: Pawan Gupta <[email protected]>
commit 7531a3596e3272d1f6841e0d601a614555dc6b65 upstream.
Platforms which are not affected by X86_BUG_TAA may want the TSX feature enabled. Add "auto" option to the TSX cmdline parameter. When tsx=auto disable TSX when X86_BUG_TAA is present, otherwise enable TSX.
More details on X86_BUG_TAA can be found here:
https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/tsx_async_abort.html
[ bp: Extend the arg buffer to accommodate "auto\0". ]
--- Documentation/kernel-parameters.txt | 3 +++ arch/x86/kernel/cpu/tsx.c | 7 ++++++- 2 files changed, 9 insertions(+), 1 deletion(-)
Documentation/kernel-parameters.txt +3 -0
@@ -4073,6 +4073,9 @@ bytes respectively. Such letter suffixes update. This new MSR allows for the reliable deactivation of the TSX functionality.) + auto - Disable TSX if X86_BUG_TAA is present, + otherwise enable TSX on the system. + Not specifying this option is equivalent to tsx=off. See Documentation/hw-vuln/tsx_async_abort.rst
arch/x86/kernel/cpu/tsx.c +6 -1
@@ -75,7 +75,7 @@ static bool __init tsx_ctrl_is_supportedvoid __init tsx_init (void ) { -char arg[4 ] = {}; +char arg[5 ] = {};int ret;if (!tsx_ctrl_is_supported ())
@@ -87,6 +87,11 @@ void __init tsx_init(void) tsx_ctrl_state =TSX_CTRL_ENABLE ; }else if (!strcmp (arg,"off" )) { tsx_ctrl_state =TSX_CTRL_DISABLE ; + }else if (!strcmp (arg,"auto" )) { +if (boot_cpu_has_bug (X86_BUG_TAA )) + tsx_ctrl_state =TSX_CTRL_DISABLE ; +else + tsx_ctrl_state =TSX_CTRL_ENABLE ; }else { tsx_ctrl_state =TSX_CTRL_DISABLE ;pr_err ("tsx: invalid option, defaulting to off\n" );
Greg Kroah-Hartman
maintainerPATCH 17/20 x86/speculation/taa: Add documentation for TSX Async Abort
In reply to Greg Kroah-HartmanFrom: Pawan Gupta <[email protected]>
commit a7a248c593e4fd7a67c50b5f5318fe42a0db335e upstream.
Add the documenation for TSX Async Abort. Include the description of the issue, how to check the mitigation state, control the mitigation, guidance for system administrators.
[ bp: Add proper SPDX tags, touch ups by Josh and me. ]
[bwh: Backported to 4.4:
- Drop changes to ReST index files
- Drop "nosmt" documentation
- Adjust filenames, context]
--- Documentation/ABI/testing/sysfs-devices-system-cpu | 1 Documentation/hw-vuln/tsx_async_abort.rst | 268 +++++++++++++++++++++ Documentation/kernel-parameters.txt | 33 ++ Documentation/x86/tsx_async_abort.rst | 117 +++++++++ 4 files changed, 419 insertions(+) create mode 100644 Documentation/hw-vuln/tsx_async_abort.rst create mode 100644 Documentation/x86/tsx_async_abort.rst
Documentation/ABI/testing/sysfs-devices-system-cpu +1 -0
@@ -279,6 +279,7 @@ What: /sys/devices/system/cpu/vulnerabi /sys/devices/system/cpu/vulnerabilities/spec_store_bypass /sys/devices/system/cpu/vulnerabilities/l1tf /sys/devices/system/cpu/vulnerabilities/mds + /sys/devices/system/cpu/vulnerabilities/tsx_async_abort Date: January 2018 Contact: Linux kernel mailing list <[email protected]> Description: Information about CPU vulnerabilities
Documentation/hw-vuln/tsx_async_abort.rst new file +268 -0
268 lines not on this page · raw message
Documentation/kernel-parameters.txt +33 -0
@@ -2189,6 +2189,7 @@ bytes respectively. Such letter suffixes spectre_v2_user=off [X86] spec_store_bypass_disable=off [X86] mds=off [X86] + tsx_async_abort=off [X86] auto (default) Mitigate all CPU vulnerabilities, but leave SMT
@@ -4081,6 +4082,38 @@ bytes respectively. Such letter suffixes See Documentation/hw-vuln/tsx_async_abort.rst for more details. + tsx_async_abort= [X86,INTEL] Control mitigation for the TSX Async + Abort (TAA) vulnerability. + + Similar to Micro-architectural Data Sampling (MDS) + certain CPUs that support Transactional + Synchronization Extensions (TSX) are vulnerable to an + exploit against CPU internal buffers which can forward + information to a disclosure gadget under certain + conditions. + + In vulnerable processors, the speculatively forwarded + data can be used in a cache side channel attack, to + access data to which the attacker does not have direct + access. + + This parameter controls the TAA mitigation. The + options are: + + full - Enable TAA mitigation on vulnerable CPUs + if TSX is enabled. + + off - Unconditionally disable TAA mitigation + + Not specifying this option is equivalent to + tsx_async_abort=full. On CPUs which are MDS affected + and deploy MDS mitigation, TAA mitigation is not + required and doesn't provide any additional + mitigation. + + For details see: + Documentation/hw-vuln/tsx_async_abort.rst + turbografx.map[2|3]= [HW,JOY] TurboGraFX parallel port interface Format:
Documentation/x86/tsx_async_abort.rst new file +117 -0
117 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 18/20 x86/tsx: Add config options to set tsx=on|off|auto
In reply to Greg Kroah-HartmanFrom: Michal Hocko <[email protected]>
commit db616173d787395787ecc93eef075fa975227b10 upstream.
There is a general consensus that TSX usage is not largely spread while the history shows there is a non trivial space for side channel attacks possible. Therefore the tsx is disabled by default even on platforms that might have a safe implementation of TSX according to the current knowledge. This is a fair trade off to make.
There are, however, workloads that really do benefit from using TSX and updating to a newer kernel with TSX disabled might introduce a noticeable regressions. This would be especially a problem for Linux distributions which will provide TAA mitigations.
Introduce config options X86_INTEL_TSX_MODE_OFF, X86_INTEL_TSX_MODE_ON and X86_INTEL_TSX_MODE_AUTO to control the TSX feature. The config setting can be overridden by the tsx cmdline options.
[ bp: Text cleanups from Josh. ]
--- arch/x86/Kconfig | 45 +++++++++++++++++++++++++++++++++++++++++++++ arch/x86/kernel/cpu/tsx.c | 22 ++++++++++++++++------ 2 files changed, 61 insertions(+), 6 deletions(-)
arch/x86/Kconfig +45 -0
@@ -1695,6 +1695,51 @@ config X86_INTEL_MPX If unsure, say N. +choice + prompt "TSX enable mode" + depends on CPU_SUP_INTEL + default X86_INTEL_TSX_MODE_OFF + help + Intel's TSX (Transactional Synchronization Extensions) feature + allows to optimize locking protocols through lock elision which + can lead to a noticeable performance boost. + + On the other hand it has been shown that TSX can be exploited + to form side channel attacks (e.g. TAA) and chances are there + will be more of those attacks discovered in the future. + + Therefore TSX is not enabled by default (aka tsx=off). An admin + might override this decision by tsx=on the command line parameter. + Even with TSX enabled, the kernel will attempt to enable the best + possible TAA mitigation setting depending on the microcode available + for the particular machine. + + This option allows to set the default tsx mode between tsx=on, =off + and =auto. See Documentation/kernel-parameters.txt for more + details. + + Say off if not sure, auto if TSX is in use but it should be used on safe + platforms or on if TSX is in use and the security aspect of tsx is not + relevant. + +config X86_INTEL_TSX_MODE_OFF + bool "off" + help + TSX is disabled if possible - equals to tsx=off command line parameter. + +config X86_INTEL_TSX_MODE_ON + bool "on" + help + TSX is always enabled on TSX capable HW - equals the tsx=on command + line parameter. + +config X86_INTEL_TSX_MODE_AUTO + bool "auto" + help + TSX is enabled on TSX capable HW that is believed to be safe against + side channel attacks- equals the tsx=auto command line parameter. +endchoice + config EFI bool "EFI runtime service support" depends on ACPI
arch/x86/kernel/cpu/tsx.c +16 -6
@@ -73,6 +73,14 @@ static bool __init tsx_ctrl_is_supportedreturn !!(ia32_cap &ARCH_CAP_TSX_CTRL_MSR ); } +static enum tsx_ctrl_states x86_get_tsx_auto_mode (void ) +{ +if (boot_cpu_has_bug (X86_BUG_TAA )) +return TSX_CTRL_DISABLE ; + +return TSX_CTRL_ENABLE ; +} +void __init tsx_init (void ) {char arg[5 ] = {};
@@ -88,17 +96,19 @@ void __init tsx_init(void) }else if (!strcmp (arg,"off" )) { tsx_ctrl_state =TSX_CTRL_DISABLE ; }else if (!strcmp (arg,"auto" )) { -if (boot_cpu_has_bug (X86_BUG_TAA )) - tsx_ctrl_state =TSX_CTRL_DISABLE ; -else - tsx_ctrl_state =TSX_CTRL_ENABLE ; + tsx_ctrl_state =x86_get_tsx_auto_mode (); }else { tsx_ctrl_state =TSX_CTRL_DISABLE ;pr_err ("tsx: invalid option, defaulting to off\n" ); } }else { -/* tsx= not provided, defaulting to off */ - tsx_ctrl_state =TSX_CTRL_DISABLE ; +/* tsx= not provided */ +if (IS_ENABLED (CONFIG_X86_INTEL_TSX_MODE_AUTO )) + tsx_ctrl_state =x86_get_tsx_auto_mode (); +else if (IS_ENABLED (CONFIG_X86_INTEL_TSX_MODE_OFF )) + tsx_ctrl_state =TSX_CTRL_DISABLE ; +else + tsx_ctrl_state =TSX_CTRL_ENABLE ; }if (tsx_ctrl_state ==TSX_CTRL_DISABLE ) {
Greg Kroah-Hartman
maintainerPATCH 19/20 x86/speculation/taa: Fix printing of TAA_MSG_SMT on IBRS_ALL CPUs
In reply to Greg Kroah-HartmanFrom: Josh Poimboeuf <[email protected]>
commit 012206a822a8b6ac09125bfaa210a95b9eb8f1c1 upstream.
For new IBRS_ALL CPUs, the Enhanced IBRS check at the beginning of cpu_bugs_smt_update() causes the function to return early, unintentionally skipping the MDS and TAA logic.
This is not a problem for MDS, because there appears to be no overlap between IBRS_ALL and MDS-affected CPUs. So the MDS mitigation would be disabled and nothing would need to be done in this function anyway.
But for TAA, the TAA_MSG_SMT string will never get printed on Cascade Lake and newer.
The check is superfluous anyway: when 'spectre_v2_enabled' is SPECTRE_V2_IBRS_ENHANCED, 'spectre_v2_user' is always SPECTRE_V2_USER_NONE, and so the 'spectre_v2_user' switch statement handles it appropriately by doing nothing. So just remove the check.
--- arch/x86/kernel/cpu/bugs.c | 4 ---- 1 file changed, 4 deletions(-)
arch/x86/kernel/cpu/bugs.c +0 -4
@@ -853,10 +853,6 @@ static void update_mds_branch_idle(void)void arch_smt_update (void ) { -/* Enhanced IBRS implies STIBP. No update required. */ -if (spectre_v2_enabled ==SPECTRE_V2_IBRS_ENHANCED ) -return ; -mutex_lock (&spec_ctrl_mutex);switch (spectre_v2_user) {
Greg Kroah-Hartman
maintainerPATCH 20/20 x86/bugs: Add ITLB_MULTIHIT bug infrastructure
In reply to Greg Kroah-HartmanFrom: Vineela Tummalapalli <[email protected]>
commit db4d30fbb71b47e4ecb11c4efa5d8aad4b03dfae upstream.
Some processors may incur a machine check error possibly resulting in an unrecoverable CPU lockup when an instruction fetch encounters a TLB multi-hit in the instruction TLB. This can occur when the page size is changed along with either the physical address or cache type. The relevant erratum can be found here:
https://bugzilla.kernel.org/show_bug.cgi?id=205195
There are other processors affected for which the erratum does not fully disclose the impact.
This issue affects both bare-metal x86 page tables and EPT.
It can be mitigated by either eliminating the use of large pages or by using careful TLB invalidations when changing the page size in the page tables.
Just like Spectre, Meltdown, L1TF and MDS, a new bit has been allocated in MSR_IA32_ARCH_CAPABILITIES (PSCHANGE_MC_NO) and will be set on CPUs which are mitigated against this issue.
[bwh: Backported to 4.4:
- No support for X86_VENDOR_HYGON, ATOM_AIRMONT_NP
- Adjust context, indentation]
--- Documentation/ABI/testing/sysfs-devices-system-cpu | 1 arch/x86/include/asm/cpufeatures.h | 1 arch/x86/include/asm/msr-index.h | 7 ++ arch/x86/kernel/cpu/bugs.c | 13 ++++ arch/x86/kernel/cpu/common.c | 61 +++++++++++---------- drivers/base/cpu.c | 8 ++ include/linux/cpu.h | 2 7 files changed, 65 insertions(+), 28 deletions(-)
Documentation/ABI/testing/sysfs-devices-system-cpu +1 -0
@@ -280,6 +280,7 @@ What: /sys/devices/system/cpu/vulnerabi /sys/devices/system/cpu/vulnerabilities/l1tf /sys/devices/system/cpu/vulnerabilities/mds /sys/devices/system/cpu/vulnerabilities/tsx_async_abort + /sys/devices/system/cpu/vulnerabilities/itlb_multihit Date: January 2018 Contact: Linux kernel mailing list <[email protected]> Description: Information about CPU vulnerabilities
arch/x86/include/asm/cpufeatures.h +1 -0
@@ -341,5 +341,6 @@#define X86_BUG_MSBDS_ONLY X86_BUG(20)/* CPU is only affected by the MSDBS variant of BUG_MDS */ #define X86_BUG_SWAPGS X86_BUG(21)/* CPU is affected by speculation through SWAPGS */ #define X86_BUG_TAA X86_BUG(22)/* CPU is affected by TSX Async Abort(TAA) */ +#define X86_BUG_ITLB_MULTIHIT X86_BUG(23)/* CPU may incur MCE during certain page attribute changes */ #endif /* _ASM_X86_CPUFEATURES_H */
arch/x86/include/asm/msr-index.h +7 -0
@@ -71,6 +71,13 @@* Microarchitectural Data * Sampling (MDS) vulnerabilities. */ +#define ARCH_CAP_PSCHANGE_MC_NO BIT(6)/* +* The processor is not susceptible to a +* machine check error due to modifying the +* code page size along with either the +* physical address or cache type +* without TLB invalidation. +*/ #define ARCH_CAP_TSX_CTRL_MSR BIT(7)/* MSR for TSX control is available. */ #define ARCH_CAP_TAA_NO BIT(8)/* * Not susceptible to
arch/x86/kernel/cpu/bugs.c +13 -0
@@ -1277,6 +1277,11 @@ static void __init l1tf_select_mitigatio#ifdef CONFIG_SYSFS +static ssize_t itlb_multihit_show_state (char *buf) +{ +return sprintf (buf,"Processor vulnerable\n" ); +} +static ssize_t mds_show_state (char *buf) {#ifdef CONFIG_HYPERVISOR_GUEST
@@ -1379,6 +1384,9 @@ static ssize_t cpu_show_common(struct decase X86_BUG_TAA :return tsx_async_abort_show_state (buf); +case X86_BUG_ITLB_MULTIHIT : +return itlb_multihit_show_state (buf); +default :break ; }
@@ -1420,4 +1428,9 @@ ssize_t cpu_show_tsx_async_abort(struct {return cpu_show_common (dev, attr, buf,X86_BUG_TAA ); } + +ssize_t cpu_show_itlb_multihit (struct device *dev,struct device_attribute *attr,char *buf) +{ +return cpu_show_common (dev, attr, buf,X86_BUG_ITLB_MULTIHIT ); +}#endif
arch/x86/kernel/cpu/common.c +33 -28
91 lines not on this page · raw message
drivers/base/cpu.c +8 -0
@@ -543,6 +543,12 @@ ssize_t __weak cpu_show_tsx_async_abort(return sprintf (buf,"Not affected\n" ); } +ssize_t __weak cpu_show_itlb_multihit (struct device *dev, +struct device_attribute *attr,char *buf) +{ +return sprintf (buf,"Not affected\n" ); +} + static DEVICE_ATTR(meltdown, 0444, cpu_show_meltdown, NULL); static DEVICE_ATTR(spectre_v1, 0444, cpu_show_spectre_v1, NULL); static DEVICE_ATTR(spectre_v2, 0444, cpu_show_spectre_v2, NULL);
@@ -550,6 +556,7 @@ static DEVICE_ATTR(spec_store_bypass, 04 static DEVICE_ATTR(l1tf, 0444, cpu_show_l1tf, NULL); static DEVICE_ATTR(mds, 0444, cpu_show_mds, NULL); static DEVICE_ATTR(tsx_async_abort, 0444, cpu_show_tsx_async_abort, NULL); +static DEVICE_ATTR(itlb_multihit, 0444, cpu_show_itlb_multihit, NULL);static struct attribute *cpu_root_vulnerabilities_attrs[] = { &dev_attr_meltdown.attr,
@@ -559,6 +566,7 @@ static struct attribute *cpu_root_vulner &dev_attr_l1tf.attr, &dev_attr_mds.attr, &dev_attr_tsx_async_abort.attr, + &dev_attr_itlb_multihit.attr, NULL };
include/linux/cpu.h +2 -0
@@ -55,6 +55,8 @@ extern ssize_t cpu_show_mds(struct devicextern ssize_t cpu_show_tsx_async_abort (struct device *dev,struct device_attribute *attr,char *buf); +extern ssize_t cpu_show_itlb_multihit (struct device *dev, +struct device_attribute *attr,char *buf); extern __printf(4, 5) struct device *cpu_device_create(struct device *parent, void *drvdata,
stable-rc/linux-4.4.y boot: 80 boots: 1 failed, 75 passed with 3 offline, 1 conflict (v4.4.201-21-gb0074e36d782)
stable-rc/linux-4.4.y boot: 80 boots: 1 failed, 75 passed with 3 offline, 1 conflict (v4.4.201-21-gb0074e36d782)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.201-21-gb0074e36d782/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.201-21-gb0074e36d782/
Tree: stable-rc
Branch: linux-4.4.y
Git Describe: v4.4.201-21-gb0074e36d782
Git Commit: b0074e36d782e84e6a2e08910103642762949d2b
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 41 unique boards, 17 SoC families, 13 builds out of 190
Boot Regressions Detected:
arm:
exynos_defconfig:
gcc-8:
exynos5422-odroidxu3:
lab-collabora: new failure (last pass: v4.4.201)Boot Failure Detected:
arm:
exynos_defconfig:
gcc-8:
exynos5422-odroidxu3: 1 failed lab
Offline Platforms:
arm:
sunxi_defconfig:
gcc-8
sun7i-a20-bananapi: 1 offline lab
multi_v7_defconfig:
gcc-8
bcm4708-smartrg-sr400ac: 1 offline lab
sun7i-a20-bananapi: 1 offline labConflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.)
i386:
i386_defconfig:
qemu_i386:
lab-baylibre: FAIL (gcc-8)
lab-collabora: PASS (gcc-8)
---
For more info write to <[email protected]>
Jon Hunter
maintainerQuoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.202 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 17 Nov 2019 06:18:31 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.202-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.4.y
and the diffstat can be found below.thanks,
greg k-h
All tests are passing for Tegra ...
Test results for stable-v4.4:
6 builds: 6 pass, 0 fail
12 boots: 12 pass, 0 fail
19 tests: 19 pass, 0 failLinux version: 4.4.202-rc1-gb0074e36d782
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra30-cardhu-a04
Cheers
Jon
Signature · 1 line
nvpublic
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.202 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 17 Nov 2019 06:18:31 +0000. Anything received after that time might be too late.
Build results:
total: 170 pass: 170 fail: 0 Qemu test results: total: 324 pass: 324 fail: 0
Guenter
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.202 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 17 Nov 2019 06:18:31 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.202-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.4.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Summary
------------------------------------------------------------------------
kernel: 4.4.202-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: b0074e36d782e84e6a2e08910103642762949d2b
git describe: v4.4.201-21-gb0074e36d782
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.201-21-gb0074e36d782
No regressions (compared to build v4.4.201)
No fixes (compared to build v4.4.201)
Ran 18051 total tests in the following environments and test suites.
Environments
--------------
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
Test Suites
-----------
* build
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* network-basic-tests
* perf
* prep-tmp-disk
* spectre-meltdown-checker-test
* kselftest
* kvm-unit-tests
* v4l2-compliance
* install-android-platform-tools-r2600
* kselftest-vsyscall-mode-native
* ssuite
Summary
------------------------------------------------------------------------
kernel: 4.4.202-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git branch: 4.4.202-rc1-hikey-20191115-607
git commit: 493901fc04b1127d80037f3fb43e916a4eec9f10
git describe: 4.4.202-rc1-hikey-20191115-607
Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.202-rc1-hikey-20191115-607
No regressions (compared to build 4.4.201-rc2-hikey-20191112-605)
No fixes (compared to build 4.4.201-rc2-hikey-20191112-605)
Ran 1538 total tests in the following environments and test suites.
Environments
--------------
- hi6220-hikey - arm64
Test Suites
-----------
* build
* install-android-platform-tools-r2600
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
Signature · 2 lines
Linaro LKFT https://lkft.linaro.org