Re: [PATCH v2 1/2] arm64: Add initial support for E0PD

From: Mark Rutland <mark.rutland@arm•com>
To: Mark Brown <broonie@kernel•org>
Cc: Catalin Marinas <catalin.marinas@arm•com>,
	Will Deacon <will@kernel•org>,
	linux-arm-kernel@lists•infradead.org,
	Suzuki K Poulose <suzuki.poulose@arm•com>
Subject: Re: [PATCH v2 1/2] arm64: Add initial support for E0PD
Date: Thu, 10 Oct 2019 17:13:17 +0100	[thread overview]
Message-ID: <20191010161317.GD24793@lakrids.cambridge.arm.com> (raw)
In-Reply-To: <20190814183103.33707-2-broonie@kernel.org>

Hi Mark,

On Wed, Aug 14, 2019 at 07:31:02PM +0100, Mark Brown wrote:
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 9323bcc40a58..62b01fc35ef6 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -219,6 +219,7 @@ static const struct arm64_ftr_bits ftr_id_aa64mmfr1[] = {
>  };
>  
>  static const struct arm64_ftr_bits ftr_id_aa64mmfr2[] = {
> +	ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_E0PD_SHIFT, 4, 0),

The presence of this entry means the system-wide value will be exposed
to a KVM guest, but since it's NONSTRICT we won't warn about a
late-onlined CPU that has a mismatch.

So if all the boot-time CPUs have E0PD, we can spawn a VM that starts
using E0PD, but we might (silently) later migrate it to a CPU without
E0PD, breaking the security guarantee.

I think we want this to be STRICT, so that we at least warn in such a
case.

More generally than this patch, I suspect we probably want to abort the
hotplug if we online a CPU that doesn't provide the same gaurantees as
the sys_val for the field.

[...]

> @@ -1559,6 +1573,19 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
>  		.sign = FTR_UNSIGNED,
>  		.min_field_value = 1,
>  	},
> +#endif
> +#ifdef CONFIG_ARM64_E0PD
> +	{
> +		.desc = "E0PD",
> +		.capability = ARM64_HAS_E0PD,
> +		.type = ARM64_CPUCAP_WEAK_LOCAL_CPU_FEATURE,

I suspect it would be better to treat this as a system-wide capability,
as with KPTI, which will make it much easier to reason about.

That would rule out having E0PD on a subset of CPUs, with or without
KPTI. With KPTI it's not really necessary, and without KPTI we don't
have a consistent guarantee, so that sounds reasonable to me.

Thanks,
Mark.

> +		.sys_reg = SYS_ID_AA64MMFR2_EL1,
> +		.sign = FTR_UNSIGNED,
> +		.field_pos = ID_AA64MMFR2_E0PD_SHIFT,
> +		.matches = has_cpuid_feature,
> +		.min_field_value = 1,
> +		.cpu_enable = cpu_enable_e0pd,
> +	},
>  #endif
>  	{},
>  };
> -- 
> 2.20.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists•infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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