linux-kernel - Re: [PATCH 18/18] arm64: Kconfig: Add CONFIG_UNMAP_KERNEL_AT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 22 Nov 2017 16:52:36 +0000
From:   Marc Zyngier <marc.zyngier@....com>
To:     Will Deacon <will.deacon@....com>,
        linux-arm-kernel@...ts.infradead.org
Cc:     linux-kernel@...r.kernel.org, catalin.marinas@....com,
        mark.rutland@....com, ard.biesheuvel@...aro.org,
        sboyd@...eaurora.org, dave.hansen@...ux.intel.com,
        keescook@...omium.org
Subject: Re: [PATCH 18/18] arm64: Kconfig: Add CONFIG_UNMAP_KERNEL_AT_EL0

Hi Will,

On 17/11/17 18:22, Will Deacon wrote:
> Add a Kconfig entry to control use of the entry trampoline, which allows
> us to unmap the kernel whilst running in userspace and improve the
> robustness of KASLR.
> 
> Signed-off-by: Will Deacon <will.deacon@....com>
> ---
>  arch/arm64/Kconfig | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index f0fcbfc2262e..f99ffb88843a 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -796,6 +796,19 @@ 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\")"
> +	default y
> +	help
> +	  Some attacks against KASLR make use of the timing difference between
> +	  a permission fault which could arise from a page table entry that is
> +	  present in the TLB, and a translation fault which always requires a
> +	  page table walk. This option defends against these attacks by unmapping
> +	  the kernel whilst running in userspace, therefore forcing translation
> +	  faults for all of kernel space.
> +
> +	  If unsure, say Y.
> +
>  menuconfig ARMV8_DEPRECATED
>  	bool "Emulate deprecated/obsolete ARMv8 instructions"
>  	depends on COMPAT
> 

Since this seems to be the recommended setting, I wonder if there is any
real value in keeping the old code around. My hunch is that the lack of
use in the field will make it fragile and that it will eventually bit-rot.

Do you have any plan to eventually drop the non-KAISER switch code?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...