Re: [PATCH v3 1/3] arm64: Factor out checks for KASLR in KPTI code into separate function

From: Catalin Marinas <catalin.marinas@arm.com>
To: Mark Brown <broonie@kernel.org>
Cc: Will Deacon <will@kernel.org>, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 1/3] arm64: Factor out checks for KASLR in KPTI code into separate function
Date: Fri, 18 Oct 2019 13:01:02 +0100	[thread overview]
Message-ID: <20191018120102.GA55431@arrakis.emea.arm.com> (raw)
In-Reply-To: <20191016151421.27708-2-broonie@kernel.org>

On Wed, Oct 16, 2019 at 04:14:19PM +0100, Mark Brown wrote:
> +static inline bool arm64_kernel_use_ng_mappings(void)
> +{
>  	/* What's a kpti? Use global mappings if we don't know. */
>  	if (!IS_ENABLED(CONFIG_UNMAP_KERNEL_AT_EL0))
>  		return false;
> @@ -52,29 +79,21 @@ static inline bool arm64_kernel_use_ng_mappings(void)
>  	if (arm64_kernel_unmapped_at_el0())
>  		return true;
>  
> -	if (!IS_ENABLED(CONFIG_RANDOMIZE_BASE))
> +	/*
> +	 * Once we are far enough into boot for capabilities to be
> +	 * ready we will have confirmed if we are using non-global
> +	 * mappings so don't need to consider anything else here.
> +	 */
> +	if (static_branch_likely(&arm64_const_caps_ready))
>  		return false;
>  
>  	/*
>  	 * KASLR is enabled so we're going to be enabling kpti on non-broken
>  	 * CPUs regardless of their susceptibility to Meltdown. Rather
>  	 * than force everybody to go through the G -> nG dance later on,
> -	 * just put down non-global mappings from the beginning.
> +	 * just put down non-global mappings from the beginning
>  	 */
> -	if (!IS_ENABLED(CONFIG_CAVIUM_ERRATUM_27456)) {
> -		tx1_bug = false;
> -#ifndef MODULE
> -	} else if (!static_branch_likely(&arm64_const_caps_ready)) {
> -		extern const struct midr_range cavium_erratum_27456_cpus[];
> -
> -		tx1_bug = is_midr_in_range_list(read_cpuid_id(),
> -						cavium_erratum_27456_cpus);
> -#endif
> -	} else {
> -		tx1_bug = __cpus_have_const_cap(ARM64_WORKAROUND_CAVIUM_27456);
> -	}
> -
> -	return !tx1_bug && kaslr_offset() > 0;
> +	return kaslr_requires_kpti();
>  }

While that's a step in the right direction, I'd like to see
{PTE,PMD}_MAYBE_NG move away from the current use of
arm64_kernel_use_ng_mappings(). These macros are used during early
during boot and we seem to rely on cpu_hwcaps not being populated yet
(arm64_kernel_unmapped_at_el0() checking it via cpus_have_const_cap()).

Could we have a global variable (boot or a pgtable attr type) which we
populate during early boot and subsequently use in the PTE_MAYBE_NG
macro?

Thanks.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel