Diffstat (limited to 'arch/arm64/Kconfig')
1 files changed, 37 insertions, 10 deletions
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 302d0b681676..177be0d1d090 100644
@@ -459,12 +459,26 @@ config ARM64_ERRATUM_845719
bool "Cortex-A53: 843419: A load or store might access an incorrect address"
- select ARM64_MODULE_CMODEL_LARGE if MODULES
+ select ARM64_MODULE_PLTS if MODULES
This option links the kernel with '--fix-cortex-a53-843419' and
- builds modules using the large memory model in order to avoid the use
- of the ADRP instruction, which can cause a subsequent memory access
- to use an incorrect address on Cortex-A53 parts up to r0p4.
+ enables PLT support to replace certain ADRP instructions, which can
+ cause subsequent memory accesses to use an incorrect address on
+ Cortex-A53 parts up to r0p4.
+ If unsure, say Y.
+ bool "Cortex-A55: 1024718: Update of DBM/AP bits without break before make might result in incorrect update"
+ default y
+ This option adds work around for Arm Cortex-A55 Erratum 1024718.
+ Affected Cortex-A55 cores (r0p0, r0p1, r1p0) could cause incorrect
+ update of the hardware dirty bit when the DBM/AP bits are updated
+ without a break-before-make. The work around is to disable the usage
+ of hardware DBM locally on the affected cores. CPUs not affected by
+ erratum will continue to use the feature.
If unsure, say Y.
@@ -1108,12 +1122,25 @@ config ARM64_SVE
To enable use of this extension on CPUs that implement it, say Y.
+ Note that for architectural reasons, firmware _must_ implement SVE
+ support when running on SVE capable hardware. The required support
+ is present in:
+ * version 1.5 and later of the ARM Trusted Firmware
+ * the AArch64 boot wrapper since commit 5e1261e08abf
+ ("bootwrapper: SVE: Enable SVE for EL2 and below").
+ For other firmware implementations, consult the firmware documentation
+ or vendor.
+ If you need the kernel to boot on SVE-capable hardware with broken
+ firmware, you may need to say N here until you get your firmware
+ fixed. Otherwise, you may experience firmware panics or lockups when
+ booting the kernel. If unsure and you are not observing these
+ symptoms, you should assume that it is safe to say Y.
- select ARM64_MODULE_CMODEL_LARGE
@@ -1147,12 +1174,12 @@ config RANDOMIZE_BASE
If unsure, say N.
- bool "Randomize the module region independently from the core kernel"
+ bool "Randomize the module region over a 4 GB range"
depends on RANDOMIZE_BASE
- Randomizes the location of the module region without considering the
- location of the core kernel. This way, it is impossible for modules
+ Randomizes the location of the module region inside a 4 GB window
+ covering the core kernel. This way, it is less likely for modules
to leak information about the location of core kernel data structures
but it does imply that function calls between modules and the core
kernel will need to be resolved via veneers in the module PLT.