ARM 64-bit (AArch64) Linux support.
This option adds an alternative code sequence to work around ARM erratum 826319 on Cortex-A53 parts up to r0p2 with an AMBA 4 ACE or AXI master interface and an L2 cache. If a Cortex-A53 uses an AMBA AXI4 ACE interface to other processors and is unable to accept a certain write via this interface, it will not progress on read data presented on the read data channel and the system can deadlock. The workaround promotes data cache clean instructions to data cache clean-and-invalidate. Please note that this does not necessarily enable the workaround, as it depends on the alternative framework, which will only patch the kernel if an affected CPU is detected. If unsure, say Y.
This option adds an alternative code sequence to work around ARM erratum 827319 on Cortex-A53 parts up to r0p2 with an AMBA 5 CHI master interface and an L2 cache. Under certain conditions this erratum can cause a clean line eviction to occur at the same time as another transaction to the same address on the AMBA 5 CHI interface, which can cause data corruption if the interconnect reorders the two transactions. The workaround promotes data cache clean instructions to data cache clean-and-invalidate. Please note that this does not necessarily enable the workaround, as it depends on the alternative framework, which will only patch the kernel if an affected CPU is detected. If unsure, say Y.
This option adds an alternative code sequence to work around ARM erratum 824069 on Cortex-A53 parts up to r0p2 when it is connected to a coherent interconnect. If a Cortex-A53 processor is executing a store or prefetch for write instruction at the same time as a processor in another cluster is executing a cache maintenance operation to the same address, then this erratum might cause a clean cache line to be incorrectly marked as dirty. The workaround promotes data cache clean instructions to data cache clean-and-invalidate. Please note that this option does not necessarily enable the workaround, as it depends on the alternative framework, which will only patch the kernel if an affected CPU is detected. If unsure, say Y.
This option adds an alternative code sequence to work around ARM erratum 819472 on Cortex-A53 parts up to r0p1 with an L2 cache present when it is connected to a coherent interconnect. If the processor is executing a load and store exclusive sequence at the same time as a processor in another cluster is executing a cache maintenance operation to the same address, then this erratum might cause data corruption. The workaround promotes data cache clean instructions to data cache clean-and-invalidate. Please note that this does not necessarily enable the workaround, as it depends on the alternative framework, which will only patch the kernel if an affected CPU is detected. If unsure, say Y.
This option adds an alternative code sequence to work around ARM erratum 832075 on Cortex-A57 parts up to r1p2. Affected Cortex-A57 parts might deadlock when exclusive load/store instructions to Write-Back memory are mixed with Device loads. The workaround is to promote device loads to use Load-Acquire semantics. Please note that this does not necessarily enable the workaround, as it depends on the alternative framework, which will only patch the kernel if an affected CPU is detected. If unsure, say Y.
This option adds an alternative code sequence to work around ARM erratum 834220 on Cortex-A57 parts up to r1p2. Affected Cortex-A57 parts might report a Stage 2 translation fault as the result of a Stage 1 fault for load crossing a page boundary when there is a permission or device memory alignment fault at Stage 1 and a translation fault at Stage 2. The workaround is to verify that the Stage 1 translation doesn't generate a fault before handling the Stage 2 fault. Please note that this does not necessarily enable the workaround, as it depends on the alternative framework, which will only patch the kernel if an affected CPU is detected. If unsure, say Y.
This option adds an alternative code sequence to work around ARM erratum 845719 on Cortex-A53 parts up to r0p4. When running a compat (AArch32) userspace on an affected Cortex-A53 part, a load at EL0 from a virtual address that matches the bottom 32 bits of the virtual address used by a recent load at (AArch64) EL1 might return incorrect data. The workaround is to write the contextidr_el1 register on exception return to a 32-bit task. Please note that this does not necessarily enable the workaround, as it depends on the alternative framework, which will only patch the kernel if an affected CPU is detected. If unsure, say Y.
This option links the kernel with '--fix-cortex-a53-843419' and 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.
This option adds a workaround for ARM Cortex-A55 Erratum 1024718. Affected Cortex-A55 cores (all revisions) could cause incorrect update of the hardware dirty bit when the DBM/AP bits are updated without a break-before-make. The workaround is to disable the usage of hardware DBM locally on the affected cores. CPUs not affected by this erratum will continue to use the feature. If unsure, say Y.
This option adds a workaround for ARM Cortex-A76/Neoverse-N1 errata 1188873 and 1418040. Affected Cortex-A76/Neoverse-N1 cores (r0p0 to r3p1) could cause register corruption when accessing the timer registers from AArch32 userspace. If unsure, say Y.
This option adds a workaround for ARM Cortex-A76 erratum 1165522. Affected Cortex-A76 cores (r0p0, r1p0, r2p0) could end-up with corrupted TLBs by speculating an AT instruction during a guest context switch. If unsure, say Y.
This option adds work arounds for ARM Cortex-A57 erratum 1319537 and A72 erratum 1319367 Cortex-A57 and A72 cores could end-up with corrupted TLBs by speculating an AT instruction during a guest context switch. If unsure, say Y.
This option adds a workaround for ARM Cortex-A55 erratum 1530923. Affected Cortex-A55 cores (r0p0, r0p1, r1p0, r2p0) could end-up with corrupted TLBs by speculating an AT instruction during a guest context switch. If unsure, say Y.
This option adds a workaround for ARM Cortex-A76 erratum 1286807. On the affected Cortex-A76 cores (r0p0 to r3p0), if a virtual address for a cacheable mapping of a location is being accessed by a core while another core is remapping the virtual address to a new physical page using the recommended break-before-make sequence, then under very rare circumstances TLBI+DSB completes before a read using the translation being invalidated has been observed by other observers. The workaround repeats the TLBI+DSB operation.
This option adds a workaround for Arm Cortex-A76 erratum 1463225. On the affected Cortex-A76 cores (r0p0 to r3p1), software stepping of a system call instruction (SVC) can prevent recognition of subsequent interrupts when software stepping is disabled in the exception handler of the system call and either kernel debugging is enabled or VHE is in use. Work around the erratum by triggering a dummy step exception when handling a system call from a task that is being stepped in a VHE configuration of the kernel. If unsure, say Y.
This option adds a workaround for ARM Neoverse-N1 erratum 1542419. Affected Neoverse-N1 cores could execute a stale instruction when modified by another CPU. The workaround depends on a firmware counterpart. Workaround the issue by hiding the DIC feature from EL0. This forces user-space to perform cache maintenance. If unsure, say Y.
This option adds a workaround for Arm Cortex-A77 erratum 1508412. Affected Cortex-A77 cores (r0p0, r1p0) could deadlock on a sequence of a store-exclusive or read of PAR_EL1 and a load with device or non-cacheable memory attributes. The workaround depends on a firmware counterpart. KVM guests must also have the workaround implemented or they can deadlock the system. Work around the issue by inserting DMB SY barriers around PAR_EL1 register reads and warning KVM users. The DMB barrier is sufficient to prevent a speculative PAR_EL1 read. If unsure, say Y.
Enable workaround for errata 22375 and 24313. This implements two gicv3-its errata workarounds for ThunderX. Both with a small impact affecting only ITS table allocation. erratum 22375: only alloc 8MB table size erratum 24313: ignore memory access type The fixes are in ITS initialization and basically ignore memory access type and table size provided by the TYPER and BASER registers. If unsure, say Y.
ITS SYNC command hang for cross node io and collections/cpu mapping. If unsure, say Y.
The gicv3 of ThunderX requires a modified version for reading the IAR status to ensure data synchronization (access to icc_iar1_el1 is not sync'ed before and after). If unsure, say Y.
On ThunderX T88 pass 1.x through 2.1 parts, broadcast TLBI instructions may cause the icache to become corrupted if it contains data for a non-current ASID. The fix is to invalidate the icache when changing the mm context. If unsure, say Y.
On ThunderX T88 pass 1.x through 2.2, T81 pass 1.0 through 1.2, and T83 Pass 1.0, KVM guest execution may disable interrupts in host. Trapping both GICv3 group-0 and group-1 accesses sidesteps the issue. If unsure, say Y.
On Cavium ThunderX2, a load, store or prefetch instruction between a TTBR update and the corresponding context synchronizing operation can cause a spurious Data Abort to be delivered to any hardware thread in the CPU core. Work around the issue by avoiding the problematic code sequence and trapping KVM guest TTBRx_EL1 writes to EL2 when SMT is enabled. The trap handler performs the corresponding register access, skips the instruction and ensures context synchronization by virtue of the exception return. If unsure, say Y.
This option adds a workaround for Fujitsu-A64FX erratum E#010001. On some variants of the Fujitsu-A64FX cores ver(1.0, 1.1), memory accesses may cause undefined fault (Data abort, DFSC=0b111111). This fault occurs under a specific hardware condition when a load/store instruction performs an address translation using: case-1 TTBR0_EL1 with TCR_EL1.NFD0 == 1. case-2 TTBR0_EL2 with TCR_EL2.NFD0 == 1. case-3 TTBR1_EL1 with TCR_EL1.NFD1 == 1. case-4 TTBR1_EL2 with TCR_EL2.NFD1 == 1. The workaround is to ensure these bits are clear in TCR_ELx. The workaround only affects the Fujitsu-A64FX. If unsure, say Y.
The HiSilicon Hip07 SoC uses the wrong redistributor base when issued ITS commands such as VMOVP and VMAPP, and requires a 128kB offset to be applied to the target address in this commands. If unsure, say Y.
On Falkor v1, an incorrect ASID may be cached in the TLB when ASID 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.
On Falkor v1, the CPU may prematurely complete a DSB following a TLBI xxIS invalidate maintenance operation. Repeat the TLBI operation one more time to fix the issue. If unsure, say Y.
On Qualcomm Datacenter Technologies QDF2400 SoC, ITS hardware reports ITE size incorrectly. The GITS_TYPER.ITT_Entry_size field should have been indicated as 16Bytes (0xf), not 8Bytes (0x7). If unsure, say Y.
Falkor CPU may speculatively fetch instructions from an improper memory location when MMU translation is changed from SCTLR_ELn[M]=1 to SCTLR_ELn[M]=0. Prefix an ISB instruction to fix the problem. If unsure, say Y.
If CNP is enabled on Carmel cores, non-sharable TLBIs on a core will not invalidate shared TLB entries installed by a different core, as it would on standard ARM cores. If unsure, say Y.
Socionext Synquacer SoCs implement a separate h/w block to generate MSI doorbell writes with non-zero values for the device ID. If unsure, say Y.
Page size (translation granule) configuration.
This feature enables 4KB pages support.
The system will use 16KB pages support. AArch32 emulation requires applications compiled with 16K (or a multiple of 16K) aligned segments.
This feature enables 64KB pages support (4KB by default) allowing only two levels of page tables and faster TLB look-up. AArch32 emulation requires applications compiled with 64K aligned segments.
Allows choosing one of multiple possible virtual address space sizes. The level of translation table is determined by a combination of page size and virtual address space size.
Enable 52-bit virtual addressing for userspace when explicitly requested via a hint to mmap(). The kernel will also use 52-bit virtual addresses for its own mappings (provided HW support for this feature is available, otherwise it reverts to 48-bit). NOTE: Enabling 52-bit virtual addressing in conjunction with ARMv8.3 Pointer Authentication will result in the PAC being reduced from 7 bits to 3 bits, which may have a significant impact on its susceptibility to brute-force attacks. If unsure, select 48-bit virtual addressing instead.
For systems with 52-bit userspace VAs enabled, the kernel will attempt to maintain compatibility with older software by providing 48-bit VAs unless a hint is supplied to mmap. This configuration option disables the 48-bit compatibility logic, and forces all userspace addresses to be 52-bit on HW that supports it. One should only enable this configuration option for stress testing userspace memory management code. If unsure say N here.
Choose the maximum physical address range that the kernel will support.
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).
Select the endianness of data accesses performed by the CPU. Userspace applications will need to be compiled and linked for the endianness that is selected here.
Say Y if you plan on running a kernel with a big-endian userspace.
Say Y if you plan on running a kernel with a little-endian userspace. This is usually the case for distributions targeting arm64.
Multi-core scheduler support improves the CPU scheduler's decision making when dealing with multi-core CPU chips at a cost of slightly increased overhead in some places. If unsure say N here.
Improves the CPU scheduler's decision making when dealing with MultiThreading at a cost of slightly increased overhead in some places. If unsure say N here.
Say Y here to experiment with turning CPUs off and on. CPUs can be controlled through /sys/devices/system/cpu.
Enable NUMA (Non-Uniform Memory Access) support. The kernel will try to allocate memory used by a CPU on the local memory of the CPU and add some more NUMA awareness to the kernel.
Specify the maximum number of NUMA Nodes available on the target system. Increases memory reserved to accommodate various tables.
This changes the kernel so it can modify itself when it is run under a hypervisor, potentially improving performance significantly over full virtualization.
Select this option to enable fine granularity task steal time accounting. Time spent executing other tasks in parallel with the current vCPU is discounted from the vCPU power. To account for that, there can be a small performance impact. If in doubt, say N here.
kexec is a system call that implements the ability to shutdown your current kernel, and to start another kernel. It is like a reboot but it is independent of the system firmware. And like a reboot you can start any kernel with it, not just Linux.
This is new version of kexec system call. This system call is file based and takes file descriptors as system call argument for kernel and initramfs as opposed to list of segments as accepted by previous system call.
Select this option to verify a signature with loaded kernel image. If configured, any attempt of loading a image without valid signature will fail. In addition to that option, you need to enable signature verification for the corresponding kernel image type being loaded in order for this to work.
Enable Image signature verification support.
Generate crash dump after being started by kexec. This should be normally only set in special crash dump kernels which are loaded in the main kernel with kexec-tools into a specially reserved region and then later executed after a crash by kdump/kexec. For more details see Documentation/admin-guide/kdump/kdump.rst
Say Y if you want to run Linux in a Virtual Machine on Xen on ARM64.
The kernel memory allocator divides physically contiguous memory blocks into "zones", where each zone is a power of two number of pages. This option selects the largest power of two that the kernel keeps in the memory allocator. If you need to allocate very large blocks of physically contiguous memory, then you may need to increase this value. This config option is actually maximum order plus one. For example, a value of 11 means that the largest free memory block is 2^10 pages. We make sure that we can allocate upto a HugePage size for each configuration. Hence we have : MAX_ORDER = (PMD_SHIFT - PAGE_SHIFT) + 1 => PAGE_SHIFT - 2 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.
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.
Apply read-only attributes of VM areas to the linear alias of the backing pages as well. This prevents code or read-only data from being modified (inadvertently or intentionally) via another mapping of the same memory page. This additional enhancement can be turned off at runtime by passing rodata=[off|on] (and turned on with rodata=full if this option is set to 'n') This requires the linear region to be mapped down to pages, which may adversely affect performance in some cases.
Enabling this option prevents the kernel from accessing user-space memory directly by pointing TTBR0_EL1 to a reserved zeroed area and reserved ASID. The user access routines restore the valid TTBR0_EL1 temporarily.
When this option is enabled, user applications can opt in to a relaxed ABI via prctl() allowing tagged addresses to be passed to system calls as pointer arguments. For details, see Documentation/arm64/tagged-address-abi.rst.
This option enables support for a 32-bit EL0 running under a 64-bit kernel at EL1. AArch32-specific components such as system calls, the user helper functions, VFP support and the ptrace interface are handled appropriately by the kernel. If you use a page size other than 4KB (i.e, 16KB or 64KB), please be aware that you will only be able to execute AArch32 binaries that were compiled with page size aligned segments. If you want to execute 32-bit userspace applications, say Y.
Warning: disabling this option may break 32-bit user programs. Provide kuser helpers to compat tasks. The kernel provides helper code to userspace in read only form at a fixed location to allow userspace to be independent of the CPU type fitted to the system. This permits binaries to be run on ARMv4 through to ARMv8 without modification. See Documentation/arm/kernel_user_helpers.rst for details. However, the fixed address nature of these helpers can be used by ROP (return orientated programming) authors when creating exploits. If all of the binaries and libraries which run on your platform are built specifically for your platform, and make no use of these helpers, then you can turn this option off to hinder such exploits. However, in that case, if a binary or library relying on those helpers is run, it will not function correctly. Say N here only if you are absolutely certain that you do not need these helpers; otherwise, the safe option is to say Y.
Place in the process address space of 32-bit applications an ELF shared object providing fast implementations of gettimeofday and clock_gettime. You must have a 32-bit build of glibc 2.22 or later for programs to seamlessly take advantage of this.
Compile the compat vDSO with '-mthumb -fomit-frame-pointer' if y, otherwise with '-marm'.
Legacy software support may require certain instructions that have been deprecated or obsoleted in the architecture. Enable this config to enable selective emulation of these features. If unsure, say Y
ARMv8 obsoletes the use of A32 SWP/SWPB instructions such that they are always undefined. Say Y here to enable software emulation of these instructions for userspace using LDXR/STXR. This feature can be controlled at runtime with the abi.swp sysctl which is disabled by default. In some older versions of glibc [<=2.8] SWP is used during futex trylock() operations with the assumption that the code will not be preempted. This invalid assumption may be more likely to fail with SWP emulation enabled, leading to deadlock of the user application. NOTE: when accessing uncached shared regions, LDXR/STXR rely on an external transaction monitoring block called a global monitor to maintain update atomicity. If your system does not implement a global monitor, this option can cause programs that perform SWP operations to uncached memory to deadlock. If unsure, say Y
The CP15 barrier instructions - CP15ISB, CP15DSB, and CP15DMB - are deprecated in ARMv8 (and ARMv7). It is strongly recommended to use the ISB, DSB, and DMB instructions instead. Say Y here to enable software emulation of these instructions for AArch32 userspace code. When this option is enabled, CP15 barrier usage is traced which can help identify software that needs updating. This feature can be controlled at runtime with the abi.cp15_barrier sysctl. If unsure, say Y
The SETEND instruction alters the data-endianness of the AArch32 EL0, and is deprecated in ARMv8. Say Y here to enable software emulation of the instruction for AArch32 userspace code. This feature can be controlled at runtime with the abi.setend sysctl. Note: All the cpus on the system must have mixed endian support at EL0 for this feature to be enabled. If a new CPU - which doesn't support mixed endian - is hotplugged in after this feature has been enabled, there could be unexpected results in the applications. If unsure, say Y
The ARMv8.1 architecture extensions introduce support for hardware updates of the access and dirty information in page table entries. When enabled in TCR_EL1 (HA and HD bits) on capable processors, accesses to pages with PTE_AF cleared will set this bit instead of raising an access flag fault. Similarly, writes to read-only pages with the DBM bit set will clear the read-only bit (AP[2]) instead of raising a permission fault. Kernels built with this configuration option enabled continue to work on pre-ARMv8.1 hardware and the performance impact is minimal. If unsure, say Y.
Privileged Access Never (PAN; part of the ARMv8.1 Extensions) prevents the kernel or hypervisor from accessing user-space (EL0) memory directly. Choosing this option will cause any unprotected (not using copy_to_user et al) memory access to fail with a permission fault. The feature is detected at runtime, and will remain as a 'nop' instruction if the cpu does not implement the feature.
As part of the Large System Extensions, ARMv8.1 introduces new atomic instructions that are designed specifically to scale in very large systems. Say Y here to make use of these instructions for the in-kernel atomic routines. This incurs a small overhead on CPUs that do not support these instructions and requires the kernel to be built with binutils >= 2.25 in order for the new instructions to be used.
Say Y to enable support for the persistent memory API based on the ARMv8.2 DCPoP feature. The feature is detected at runtime, and the kernel will use DC CVAC operations if DC CVAP is not supported (following the behaviour of DC CVAP itself if the system does not define a point of persistence).
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.
Common Not Private (CNP) allows translation table entries to be shared between different PEs in the same inner shareable domain, so the hardware can use this fact to optimise the caching of such entries in the TLB. Selecting this option allows the CNP feature to be detected at runtime, and does not affect PEs that do not implement this feature.
Pointer authentication (part of the ARMv8.3 Extensions) provides instructions for signing and authenticating pointers against secret keys, which can be used to mitigate Return Oriented Programming (ROP) and other attacks. This option enables these instructions at EL0 (i.e. for userspace). Choosing this option will cause the kernel to initialise secret keys for each process at exec() time, with these keys being context-switched along with the process. If the compiler supports the -mbranch-protection or -msign-return-address flag (e.g. GCC 7 or later), then this option will also cause the kernel itself to be compiled with return address protection. In this case, and if the target hardware is known to support pointer authentication, then CONFIG_STACKPROTECTOR can be disabled with minimal loss of protection. The feature is detected at runtime. If the feature is not present in hardware it will not be advertised to userspace/KVM guest nor will it be enabled. If the feature is present on the boot CPU but not on a late CPU, then the late CPU will be parked. Also, if the boot CPU does not have address auth and the late CPU has then the late CPU will still boot but with the feature disabled. On such a system, this option should not be selected. This feature works with FUNCTION_GRAPH_TRACER option only if DYNAMIC_FTRACE_WITH_REGS is enabled.
The activity monitors extension is an optional extension introduced by the ARMv8.4 CPU architecture. This enables support for version 1 of the activity monitors architecture, AMUv1. To enable the use of this extension on CPUs that implement it, say Y. Note that for architectural reasons, firmware _must_ implement AMU support when running on CPUs that present the activity monitors extension. The required support is present in: * Version 1.5 and later of the ARM Trusted Firmware For kernels that have this configuration enabled but boot with broken firmware, you may need to say N here until the firmware is fixed. Otherwise you may experience firmware panics or lockups when accessing the counter registers. Even if you are not observing these symptoms, the values returned by the register reads might not correctly reflect reality. Most commonly, the value read will be 0, indicating that the counter is not enabled.
ARMv8.4-TLBI provides TLBI invalidation instruction that apply to a range of input addresses. The feature introduces new assembly instructions, and they were support when binutils >= 2.30.
Branch Target Identification (part of the ARMv8.5 Extensions) provides a mechanism to limit the set of locations to which computed branch instructions such as BR or BLR can jump. To make use of BTI on CPUs that support it, say Y. BTI is intended to provide complementary protection to other control flow integrity protection mechanisms, such as the Pointer authentication mechanism provided as part of the ARMv8.3 Extensions. For this reason, it does not make sense to enable this option without also enabling support for pointer authentication. Thus, when enabling this option you should also select ARM64_PTR_AUTH=y. Userspace binaries must also be specifically compiled to make use of this mechanism. If you say N here or the hardware does not support BTI, such binaries can still run, but you get no additional enforcement of branch destinations.
Build the kernel with Branch Target Identification annotations and enable enforcement of this for kernel code. When this option is enabled and the system supports BTI all kernel code including modular code must have BTI enabled.
E0PD (part of the ARMv8.5 extensions) allows us to ensure that EL0 accesses made via TTBR1 always fault in constant time, providing similar benefits to KASLR as those provided by KPTI, but with lower overhead and without disrupting legitimate access to kernel memory such as SPE. This option enables E0PD for TTBR1 where available.
Random number generation (part of the ARMv8.5 Extensions) provides a high bandwidth, cryptographically secure hardware random number generator.
Memory Tagging (part of the ARMv8.5 Extensions) provides architectural support for run-time, always-on detection of various classes of memory error to aid with software debugging to eliminate vulnerabilities arising from memory-unsafe languages. This option enables the support for the Memory Tagging Extension at EL0 (i.e. for userspace). Selecting this option allows the feature to be detected at runtime. Any secondary CPU not implementing this feature will not be allowed a late bring-up. Userspace binaries that want to use this feature must explicitly opt in. The mechanism for the userspace is described in: Documentation/arm64/memory-tagging-extension.rst.
Enhanced Privileged Access Never (EPAN) allows Privileged Access Never to be used with Execute-only mappings. The feature is detected at runtime, and will remain disabled if the cpu does not implement the feature.
The Scalable Vector Extension (SVE) is an extension to the AArch64
execution state which complements and extends the SIMD functionality
of the base architecture to support much larger vectors and to enable
additional vectorisation opportunities.
To enable use of this extension on CPUs that implement it, say Y.
On CPUs that support the SVE2 extensions, this option will enable
those too.
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.
Allocate PLTs when loading modules so that jumps and calls whose targets are too far away for their relative offsets to be encoded in the instructions themselves can be bounced via veneers in the module's PLT. This allows modules to be allocated in the generic vmalloc area after the dedicated module memory area has been exhausted. When running with address space randomization (KASLR), the module region itself may be too far away for ordinary relative jumps and calls, and so in that case, module PLTs are required and cannot be disabled. Specific errata workaround(s) might also force module PLTs to be enabled (ARM64_ERRATUM_843419).
Adds support for mimicking Non-Maskable Interrupts through the use of GIC interrupt priority. This support requires version 3 or later of ARM GIC. This high priority configuration for interrupts needs to be explicitly enabled by setting the kernel parameter "irqchip.gicv3_pseudo_nmi" to 1. If unsure, say N
This adds runtime checks to functions enabling/disabling interrupts when using priority masking. The additional checks verify the validity of ICC_PMR_EL1 when calling concerned functions. If unsure, say N
This builds the kernel as a Position Independent Executable (PIE), which retains all relocation metadata required to relocate the kernel binary at runtime to a different virtual address than the address it was linked at. Since AArch64 uses the RELA relocation format, this requires a relocation pass at runtime even if the kernel is loaded at the same address it was linked at.
Randomizes the virtual address at which the kernel image is loaded, as a security feature that deters exploit attempts relying on knowledge of the location of kernel internals. It is the bootloader's job to provide entropy, by passing a random u64 value in /chosen/kaslr-seed at kernel entry. When booting via the UEFI stub, it will invoke the firmware's EFI_RNG_PROTOCOL implementation (if available) to supply entropy to the kernel proper. In addition, it will randomise the physical location of the kernel Image as well. If unsure, say N.
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. When this option is not set, the module region will be randomized over a limited range that contains the [_stext, _etext] interval of the core kernel, so branch relocations are always in range.
Enable support for the ARM64 ACPI parking protocol. If disabled the kernel will not allow booting through the ARM64 ACPI parking protocol even if the corresponding data is present in the ACPI MADT table.
Provide a set of default command-line options at build time by entering them here. As a minimum, you should specify the the root device (e.g. root=/dev/nfs).
Choose how the kernel will handle the provided default kernel command line string.
Uses the command-line options passed by the boot loader. If the boot loader doesn't provide any, the default kernel command string provided in CMDLINE will be used.
Always use the default kernel command string, even if the boot loader passes other arguments to the kernel. This is useful if you cannot or don't want to change the command-line options your boot loader passes to the kernel.
This option provides support for runtime services provided by UEFI firmware (such as non-volatile variables, realtime clock, and platform reset). A UEFI stub is also provided to allow the kernel to be booted as an EFI application. This is only useful on systems that have UEFI firmware.
This enables SMBIOS/DMI feature for systems. This option is only useful on systems that have UEFI firmware. However, even with this option, the resultant kernel should continue to boot on existing non-UEFI platforms.