This is the start of the stable review cycle for the 5.16.14 release.
There are 37 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 Fri, 11 Mar 2022 15:58:48 +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.16.14-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-5.16.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 5.16.14-rc1
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]>
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]>
KVM: arm64: Allow indirect vectors to be used without SPECTRE_V3A
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
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
-------------
Diffstat:
Documentation/admin-guide/hw-vuln/spectre.rst | 50 +--
Documentation/admin-guide/kernel-parameters.txt | 8 +-
Documentation/arm64/cpu-feature-registers.rst | 17 ++
Documentation/arm64/elf_hwcaps.rst | 8 +
Makefile | 4 +-
arch/arm/include/asm/assembler.h | 10 +
arch/arm/include/asm/spectre.h | 32 ++
arch/arm/include/asm/vmlinux.lds.h | 35 ++-
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 | 207 ++++++++++---
arch/arm64/Kconfig | 9 +
arch/arm64/include/asm/assembler.h | 53 ++++
arch/arm64/include/asm/cpu.h | 1 +
arch/arm64/include/asm/cpufeature.h | 29 ++
arch/arm64/include/asm/cputype.h | 8 +
arch/arm64/include/asm/fixmap.h | 6 +-
arch/arm64/include/asm/hwcap.h | 2 +
arch/arm64/include/asm/insn.h | 1 +
arch/arm64/include/asm/kvm_host.h | 5 +
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 | 2 +
arch/arm64/include/uapi/asm/kvm.h | 5 +
arch/arm64/kernel/cpu_errata.c | 7 +
arch/arm64/kernel/cpufeature.c | 25 ++
arch/arm64/kernel/cpuinfo.c | 3 +
arch/arm64/kernel/entry.S | 214 +++++++++----
arch/arm64/kernel/image-vars.h | 4 +
arch/arm64/kernel/proton-pack.c | 391 +++++++++++++++++++++++-
arch/arm64/kernel/vmlinux.lds.S | 2 +-
arch/arm64/kvm/arm.c | 5 +-
arch/arm64/kvm/hyp/hyp-entry.S | 9 +
arch/arm64/kvm/hyp/nvhe/mm.c | 4 +-
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/arm64/tools/cpucaps | 1 +
arch/x86/include/asm/cpufeatures.h | 2 +-
arch/x86/include/asm/nospec-branch.h | 16 +-
arch/x86/kernel/alternative.c | 8 +-
arch/x86/kernel/cpu/bugs.c | 204 ++++++++++---
arch/x86/lib/retpoline.S | 2 +-
arch/x86/net/bpf_jit_comp.c | 2 +-
include/linux/arm-smccc.h | 5 +
include/linux/bpf.h | 12 +
kernel/sysctl.c | 7 +
tools/arch/x86/include/asm/cpufeatures.h | 2 +-
56 files changed, 1606 insertions(+), 216 deletions(-)
From: Kim Phillips <[email protected]>
commit e9b6013a7ce31535b04b02ba99babefe8a8599fa upstream.
Update the link to the "Software Techniques for Managing Speculation
on AMD Processors" whitepaper.
Signed-off-by: Kim Phillips <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
Documentation/admin-guide/hw-vuln/spectre.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/Documentation/admin-guide/hw-vuln/spectre.rst
+++ b/Documentation/admin-guide/hw-vuln/spectre.rst
@@ -60,8 +60,8 @@ privileged data touched during the specu
Spectre variant 1 attacks take advantage of speculative execution of
conditional branches, while Spectre variant 2 attacks use speculative
execution of indirect branches to leak privileged memory.
-See :ref:`[1] <spec_ref1>` :ref:`[5] <spec_ref5>` :ref:`[7] <spec_ref7>`
-:ref:`[10] <spec_ref10>` :ref:`[11] <spec_ref11>`.
+See :ref:`[1] <spec_ref1>` :ref:`[5] <spec_ref5>` :ref:`[6] <spec_ref6>`
+:ref:`[7] <spec_ref7>` :ref:`[10] <spec_ref10>` :ref:`[11] <spec_ref11>`.
Spectre variant 1 (Bounds Check Bypass)
---------------------------------------
@@ -697,7 +697,7 @@ AMD white papers:
.. _spec_ref6:
-[6] `Software techniques for managing speculation on AMD processors <https://developer.amd.com/wp-content/resources/90343-B_SoftwareTechniquesforManagingSpeculation_WP_7-18Update_FNL.pdf>`_.
+[6] `Software techniques for managing speculation on AMD processors <https://developer.amd.com/wp-content/resources/Managing-Speculation-on-AMD-Processors.pdf>`_.
ARM white papers:
From: Josh Poimboeuf <[email protected]>
commit 0de05d056afdb00eca8c7bbb0c79a3438daf700c upstream.
The commit
44a3918c8245 ("x86/speculation: Include unprivileged eBPF status in Spectre v2 mitigation reporting")
added a warning for the "eIBRS + unprivileged eBPF" combination, which
has been shown to be vulnerable against Spectre v2 BHB-based attacks.
However, there's no warning about the "eIBRS + LFENCE retpoline +
unprivileged eBPF" combo. The LFENCE adds more protection by shortening
the speculation window after a mispredicted branch. That makes an attack
significantly more difficult, even with unprivileged eBPF. So at least
for now the logic doesn't warn about that combination.
But if you then add SMT into the mix, the SMT attack angle weakens the
effectiveness of the LFENCE considerably.
So extend the "eIBRS + unprivileged eBPF" warning to also include the
"eIBRS + LFENCE + unprivileged eBPF + SMT" case.
[ bp: Massage commit message. ]
Suggested-by: Alyssa Milburn <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/cpu/bugs.c | 27 +++++++++++++++++++++++++--
1 file changed, 25 insertions(+), 2 deletions(-)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -653,12 +653,27 @@ static inline const char *spectre_v2_mod
#define SPECTRE_V2_LFENCE_MSG "WARNING: LFENCE mitigation is not recommended for this CPU, data leaks possible!\n"
#define SPECTRE_V2_EIBRS_EBPF_MSG "WARNING: Unprivileged eBPF is enabled with eIBRS on, data leaks possible via Spectre v2 BHB attacks!\n"
+#define SPECTRE_V2_EIBRS_LFENCE_EBPF_SMT_MSG "WARNING: Unprivileged eBPF is enabled with eIBRS+LFENCE mitigation and SMT, data leaks possible via Spectre v2 BHB attacks!\n"
#ifdef CONFIG_BPF_SYSCALL
void unpriv_ebpf_notify(int new_state)
{
- if (spectre_v2_enabled == SPECTRE_V2_EIBRS && !new_state)
+ if (new_state)
+ return;
+
+ /* Unprivileged eBPF is enabled */
+
+ switch (spectre_v2_enabled) {
+ case SPECTRE_V2_EIBRS:
pr_err(SPECTRE_V2_EIBRS_EBPF_MSG);
+ break;
+ case SPECTRE_V2_EIBRS_LFENCE:
+ if (sched_smt_active())
+ pr_err(SPECTRE_V2_EIBRS_LFENCE_EBPF_SMT_MSG);
+ break;
+ default:
+ break;
+ }
}
#endif
@@ -1118,6 +1133,10 @@ void cpu_bugs_smt_update(void)
{
mutex_lock(&spec_ctrl_mutex);
+ if (sched_smt_active() && unprivileged_ebpf_enabled() &&
+ spectre_v2_enabled == SPECTRE_V2_EIBRS_LFENCE)
+ pr_warn_once(SPECTRE_V2_EIBRS_LFENCE_EBPF_SMT_MSG);
+
switch (spectre_v2_user_stibp) {
case SPECTRE_V2_USER_NONE:
break;
@@ -1793,7 +1812,11 @@ static ssize_t spectre_v2_show_state(cha
return sprintf(buf, "Vulnerable: LFENCE\n");
if (spectre_v2_enabled == SPECTRE_V2_EIBRS && unprivileged_ebpf_enabled())
- return sprintf(buf, "Vulnerable: Unprivileged eBPF enabled\n");
+ return sprintf(buf, "Vulnerable: eIBRS with unprivileged eBPF\n");
+
+ if (sched_smt_active() && unprivileged_ebpf_enabled() &&
+ spectre_v2_enabled == SPECTRE_V2_EIBRS_LFENCE)
+ return sprintf(buf, "Vulnerable: eIBRS+LFENCE with unprivileged eBPF and SMT\n");
return sprintf(buf, "%s%s%s%s%s%s\n",
spectre_v2_strings[spectre_v2_enabled],
From: Josh Poimboeuf <[email protected]>
commit 44a3918c8245ab10c6c9719dd12e7a8d291980d8 upstream.
With unprivileged eBPF enabled, eIBRS (without retpoline) is vulnerable
to Spectre v2 BHB-based attacks.
When both are enabled, print a warning message and report it in the
'spectre_v2' sysfs vulnerabilities file.
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/cpu/bugs.c | 35 +++++++++++++++++++++++++++++------
include/linux/bpf.h | 12 ++++++++++++
kernel/sysctl.c | 7 +++++++
3 files changed, 48 insertions(+), 6 deletions(-)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -16,6 +16,7 @@
#include <linux/prctl.h>
#include <linux/sched/smt.h>
#include <linux/pgtable.h>
+#include <linux/bpf.h>
#include <asm/spec-ctrl.h>
#include <asm/cmdline.h>
@@ -650,6 +651,16 @@ static inline const char *spectre_v2_mod
static inline const char *spectre_v2_module_string(void) { return ""; }
#endif
+#define SPECTRE_V2_EIBRS_EBPF_MSG "WARNING: Unprivileged eBPF is enabled with eIBRS on, data leaks possible via Spectre v2 BHB attacks!\n"
+
+#ifdef CONFIG_BPF_SYSCALL
+void unpriv_ebpf_notify(int new_state)
+{
+ if (spectre_v2_enabled == SPECTRE_V2_EIBRS && !new_state)
+ pr_err(SPECTRE_V2_EIBRS_EBPF_MSG);
+}
+#endif
+
static inline bool match_option(const char *arg, int arglen, const char *opt)
{
int len = strlen(opt);
@@ -994,6 +1005,9 @@ static void __init spectre_v2_select_mit
break;
}
+ if (mode == SPECTRE_V2_EIBRS && unprivileged_ebpf_enabled())
+ pr_err(SPECTRE_V2_EIBRS_EBPF_MSG);
+
if (spectre_v2_in_eibrs_mode(mode)) {
/* Force it so VMEXIT will restore correctly */
x86_spec_ctrl_base |= SPEC_CTRL_IBRS;
@@ -1780,6 +1794,20 @@ static char *ibpb_state(void)
return "";
}
+static ssize_t spectre_v2_show_state(char *buf)
+{
+ if (spectre_v2_enabled == SPECTRE_V2_EIBRS && unprivileged_ebpf_enabled())
+ return sprintf(buf, "Vulnerable: Unprivileged eBPF enabled\n");
+
+ return sprintf(buf, "%s%s%s%s%s%s\n",
+ spectre_v2_strings[spectre_v2_enabled],
+ ibpb_state(),
+ boot_cpu_has(X86_FEATURE_USE_IBRS_FW) ? ", IBRS_FW" : "",
+ stibp_state(),
+ boot_cpu_has(X86_FEATURE_RSB_CTXSW) ? ", RSB filling" : "",
+ spectre_v2_module_string());
+}
+
static ssize_t srbds_show_state(char *buf)
{
return sprintf(buf, "%s\n", srbds_strings[srbds_mitigation]);
@@ -1805,12 +1833,7 @@ static ssize_t cpu_show_common(struct de
return sprintf(buf, "%s\n", spectre_v1_strings[spectre_v1_mitigation]);
case X86_BUG_SPECTRE_V2:
- return sprintf(buf, "%s%s%s%s%s%s\n", spectre_v2_strings[spectre_v2_enabled],
- ibpb_state(),
- boot_cpu_has(X86_FEATURE_USE_IBRS_FW) ? ", IBRS_FW" : "",
- stibp_state(),
- boot_cpu_has(X86_FEATURE_RSB_CTXSW) ? ", RSB filling" : "",
- spectre_v2_module_string());
+ return spectre_v2_show_state(buf);
case X86_BUG_SPEC_STORE_BYPASS:
return sprintf(buf, "%s\n", ssb_strings[ssb_mode]);
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -1774,6 +1774,12 @@ bool bpf_prog_has_kfunc_call(const struc
const struct btf_func_model *
bpf_jit_find_kfunc_model(const struct bpf_prog *prog,
const struct bpf_insn *insn);
+
+static inline bool unprivileged_ebpf_enabled(void)
+{
+ return !sysctl_unprivileged_bpf_disabled;
+}
+
#else /* !CONFIG_BPF_SYSCALL */
static inline struct bpf_prog *bpf_prog_get(u32 ufd)
{
@@ -1993,6 +1999,12 @@ bpf_jit_find_kfunc_model(const struct bp
{
return NULL;
}
+
+static inline bool unprivileged_ebpf_enabled(void)
+{
+ return false;
+}
+
#endif /* CONFIG_BPF_SYSCALL */
void __bpf_free_used_btfs(struct bpf_prog_aux *aux,
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -228,6 +228,10 @@ static int bpf_stats_handler(struct ctl_
return ret;
}
+void __weak unpriv_ebpf_notify(int new_state)
+{
+}
+
static int bpf_unpriv_handler(struct ctl_table *table, int write,
void *buffer, size_t *lenp, loff_t *ppos)
{
@@ -245,6 +249,9 @@ static int bpf_unpriv_handler(struct ctl
return -EPERM;
*(int *)table->data = unpriv_enable;
}
+
+ unpriv_ebpf_notify(unpriv_enable);
+
return ret;
}
#endif /* CONFIG_BPF_SYSCALL && CONFIG_SYSCTL */
From: James Morse <[email protected]>
commit 58c9a5060cb7cd529d49c93954cdafe81c1d642a upstream.
The mitigations for Spectre-BHB are only applied when an exception is
taken from user-space. The mitigation status is reported via the spectre_v2
sysfs vulnerabilities file.
When unprivileged eBPF is enabled the mitigation in the exception vectors
can be avoided by an eBPF program.
When unprivileged eBPF is enabled, print a warning and report vulnerable
via the sysfs vulnerabilities file.
Acked-by: Catalin Marinas <[email protected]>
Signed-off-by: James Morse <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm64/kernel/proton-pack.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
--- a/arch/arm64/kernel/proton-pack.c
+++ b/arch/arm64/kernel/proton-pack.c
@@ -18,6 +18,7 @@
*/
#include <linux/arm-smccc.h>
+#include <linux/bpf.h>
#include <linux/cpu.h>
#include <linux/device.h>
#include <linux/nospec.h>
@@ -111,6 +112,15 @@ static const char *get_bhb_affected_stri
}
}
+static bool _unprivileged_ebpf_enabled(void)
+{
+#ifdef CONFIG_BPF_SYSCALL
+ return !sysctl_unprivileged_bpf_disabled;
+#else
+ return false;
+#endif
+}
+
ssize_t cpu_show_spectre_v2(struct device *dev, struct device_attribute *attr,
char *buf)
{
@@ -130,6 +140,9 @@ ssize_t cpu_show_spectre_v2(struct devic
v2_str = "CSV2";
fallthrough;
case SPECTRE_MITIGATED:
+ if (bhb_state == SPECTRE_MITIGATED && _unprivileged_ebpf_enabled())
+ return sprintf(buf, "Vulnerable: Unprivileged eBPF enabled\n");
+
return sprintf(buf, "Mitigation: %s%s\n", v2_str, bhb_str);
case SPECTRE_VULNERABLE:
fallthrough;
@@ -1125,3 +1138,16 @@ void __init spectre_bhb_patch_clearbhb(s
*updptr++ = cpu_to_le32(aarch64_insn_gen_nop());
*updptr++ = cpu_to_le32(aarch64_insn_gen_nop());
}
+
+#ifdef CONFIG_BPF_SYSCALL
+#define EBPF_WARN "Unprivileged eBPF is enabled, data leaks possible via Spectre v2 BHB attacks!\n"
+void unpriv_ebpf_notify(int new_state)
+{
+ if (spectre_v2_state == SPECTRE_VULNERABLE ||
+ spectre_bhb_state != SPECTRE_MITIGATED)
+ return;
+
+ if (!new_state)
+ pr_err("WARNING: %s", EBPF_WARN);
+}
+#endif
From: James Morse <[email protected]>
commit bd09128d16fac3c34b80bd6a29088ac632e8ce09 upstream.
The Spectre-BHB workaround adds a firmware call to the vectors. This
is needed on some CPUs, but not others. To avoid the unaffected CPU in
a big/little pair from making the firmware call, create per cpu vectors.
The per-cpu vectors only apply when returning from EL0.
Systems using KPTI can use the canonical 'full-fat' vectors directly at
EL1, the trampoline exit code will switch to this_cpu_vector on exit to
EL0. Systems not using KPTI should always use this_cpu_vector.
this_cpu_vector will point at a vector in tramp_vecs or
__bp_harden_el1_vectors, depending on whether KPTI is in use.
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/vectors.h | 29 ++++++++++++++++++++++++++++-
arch/arm64/kernel/cpufeature.c | 11 +++++++++++
arch/arm64/kernel/entry.S | 12 ++++++------
arch/arm64/kvm/hyp/vhe/switch.c | 9 +++++++--
4 files changed, 52 insertions(+), 9 deletions(-)
--- a/arch/arm64/include/asm/vectors.h
+++ b/arch/arm64/include/asm/vectors.h
@@ -5,6 +5,15 @@
#ifndef __ASM_VECTORS_H
#define __ASM_VECTORS_H
+#include <linux/bug.h>
+#include <linux/percpu.h>
+
+#include <asm/fixmap.h>
+
+extern char vectors[];
+extern char tramp_vectors[];
+extern char __bp_harden_el1_vectors[];
+
/*
* Note: the order of this enum corresponds to two arrays in entry.S:
* tramp_vecs and __bp_harden_el1_vectors. By default the canonical
@@ -29,6 +38,24 @@ enum arm64_bp_harden_el1_vectors {
* Remap the kernel before branching to the canonical vectors.
*/
EL1_VECTOR_KPTI,
-+};
+};
+
+/* The vectors to use on return from EL0. e.g. to remap the kernel */
+DECLARE_PER_CPU_READ_MOSTLY(const char *, this_cpu_vector);
+
+#ifndef CONFIG_UNMAP_KERNEL_AT_EL0
+#define TRAMP_VALIAS 0
+#endif
+
+static inline const char *
+arm64_get_bp_hardening_vector(enum arm64_bp_harden_el1_vectors slot)
+{
+ if (arm64_kernel_unmapped_at_el0())
+ return (char *)TRAMP_VALIAS + SZ_2K * slot;
+
+ WARN_ON_ONCE(slot == EL1_VECTOR_KPTI);
+
+ return __bp_harden_el1_vectors + SZ_2K * slot;
+}
#endif /* __ASM_VECTORS_H */
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -73,6 +73,8 @@
#include <linux/mm.h>
#include <linux/cpu.h>
#include <linux/kasan.h>
+#include <linux/percpu.h>
+
#include <asm/cpu.h>
#include <asm/cpufeature.h>
#include <asm/cpu_ops.h>
@@ -85,6 +87,7 @@
#include <asm/smp.h>
#include <asm/sysreg.h>
#include <asm/traps.h>
+#include <asm/vectors.h>
#include <asm/virt.h>
/* Kernel representation of AT_HWCAP and AT_HWCAP2 */
@@ -110,6 +113,8 @@ DECLARE_BITMAP(boot_capabilities, ARM64_
bool arm64_use_ng_mappings = false;
EXPORT_SYMBOL(arm64_use_ng_mappings);
+DEFINE_PER_CPU_READ_MOSTLY(const char *, this_cpu_vector) = vectors;
+
/*
* Permit PER_LINUX32 and execve() of 32-bit binaries even if not all CPUs
* support it?
@@ -1590,6 +1595,12 @@ kpti_install_ng_mappings(const struct ar
int cpu = smp_processor_id();
+ if (__this_cpu_read(this_cpu_vector) == vectors) {
+ const char *v = arm64_get_bp_hardening_vector(EL1_VECTOR_KPTI);
+
+ __this_cpu_write(this_cpu_vector, v);
+ }
+
/*
* We don't need to rewrite the page-tables if either we've done
* it already or we have KASLR enabled and therefore have not
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -38,7 +38,6 @@
.macro kernel_ventry, el:req, ht:req, regsize:req, label:req
.align 7
.Lventry_start\@:
-#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
.if \el == 0
/*
* This must be the first instruction of the EL0 vector entries. It is
@@ -53,7 +52,6 @@
.endif
.Lskip_tramp_vectors_cleanup\@:
.endif
-#endif
sub sp, sp, #PT_REGS_SIZE
#ifdef CONFIG_VMAP_STACK
@@ -712,10 +710,10 @@ alternative_else_nop_endif
.endm
.macro tramp_exit, regsize = 64
- adr x30, tramp_vectors
-#ifdef CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY
- add x30, x30, SZ_4K
-#endif
+ tramp_data_read_var x30, this_cpu_vector
+ get_this_cpu_offset x29
+ ldr x30, [x30, x29]
+
msr vbar_el1, x30
ldr lr, [sp, #S_LR]
tramp_unmap_kernel x29
@@ -775,6 +773,8 @@ __entry_tramp_data_vectors:
__entry_tramp_data___sdei_asm_handler:
.quad __sdei_asm_handler
#endif /* CONFIG_ARM_SDE_INTERFACE */
+__entry_tramp_data_this_cpu_vector:
+ .quad this_cpu_vector
SYM_DATA_END(__entry_tramp_data_start)
.popsection // .rodata
#endif /* CONFIG_RANDOMIZE_BASE */
--- a/arch/arm64/kvm/hyp/vhe/switch.c
+++ b/arch/arm64/kvm/hyp/vhe/switch.c
@@ -10,6 +10,7 @@
#include <linux/kvm_host.h>
#include <linux/types.h>
#include <linux/jump_label.h>
+#include <linux/percpu.h>
#include <uapi/linux/psci.h>
#include <kvm/arm_psci.h>
@@ -25,6 +26,7 @@
#include <asm/debug-monitors.h>
#include <asm/processor.h>
#include <asm/thread_info.h>
+#include <asm/vectors.h>
/* VHE specific context */
DEFINE_PER_CPU(struct kvm_host_data, kvm_host_data);
@@ -68,7 +70,7 @@ NOKPROBE_SYMBOL(__activate_traps);
static void __deactivate_traps(struct kvm_vcpu *vcpu)
{
- extern char vectors[]; /* kernel exception vectors */
+ const char *host_vectors = vectors;
___deactivate_traps(vcpu);
@@ -82,7 +84,10 @@ static void __deactivate_traps(struct kv
asm(ALTERNATIVE("nop", "isb", ARM64_WORKAROUND_SPECULATIVE_AT));
write_sysreg(CPACR_EL1_DEFAULT, cpacr_el1);
- write_sysreg(vectors, vbar_el1);
+
+ if (!arm64_kernel_unmapped_at_el0())
+ host_vectors = __this_cpu_read(this_cpu_vector);
+ write_sysreg(host_vectors, vbar_el1);
}
NOKPROBE_SYMBOL(__deactivate_traps);
From: James Morse <[email protected]>
commit ba2689234be92024e5635d30fe744f4853ad97db upstream.
Some CPUs affected by Spectre-BHB need a sequence of branches, or a
firmware call to be run before any indirect branch. This needs to go
in the vectors. No CPU needs both.
While this can be patched in, it would run on all CPUs as there is a
single set of vectors. If only one part of a big/little combination is
affected, the unaffected CPUs have to run the mitigation too.
Create extra vectors that include the sequence. Subsequent patches will
allow affected CPUs to select this set of vectors. Later patches will
modify the loop count to match what the CPU requires.
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/assembler.h | 24 ++++++++++++++++
arch/arm64/include/asm/vectors.h | 34 +++++++++++++++++++++++
arch/arm64/kernel/entry.S | 53 ++++++++++++++++++++++++++++++-------
arch/arm64/kernel/proton-pack.c | 16 +++++++++++
include/linux/arm-smccc.h | 5 +++
5 files changed, 123 insertions(+), 9 deletions(-)
create mode 100644 arch/arm64/include/asm/vectors.h
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -840,4 +840,28 @@ alternative_endif
#endif /* GNU_PROPERTY_AARCH64_FEATURE_1_DEFAULT */
+ .macro __mitigate_spectre_bhb_loop tmp
+#ifdef CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY
+ mov \tmp, #32
+.Lspectre_bhb_loop\@:
+ b . + 4
+ subs \tmp, \tmp, #1
+ b.ne .Lspectre_bhb_loop\@
+ sb
+#endif /* CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY */
+ .endm
+
+ /* Save/restores x0-x3 to the stack */
+ .macro __mitigate_spectre_bhb_fw
+#ifdef CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY
+ stp x0, x1, [sp, #-16]!
+ stp x2, x3, [sp, #-16]!
+ mov w0, #ARM_SMCCC_ARCH_WORKAROUND_3
+alternative_cb smccc_patch_fw_mitigation_conduit
+ nop // Patched to SMC/HVC #0
+alternative_cb_end
+ ldp x2, x3, [sp], #16
+ ldp x0, x1, [sp], #16
+#endif /* CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY */
+ .endm
#endif /* __ASM_ASSEMBLER_H */
--- /dev/null
+++ b/arch/arm64/include/asm/vectors.h
@@ -0,0 +1,34 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2022 ARM Ltd.
+ */
+#ifndef __ASM_VECTORS_H
+#define __ASM_VECTORS_H
+
+/*
+ * Note: the order of this enum corresponds to two arrays in entry.S:
+ * tramp_vecs and __bp_harden_el1_vectors. By default the canonical
+ * 'full fat' vectors are used directly.
+ */
+enum arm64_bp_harden_el1_vectors {
+#ifdef CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY
+ /*
+ * Perform the BHB loop mitigation, before branching to the canonical
+ * vectors.
+ */
+ EL1_VECTOR_BHB_LOOP,
+
+ /*
+ * Make the SMC call for firmware mitigation, before branching to the
+ * canonical vectors.
+ */
+ EL1_VECTOR_BHB_FW,
+#endif /* CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY */
+
+ /*
+ * Remap the kernel before branching to the canonical vectors.
+ */
+ EL1_VECTOR_KPTI,
++};
+
+#endif /* __ASM_VECTORS_H */
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -646,13 +646,26 @@ alternative_else_nop_endif
sub \dst, \dst, PAGE_SIZE
.endm
- .macro tramp_ventry, vector_start, regsize, kpti
+
+#define BHB_MITIGATION_NONE 0
+#define BHB_MITIGATION_LOOP 1
+#define BHB_MITIGATION_FW 2
+
+ .macro tramp_ventry, vector_start, regsize, kpti, bhb
.align 7
1:
.if \regsize == 64
msr tpidrro_el0, x30 // Restored in kernel_ventry
.endif
+ .if \bhb == BHB_MITIGATION_LOOP
+ /*
+ * This sequence must appear before the first indirect branch. i.e. the
+ * ret out of tramp_ventry. It appears here because x30 is free.
+ */
+ __mitigate_spectre_bhb_loop x30
+ .endif // \bhb == BHB_MITIGATION_LOOP
+
.if \kpti == 1
/*
* Defend against branch aliasing attacks by pushing a dummy
@@ -680,6 +693,15 @@ alternative_else_nop_endif
ldr x30, =vectors
.endif // \kpti == 1
+ .if \bhb == BHB_MITIGATION_FW
+ /*
+ * The firmware sequence must appear before the first indirect branch.
+ * i.e. the ret out of tramp_ventry. But it also needs the stack to be
+ * mapped to save/restore the registers the SMC clobbers.
+ */
+ __mitigate_spectre_bhb_fw
+ .endif // \bhb == BHB_MITIGATION_FW
+
add x30, x30, #(1b - \vector_start + 4)
ret
.org 1b + 128 // Did we overflow the ventry slot?
@@ -687,6 +709,9 @@ alternative_else_nop_endif
.macro tramp_exit, regsize = 64
adr x30, tramp_vectors
+#ifdef CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY
+ add x30, x30, SZ_4K
+#endif
msr vbar_el1, x30
ldr lr, [sp, #S_LR]
tramp_unmap_kernel x29
@@ -698,26 +723,32 @@ alternative_else_nop_endif
sb
.endm
- .macro generate_tramp_vector, kpti
+ .macro generate_tramp_vector, kpti, bhb
.Lvector_start\@:
.space 0x400
.rept 4
- tramp_ventry .Lvector_start\@, 64, \kpti
+ tramp_ventry .Lvector_start\@, 64, \kpti, \bhb
.endr
.rept 4
- tramp_ventry .Lvector_start\@, 32, \kpti
+ tramp_ventry .Lvector_start\@, 32, \kpti, \bhb
.endr
.endm
#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
/*
* Exception vectors trampoline.
+ * The order must match __bp_harden_el1_vectors and the
+ * arm64_bp_harden_el1_vectors enum.
*/
.pushsection ".entry.tramp.text", "ax"
.align 11
SYM_CODE_START_NOALIGN(tramp_vectors)
- generate_tramp_vector kpti=1
+#ifdef CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY
+ generate_tramp_vector kpti=1, bhb=BHB_MITIGATION_LOOP
+ generate_tramp_vector kpti=1, bhb=BHB_MITIGATION_FW
+#endif /* CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY */
+ generate_tramp_vector kpti=1, bhb=BHB_MITIGATION_NONE
SYM_CODE_END(tramp_vectors)
SYM_CODE_START(tramp_exit_native)
@@ -744,7 +775,7 @@ SYM_DATA_END(__entry_tramp_data_start)
* Exception vectors for spectre mitigations on entry from EL1 when
* kpti is not in use.
*/
- .macro generate_el1_vector
+ .macro generate_el1_vector, bhb
.Lvector_start\@:
kernel_ventry 1, t, 64, sync // Synchronous EL1t
kernel_ventry 1, t, 64, irq // IRQ EL1t
@@ -757,17 +788,21 @@ SYM_DATA_END(__entry_tramp_data_start)
kernel_ventry 1, h, 64, error // Error EL1h
.rept 4
- tramp_ventry .Lvector_start\@, 64, kpti=0
+ tramp_ventry .Lvector_start\@, 64, 0, \bhb
.endr
.rept 4
- tramp_ventry .Lvector_start\@, 32, kpti=0
+ tramp_ventry .Lvector_start\@, 32, 0, \bhb
.endr
.endm
+/* The order must match tramp_vecs and the arm64_bp_harden_el1_vectors enum. */
.pushsection ".entry.text", "ax"
.align 11
SYM_CODE_START(__bp_harden_el1_vectors)
- generate_el1_vector
+#ifdef CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY
+ generate_el1_vector bhb=BHB_MITIGATION_LOOP
+ generate_el1_vector bhb=BHB_MITIGATION_FW
+#endif /* CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY */
SYM_CODE_END(__bp_harden_el1_vectors)
.popsection
--- a/arch/arm64/kernel/proton-pack.c
+++ b/arch/arm64/kernel/proton-pack.c
@@ -770,3 +770,19 @@ int arch_prctl_spec_ctrl_get(struct task
return -ENODEV;
}
}
+
+/* Patched to NOP when enabled */
+void noinstr spectre_bhb_patch_loop_mitigation_enable(struct alt_instr *alt,
+ __le32 *origptr,
+ __le32 *updptr, int nr_inst)
+{
+ BUG_ON(nr_inst != 1);
+}
+
+/* Patched to NOP when enabled */
+void noinstr spectre_bhb_patch_fw_mitigation_enabled(struct alt_instr *alt,
+ __le32 *origptr,
+ __le32 *updptr, int nr_inst)
+{
+ BUG_ON(nr_inst != 1);
+}
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -92,6 +92,11 @@
ARM_SMCCC_SMC_32, \
0, 0x7fff)
+#define ARM_SMCCC_ARCH_WORKAROUND_3 \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ 0, 0x3fff)
+
#define ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID \
ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
ARM_SMCCC_SMC_32, \
Oops! Slipped away.
On 09/03/22 15:17, Daniel Díaz wrote:
> Hello!
>
> On 09/03/22 10:00, Greg Kroah-Hartman wrote:
>> This is the start of the stable review cycle for the 5.16.14 release.
>> There are 37 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 Fri, 11 Mar 2022 15:58:48 +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.16.14-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-5.16.y
>> and the diffstat can be found below.
>>
>> thanks,
>>
>> greg k-h
>
> Regressions found.
>
> The following Arm combinations failed to build:
> - arm-gcc-8-bcm2835_defconfig
> - arm-gcc-8-imx_v6_v7_defconfig
> - arm-gcc-8-omap2plus_defconfig
> - arm-gcc-9-bcm2835_defconfig
> - arm-gcc-9-imx_v6_v7_defconfig
> - arm-gcc-9-omap2plus_defconfig
> - arm-gcc-10-bcm2835_defconfig
> - arm-gcc-10-imx_v6_v7_defconfig
> - arm-gcc-10-omap2plus_defconfig
> - arm-gcc-11-bcm2835_defconfig
> - arm-gcc-11-imx_v6_v7_defconfig
> - arm-gcc-11-omap2plus_defconfig
> - arm-clang-11-allnoconfig
> - arm-clang-11-at91_dt_defconfig
> - arm-clang-11-axm55xx_defconfig
> - arm-clang-11-bcm2835_defconfig
> - arm-clang-11-clps711x_defconfig
> - arm-clang-11-davinci_all_defconfig
> - arm-clang-11-defconfig
> - arm-clang-11-exynos_defconfig
> - arm-clang-11-footbridge_defconfig
> - arm-clang-11-imx_v4_v5_defconfig
> - arm-clang-11-imx_v6_v7_defconfig
> - arm-clang-11-integrator_defconfig
> - arm-clang-11-ixp4xx_defconfig
> - arm-clang-11-keystone_defconfig
> - arm-clang-11-lpc32xx_defconfig
> - arm-clang-11-mini2440_defconfig
> - arm-clang-11-multi_v5_defconfig
> - arm-clang-11-mxs_defconfig
> - arm-clang-11-nhk8815_defconfig
> - arm-clang-11-omap1_defconfig
> - arm-clang-11-omap2plus_defconfig
> - arm-clang-11-orion5x_defconfig
> - arm-clang-11-pxa910_defconfig
> - arm-clang-11-s3c2410_defconfig
> - arm-clang-11-s3c6400_defconfig
> - arm-clang-11-s5pv210_defconfig
> - arm-clang-11-sama5_defconfig
> - arm-clang-11-shmobile_defconfig
> - arm-clang-11-tinyconfig
> - arm-clang-11-u8500_defconfig
> - arm-clang-11-vexpress_defconfig
> - arm-clang-12-allnoconfig
> - arm-clang-12-at91_dt_defconfig
> - arm-clang-12-axm55xx_defconfig
> - arm-clang-12-bcm2835_defconfig
> - arm-clang-12-clps711x_defconfig
> - arm-clang-12-davinci_all_defconfig
> - arm-clang-12-defconfig
> - arm-clang-12-exynos_defconfig
> - arm-clang-12-footbridge_defconfig
> - arm-clang-12-imx_v4_v5_defconfig
> - arm-clang-12-imx_v6_v7_defconfig
> - arm-clang-12-integrator_defconfig
> - arm-clang-12-ixp4xx_defconfig
> - arm-clang-12-keystone_defconfig
> - arm-clang-12-lpc32xx_defconfig
> - arm-clang-12-mini2440_defconfig
> - arm-clang-12-multi_v5_defconfig
> - arm-clang-12-mxs_defconfig
> - arm-clang-12-nhk8815_defconfig
> - arm-clang-12-omap1_defconfig
> - arm-clang-12-omap2plus_defconfig
> - arm-clang-12-orion5x_defconfig
> - arm-clang-12-pxa910_defconfig
> - arm-clang-12-s3c2410_defconfig
> - arm-clang-12-s3c6400_defconfig
> - arm-clang-12-s5pv210_defconfig
> - arm-clang-12-sama5_defconfig
> - arm-clang-12-shmobile_defconfig
> - arm-clang-12-tinyconfig
> - arm-clang-12-u8500_defconfig
> - arm-clang-12-vexpress_defconfig
> - arm-clang-13-allnoconfig
> - arm-clang-13-at91_dt_defconfig
> - arm-clang-13-axm55xx_defconfig
> - arm-clang-13-bcm2835_defconfig
> - arm-clang-13-clps711x_defconfig
> - arm-clang-13-davinci_all_defconfig
> - arm-clang-13-defconfig
> - arm-clang-13-exynos_defconfig
> - arm-clang-13-footbridge_defconfig
> - arm-clang-13-imx_v4_v5_defconfig
> - arm-clang-13-imx_v6_v7_defconfig
> - arm-clang-13-integrator_defconfig
> - arm-clang-13-ixp4xx_defconfig
> - arm-clang-13-keystone_defconfig
> - arm-clang-13-lpc32xx_defconfig
> - arm-clang-13-mini2440_defconfig
> - arm-clang-13-multi_v5_defconfig
> - arm-clang-13-mxs_defconfig
> - arm-clang-13-nhk8815_defconfig
> - arm-clang-13-omap1_defconfig
> - arm-clang-13-omap2plus_defconfig
> - arm-clang-13-orion5x_defconfig
> - arm-clang-13-pxa910_defconfig
> - arm-clang-13-s3c2410_defconfig
> - arm-clang-13-s3c6400_defconfig
> - arm-clang-13-s5pv210_defconfig
> - arm-clang-13-sama5_defconfig
> - arm-clang-13-shmobile_defconfig
> - arm-clang-13-tinyconfig
> - arm-clang-13-u8500_defconfig
> - arm-clang-13-vexpress_defconfig
> - arm-clang-14-allnoconfig
> - arm-clang-14-at91_dt_defconfig
> - arm-clang-14-axm55xx_defconfig
> - arm-clang-14-bcm2835_defconfig
> - arm-clang-14-clps711x_defconfig
> - arm-clang-14-davinci_all_defconfig
> - arm-clang-14-defconfig
> - arm-clang-14-exynos_defconfig
> - arm-clang-14-footbridge_defconfig
> - arm-clang-14-imx_v4_v5_defconfig
> - arm-clang-14-imx_v6_v7_defconfig
> - arm-clang-14-integrator_defconfig
> - arm-clang-14-ixp4xx_defconfig
> - arm-clang-14-keystone_defconfig
> - arm-clang-14-lpc32xx_defconfig
> - arm-clang-14-mini2440_defconfig
> - arm-clang-14-multi_v5_defconfig
> - arm-clang-14-mxs_defconfig
> - arm-clang-14-nhk8815_defconfig
> - arm-clang-14-omap1_defconfig
> - arm-clang-14-omap2plus_defconfig
> - arm-clang-14-orion5x_defconfig
> - arm-clang-14-pxa910_defconfig
> - arm-clang-14-s3c2410_defconfig
> - arm-clang-14-s3c6400_defconfig
> - arm-clang-14-s5pv210_defconfig
> - arm-clang-14-sama5_defconfig
> - arm-clang-14-shmobile_defconfig
> - arm-clang-14-tinyconfig
> - arm-clang-14-u8500_defconfig
> - arm-clang-14-vexpress_defconfig
> - arm-clang-nightly-allnoconfig
> - arm-clang-nightly-at91_dt_defconfig
> - arm-clang-nightly-axm55xx_defconfig
> - arm-clang-nightly-bcm2835_defconfig
> - arm-clang-nightly-clps711x_defconfig
> - arm-clang-nightly-davinci_all_defconfig
> - arm-clang-nightly-defconfig
> - arm-clang-nightly-exynos_defconfig
> - arm-clang-nightly-footbridge_defconfig
> - arm-clang-nightly-imx_v4_v5_defconfig
> - arm-clang-nightly-imx_v6_v7_defconfig
> - arm-clang-nightly-integrator_defconfig
> - arm-clang-nightly-ixp4xx_defconfig
> - arm-clang-nightly-keystone_defconfig
> - arm-clang-nightly-lpc32xx_defconfig
> - arm-clang-nightly-mini2440_defconfig
> - arm-clang-nightly-multi_v5_defconfig
> - arm-clang-nightly-mxs_defconfig
> - arm-clang-nightly-nhk8815_defconfig
> - arm-clang-nightly-omap1_defconfig
> - arm-clang-nightly-omap2plus_defconfig
> - arm-clang-nightly-orion5x_defconfig
> - arm-clang-nightly-pxa910_defconfig
> - arm-clang-nightly-s3c2410_defconfig
> - arm-clang-nightly-s3c6400_defconfig
> - arm-clang-nightly-s5pv210_defconfig
> - arm-clang-nightly-sama5_defconfig
> - arm-clang-nightly-shmobile_defconfig
> - arm-clang-nightly-tinyconfig
> - arm-clang-nightly-u8500_defconfig
> - arm-clang-nightly-vexpress_defconfig
>
> This is a GCC failure (bcm2835_defconfig with gcc-8):
>
> /builds/linux/arch/arm/kernel/entry-common.S: Assembler messages:
> /builds/linux/arch/arm/kernel/entry-common.S:166: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
> /builds/linux/arch/arm/kernel/entry-common.S:175: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
> make[3]: *** [/builds/linux/scripts/Makefile.build:388: arch/arm/kernel/entry-common.o] Error 1
> /builds/linux/arch/arm/kernel/entry-armv.S: Assembler messages:
> /builds/linux/arch/arm/kernel/entry-armv.S:1090: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
> /builds/linux/arch/arm/kernel/entry-armv.S:1113: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
> /builds/linux/arch/arm/kernel/entry-armv.S:1136: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
> /builds/linux/arch/arm/kernel/entry-armv.S:1159: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
> /builds/linux/arch/arm/kernel/entry-armv.S:1198: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
> make[3]: *** [/builds/linux/scripts/Makefile.build:388: arch/arm/kernel/entry-armv.o] Error 1
> /builds/linux/arch/arm/common/secure_cntvoff.S: Assembler messages:
> /builds/linux/arch/arm/common/secure_cntvoff.S:24: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
> /builds/linux/arch/arm/common/secure_cntvoff.S:27: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
> /builds/linux/arch/arm/common/secure_cntvoff.S:29: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
> make[3]: *** [/builds/linux/scripts/Makefile.build:388: arch/arm/common/secure_cntvoff.o] Error 1
> make[3]: Target '__build' not remade because of errors.
> make[2]: *** [/builds/linux/scripts/Makefile.build:549: arch/arm/common] Error 2
> /builds/linux/arch/arm/mm/cache-v7.S: Assembler messages:
> /builds/linux/arch/arm/mm/cache-v7.S:42: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
> /builds/linux/arch/arm/mm/cache-v7.S:69: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
> /builds/linux/arch/arm/mm/cache-v7.S:142: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
> /builds/linux/arch/arm/mm/cache-v7.S:179: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
> /builds/linux/arch/arm/mm/cache-v7.S:312: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
> make[3]: *** [/builds/linux/scripts/Makefile.build:388: arch/arm/mm/cache-v7.o] Error 1
> /builds/linux/arch/arm/mm/tlb-v7.S: Assembler messages:
> /builds/linux/arch/arm/mm/tlb-v7.S:85: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
> make[3]: *** [/builds/linux/scripts/Makefile.build:388: arch/arm/mm/tlb-v7.o] Error 1
> /builds/linux/arch/arm/mm/proc-v7-2level.S: Assembler messages:
> /builds/linux/arch/arm/mm/proc-v7-2level.S:55: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
> /builds/linux/arch/arm/mm/proc-v7-2level.S:57: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
> /builds/linux/arch/arm/mm/proc-v7.S:59: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
> make[3]: *** [/builds/linux/scripts/Makefile.build:388: arch/arm/mm/proc-v7.o] Error 1
> make[3]: Target '__build' not remade because of errors.
> make[2]: *** [/builds/linux/scripts/Makefile.build:549: arch/arm/mm] Error 2
>
>
> And this is a Clang failure (
axm55xx_defconfig with clang-12)
ld.lld: error: ./arch/arm/kernel/vmlinux.lds:123: AT expected, but got NOCROSSREFS
>>> __vectors_lma = .; OVERLAY 0xffff0000 : NOCROSSREFS AT(__vectors_lma) { .vectors { *(.vectors) } .vectors.bhb.loop8 { *(.vectors.bhb.loop8) } .vectors.bhb.bpiall { *(.vectors.bhb.bpiall) } } __vectors_start = LOADADDR(.vectors); __vectors_end = LOADADDR(.vectors) + SIZEOF(.vectors); __vectors_bhb_loop8_start = LOADADDR(.vectors.bhb.loop8); __vectors_bhb_loop8_end = LOADADDR(.vectors.bhb.loop8) + SIZEOF(.vectors.bhb.loop8); __vectors_bhb_bpiall_start = LOADADDR(.vectors.bhb.bpiall); __vectors_bhb_bpiall_end = LOADADDR(.vectors.bhb.bpiall) + SIZEOF(.vectors.bhb.bpiall); . = __vectors_lma + SIZEOF(.vectors) + SIZEOF(.vectors.bhb.loop8) + SIZEOF(.vectors.bhb.bpiall); __stubs_lma = .; .stubs ADDR(.vectors) + 0x1000 : AT(__stubs_lma) { *(.stubs) } __stubs_start = LOADADDR(.stubs); __stubs_end = LOADADDR(.stubs) + SIZEOF(.stubs); . = __stubs_lma + SIZEOF(.stubs); PROVIDE(vector_fiq_offset = vector_fiq - ADDR(.vectors));
>>> ^
make[1]: *** [/builds/linux/Makefile:1161: vmlinux] Error 1
Greetings!
Daniel Díaz
[email protected]
Hello!
On 09/03/22 10:00, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.16.14 release.
> There are 37 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 Fri, 11 Mar 2022 15:58:48 +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.16.14-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-5.16.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Regressions found.
The following Arm combinations failed to build:
- arm-gcc-8-bcm2835_defconfig
- arm-gcc-8-imx_v6_v7_defconfig
- arm-gcc-8-omap2plus_defconfig
- arm-gcc-9-bcm2835_defconfig
- arm-gcc-9-imx_v6_v7_defconfig
- arm-gcc-9-omap2plus_defconfig
- arm-gcc-10-bcm2835_defconfig
- arm-gcc-10-imx_v6_v7_defconfig
- arm-gcc-10-omap2plus_defconfig
- arm-gcc-11-bcm2835_defconfig
- arm-gcc-11-imx_v6_v7_defconfig
- arm-gcc-11-omap2plus_defconfig
- arm-clang-11-allnoconfig
- arm-clang-11-at91_dt_defconfig
- arm-clang-11-axm55xx_defconfig
- arm-clang-11-bcm2835_defconfig
- arm-clang-11-clps711x_defconfig
- arm-clang-11-davinci_all_defconfig
- arm-clang-11-defconfig
- arm-clang-11-exynos_defconfig
- arm-clang-11-footbridge_defconfig
- arm-clang-11-imx_v4_v5_defconfig
- arm-clang-11-imx_v6_v7_defconfig
- arm-clang-11-integrator_defconfig
- arm-clang-11-ixp4xx_defconfig
- arm-clang-11-keystone_defconfig
- arm-clang-11-lpc32xx_defconfig
- arm-clang-11-mini2440_defconfig
- arm-clang-11-multi_v5_defconfig
- arm-clang-11-mxs_defconfig
- arm-clang-11-nhk8815_defconfig
- arm-clang-11-omap1_defconfig
- arm-clang-11-omap2plus_defconfig
- arm-clang-11-orion5x_defconfig
- arm-clang-11-pxa910_defconfig
- arm-clang-11-s3c2410_defconfig
- arm-clang-11-s3c6400_defconfig
- arm-clang-11-s5pv210_defconfig
- arm-clang-11-sama5_defconfig
- arm-clang-11-shmobile_defconfig
- arm-clang-11-tinyconfig
- arm-clang-11-u8500_defconfig
- arm-clang-11-vexpress_defconfig
- arm-clang-12-allnoconfig
- arm-clang-12-at91_dt_defconfig
- arm-clang-12-axm55xx_defconfig
- arm-clang-12-bcm2835_defconfig
- arm-clang-12-clps711x_defconfig
- arm-clang-12-davinci_all_defconfig
- arm-clang-12-defconfig
- arm-clang-12-exynos_defconfig
- arm-clang-12-footbridge_defconfig
- arm-clang-12-imx_v4_v5_defconfig
- arm-clang-12-imx_v6_v7_defconfig
- arm-clang-12-integrator_defconfig
- arm-clang-12-ixp4xx_defconfig
- arm-clang-12-keystone_defconfig
- arm-clang-12-lpc32xx_defconfig
- arm-clang-12-mini2440_defconfig
- arm-clang-12-multi_v5_defconfig
- arm-clang-12-mxs_defconfig
- arm-clang-12-nhk8815_defconfig
- arm-clang-12-omap1_defconfig
- arm-clang-12-omap2plus_defconfig
- arm-clang-12-orion5x_defconfig
- arm-clang-12-pxa910_defconfig
- arm-clang-12-s3c2410_defconfig
- arm-clang-12-s3c6400_defconfig
- arm-clang-12-s5pv210_defconfig
- arm-clang-12-sama5_defconfig
- arm-clang-12-shmobile_defconfig
- arm-clang-12-tinyconfig
- arm-clang-12-u8500_defconfig
- arm-clang-12-vexpress_defconfig
- arm-clang-13-allnoconfig
- arm-clang-13-at91_dt_defconfig
- arm-clang-13-axm55xx_defconfig
- arm-clang-13-bcm2835_defconfig
- arm-clang-13-clps711x_defconfig
- arm-clang-13-davinci_all_defconfig
- arm-clang-13-defconfig
- arm-clang-13-exynos_defconfig
- arm-clang-13-footbridge_defconfig
- arm-clang-13-imx_v4_v5_defconfig
- arm-clang-13-imx_v6_v7_defconfig
- arm-clang-13-integrator_defconfig
- arm-clang-13-ixp4xx_defconfig
- arm-clang-13-keystone_defconfig
- arm-clang-13-lpc32xx_defconfig
- arm-clang-13-mini2440_defconfig
- arm-clang-13-multi_v5_defconfig
- arm-clang-13-mxs_defconfig
- arm-clang-13-nhk8815_defconfig
- arm-clang-13-omap1_defconfig
- arm-clang-13-omap2plus_defconfig
- arm-clang-13-orion5x_defconfig
- arm-clang-13-pxa910_defconfig
- arm-clang-13-s3c2410_defconfig
- arm-clang-13-s3c6400_defconfig
- arm-clang-13-s5pv210_defconfig
- arm-clang-13-sama5_defconfig
- arm-clang-13-shmobile_defconfig
- arm-clang-13-tinyconfig
- arm-clang-13-u8500_defconfig
- arm-clang-13-vexpress_defconfig
- arm-clang-14-allnoconfig
- arm-clang-14-at91_dt_defconfig
- arm-clang-14-axm55xx_defconfig
- arm-clang-14-bcm2835_defconfig
- arm-clang-14-clps711x_defconfig
- arm-clang-14-davinci_all_defconfig
- arm-clang-14-defconfig
- arm-clang-14-exynos_defconfig
- arm-clang-14-footbridge_defconfig
- arm-clang-14-imx_v4_v5_defconfig
- arm-clang-14-imx_v6_v7_defconfig
- arm-clang-14-integrator_defconfig
- arm-clang-14-ixp4xx_defconfig
- arm-clang-14-keystone_defconfig
- arm-clang-14-lpc32xx_defconfig
- arm-clang-14-mini2440_defconfig
- arm-clang-14-multi_v5_defconfig
- arm-clang-14-mxs_defconfig
- arm-clang-14-nhk8815_defconfig
- arm-clang-14-omap1_defconfig
- arm-clang-14-omap2plus_defconfig
- arm-clang-14-orion5x_defconfig
- arm-clang-14-pxa910_defconfig
- arm-clang-14-s3c2410_defconfig
- arm-clang-14-s3c6400_defconfig
- arm-clang-14-s5pv210_defconfig
- arm-clang-14-sama5_defconfig
- arm-clang-14-shmobile_defconfig
- arm-clang-14-tinyconfig
- arm-clang-14-u8500_defconfig
- arm-clang-14-vexpress_defconfig
- arm-clang-nightly-allnoconfig
- arm-clang-nightly-at91_dt_defconfig
- arm-clang-nightly-axm55xx_defconfig
- arm-clang-nightly-bcm2835_defconfig
- arm-clang-nightly-clps711x_defconfig
- arm-clang-nightly-davinci_all_defconfig
- arm-clang-nightly-defconfig
- arm-clang-nightly-exynos_defconfig
- arm-clang-nightly-footbridge_defconfig
- arm-clang-nightly-imx_v4_v5_defconfig
- arm-clang-nightly-imx_v6_v7_defconfig
- arm-clang-nightly-integrator_defconfig
- arm-clang-nightly-ixp4xx_defconfig
- arm-clang-nightly-keystone_defconfig
- arm-clang-nightly-lpc32xx_defconfig
- arm-clang-nightly-mini2440_defconfig
- arm-clang-nightly-multi_v5_defconfig
- arm-clang-nightly-mxs_defconfig
- arm-clang-nightly-nhk8815_defconfig
- arm-clang-nightly-omap1_defconfig
- arm-clang-nightly-omap2plus_defconfig
- arm-clang-nightly-orion5x_defconfig
- arm-clang-nightly-pxa910_defconfig
- arm-clang-nightly-s3c2410_defconfig
- arm-clang-nightly-s3c6400_defconfig
- arm-clang-nightly-s5pv210_defconfig
- arm-clang-nightly-sama5_defconfig
- arm-clang-nightly-shmobile_defconfig
- arm-clang-nightly-tinyconfig
- arm-clang-nightly-u8500_defconfig
- arm-clang-nightly-vexpress_defconfig
This is a GCC failure (bcm2835_defconfig with gcc-8):
/builds/linux/arch/arm/kernel/entry-common.S: Assembler messages:
/builds/linux/arch/arm/kernel/entry-common.S:166: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
/builds/linux/arch/arm/kernel/entry-common.S:175: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
make[3]: *** [/builds/linux/scripts/Makefile.build:388: arch/arm/kernel/entry-common.o] Error 1
/builds/linux/arch/arm/kernel/entry-armv.S: Assembler messages:
/builds/linux/arch/arm/kernel/entry-armv.S:1090: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
/builds/linux/arch/arm/kernel/entry-armv.S:1113: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
/builds/linux/arch/arm/kernel/entry-armv.S:1136: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
/builds/linux/arch/arm/kernel/entry-armv.S:1159: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
/builds/linux/arch/arm/kernel/entry-armv.S:1198: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
make[3]: *** [/builds/linux/scripts/Makefile.build:388: arch/arm/kernel/entry-armv.o] Error 1
/builds/linux/arch/arm/common/secure_cntvoff.S: Assembler messages:
/builds/linux/arch/arm/common/secure_cntvoff.S:24: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
/builds/linux/arch/arm/common/secure_cntvoff.S:27: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
/builds/linux/arch/arm/common/secure_cntvoff.S:29: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
make[3]: *** [/builds/linux/scripts/Makefile.build:388: arch/arm/common/secure_cntvoff.o] Error 1
make[3]: Target '__build' not remade because of errors.
make[2]: *** [/builds/linux/scripts/Makefile.build:549: arch/arm/common] Error 2
/builds/linux/arch/arm/mm/cache-v7.S: Assembler messages:
/builds/linux/arch/arm/mm/cache-v7.S:42: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
/builds/linux/arch/arm/mm/cache-v7.S:69: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
/builds/linux/arch/arm/mm/cache-v7.S:142: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
/builds/linux/arch/arm/mm/cache-v7.S:179: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
/builds/linux/arch/arm/mm/cache-v7.S:312: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
make[3]: *** [/builds/linux/scripts/Makefile.build:388: arch/arm/mm/cache-v7.o] Error 1
/builds/linux/arch/arm/mm/tlb-v7.S: Assembler messages:
/builds/linux/arch/arm/mm/tlb-v7.S:85: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
make[3]: *** [/builds/linux/scripts/Makefile.build:388: arch/arm/mm/tlb-v7.o] Error 1
/builds/linux/arch/arm/mm/proc-v7-2level.S: Assembler messages:
/builds/linux/arch/arm/mm/proc-v7-2level.S:55: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
/builds/linux/arch/arm/mm/proc-v7-2level.S:57: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
/builds/linux/arch/arm/mm/proc-v7.S:59: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
make[3]: *** [/builds/linux/scripts/Makefile.build:388: arch/arm/mm/proc-v7.o] Error 1
make[3]: Target '__build' not remade because of errors.
make[2]: *** [/builds/linux/scripts/Makefile.build:549: arch/arm/mm] Error 2
And this is a Clang failure (
On Wed, 9 Mar 2022 17:00:01 +0100, Greg Kroah-Hartman <[email protected]> wrote:
> This is the start of the stable review cycle for the 5.16.14 release.
> There are 37 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 Fri, 11 Mar 2022 15:58:48 +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.16.14-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-5.16.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
5.16.14-rc1 Successfully Compiled and booted on my Raspberry PI 4b (8g) (bcm2711)
Tested-by: Fox Chen <[email protected]>
On Wed, Mar 09, 2022 at 09:01:48PM +0100, Greg Kroah-Hartman wrote:
> On Wed, Mar 09, 2022 at 11:05:15AM -0800, Guenter Roeck wrote:
> > On 3/9/22 08:00, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 5.16.14 release.
> > > There are 37 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 Fri, 11 Mar 2022 15:58:48 +0000.
> > > Anything received after that time might be too late.
> > >
> >
> > Almost all arm builds, all branches from 4.9.y to 5.16.y:
> >
> > Error log:
> > arch/arm/common/secure_cntvoff.S: Assembler messages:
> > arch/arm/common/secure_cntvoff.S:24: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
> > arch/arm/common/secure_cntvoff.S:27: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
> > arch/arm/common/secure_cntvoff.S:29: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
> >
> > bisect log:
> >
> > # bad: [3416254dac79ea26e08dffde371ab1fd3130223c] Linux 5.16.14-rc1
> > # good: [6273c309621c9dd61c9c3f6d63f5d56ee2d89c73] Linux 5.16.13
> > git bisect start 'HEAD' 'v5.16.13'
> > # bad: [4403d69931dbc17659845d2d710602bbe35b4398] KVM: arm64: Allow indirect vectors to be used without SPECTRE_V3A
> > git bisect bad 4403d69931dbc17659845d2d710602bbe35b4398
> > # good: [6f0cf3a1eb8b46a5d652a395ba25a59c32a86692] ARM: report Spectre v2 status through sysfs
> > git bisect good 6f0cf3a1eb8b46a5d652a395ba25a59c32a86692
> > # bad: [87e96a363eb4a62b65bb974a46d518a87153cd1c] arm64: add ID_AA64ISAR2_EL1 sys register
> > git bisect bad 87e96a363eb4a62b65bb974a46d518a87153cd1c
> > # good: [654f0a73f042662a36155a0cafa30db846ccb5a9] ARM: use LOADADDR() to get load address of sections
> > git bisect good 654f0a73f042662a36155a0cafa30db846ccb5a9
> > # bad: [91bdae56c40ee6de675fba6ac283311c92c437ce] ARM: include unprivileged BPF status in Spectre V2 reporting
> > git bisect bad 91bdae56c40ee6de675fba6ac283311c92c437ce
> > # bad: [95ff4cb3b696a581d6166f0d754771bf9af5e27b] ARM: Spectre-BHB workaround
> > git bisect bad 95ff4cb3b696a581d6166f0d754771bf9af5e27b
> > # first bad commit: [95ff4cb3b696a581d6166f0d754771bf9af5e27b] ARM: Spectre-BHB workaround
> >
> > Guenter
>
> Wow these are all broken, have I mentioned I hate working on patches in
> embargos?
>
> I'll look at these in the morning, it's odd that Linus's tree isn't
> showing these same issue, but I might have messed up the arm backports
> somehow. I did test them on using the multi_v7_defconfig configuration
> and they built for me locally with gcc. I'll try to see what is
> different here...
Ah, 33970b031dc4 ("ARM: fix co-processor register typo") looks to solve
a bunch of these, I'll queue that up now...
On Wed, Mar 09, 2022 at 11:05:15AM -0800, Guenter Roeck wrote:
> On 3/9/22 08:00, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.16.14 release.
> > There are 37 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 Fri, 11 Mar 2022 15:58:48 +0000.
> > Anything received after that time might be too late.
> >
>
> Almost all arm builds, all branches from 4.9.y to 5.16.y:
>
> Error log:
> arch/arm/common/secure_cntvoff.S: Assembler messages:
> arch/arm/common/secure_cntvoff.S:24: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
> arch/arm/common/secure_cntvoff.S:27: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
> arch/arm/common/secure_cntvoff.S:29: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
>
> bisect log:
>
> # bad: [3416254dac79ea26e08dffde371ab1fd3130223c] Linux 5.16.14-rc1
> # good: [6273c309621c9dd61c9c3f6d63f5d56ee2d89c73] Linux 5.16.13
> git bisect start 'HEAD' 'v5.16.13'
> # bad: [4403d69931dbc17659845d2d710602bbe35b4398] KVM: arm64: Allow indirect vectors to be used without SPECTRE_V3A
> git bisect bad 4403d69931dbc17659845d2d710602bbe35b4398
> # good: [6f0cf3a1eb8b46a5d652a395ba25a59c32a86692] ARM: report Spectre v2 status through sysfs
> git bisect good 6f0cf3a1eb8b46a5d652a395ba25a59c32a86692
> # bad: [87e96a363eb4a62b65bb974a46d518a87153cd1c] arm64: add ID_AA64ISAR2_EL1 sys register
> git bisect bad 87e96a363eb4a62b65bb974a46d518a87153cd1c
> # good: [654f0a73f042662a36155a0cafa30db846ccb5a9] ARM: use LOADADDR() to get load address of sections
> git bisect good 654f0a73f042662a36155a0cafa30db846ccb5a9
> # bad: [91bdae56c40ee6de675fba6ac283311c92c437ce] ARM: include unprivileged BPF status in Spectre V2 reporting
> git bisect bad 91bdae56c40ee6de675fba6ac283311c92c437ce
> # bad: [95ff4cb3b696a581d6166f0d754771bf9af5e27b] ARM: Spectre-BHB workaround
> git bisect bad 95ff4cb3b696a581d6166f0d754771bf9af5e27b
> # first bad commit: [95ff4cb3b696a581d6166f0d754771bf9af5e27b] ARM: Spectre-BHB workaround
>
> Guenter
Wow these are all broken, have I mentioned I hate working on patches in
embargos?
I'll look at these in the morning, it's odd that Linus's tree isn't
showing these same issue, but I might have messed up the arm backports
somehow. I did test them on using the multi_v7_defconfig configuration
and they built for me locally with gcc. I'll try to see what is
different here...
thanks,
greg k-h
On 3/9/22 08:00, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.16.14 release.
> There are 37 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 Fri, 11 Mar 2022 15:58:48 +0000.
> Anything received after that time might be too late.
>
Almost all arm builds, all branches from 4.9.y to 5.16.y:
Error log:
arch/arm/common/secure_cntvoff.S: Assembler messages:
arch/arm/common/secure_cntvoff.S:24: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
arch/arm/common/secure_cntvoff.S:27: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
arch/arm/common/secure_cntvoff.S:29: Error: co-processor register expected -- `mcr p15,0,r0,c7,r5,4'
bisect log:
# bad: [3416254dac79ea26e08dffde371ab1fd3130223c] Linux 5.16.14-rc1
# good: [6273c309621c9dd61c9c3f6d63f5d56ee2d89c73] Linux 5.16.13
git bisect start 'HEAD' 'v5.16.13'
# bad: [4403d69931dbc17659845d2d710602bbe35b4398] KVM: arm64: Allow indirect vectors to be used without SPECTRE_V3A
git bisect bad 4403d69931dbc17659845d2d710602bbe35b4398
# good: [6f0cf3a1eb8b46a5d652a395ba25a59c32a86692] ARM: report Spectre v2 status through sysfs
git bisect good 6f0cf3a1eb8b46a5d652a395ba25a59c32a86692
# bad: [87e96a363eb4a62b65bb974a46d518a87153cd1c] arm64: add ID_AA64ISAR2_EL1 sys register
git bisect bad 87e96a363eb4a62b65bb974a46d518a87153cd1c
# good: [654f0a73f042662a36155a0cafa30db846ccb5a9] ARM: use LOADADDR() to get load address of sections
git bisect good 654f0a73f042662a36155a0cafa30db846ccb5a9
# bad: [91bdae56c40ee6de675fba6ac283311c92c437ce] ARM: include unprivileged BPF status in Spectre V2 reporting
git bisect bad 91bdae56c40ee6de675fba6ac283311c92c437ce
# bad: [95ff4cb3b696a581d6166f0d754771bf9af5e27b] ARM: Spectre-BHB workaround
git bisect bad 95ff4cb3b696a581d6166f0d754771bf9af5e27b
# first bad commit: [95ff4cb3b696a581d6166f0d754771bf9af5e27b] ARM: Spectre-BHB workaround
Guenter
On 09/03/22 23.00, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.16.14 release.
> There are 37 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
On 3/9/22 9:00 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.16.14 release.
> There are 37 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 Fri, 11 Mar 2022 15:58:48 +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.16.14-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-5.16.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan <[email protected]>
thanks,
-- Shuah
Hi!
> From: James Morse <[email protected]>
>
> commit ba2689234be92024e5635d30fe744f4853ad97db upstream.
>
> Some CPUs affected by Spectre-BHB need a sequence of branches, or a
> firmware call to be run before any indirect branch. This needs to go
> in the vectors. No CPU needs both.
>
> While this can be patched in, it would run on all CPUs as there is a
> single set of vectors. If only one part of a big/little combination is
> affected, the unaffected CPUs have to run the mitigation too.
This adds build error. Same problem is in 5.10.
> --- /dev/null
> +++ b/arch/arm64/include/asm/vectors.h
> @@ -0,0 +1,34 @@
...
> +/*
> + * Note: the order of this enum corresponds to two arrays in entry.S:
> + * tramp_vecs and __bp_harden_el1_vectors. By default the canonical
> + * 'full fat' vectors are used directly.
> + */
> +enum arm64_bp_harden_el1_vectors {
> +#ifdef CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY
> + /*
> + * Perform the BHB loop mitigation, before branching to the canonical
> + * vectors.
> + */
> + EL1_VECTOR_BHB_LOOP,
> +
> + /*
> + * Make the SMC call for firmware mitigation, before branching to the
> + * canonical vectors.
> + */
> + EL1_VECTOR_BHB_FW,
> +#endif /* CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY */
> +
> + /*
> + * Remap the kernel before branching to the canonical vectors.
> + */
> + EL1_VECTOR_KPTI,
> ++};
> +
Note "++". Following patch fixes this up, but it is still a trap for
people trying to bisect.
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
On Fri, Mar 11, 2022 at 09:15:32AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Mar 11, 2022 at 12:27:29AM +0100, Pavel Machek wrote:
> > Hi!
> >
> > > From: James Morse <[email protected]>
> > >
> > > commit ba2689234be92024e5635d30fe744f4853ad97db upstream.
> > >
> > > Some CPUs affected by Spectre-BHB need a sequence of branches, or a
> > > firmware call to be run before any indirect branch. This needs to go
> > > in the vectors. No CPU needs both.
> > >
> > > While this can be patched in, it would run on all CPUs as there is a
> > > single set of vectors. If only one part of a big/little combination is
> > > affected, the unaffected CPUs have to run the mitigation too.
> >
> > This adds build error. Same problem is in 5.10.
> >
> > > --- /dev/null
> > > +++ b/arch/arm64/include/asm/vectors.h
> > > @@ -0,0 +1,34 @@
> > ...
> > > +/*
> > > + * Note: the order of this enum corresponds to two arrays in entry.S:
> > > + * tramp_vecs and __bp_harden_el1_vectors. By default the canonical
> > > + * 'full fat' vectors are used directly.
> > > + */
> > > +enum arm64_bp_harden_el1_vectors {
> > > +#ifdef CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY
> > > + /*
> > > + * Perform the BHB loop mitigation, before branching to the canonical
> > > + * vectors.
> > > + */
> > > + EL1_VECTOR_BHB_LOOP,
> > > +
> > > + /*
> > > + * Make the SMC call for firmware mitigation, before branching to the
> > > + * canonical vectors.
> > > + */
> > > + EL1_VECTOR_BHB_FW,
> > > +#endif /* CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY */
> > > +
> > > + /*
> > > + * Remap the kernel before branching to the canonical vectors.
> > > + */
> > > + EL1_VECTOR_KPTI,
> > > ++};
> > > +
> >
> >
> > Note "++". Following patch fixes this up, but it is still a trap for
> > people trying to bisect.
>
> Ick, ok, will try to fix up, thanks for finding this.
Now fixed up for 5.16.y, 5.15.y, and 5.10.y, thanks.
greg k-h
On Fri, Mar 11, 2022 at 12:27:29AM +0100, Pavel Machek wrote:
> Hi!
>
> > From: James Morse <[email protected]>
> >
> > commit ba2689234be92024e5635d30fe744f4853ad97db upstream.
> >
> > Some CPUs affected by Spectre-BHB need a sequence of branches, or a
> > firmware call to be run before any indirect branch. This needs to go
> > in the vectors. No CPU needs both.
> >
> > While this can be patched in, it would run on all CPUs as there is a
> > single set of vectors. If only one part of a big/little combination is
> > affected, the unaffected CPUs have to run the mitigation too.
>
> This adds build error. Same problem is in 5.10.
>
> > --- /dev/null
> > +++ b/arch/arm64/include/asm/vectors.h
> > @@ -0,0 +1,34 @@
> ...
> > +/*
> > + * Note: the order of this enum corresponds to two arrays in entry.S:
> > + * tramp_vecs and __bp_harden_el1_vectors. By default the canonical
> > + * 'full fat' vectors are used directly.
> > + */
> > +enum arm64_bp_harden_el1_vectors {
> > +#ifdef CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY
> > + /*
> > + * Perform the BHB loop mitigation, before branching to the canonical
> > + * vectors.
> > + */
> > + EL1_VECTOR_BHB_LOOP,
> > +
> > + /*
> > + * Make the SMC call for firmware mitigation, before branching to the
> > + * canonical vectors.
> > + */
> > + EL1_VECTOR_BHB_FW,
> > +#endif /* CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY */
> > +
> > + /*
> > + * Remap the kernel before branching to the canonical vectors.
> > + */
> > + EL1_VECTOR_KPTI,
> > ++};
> > +
>
>
> Note "++". Following patch fixes this up, but it is still a trap for
> people trying to bisect.
Ick, ok, will try to fix up, thanks for finding this.
greg k-h