Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64...

[linux-2.6-block.git] / arch / arm64 / Kconfig

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index c9a7e9e1414f344c9dfd515600e3e4378bf61d81..b488076d63c2c389bd3b2fe94bffdd63f84adb7c 100644 (file)
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -522,20 +522,13 @@ config CAVIUM_ERRATUM_30115
 config QCOM_FALKOR_ERRATUM_1003
        bool "Falkor E1003: Incorrect translation due to ASID change"
        default y
-       select ARM64_PAN if ARM64_SW_TTBR0_PAN
        help
          On Falkor v1, an incorrect ASID may be cached in the TLB when ASID
-         and BADDR are changed together in TTBRx_EL1. The workaround for this
-         issue is to use a reserved ASID in cpu_do_switch_mm() before
-         switching to the new ASID. Saying Y here selects ARM64_PAN if
-         ARM64_SW_TTBR0_PAN is selected. This is done because implementing and
-         maintaining the E1003 workaround in the software PAN emulation code
-         would be an unnecessary complication. The affected Falkor v1 CPU
-         implements ARMv8.1 hardware PAN support and using hardware PAN
-         support versus software PAN emulation is mutually exclusive at
-         runtime.
-
-         If unsure, say Y.
+         and BADDR are changed together in TTBRx_EL1. Since we keep the ASID
+         in TTBR1_EL1, this situation only occurs in the entry trampoline and
+         then only for entries in the walk cache, since the leaf translation
+         is unchanged. Work around the erratum by invalidating the walk cache
+         entries for the trampoline before entering the kernel proper.
 
 config QCOM_FALKOR_ERRATUM_1009
        bool "Falkor E1009: Prematurely complete a DSB after a TLBI"
@@ -656,6 +649,35 @@ config ARM64_VA_BITS
        default 47 if ARM64_VA_BITS_47
        default 48 if ARM64_VA_BITS_48
 
+choice
+       prompt "Physical address space size"
+       default ARM64_PA_BITS_48
+       help
+         Choose the maximum physical address range that the kernel will
+         support.
+
+config ARM64_PA_BITS_48
+       bool "48-bit"
+
+config ARM64_PA_BITS_52
+       bool "52-bit (ARMv8.2)"
+       depends on ARM64_64K_PAGES
+       depends on ARM64_PAN || !ARM64_SW_TTBR0_PAN
+       help
+         Enable support for a 52-bit physical address space, introduced as
+         part of the ARMv8.2-LPA extension.
+
+         With this enabled, the kernel will also continue to work on CPUs that
+         do not support ARMv8.2-LPA, but with some added memory overhead (and
+         minor performance overhead).
+
+endchoice
+
+config ARM64_PA_BITS
+       int
+       default 48 if ARM64_PA_BITS_48
+       default 52 if ARM64_PA_BITS_52
+
 config CPU_BIG_ENDIAN
        bool "Build big-endian kernel"
        help
@@ -850,6 +872,35 @@ config FORCE_MAX_ZONEORDER
          However for 4K, we choose a higher default value, 11 as opposed to 10, giving us
          4M allocations matching the default size used by generic code.
 
+config UNMAP_KERNEL_AT_EL0
+       bool "Unmap kernel when running in userspace (aka \"KAISER\")" if EXPERT
+       default y
+       help
+         Speculation attacks against some high-performance processors can
+         be used to bypass MMU permission checks and leak kernel data to
+         userspace. This can be defended against by unmapping the kernel
+         when running in userspace, mapping it back in on exception entry
+         via a trampoline page in the vector table.
+
+         If unsure, say Y.
+
+config HARDEN_BRANCH_PREDICTOR
+       bool "Harden the branch predictor against aliasing attacks" if EXPERT
+       default y
+       help
+         Speculation attacks against some high-performance processors rely on
+         being able to manipulate the branch predictor for a victim context by
+         executing aliasing branches in the attacker context.  Such attacks
+         can be partially mitigated against by clearing internal branch
+         predictor state and limiting the prediction logic in some situations.
+
+         This config option will take CPU-specific actions to harden the
+         branch predictor against aliasing attacks and may rely on specific
+         instruction sequences or control bits being set by the system
+         firmware.
+
+         If unsure, say Y.
+
 menuconfig ARMV8_DEPRECATED
        bool "Emulate deprecated/obsolete ARMv8 instructions"
        depends on COMPAT
@@ -1021,6 +1072,22 @@ config ARM64_PMEM
          operations if DC CVAP is not supported (following the behaviour of
          DC CVAP itself if the system does not define a point of persistence).
 
+config ARM64_RAS_EXTN
+       bool "Enable support for RAS CPU Extensions"
+       default y
+       help
+         CPUs that support the Reliability, Availability and Serviceability
+         (RAS) Extensions, part of ARMv8.2 are able to track faults and
+         errors, classify them and report them to software.
+
+         On CPUs with these extensions system software can use additional
+         barriers to determine if faults are pending and read the
+         classification from a new set of registers.
+
+         Selecting this feature will allow the kernel to use these barriers
+         and access the new registers if the system supports the extension.
+         Platform RAS features may additionally depend on firmware support.
+
 endmenu
 
 config ARM64_SVE