Commit 0617052d authored by Will Deacon's avatar Will Deacon Committed by Catalin Marinas
Browse files

arm64: Kconfig: Reword UNMAP_KERNEL_AT_EL0 kconfig entry 



Although CONFIG_UNMAP_KERNEL_AT_EL0 does make KASLR more robust, it's
actually more useful as a mitigation against speculation attacks that
can leak arbitrary kernel data to userspace through speculation.

Reword the Kconfig help message to reflect this, and make the option
depend on EXPERT so that it is on by default for the majority of users.

Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
parent be04a6d1

arch/arm64/Kconfig

+6 −7
Original line number Original line Diff line number Diff line
@@ -863,15 +863,14 @@ config FORCE_MAX_ZONEORDER 
	  4M allocations matching the default size used by generic code.

	  4M allocations matching the default size used by generic code.





config UNMAP_KERNEL_AT_EL0

config UNMAP_KERNEL_AT_EL0

	bool "Unmap kernel when running in userspace (aka \"KAISER\")"

	bool "Unmap kernel when running in userspace (aka \"KAISER\")" if EXPERT

	default y

	default y

	help

	help

	  Some attacks against KASLR make use of the timing difference between

	  Speculation attacks against some high-performance processors can

	  a permission fault which could arise from a page table entry that is

	  be used to bypass MMU permission checks and leak kernel data to

	  present in the TLB, and a translation fault which always requires a

	  userspace. This can be defended against by unmapping the kernel

	  page table walk. This option defends against these attacks by unmapping

	  when running in userspace, mapping it back in on exception entry

	  the kernel whilst running in userspace, therefore forcing translation

	  via a trampoline page in the vector table.

	  faults for all of kernel space.





	  If unsure, say Y.

	  If unsure, say Y.