This is the start of the stable review cycle for the 5.10.105 release.
There are 58 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 Sat, 12 Mar 2022 14:07:58 +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/v5.x/stable-review/patch-5.10.105-rc2.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 5.10.105-rc2
Greg Kroah-Hartman <[email protected]>
Revert "ACPI: PM: s2idle: Cancel wakeup before dispatching EC GPE"
Juergen Gross <[email protected]>
xen/netfront: react properly to failing gnttab_end_foreign_access_ref()
Juergen Gross <[email protected]>
xen/gnttab: fix gnttab_end_foreign_access() without page specified
Juergen Gross <[email protected]>
xen/pvcalls: use alloc/free_pages_exact()
Juergen Gross <[email protected]>
xen/9p: use alloc/free_pages_exact()
Juergen Gross <[email protected]>
xen: remove gnttab_query_foreign_access()
Juergen Gross <[email protected]>
xen/gntalloc: don't use gnttab_query_foreign_access()
Juergen Gross <[email protected]>
xen/scsifront: don't use gnttab_query_foreign_access() for mapped status
Juergen Gross <[email protected]>
xen/netfront: don't use gnttab_query_foreign_access() for mapped status
Juergen Gross <[email protected]>
xen/blkfront: don't use gnttab_query_foreign_access() for mapped status
Juergen Gross <[email protected]>
xen/grant-table: add gnttab_try_end_foreign_access()
Juergen Gross <[email protected]>
xen/xenbus: don't let xenbus_grant_ring() remove grants in error case
Russell King (Oracle) <[email protected]>
ARM: fix build warning in proc-v7-bugs.c
Nathan Chancellor <[email protected]>
ARM: Do not use NOCROSSREFS directive with ld.lld
Russell King (Oracle) <[email protected]>
ARM: fix co-processor register typo
Emmanuel Gil Peyrot <[email protected]>
ARM: fix build error when BPF_SYSCALL is disabled
James Morse <[email protected]>
arm64: proton-pack: Include unprivileged eBPF status in Spectre v2 mitigation reporting
James Morse <[email protected]>
arm64: Use the clearbhb instruction in mitigations
James Morse <[email protected]>
KVM: arm64: Allow SMCCC_ARCH_WORKAROUND_3 to be discovered and migrated
James Morse <[email protected]>
arm64: Mitigate spectre style branch history side channels
James Morse <[email protected]>
KVM: arm64: Allow indirect vectors to be used without SPECTRE_V3A
James Morse <[email protected]>
arm64: proton-pack: Report Spectre-BHB vulnerabilities as part of Spectre-v2
James Morse <[email protected]>
arm64: Add percpu vectors for EL1
James Morse <[email protected]>
arm64: entry: Add macro for reading symbol addresses from the trampoline
James Morse <[email protected]>
arm64: entry: Add vectors that have the bhb mitigation sequences
James Morse <[email protected]>
arm64: entry: Add non-kpti __bp_harden_el1_vectors for mitigations
James Morse <[email protected]>
arm64: entry: Allow the trampoline text to occupy multiple pages
James Morse <[email protected]>
arm64: entry: Make the kpti trampoline's kpti sequence optional
James Morse <[email protected]>
arm64: entry: Move trampoline macros out of ifdef'd section
James Morse <[email protected]>
arm64: entry: Don't assume tramp_vectors is the start of the vectors
James Morse <[email protected]>
arm64: entry: Allow tramp_alias to access symbols after the 4K boundary
James Morse <[email protected]>
arm64: entry: Move the trampoline data page before the text page
James Morse <[email protected]>
arm64: entry: Free up another register on kpti's tramp_exit path
James Morse <[email protected]>
arm64: entry: Make the trampoline cleanup optional
James Morse <[email protected]>
arm64: spectre: Rename spectre_v4_patch_fw_mitigation_conduit
James Morse <[email protected]>
arm64: entry.S: Add ventry overflow sanity checks
Joey Gouly <[email protected]>
arm64: cpufeature: add HWCAP for FEAT_RPRES
Joey Gouly <[email protected]>
arm64: cpufeature: add HWCAP for FEAT_AFP
Joey Gouly <[email protected]>
arm64: add ID_AA64ISAR2_EL1 sys register
Marc Zyngier <[email protected]>
arm64: Add HWCAP for self-synchronising virtual counter
Anshuman Khandual <[email protected]>
arm64: Add Cortex-A510 CPU part definition
Anshuman Khandual <[email protected]>
arm64: Add Cortex-X2 CPU part definition
Suzuki K Poulose <[email protected]>
arm64: Add Neoverse-N2, Cortex-A710 CPU part definition
Hector Martin <[email protected]>
arm64: cputype: Add CPU implementor & types for the Apple M1 cores
Russell King (Oracle) <[email protected]>
ARM: include unprivileged BPF status in Spectre V2 reporting
Russell King (Oracle) <[email protected]>
ARM: Spectre-BHB workaround
Russell King (Oracle) <[email protected]>
ARM: use LOADADDR() to get load address of sections
Russell King (Oracle) <[email protected]>
ARM: early traps initialisation
Russell King (Oracle) <[email protected]>
ARM: report Spectre v2 status through sysfs
Josh Poimboeuf <[email protected]>
x86/speculation: Warn about eIBRS + LFENCE + Unprivileged eBPF + SMT
Josh Poimboeuf <[email protected]>
x86/speculation: Warn about Spectre v2 LFENCE mitigation
Kim Phillips <[email protected]>
x86/speculation: Update link to AMD speculation whitepaper
Kim Phillips <[email protected]>
x86/speculation: Use generic retpoline by default on AMD
Josh Poimboeuf <[email protected]>
x86/speculation: Include unprivileged eBPF status in Spectre v2 mitigation reporting
Peter Zijlstra <[email protected]>
Documentation/hw-vuln: Update spectre doc
Peter Zijlstra <[email protected]>
x86/speculation: Add eIBRS + Retpoline options
Peter Zijlstra (Intel) <[email protected]>
x86/speculation: Rename RETPOLINE_AMD to RETPOLINE_LFENCE
Peter Zijlstra <[email protected]>
x86,bugs: Unconditionally allow spectre_v2=retpoline,amd
-------------
Diffstat:
Documentation/admin-guide/hw-vuln/spectre.rst | 48 ++--
Documentation/admin-guide/kernel-parameters.txt | 8 +-
Documentation/arm64/cpu-feature-registers.rst | 29 +-
Documentation/arm64/elf_hwcaps.rst | 12 +
Makefile | 4 +-
arch/arm/include/asm/assembler.h | 10 +
arch/arm/include/asm/spectre.h | 32 +++
arch/arm/include/asm/vmlinux.lds.h | 43 ++-
arch/arm/kernel/Makefile | 2 +
arch/arm/kernel/entry-armv.S | 79 +++++-
arch/arm/kernel/entry-common.S | 24 ++
arch/arm/kernel/spectre.c | 71 +++++
arch/arm/kernel/traps.c | 65 ++++-
arch/arm/mm/Kconfig | 11 +
arch/arm/mm/proc-v7-bugs.c | 208 +++++++++++---
arch/arm64/Kconfig | 9 +
arch/arm64/include/asm/assembler.h | 33 +++
arch/arm64/include/asm/cpu.h | 1 +
arch/arm64/include/asm/cpucaps.h | 3 +-
arch/arm64/include/asm/cpufeature.h | 28 ++
arch/arm64/include/asm/cputype.h | 22 ++
arch/arm64/include/asm/fixmap.h | 6 +-
arch/arm64/include/asm/hwcap.h | 3 +
arch/arm64/include/asm/insn.h | 1 +
arch/arm64/include/asm/kvm_asm.h | 8 +
arch/arm64/include/asm/kvm_mmu.h | 3 +-
arch/arm64/include/asm/mmu.h | 6 +
arch/arm64/include/asm/sections.h | 5 +
arch/arm64/include/asm/spectre.h | 4 +
arch/arm64/include/asm/sysreg.h | 18 ++
arch/arm64/include/asm/vectors.h | 73 +++++
arch/arm64/include/uapi/asm/hwcap.h | 3 +
arch/arm64/include/uapi/asm/kvm.h | 5 +
arch/arm64/kernel/cpu_errata.c | 7 +
arch/arm64/kernel/cpufeature.c | 28 +-
arch/arm64/kernel/cpuinfo.c | 4 +
arch/arm64/kernel/entry.S | 213 ++++++++++----
arch/arm64/kernel/proton-pack.c | 359 +++++++++++++++++++++++-
arch/arm64/kernel/vmlinux.lds.S | 2 +-
arch/arm64/kvm/arm.c | 3 +-
arch/arm64/kvm/hyp/hyp-entry.S | 4 +
arch/arm64/kvm/hyp/smccc_wa.S | 75 +++++
arch/arm64/kvm/hyp/vhe/switch.c | 9 +-
arch/arm64/kvm/hypercalls.c | 12 +
arch/arm64/kvm/psci.c | 18 +-
arch/arm64/kvm/sys_regs.c | 2 +-
arch/arm64/mm/mmu.c | 12 +-
arch/x86/include/asm/cpufeatures.h | 2 +-
arch/x86/include/asm/nospec-branch.h | 16 +-
arch/x86/kernel/cpu/bugs.c | 205 ++++++++++----
drivers/acpi/ec.c | 10 -
drivers/acpi/sleep.c | 14 +-
drivers/block/xen-blkfront.c | 63 +++--
drivers/net/xen-netfront.c | 54 ++--
drivers/scsi/xen-scsifront.c | 3 +-
drivers/xen/gntalloc.c | 25 +-
drivers/xen/grant-table.c | 71 ++---
drivers/xen/pvcalls-front.c | 8 +-
drivers/xen/xenbus/xenbus_client.c | 24 +-
include/linux/arm-smccc.h | 5 +
include/linux/bpf.h | 12 +
include/xen/grant_table.h | 19 +-
kernel/sysctl.c | 7 +
net/9p/trans_xen.c | 14 +-
tools/arch/x86/include/asm/cpufeatures.h | 2 +-
65 files changed, 1825 insertions(+), 354 deletions(-)
From: James Morse <[email protected]>
commit ed50da7764535f1e24432ded289974f2bf2b0c5a upstream.
The tramp_ventry macro uses tramp_vectors as the address of the vectors
when calculating which ventry in the 'full fat' vectors to branch to.
While there is one set of tramp_vectors, this will be true.
Adding multiple sets of vectors will break this assumption.
Move the generation of the vectors to a macro, and pass the start
of the vectors as an argument to tramp_ventry.
Reviewed-by: Russell King (Oracle) <[email protected]>
Reviewed-by: Catalin Marinas <[email protected]>
Signed-off-by: James Morse <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm64/kernel/entry.S | 30 ++++++++++++++++--------------
1 file changed, 16 insertions(+), 14 deletions(-)
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -822,7 +822,7 @@ alternative_else_nop_endif
sub \dst, \dst, PAGE_SIZE
.endm
- .macro tramp_ventry, regsize = 64
+ .macro tramp_ventry, vector_start, regsize
.align 7
1:
.if \regsize == 64
@@ -845,10 +845,10 @@ alternative_insn isb, nop, ARM64_WORKARO
ldr x30, =vectors
#endif
alternative_if_not ARM64_WORKAROUND_CAVIUM_TX2_219_PRFM
- prfm plil1strm, [x30, #(1b - tramp_vectors)]
+ prfm plil1strm, [x30, #(1b - \vector_start)]
alternative_else_nop_endif
msr vbar_el1, x30
- add x30, x30, #(1b - tramp_vectors + 4)
+ add x30, x30, #(1b - \vector_start + 4)
isb
ret
.org 1b + 128 // Did we overflow the ventry slot?
@@ -867,19 +867,21 @@ alternative_else_nop_endif
sb
.endm
- .align 11
-SYM_CODE_START_NOALIGN(tramp_vectors)
+ .macro generate_tramp_vector
+.Lvector_start\@:
.space 0x400
- tramp_ventry
- tramp_ventry
- tramp_ventry
- tramp_ventry
-
- tramp_ventry 32
- tramp_ventry 32
- tramp_ventry 32
- tramp_ventry 32
+ .rept 4
+ tramp_ventry .Lvector_start\@, 64
+ .endr
+ .rept 4
+ tramp_ventry .Lvector_start\@, 32
+ .endr
+ .endm
+
+ .align 11
+SYM_CODE_START_NOALIGN(tramp_vectors)
+ generate_tramp_vector
SYM_CODE_END(tramp_vectors)
SYM_CODE_START(tramp_exit_native)
From: Juergen Gross <[email protected]>
Commit 5cadd4bb1d7fc9ab201ac14620d1a478357e4ebd upstream.
Instead of __get_free_pages() and free_pages() use alloc_pages_exact()
and free_pages_exact(). This is in preparation of a change of
gnttab_end_foreign_access() which will prohibit use of high-order
pages.
By using the local variable "order" instead of ring->intf->ring_order
in the error path of xen_9pfs_front_alloc_dataring() another bug is
fixed, as the error path can be entered before ring->intf->ring_order
is being set.
By using alloc_pages_exact() the size in bytes is specified for the
allocation, which fixes another bug for the case of
order < (PAGE_SHIFT - XEN_PAGE_SHIFT).
This is part of CVE-2022-23041 / XSA-396.
Reported-by: Simon Gaiser <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
Reviewed-by: Jan Beulich <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/9p/trans_xen.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
--- a/net/9p/trans_xen.c
+++ b/net/9p/trans_xen.c
@@ -304,9 +304,9 @@ static void xen_9pfs_front_free(struct x
ref = priv->rings[i].intf->ref[j];
gnttab_end_foreign_access(ref, 0, 0);
}
- free_pages((unsigned long)priv->rings[i].data.in,
- priv->rings[i].intf->ring_order -
- (PAGE_SHIFT - XEN_PAGE_SHIFT));
+ free_pages_exact(priv->rings[i].data.in,
+ 1UL << (priv->rings[i].intf->ring_order +
+ XEN_PAGE_SHIFT));
}
gnttab_end_foreign_access(priv->rings[i].ref, 0, 0);
free_page((unsigned long)priv->rings[i].intf);
@@ -345,8 +345,8 @@ static int xen_9pfs_front_alloc_dataring
if (ret < 0)
goto out;
ring->ref = ret;
- bytes = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
- order - (PAGE_SHIFT - XEN_PAGE_SHIFT));
+ bytes = alloc_pages_exact(1UL << (order + XEN_PAGE_SHIFT),
+ GFP_KERNEL | __GFP_ZERO);
if (!bytes) {
ret = -ENOMEM;
goto out;
@@ -377,9 +377,7 @@ out:
if (bytes) {
for (i--; i >= 0; i--)
gnttab_end_foreign_access(ring->intf->ref[i], 0, 0);
- free_pages((unsigned long)bytes,
- ring->intf->ring_order -
- (PAGE_SHIFT - XEN_PAGE_SHIFT));
+ free_pages_exact(bytes, 1UL << (order + XEN_PAGE_SHIFT));
}
gnttab_end_foreign_access(ring->ref, 0, 0);
free_page((unsigned long)ring->intf);
From: James Morse <[email protected]>
commit 4330e2c5c04c27bebf89d34e0bc14e6943413067 upstream.
Subsequent patches add even more code to the ventry slots.
Ensure kernels that overflow a ventry slot don't get built.
Reviewed-by: Russell King (Oracle) <[email protected]>
Reviewed-by: Catalin Marinas <[email protected]>
Signed-off-by: James Morse <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm64/kernel/entry.S | 3 +++
1 file changed, 3 insertions(+)
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -62,6 +62,7 @@
.macro kernel_ventry, el, label, regsize = 64
.align 7
+.Lventry_start\@:
#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
.if \el == 0
alternative_if ARM64_UNMAP_KERNEL_AT_EL0
@@ -120,6 +121,7 @@ alternative_else_nop_endif
mrs x0, tpidrro_el0
#endif
b el\()\el\()_\label
+.org .Lventry_start\@ + 128 // Did we overflow the ventry slot?
.endm
.macro tramp_alias, dst, sym
@@ -832,6 +834,7 @@ alternative_else_nop_endif
add x30, x30, #(1b - tramp_vectors)
isb
ret
+.org 1b + 128 // Did we overflow the ventry slot?
.endm
.macro tramp_exit, regsize = 64
From: James Morse <[email protected]>
commit dee435be76f4117410bbd90573a881fd33488f37 upstream.
Speculation attacks against some high-performance processors can
make use of branch history to influence future speculation as part of
a spectre-v2 attack. This is not mitigated by CSV2, meaning CPUs that
previously reported 'Not affected' are now moderately mitigated by CSV2.
Update the value in /sys/devices/system/cpu/vulnerabilities/spectre_v2
to also show the state of the BHB mitigation.
Reviewed-by: Catalin Marinas <[email protected]>
Signed-off-by: James Morse <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm64/include/asm/spectre.h | 2 ++
arch/arm64/kernel/proton-pack.c | 36 ++++++++++++++++++++++++++++++++++--
2 files changed, 36 insertions(+), 2 deletions(-)
--- a/arch/arm64/include/asm/spectre.h
+++ b/arch/arm64/include/asm/spectre.h
@@ -29,4 +29,6 @@ bool has_spectre_v4(const struct arm64_c
void spectre_v4_enable_mitigation(const struct arm64_cpu_capabilities *__unused);
void spectre_v4_enable_task_mitigation(struct task_struct *tsk);
+enum mitigation_state arm64_get_spectre_bhb_state(void);
+
#endif /* __ASM_SPECTRE_H */
--- a/arch/arm64/kernel/proton-pack.c
+++ b/arch/arm64/kernel/proton-pack.c
@@ -94,14 +94,39 @@ static bool spectre_v2_mitigations_off(v
return ret;
}
+static const char *get_bhb_affected_string(enum mitigation_state bhb_state)
+{
+ switch (bhb_state) {
+ case SPECTRE_UNAFFECTED:
+ return "";
+ default:
+ case SPECTRE_VULNERABLE:
+ return ", but not BHB";
+ case SPECTRE_MITIGATED:
+ return ", BHB";
+ }
+}
+
ssize_t cpu_show_spectre_v2(struct device *dev, struct device_attribute *attr,
char *buf)
{
+ enum mitigation_state bhb_state = arm64_get_spectre_bhb_state();
+ const char *bhb_str = get_bhb_affected_string(bhb_state);
+ const char *v2_str = "Branch predictor hardening";
+
switch (spectre_v2_state) {
case SPECTRE_UNAFFECTED:
- return sprintf(buf, "Not affected\n");
+ if (bhb_state == SPECTRE_UNAFFECTED)
+ return sprintf(buf, "Not affected\n");
+
+ /*
+ * Platforms affected by Spectre-BHB can't report
+ * "Not affected" for Spectre-v2.
+ */
+ v2_str = "CSV2";
+ fallthrough;
case SPECTRE_MITIGATED:
- return sprintf(buf, "Mitigation: Branch predictor hardening\n");
+ return sprintf(buf, "Mitigation: %s%s\n", v2_str, bhb_str);
case SPECTRE_VULNERABLE:
fallthrough;
default:
@@ -787,3 +812,10 @@ int arch_prctl_spec_ctrl_get(struct task
return -ENODEV;
}
}
+
+static enum mitigation_state spectre_bhb_state;
+
+enum mitigation_state arm64_get_spectre_bhb_state(void)
+{
+ return spectre_bhb_state;
+}
On 10/03/22 21.18, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.105 release.
> There are 58 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.
>
Successfully cross-compiled for arm64 (bcm2711_defconfig, gcc 10.2.0) and
powerpc (ps3_defconfig, gcc 11.2.0).
Tested-by: Bagas Sanjaya <[email protected]>
--
An old man doll... just what I always wanted! - Clara
From: Peter Zijlstra <[email protected]>
commit 5ad3eb1132453b9795ce5fd4572b1c18b292cca9 upstream.
Update the doc with the new fun.
[ bp: Massage commit message. ]
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
[[email protected]: backported to 5.10]
Signed-off-by: Frank van der Linden <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
Documentation/admin-guide/hw-vuln/spectre.rst | 42 ++++++++++++++++--------
Documentation/admin-guide/kernel-parameters.txt | 8 +++-
2 files changed, 35 insertions(+), 15 deletions(-)
--- a/Documentation/admin-guide/hw-vuln/spectre.rst
+++ b/Documentation/admin-guide/hw-vuln/spectre.rst
@@ -131,6 +131,19 @@ steer its indirect branch speculations t
speculative execution's side effects left in level 1 cache to infer the
victim's data.
+Yet another variant 2 attack vector is for the attacker to poison the
+Branch History Buffer (BHB) to speculatively steer an indirect branch
+to a specific Branch Target Buffer (BTB) entry, even if the entry isn't
+associated with the source address of the indirect branch. Specifically,
+the BHB might be shared across privilege levels even in the presence of
+Enhanced IBRS.
+
+Currently the only known real-world BHB attack vector is via
+unprivileged eBPF. Therefore, it's highly recommended to not enable
+unprivileged eBPF, especially when eIBRS is used (without retpolines).
+For a full mitigation against BHB attacks, it's recommended to use
+retpolines (or eIBRS combined with retpolines).
+
Attack scenarios
----------------
@@ -364,13 +377,15 @@ The possible values in this file are:
- Kernel status:
- ==================================== =================================
- 'Not affected' The processor is not vulnerable
- 'Vulnerable' Vulnerable, no mitigation
- 'Mitigation: Full generic retpoline' Software-focused mitigation
- 'Mitigation: Full AMD retpoline' AMD-specific software mitigation
- 'Mitigation: Enhanced IBRS' Hardware-focused mitigation
- ==================================== =================================
+ ======================================== =================================
+ 'Not affected' The processor is not vulnerable
+ 'Mitigation: None' Vulnerable, no mitigation
+ 'Mitigation: Retpolines' Use Retpoline thunks
+ 'Mitigation: LFENCE' Use LFENCE instructions
+ 'Mitigation: Enhanced IBRS' Hardware-focused mitigation
+ 'Mitigation: Enhanced IBRS + Retpolines' Hardware-focused + Retpolines
+ 'Mitigation: Enhanced IBRS + LFENCE' Hardware-focused + LFENCE
+ ======================================== =================================
- Firmware status: Show if Indirect Branch Restricted Speculation (IBRS) is
used to protect against Spectre variant 2 attacks when calling firmware (x86 only).
@@ -584,12 +599,13 @@ kernel command line.
Specific mitigations can also be selected manually:
- retpoline
- replace indirect branches
- retpoline,generic
- google's original retpoline
- retpoline,amd
- AMD-specific minimal thunk
+ retpoline auto pick between generic,lfence
+ retpoline,generic Retpolines
+ retpoline,lfence LFENCE; indirect branch
+ retpoline,amd alias for retpoline,lfence
+ eibrs enhanced IBRS
+ eibrs,retpoline enhanced IBRS + Retpolines
+ eibrs,lfence enhanced IBRS + LFENCE
Not specifying this option is equivalent to
spectre_v2=auto.
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4957,8 +4957,12 @@
Specific mitigations can also be selected manually:
retpoline - replace indirect branches
- retpoline,generic - google's original retpoline
- retpoline,amd - AMD-specific minimal thunk
+ retpoline,generic - Retpolines
+ retpoline,lfence - LFENCE; indirect branch
+ retpoline,amd - alias for retpoline,lfence
+ eibrs - enhanced IBRS
+ eibrs,retpoline - enhanced IBRS + Retpolines
+ eibrs,lfence - enhanced IBRS + LFENCE
Not specifying this option is equivalent to
spectre_v2=auto.
From: Peter Zijlstra <[email protected]>
commit f8a66d608a3e471e1202778c2a36cbdc96bae73b upstream.
Currently Linux prevents usage of retpoline,amd on !AMD hardware, this
is unfriendly and gets in the way of testing. Remove this restriction.
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Reviewed-by: Borislav Petkov <[email protected]>
Acked-by: Josh Poimboeuf <[email protected]>
Tested-by: Alexei Starovoitov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/cpu/bugs.c | 7 -------
1 file changed, 7 deletions(-)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -845,13 +845,6 @@ static enum spectre_v2_mitigation_cmd __
return SPECTRE_V2_CMD_AUTO;
}
- if (cmd == SPECTRE_V2_CMD_RETPOLINE_AMD &&
- boot_cpu_data.x86_vendor != X86_VENDOR_HYGON &&
- boot_cpu_data.x86_vendor != X86_VENDOR_AMD) {
- pr_err("retpoline,amd selected but CPU is not AMD. Switching to AUTO select\n");
- return SPECTRE_V2_CMD_AUTO;
- }
-
spec_v2_print_cond(mitigation_options[i].option,
mitigation_options[i].secure);
return cmd;
From: "Russell King (Oracle)" <[email protected]>
commit 8d9d651ff2270a632e9dc497b142db31e8911315 upstream.
Use the linker's LOADADDR() macro to get the load address of the
sections, and provide a macro to set the start and end symbols.
Acked-by: Catalin Marinas <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/include/asm/vmlinux.lds.h | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
--- a/arch/arm/include/asm/vmlinux.lds.h
+++ b/arch/arm/include/asm/vmlinux.lds.h
@@ -26,6 +26,11 @@
#define ARM_MMU_DISCARD(x) x
#endif
+/* Set start/end symbol names to the LMA for the section */
+#define ARM_LMA(sym, section) \
+ sym##_start = LOADADDR(section); \
+ sym##_end = LOADADDR(section) + SIZEOF(section)
+
#define PROC_INFO \
. = ALIGN(4); \
__proc_info_begin = .; \
@@ -110,19 +115,19 @@
* only thing that matters is their relative offsets
*/
#define ARM_VECTORS \
- __vectors_start = .; \
+ __vectors_lma = .; \
.vectors 0xffff0000 : AT(__vectors_start) { \
*(.vectors) \
} \
- . = __vectors_start + SIZEOF(.vectors); \
- __vectors_end = .; \
+ ARM_LMA(__vectors, .vectors); \
+ . = __vectors_lma + SIZEOF(.vectors); \
\
- __stubs_start = .; \
- .stubs ADDR(.vectors) + 0x1000 : AT(__stubs_start) { \
+ __stubs_lma = .; \
+ .stubs ADDR(.vectors) + 0x1000 : AT(__stubs_lma) { \
*(.stubs) \
} \
- . = __stubs_start + SIZEOF(.stubs); \
- __stubs_end = .; \
+ ARM_LMA(__stubs, .stubs); \
+ . = __stubs_lma + SIZEOF(.stubs); \
\
PROVIDE(vector_fiq_offset = vector_fiq - ADDR(.vectors));
On 3/10/22 6:18 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.105 release.
> There are 58 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 Sat, 12 Mar 2022 14:07:58 +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/v5.x/stable-review/patch-5.10.105-rc2.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels:
Tested-by: Florian Fainelli <[email protected]>
--
Florian
On Thu, 10 Mar 2022 15:18:20 +0100, Greg Kroah-Hartman <[email protected]> wrote:
> This is the start of the stable review cycle for the 5.10.105 release.
> There are 58 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 Sat, 12 Mar 2022 14:07:58 +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/v5.x/stable-review/patch-5.10.105-rc2.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
5.10.105-rc2 Successfully Compiled and booted on my Raspberry PI 4b (8g) (bcm2711)
Tested-by: Fox Chen <[email protected]>