linux-stable.git/arch/arm64/kernel, branch linux-4.9.y

arm64: errata: Fix KVM Spectre-v2 mitigation selection for Cortex-A57/A72

2022-12-08T10:15:41+00:00

Both the Spectre-v2 and Spectre-BHB mitigations involve running a sequence
immediately after exiting a guest, before any branches. In the stable
kernels these sequences are built by copying templates into an empty vector
slot.

For Spectre-BHB, Cortex-A57 and A72 require the branchy loop with k=8.
If Spectre-v2 needs mitigating at the same time, a firmware call to EL3 is
needed. The work EL3 does at this point is also enough to mitigate
Spectre-BHB.

When enabling the Spectre-BHB mitigation, spectre_bhb_enable_mitigation()
should check if a slot has already been allocated for Spectre-v2, meaning
no work is needed for Spectre-BHB.

This check was missed in the earlier backport, add it.

Fixes: 4dd8aae585a5 ("arm64: Mitigate spectre style branch history side channels")
Signed-off-by: James Morse 
Signed-off-by: Greg Kroah-Hartman

arm64: Fix panic() when Spectre-v2 causes Spectre-BHB to re-allocate KVM vectors

2022-12-08T10:15:41+00:00

Sami reports that linux panic()s when resuming from suspend to RAM. This
is because when CPUs are brought back online, they re-enable any
necessary mitigations.

The Spectre-v2 and Spectre-BHB mitigations interact as both need to
done by KVM when exiting a guest. Slots KVM can use as vectors are
allocated, and templates for the mitigation are patched into the vector.

This fails if a new slot needs to be allocated once the kernel has finished
booting as it is no-longer possible to modify KVM's vectors:
| root@adam:/sys/devices/system/cpu/cpu1# echo 1 > online
| Unable to handle kernel write to read-only memory at virtual add>
| Mem abort info:
|   ESR = 0x9600004e
|   Exception class = DABT (current EL), IL = 32 bits
|   SET = 0, FnV = 0
|   EA = 0, S1PTW = 0
| Data abort info:
|   ISV = 0, ISS = 0x0000004e
|   CM = 0, WnR = 1
| swapper pgtable: 4k pages, 48-bit VAs, pgdp = 000000000f07a71c
| [ffff800000b4b800] pgd=00000009ffff8803, pud=00000009ffff7803, p>
| Internal error: Oops: 9600004e [#1] PREEMPT SMP
| Modules linked in:
| Process swapper/1 (pid: 0, stack limit = 0x0000000063153c53)
| CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.19.252-dirty #14
| Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno De>
| pstate: 000001c5 (nzcv dAIF -PAN -UAO)
| pc : __memcpy+0x48/0x180
| lr : __copy_hyp_vect_bpi+0x64/0x90

| Call trace:
|  __memcpy+0x48/0x180
|  kvm_setup_bhb_slot+0x204/0x2a8
|  spectre_bhb_enable_mitigation+0x1b8/0x1d0
|  __verify_local_cpu_caps+0x54/0xf0
|  check_local_cpu_capabilities+0xc4/0x184
|  secondary_start_kernel+0xb0/0x170
| Code: b8404423 b80044c3 36180064 f8408423 (f80084c3)
| ---[ end trace 859bcacb09555348 ]---
| Kernel panic - not syncing: Attempted to kill the idle task!
| SMP: stopping secondary CPUs
| Kernel Offset: disabled
| CPU features: 0x10,25806086
| Memory Limit: none
| ---[ end Kernel panic - not syncing: Attempted to kill the idle ]

This is only a problem on platforms where there is only one CPU that is
vulnerable to both Spectre-v2 and Spectre-BHB.

The Spectre-v2 mitigation identifies the slot it can re-use by the CPU's
'fn'. It unconditionally writes the slot number and 'template_start'
pointer. The Spectre-BHB mitigation identifies slots it can re-use by
the CPU's template_start pointer, which was previously clobbered by the
Spectre-v2 mitigation.

When there is only one CPU that is vulnerable to both issues, this causes
Spectre-v2 to try to allocate a new slot, which fails.

Change both mitigations to check whether they are changing the slot this
CPU uses before writing the percpu variables again.

This issue only exists in the stable backports for Spectre-BHB which have
to use totally different infrastructure to mainline.

Reported-by: Sami Lee 
Fixes: 4dd8aae585a5 ("arm64: Mitigate spectre style branch history side channels")
Signed-off-by: James Morse 
Signed-off-by: Greg Kroah-Hartman

arm64: errata: Remove AES hwcap for COMPAT tasks

2022-11-03T14:49:15+00:00

commit 44b3834b2eed595af07021b1c64e6f9bc396398b upstream.

Cortex-A57 and Cortex-A72 have an erratum where an interrupt that
occurs between a pair of AES instructions in aarch32 mode may corrupt
the ELR. The task will subsequently produce the wrong AES result.

The AES instructions are part of the cryptographic extensions, which are
optional. User-space software will detect the support for these
instructions from the hwcaps. If the platform doesn't support these
instructions a software implementation should be used.

Remove the hwcap bits on affected parts to indicate user-space should
not use the AES instructions.

Acked-by: Ard Biesheuvel 
Signed-off-by: James Morse 
Link: https://lore.kernel.org/r/20220714161523.279570-3-james.morse@arm.com
Signed-off-by: Will Deacon 
[florian: resolved conflicts in arch/arm64/tools/cpucaps and cpu_errata.c]
Signed-off-by: Florian Fainelli 
Signed-off-by: Greg Kroah-Hartman

arm64: map FDT as RW for early_init_dt_scan()

2022-09-05T08:23:57+00:00

commit e112b032a72c78f15d0c803c5dc6be444c2e6c66 upstream.

Currently in arm64, FDT is mapped to RO before it's passed to
early_init_dt_scan(). However, there might be some codes
(eg. commit "fdt: add support for rng-seed") that need to modify FDT
during init. Map FDT to RO after early fixups are done.

Signed-off-by: Hsin-Yi Wang 
Reviewed-by: Stephen Boyd 
Reviewed-by: Mike Rapoport 
Signed-off-by: Will Deacon 
[mkbestas: fixed trivial conflicts for 4.9 backport]
Signed-off-by: Michael Bestas 
Signed-off-by: Greg Kroah-Hartman

arm64: entry: Restore tramp_map_kernel ISB

2022-07-21T18:40:30+00:00

Summit reports that the BHB backports for v4.9 prevent vulnerable
platforms from booting when CONFIG_RANDOMIZE_BASE is enabled.

This is because the trampoline code takes a translation fault when
accessing the data page, because the TTBR write hasn't been completed
by an ISB before the access is made.

Upstream has a complex erratum workaround for QCOM_FALKOR_E1003 in
this area, which removes the ISB when the workaround has been applied.
v4.9 lacks this workaround, but should still have the ISB.

Restore the barrier.

Fixes: aee10c2dd013 ("arm64: entry: Add macro for reading symbol addresses from the trampoline")
Reported-by: Sumit Gupta 
Tested-by: Sumit Gupta 
Cc: 
Signed-off-by: James Morse 
Signed-off-by: Greg Kroah-Hartman

arm64: module: remove (NOLOAD) from linker script

2022-04-20T07:06:44+00:00

commit 4013e26670c590944abdab56c4fa797527b74325 upstream.

On ELF, (NOLOAD) sets the section type to SHT_NOBITS[1]. It is conceptually
inappropriate for .plt and .text.* sections which are always
SHT_PROGBITS.

In GNU ld, if PLT entries are needed, .plt will be SHT_PROGBITS anyway
and (NOLOAD) will be essentially ignored. In ld.lld, since
https://reviews.llvm.org/D118840 ("[ELF] Support (TYPE=) to
customize the output section type"), ld.lld will report a `section type
mismatch` error. Just remove (NOLOAD) to fix the error.

[1] https://lld.llvm.org/ELF/linker_script.html As of today, "The
section should be marked as not loadable" on
https://sourceware.org/binutils/docs/ld/Output-Section-Type.html is
outdated for ELF.

Tested-by: Nathan Chancellor 
Reported-by: Nathan Chancellor 
Signed-off-by: Fangrui Song 
Acked-by: Ard Biesheuvel 
Link: https://lore.kernel.org/r/20220218081209.354383-1-maskray@google.com
Signed-off-by: Will Deacon 
[nathan: Fix conflicts due to lack of 596b0474d3d9, be0f272bfc83, and 24af6c4e4e0f]
Signed-off-by: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman

arm64: patch_text: Fixup last cpu should be master

2022-04-20T07:06:44+00:00

commit 31a099dbd91e69fcab55eef4be15ed7a8c984918 upstream.

These patch_text implementations are using stop_machine_cpuslocked
infrastructure with atomic cpu_count. The original idea: When the
master CPU patch_text, the others should wait for it. But current
implementation is using the first CPU as master, which couldn't
guarantee the remaining CPUs are waiting. This patch changes the
last CPU as the master to solve the potential risk.

Fixes: ae16480785de ("arm64: introduce interfaces to hotpatch kernel and module code")
Signed-off-by: Guo Ren 
Signed-off-by: Guo Ren 
Reviewed-by: Catalin Marinas 
Reviewed-by: Masami Hiramatsu 
Cc: 
Link: https://lore.kernel.org/r/20220407073323.743224-2-guoren@kernel.org
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

arm64: Use the clearbhb instruction in mitigations

2022-04-12T05:52:17+00:00

commit 228a26b912287934789023b4132ba76065d9491c upstream.

Future CPUs may implement a clearbhb instruction that is sufficient
to mitigate SpectreBHB. CPUs that implement this instruction, but
not CSV2.3 must be affected by Spectre-BHB.

Add support to use this instruction as the BHB mitigation on CPUs
that support it. The instruction is in the hint space, so it will
be treated by a NOP as older CPUs.

Reviewed-by: Russell King (Oracle) 
Reviewed-by: Catalin Marinas 
[ modified for stable: Use a KVM vector template instead of alternatives ]
Signed-off-by: James Morse 
Signed-off-by: Greg Kroah-Hartman

arm64: add ID_AA64ISAR2_EL1 sys register

2022-04-12T05:52:17+00:00

commit 9e45365f1469ef2b934f9d035975dbc9ad352116 upstream.

This is a new ID register, introduced in 8.7.

Signed-off-by: Joey Gouly 
Cc: Will Deacon 
Cc: Marc Zyngier 
Cc: James Morse 
Cc: Alexandru Elisei 
Cc: Suzuki K Poulose 
Cc: Reiji Watanabe 
Acked-by: Marc Zyngier 
Link: https://lore.kernel.org/r/20211210165432.8106-3-joey.gouly@arm.com
Signed-off-by: Catalin Marinas 
Signed-off-by: James Morse 
Signed-off-by: Greg Kroah-Hartman

arm64: Mitigate spectre style branch history side channels

2022-04-12T05:52:17+00:00

commit 558c303c9734af5a813739cd284879227f7297d2 upstream.

Speculation attacks against some high-performance processors can
make use of branch history to influence future speculation.
When taking an exception from user-space, a sequence of branches
or a firmware call overwrites or invalidates the branch history.

The sequence of branches is added to the vectors, and should appear
before the first indirect branch. For systems using KPTI the sequence
is added to the kpti trampoline where it has a free register as the exit
from the trampoline is via a 'ret'. For systems not using KPTI, the same
register tricks are used to free up a register in the vectors.

For the firmware call, arch-workaround-3 clobbers 4 registers, so
there is no choice but to save them to the EL1 stack. This only happens
for entry from EL0, so if we take an exception due to the stack access,
it will not become re-entrant.

For KVM, the existing branch-predictor-hardening vectors are used.
When a spectre version of these vectors is in use, the firmware call
is sufficient to mitigate against Spectre-BHB. For the non-spectre
versions, the sequence of branches is added to the indirect vector.

Reviewed-by: Catalin Marinas 
Cc:  #  #  # 
Signed-off-by: Greg Kroah-Hartman