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: Will Deacon <will.deacon@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
This commit is contained in:
parent
be04a6d112
commit
0617052ddd
|
@ -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.
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue