[PATCH v2] arm64: Add initial support for E0PD

[PATCH v2] arm64: Add initial support for E0PD

[Mark Brown]

Kernel Page Table Isolation (KPTI) is used to mitigate some speculation
based security issues by ensuring that the kernel is not mapped when
userspace is running but this approach is expensive and is incompatible
with SPE.  E0PD, introduced in the ARMv8.5 extensions, provides an
alternative to this which ensures that accesses from userspace to the
kernel's half of the memory map to always fault with constant time,
preventing timing attacks without requiring constant unmapping and
remapping or preventing legitimate accesses.

This initial patch does not yet integrate with KPTI, a followup patch
will ensure that by default we don't use KPTI on CPUs where E0PD is
present which will provide a much greater benefit in general
configurations.

Signed-off-by: Mark Brown <broonie@kernel.org>
---

 - Reword commit message
 - Change to detection as ARM64_CPUCAP_WEAK_LOCAL_CPU_FEATURE.
 
 arch/arm64/Kconfig                     | 14 ++++++++++++++
 arch/arm64/include/asm/cpucaps.h       |  3 ++-
 arch/arm64/include/asm/pgtable-hwdef.h |  2 ++
 arch/arm64/include/asm/sysreg.h        |  1 +
 arch/arm64/kernel/cpufeature.c         | 21 +++++++++++++++++++++
 5 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 0758d89524d0..6bb0d6b578d3 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1382,6 +1382,20 @@ config ARM64_PTR_AUTH
 
 endmenu
 
+menu "ARMv8.5 architectural features"
+
+config ARM64_E0PD
+	bool "Enable support for E0PD"
+	default y
+	help
+	   E0PD (part of the ARMv8.5 extensions) ensures that EL0
+	   accesses made via TTBR1 always fault in constant time,
+	   providing the same guarantees as KPTI with lower overhead.
+
+	   This option enables E0PD where available.
+
+endmenu
+
 config ARM64_SVE
 	bool "ARM Scalable Vector Extension support"
 	default y
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index f19fe4b9acc4..f25388981075 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -52,7 +52,8 @@
 #define ARM64_HAS_IRQ_PRIO_MASKING		42
 #define ARM64_HAS_DCPODP			43
 #define ARM64_WORKAROUND_1463225		44
+#define ARM64_HAS_E0PD				45
 
-#define ARM64_NCAPS				45
+#define ARM64_NCAPS				46
 
 #endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h
index e2f8c6b09717..195a01156460 100644
--- a/arch/arm64/include/asm/pgtable-hwdef.h
+++ b/arch/arm64/include/asm/pgtable-hwdef.h
@@ -294,6 +294,8 @@
 #define TCR_HD			(UL(1) << 40)
 #define TCR_NFD0		(UL(1) << 53)
 #define TCR_NFD1		(UL(1) << 54)
+#define TCR_E0PD0		(UL(1) << 55)
+#define TCR_E0PD1		(UL(1) << 56)
 
 /*
  * TTBR.
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index b069b673494f..2f3672c186dc 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -650,6 +650,7 @@
 #define ID_AA64MMFR1_VMIDBITS_16	2
 
 /* id_aa64mmfr2 */
+#define ID_AA64MMFR2_E0PD_SHIFT		60
 #define ID_AA64MMFR2_FWB_SHIFT		40
 #define ID_AA64MMFR2_AT_SHIFT		32
 #define ID_AA64MMFR2_LVA_SHIFT		16
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index f29f36a65175..676ec3db35a3 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -211,6 +211,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_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_E0PD_SHIFT, 4, 0),
 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_FWB_SHIFT, 4, 0),
 	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_AT_SHIFT, 4, 0),
 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_LVA_SHIFT, 4, 0),
@@ -1232,6 +1233,13 @@ static void cpu_enable_address_auth(struct arm64_cpu_capabilities const *cap)
 }
 #endif /* CONFIG_ARM64_PTR_AUTH */
 
+#ifdef CONFIG_ARM64_E0PD
+static void cpu_enable_e0pd(struct arm64_cpu_capabilities const *cap)
+{
+	sysreg_clear_set(tcr_el1, 0, TCR_E0PD1);
+}
+#endif /* CONFIG_ARM64_E0PD */
+
 #ifdef CONFIG_ARM64_PSEUDO_NMI
 static bool enable_pseudo_nmi;
 
@@ -1547,6 +1555,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,
+		.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

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

[Will Deacon]

On Thu, Jun 27, 2019 at 03:15:32PM +0100, Mark Brown wrote:
> Kernel Page Table Isolation (KPTI) is used to mitigate some speculation
> based security issues by ensuring that the kernel is not mapped when
> userspace is running but this approach is expensive and is incompatible
> with SPE.  E0PD, introduced in the ARMv8.5 extensions, provides an
> alternative to this which ensures that accesses from userspace to the
> kernel's half of the memory map to always fault with constant time,
> preventing timing attacks without requiring constant unmapping and
> remapping or preventing legitimate accesses.
> 
> This initial patch does not yet integrate with KPTI, a followup patch
> will ensure that by default we don't use KPTI on CPUs where E0PD is
> present which will provide a much greater benefit in general
> configurations.
> 
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
> 
>  - Reword commit message
>  - Change to detection as ARM64_CPUCAP_WEAK_LOCAL_CPU_FEATURE.

Thanks for the quick v2, although I still don't see the rush to merge this
without the associated kaslr/kpti changes we've been discussing. It's not
like there's a whole load of 8.5 silicon we're rushing to support.

Will

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

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

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 609 bytes --]

On Fri, Jun 28, 2019 at 12:04:30PM +0100, Will Deacon wrote:

> Thanks for the quick v2, although I still don't see the rush to merge this
> without the associated kaslr/kpti changes we've been discussing. It's not
> like there's a whole load of 8.5 silicon we're rushing to support.

It's largely on the general theory that it's better to carry less out of
tree code - there's less diff to manage, less chance of collisions with
other work (in either direction), and less pending review to worry about.
So long as something represents forward progress I tend to work on the
basis of why not rather than why.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

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

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

[Catalin Marinas]

On Fri, Jun 28, 2019 at 01:30:40PM +0100, Mark Brown wrote:
> On Fri, Jun 28, 2019 at 12:04:30PM +0100, Will Deacon wrote:
> > Thanks for the quick v2, although I still don't see the rush to merge this
> > without the associated kaslr/kpti changes we've been discussing. It's not
> > like there's a whole load of 8.5 silicon we're rushing to support.
> 
> It's largely on the general theory that it's better to carry less out of
> tree code - there's less diff to manage, less chance of collisions with
> other work (in either direction), and less pending review to worry about.
> So long as something represents forward progress I tend to work on the
> basis of why not rather than why.

A reason is that once we add the support for disabling kpti based on
the E0PD feature, this patch may turn out to be slightly different (for
example, you may add a common has_e0pd() check that is called from
both unmap_kernel_at_el0() and the E0PD arm64_features[] entry). Given
that both patches would be relatively small, I agree with Will that
there is no rush to merge them independently.

-- 
Catalin

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

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

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1165 bytes --]

On Fri, Jun 28, 2019 at 05:36:42PM +0100, Catalin Marinas wrote:
> On Fri, Jun 28, 2019 at 01:30:40PM +0100, Mark Brown wrote:

> > It's largely on the general theory that it's better to carry less out of
> > tree code - there's less diff to manage, less chance of collisions with
> > other work (in either direction), and less pending review to worry about.
> > So long as something represents forward progress I tend to work on the
> > basis of why not rather than why.

> A reason is that once we add the support for disabling kpti based on
> the E0PD feature, this patch may turn out to be slightly different (for
> example, you may add a common has_e0pd() check that is called from
> both unmap_kernel_at_el0() and the E0PD arm64_features[] entry). Given

Hrm, I don't really get that - incremental patches can always be done
(indeed they're often really helpful for people trying to understand how
the code got to be the way it is).  Obviously you can go too far in the
other direction as well, a middle ground is generally best.

> that both patches would be relatively small, I agree with Will that
> there is no rush to merge them independently.

I guess.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

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

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

[Catalin Marinas]

Hi Mark,

On Fri, Jun 28, 2019 at 06:39:20PM +0100, Mark Brown wrote:
> On Fri, Jun 28, 2019 at 05:36:42PM +0100, Catalin Marinas wrote:
> > On Fri, Jun 28, 2019 at 01:30:40PM +0100, Mark Brown wrote:
> 
> > > It's largely on the general theory that it's better to carry less out of
> > > tree code - there's less diff to manage, less chance of collisions with
> > > other work (in either direction), and less pending review to worry about.
> > > So long as something represents forward progress I tend to work on the
> > > basis of why not rather than why.
> 
> > A reason is that once we add the support for disabling kpti based on
> > the E0PD feature, this patch may turn out to be slightly different (for
> > example, you may add a common has_e0pd() check that is called from
> > both unmap_kernel_at_el0() and the E0PD arm64_features[] entry). Given
> 
> Hrm, I don't really get that - incremental patches can always be done
> (indeed they're often really helpful for people trying to understand how
> the code got to be the way it is).

Sorry, I wasn't clear enough. I'm perfectly fine to incremental patches
and encourage them as part of a series achieving an end goal. Here the
end goal (and the reason behind this architecture feature) is to be able
to safely disable KPTI in favour of a hardware-based mitigation. Your
one-patch series does not achieve this yet, so I suggest we don't merge
this until we have the other part of the series.

-- 
Catalin

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